Posted by The Channel 9 Team // Tue, Aug 23, 2005 12:32 PM
Charles Torre sits down with Martin Taylor and Bill Hilf and chats about Linux, Windows and Microsoft.
Martin Taylor is Microsoft's General Manager of Competitive Strategy. He's the guy that's been known to wear bullet proof vests at Linux conferences and reaches out to the Linux/OSS community by throwing himself into the SlashDot fire. Remember that phone interview?
Bill Hilf is a Linux developer and Microsoft Technical Director of Platform Strategy. He runs a really nifty lab where his team of Linux hackers explore the world of distros and compare Windows technologies with Linux technologies. You'll see the lab in the second part of the interview.
Also, Charles didn't forget about your questions. Niners get some well-deserved love in Part II
Enjoy.
Download Size: 88 MB
|
| Clip Length: 00:23:25
|
|
Replies:
55
// Views:
41,780
|
 |
|
|
 |
Beer28
I contend Channel9 is a covert research project
|
|
|
I'm downloading this right now, I've been waiting to see this. I will
of course play this on mplayer from mplayerhq.hu with the not so legit
asf decoder.
I'm glad it's finally up at any rate. I'll be back to comment after viewing.
|
Beer, this one's for you! :-)
|
|
Beer28
I contend Channel9 is a covert research project
|
|
|
I heard my screen name mentioned.
Maybe these guys, M. Taylor and Bill would benifit from a little visit to linuxbase.org
. I noticed them describing linux as just a kernel, which is correct,
then describing possible inconsistencies on top of that with different
distributions.
Also they were describing how windows has the graphical layer fused
into it with GDI.lib/Windows Messaging instead of having an Xserver layer with a window
manager. Then they went on to describe how the lack of the gdi.lib and
windows.h layer hinders user applications in respect to using Xlib and
the networked X Protocol, what will soon be XCB.
I found it a little strange that they didn't elaborate and say why this
is. I think Win 9.X and ME ran with DOS7.X in the background also.
So how is fusing GDI, windows graphical messaging into the kernel and
shell so much better than Xlib and a networked graphical protocol in
XProtocol and soon XCB?
I've coded both and I don't see a significant advantage. XProtcol is
nice, because it's inheritly ready for TCP where as Windows messaging
is not. They are both message or event based with a loop to dispatch
drawing or paint messages.
So I feel that they really could have elaborated there instead of just
implying that Windows GDI is so much better "because". One is network
ready in XProtocol, and one is not in the windows messaging system.
X is nice because it is a seperate layer, and if another company wants
to come in with another graphical server to handle the video card they
can. Also it allows for multiple vendors to come in with window mangers
on top of X like KDE, Gnome and Sun's JDesktop and Looking glass. MS
windows will not allow a cool idea to come and kick them to the side on
that layer. Most likely very purposely, because it would facilitate
users to move to another system. So they supress anything that could be
a better graphical environment than their own.
I'm almost done watching.
|
|
Beer28
I contend Channel9 is a covert research project
|
|
|
OK, now Martin is talking about inconsistencies with upgrading
software, when a certain package relies on it. RPM actually prevents
you from breaking ANY rpm installed software, unless you --force or
--nodeps the installation, which you really shouldn't and which a
newbie simply would not know how to do.
So most linux software is packaged in rpm's, esp for a big distro like
redhat or fedora, but also for Mandrake, SuSE and most other distros.
RPM The redhat package manager is the standard installer specified by
the Linux Standard Base, which
provides a specification for making applications that work on any
distro that adheres to it. Most of the major consumer linux distros do.
|
|
Beer28
I contend Channel9 is a covert research project
|
|
|
As for the different widget kits, Gnome is probably the biggest with
it's extensions into multiple languages like GTKmm, pyGTK, Java GTK,
GTK+, GTK# and other wrappers like those for perl.
What wasn't said is that a GTK application, no matter the interface
will work seemlessly on a KDE desktop, as long as the library is there,
and that Xorg is pretty standardized now adays for the linux X server.
So no matter the desktop, even looking glass, you can run Gnome
applications seemlessly, or even KDE apps, because the middle layer
libraries for KDE and Gnome both depend on the same Xlib backend.
So there is no problem as they described.
When you package an RPM, just as when you package a windows installer,
you can list dependancies, why this is important, is now with an RPM,
if a user is missing X or Y library before they can run your app, and
you have them put your repository in their yum.conf of the rh sources
file, They can now just type up2date thisapp, and it will autolocate
and install all dependant packages, or they can use yum or urpmi, the
same.
So in this way RPM fills dependancies and solves problems between your
app and the system backend required for it to run. This is actually a
much more advanced system than is available on windows to fill
dependancies for appliciations. 100 windows apps may ship the same .dll
file like mfc42.dll because Windows can not autofill dependancies the
same way. It can with .inf files with a hook to a download, but
nobody's going to use that as their windows installer.
|
In all fairness to Martin and Bill, I felt that they were doing
more explination of differences than touting Windows as vastly superior
in all respects.
|
|
Beer28
I contend Channel9 is a covert research project
|
|
|
 | Larsenal wrote:
In all fairness to Martin and Bill, I felt that they were doing
more explination of differences than touting Windows as vastly superior
in all respects.
|
<?>Yeah, well, if you want to do your own kernel patches, and
maintain the patches forever, then um.... linux is for you. So it's the
best tool for the job....</?>
Nevermind submitting the patch to kernel.org or posting it on a group
so it's implemented in the main tree. Nevermind the fact that 99% of
people who use linux don't write kernel patches.
I mean if you're using the kernel core for a lawn mower or a garage
door opener or some other commercial application for hardware that a
company is going to sell, and you don't feel like paying for WinCE,
THEN you have to maintain the kernel you made by yourself.
Other than that, you'll probably never have to patch the kernel, unless
you want to implement your own syscalls or what not, and that's not in
the norm for most linux users.
|
 |
rasx
Programmer/Analyst III, Emperor of String.Empty
|
|
|
Traditionally, Microsoft is the superior 'personal' or
small-scale data management company. This is not very sexy superiority
because most people are relatively sloppy with their small-scale data
management. (And this includes large corporations on the department
level.) What Microsoft should do is to try to make this stuff more
sexy---promote the concept instead of products. This is much harder
than making an iPod look sexy.
Over the last few years, Microsoft stock is like an index of technology
stocks: it is investing in everything technology money can
buy---including tera-byte-level, big-iron data management. In spite of
all this large-scale stuff, I still think that Microsoft is the
superior small-scale data management company. Did I miss a television
commercial?
MySQL and OpenOffice.org face years of lagging behind the luxuries we
enjoy with SQL Server, .NET and the Office System. However, I use MySQL
almost every day using .NET assemblies to feed it data from SQL Server.
Why? Because I run a Web site through a Web host that uses MySQL,
Apache and Linux. Why do I use this Web host? Because
Microsoft-equivalent tools have only recently started to match the
convenience of MySQL, Apache and Linux (it's all about remote
administration).
So my point is that I use proprietary and open source tools every day
with one eye on the proprietary people trying to lock me into one less
area of interoperability---in spite of using open standards
(WordProeccingML comes to mind here).
|
| Beer28 wrote:
Yeah, well, if you want to do your own kernel patches, and
maintain the patches forever, then um.... linux is for you. So it's the
best tool for the job...
|
You see, Beer, you've got your if-then conditional in there just like they did. (I'm only kidding.)
Instead of talking Linux vs. Windows, how about some thoughts on their
ideas of embracing the benefits of the open source movement. I
thought they made a good point that a major benefit of open source is
the community it has around it. Maybe it's not as much about
being able to see/use the source code as it is about having an active
community of users and devs provide input and ingenuity during the
development lifecycle.
|
Hey Beer28, Bill Hilf here - thanks for all the comments.
Maybe I came off a little unclear, my point was not to infer that one is better than another, rather I was trying to explain some fundamental architectural differences between a Windows OS and a Linux OS - the separation of the X server, window manager and OS is one of the key examples of this difference. There are pros and cons with these implementations of a graphical system (as well as to other graphical systems such as MacOS, and many others historically). It's largely dependent on what works best for the problem you are trying to solve.
We think Windows provides a strong story here because there is a rich environment to develop against, with consistent and predictable support across a large amount of pcs and devices.
Keep your comments coming - also, check out the part II where we go into some further detail on the work in my lab. -Bill
|
As the saying goes - "You're soaking in it!"
Channel9 is a great example of this. You should also check out http://www.microsoft.com/resources/sharedsource/default.mspx
We are active in - and continue to develop - ideas around community.
Let me ask you: what are the key characteristics of a community development project that you find appealing? -Bill
|
|
Beer28
I contend Channel9 is a covert research project
|
|
|
| there_is_no_spoon wrote:
Let me ask you: what are the key characteristics of a community development project that you find appealing? -Bill |
I am a partner volunteer developer on the looking glass project
incubator, and though I stopped actively participating a few months
ago, I'm just now starting to get back on the project.
I like the fact that I can put my Sun username and password into CVS
and log on and download all the Sun projects and work on LG incubator
with CVS write permissions without being a big company or what not that
has shared source access. As a matter of fact anybody can CVS LGlass,
Gnome or KDE and work on it and submit mods. For sourceforge projects you don't need a Sun user/pass for CVS.
I don't like visual source safe and the microsoft source sharing
system, compared to CVS. CVS is easy to use and works in alot of open
source tools as their integrated source manager for projects, like
Eclipse CDT, netbeans, ActiveState Komodo and so forth.
So I haven't yet come across a MS page that shows you how to sync your IDE with Longhorn and build it.
CLICK for real size
so as you can see here, I can load Looking glass window manager in
netbeans and hack it and recompile and test run it. I can also do the
same with Gnome CVS in eclipse CDT which also has CVS integration. I will
be doing that soon as well.
So open source is nice, because you can put the CVS project into
Eclipse CDT for C++ or netbeans for Java or Perl or php with komodo pro
and work on the OSS project with the comfort of a GUI.
So I own a license for Visual C++6. So where can I point Source Safe to
download and sync the daily Longhorn build and build my own hacks into
it?
I don't like some of aero, and I would like to try some things out and
do my own build. For instance I don't like the fact that DX on windows
requires all 3d to be windowed. So I would like to attempt to hack that
and remake the touched files once the main build is done.
CVS projects like this don't only work for window managers, they work
for any type of project, like those on sourceforge, which can range
from a system tray widget to a word processor. So that is very
convienient. There are no forms to sign, no NDA's. No fuss, no frills,
no legal worries, and I can reuse the Linux and or open source code
freely as long as I abide by GPL, which means I can resell other
people's code including my own for as much as I want.
This is part of the appeal of community development using CVS which
along with subversion is the prefered sharing method for community
projects.
EDIT: Setting up CVS on the server and client side are both free and come standard with most linux distros, ditto on subversion.
|
| Beer28 wrote:
...
...
stuff
...
...
|
Translation:
Beer wants it to be open source.
|
|
Beer28
I contend Channel9 is a covert research project
|
|
|
| pikatung wrote:
| Beer28 wrote:
...
...
stuff
...
...
|
Translation:
Beer wants it to be open source. |
that's wrong. I have so much I can do with LG3d and Gnome and apache,
and all the stuff I'm currently doing on linux with the desktop and
server, I really don't care about Longhorn being opened on CVS. I think
it would be cool for other people to be able to hack it to their liking
though and be creative.
I only wrote that I wanted to change DX to support non-windowed desktop
apps to be a pain, I really don't care if it does or doesn't.
There is a whole universe of stuff to do on linux and a whole eco
system of applications and frameworks that surround the OS, that I am
thorougly satisfied only doing legacy work on my old VC++6 apps for
windows from now on.
I do think it would really be cool for windows users though to be able
to have the same grain of control that I have on linux. That would be
good for them.
|
| Beer28 wrote:
that's wrong.
|
Then why write about 9 paragraphs over essentially that? You obviously care to *some* degree.
|
|
Beer28
I contend Channel9 is a covert research project
|
|
|
I was stating that I like linux because I can hack the source and
submit improvements on builds to the authors so if it's good enough
they can put it in the main tree.
Or work on an open looking glass incubator project.
I only really made one statement about hacking a feature of longhorn
and it was more just to accentuate the fact that you can't unless you
work for microsoft.
I may have wanted to hack features of windows for real about a year or
2 ago, but I don't care anymore. I was simply arguing a different point
of view.
|
Keep on hacking! 
|
| Larsenal wrote:
In all fairness to Martin and Bill, I felt that they were doing
more explination of differences than touting Windows as vastly superior
in all respects.
|
You just have to understand you arent going to make everyone happy and
Beer28 happens to be one of them. I have coded for both
systems and I happen to think compared to Linux, Windows wins, as a
platform and as a development environment. Of course I do have to
keep Java around some, have to support those Legacy applications.
|
| Beer28 wrote:
I was stating that I like linux because I can hack the source and
submit improvements on builds to the authors so if it's good enough
they can put it in the main tree.
|
I have submitted 48 kernel patches to the kernel.org team in my time,
you know how many got worked into the main tree? NONE, 0 and do you
want to know why? They have their own friends and colleagues that they
use their stuff. Joe Blow, rjdohnert and beer28 unless we are on
the A-List none of our patches get in. I asked on the kernel.org
mailing list way back, how to get my patches into a mainstream Linux
distribution. I was told to start my own distribution. Its
like Apple, only committers get patches in, everyone else = 2
bad. I was told Apple only used 2% of user submitted OpenDarwin code in
10.4, my guess is that a commiter took it, probably credited himself and got it in. So much for community efforts.
|
|
Beer28
I contend Channel9 is a covert research project
|
|
|
That's odd, in revolution os, Linus states that he looks to the
community and newsgroups for possible bug fixes and or improvements to
the kernel.
I can imagine the kernel is a very touchy component to take submissions
from outsiders on. I can imagine a patch to gnome inbox monitor would
be alot easier to get added than a kernel patch, for instance.
OK, with that said, I'm almost through reading Robert Love's book,
linux kernel development and I'm half way familiar with the kernel. I'm
wondering, what did you change and on what version?
Did you add syscalls or was it something with the driver interface or did you do bug fixes?
I submitted a bug to bugzilla tonight on RH, so I've submitted a few,
but I have yet to contribute major code to any of the larger projects
except for being on incubator for looking glass, so this is interesting
to me. I plan to submit a good deal of Gnome CVS code soon, and I hope
at least a couple things are accepted.
|
It's important to realize that kernel-level code is significantly different than application or user level code.
The kernel of an operating system like Red Hat or Windows XP is primarily a software interface to hardware; a software-based machine virtualizer.
Everything that happens on your PC, for example, does so either directly or indirectly through the kernel.
As you would infer from such a proclamation, this means the kernel must be as efficient, stable, performant, secure, reliable, predictable as humanly possible. It follows that you will want to restrict the number of humans writing the kernel of an operating system to a select group of highly skilled (and narrowly focused) software engineers who are very well-versed in both the art of machine level programming and the craftmanship of enabling a machine to be programmable.
C
|
|
Beer28
I contend Channel9 is a covert research project
|
|
|
| Charles wrote:
It's important to realize that kernel-level
code is significantly different than application or user level
code.
The kernel of an operating system like Red Hat or
Windows XP is primarily a software interface to hardware; a
software-based machine virtualizer.
Everything that happens on your PC, for example, does so either directly or indirectly through the kernel.
As
you would infer from such a proclamation, this means the kernel must be
as efficient, stable, performant, secure, reliable, predictable as
humanly possible. It follows that you will want to restrict
the number of humans writing the kernel of an operating system to a
select group of highly skilled (and narrowly focused) software
engineers who are very well-versed in both the art of machine
level programming and the craftmanship of enabling a
machine to be programmable.
C |
Not necessarily Charles, not on linux anyway.
Remember the signal.c bug in the kernel last year anybody? (you could crash the kernel with userspace C script)
I didn't think you would so here's a link
http://linuxreviews.org/news/2004/06/11_kernel_crash/
<quote>The flaw was by accident discovered by Stian Skjelstad when he was
doing some code tests while on vacation. He was quite surprised when he
discovered that the code he was trying froze his machine. He reported
it to the Linux-kernel mailing list and the gcc bugzilla 2004-06-09.</quote>
Because the linux kernel is open source, and because you can mess with
it without being a corporate hire, it means tons and tons of
individuals like myself are reading books about it and learning about
it, and rebuilding it with whatever new calls or code "just to see what
happens". This sometimes leads to finding bugs by accident, and once
you do, you'll want that credit, so the first thing a person does after
calming down from their nervous panic, is post it on the mailing list
or newsgroup.
From there, if it's confirmed, like this signal.c bug was last year,
the core kernel team has no choice but to patch it or look like a bunch
of stupid arses for not fixing it.
So instead of 1 pair of eyes on the code, you effectively have the
entire world's eyes on the code, which I think is better. The kernel is
open to the public, and always has been and you can hack it and try
different things, and try to break it on your own, with no microsoft
badge required.
As far as non-bug fixes, I can imagine it's harder to get them added to
the tree, but for finding bugs, they really have no choice but to look
at what the public finds if it's confirmed by a few people that try it.
That's some of the real power of open source.
|
 |
Sk4rlath
The lesser of two Sampys (in age only).
|
|
|
| Beer28 wrote:
...some great stuff about open source...
That's some of the real power of open source.
|
(Note: the author of this post has no idea what really happened in regards to the kernel bug fix story and is merely using your example to show his point. Please don't bash me into the ground with mighty semantic issues.)
You're absolutely right. With the power of open source, a major bug was found and fixed!
The story doesn't end there.
So the kernel team fixed the bug. What happens now? How does the bug really get fixed? How does it propagate to every server and desktop out there? Is there an update system in place? What about for this distro over here? What about the guy who hasn't patched since 3 minor versions ago since the new kernel 'broke his box that one time'? Are you just going to rely on the maintainers of all those distros to update and then get the updates to their users? Are you also going to rely on sysadmins to go out and read the news and see that there's a new patch they need to apply and spend the next week figuring out why their 15 year old app now barfs on the new kernel? Seems like a mighty big buck you're passing around there.
The way I see it, that's the big difference between closed source and open source. Open source is pretty much all do-it-yourself. Some people have made kits, but you still gotta get your hands dirty and mangle the kit into your workspace and remember what manglings you did to get it there (which can be pretty fun if you're not in a hurry or in a bad mood). But with closed source there's a company to take care of all that for you. If something isn't working, They have to fix it for you since you gave them money for their software (despite how it often happens in the real world, that's the general idea). But then again, you have to wait for them to do it. You don't have the code so you can't do it yourself. Then there's companies that bridge this gap and maintain open source things and make money only on support, but it's late and I don't quite feel like typing much more.
Yes, the fact that 'millions of eyes are looking over the code' does mean that more bugs get caught and fixed. But I think the open source community still has a long way to go in terms of doing all the other work needed after you hit compile, run your tests, and check in for the night.
I'm not saying that Microsoft is the ultimate example of exemplary coding and bugfix deployment technology (though Windows Update is very nice) either.
And waaaaay back a bunch of posts, you said something about how X had network support and Windows Messaging didn't and you seemed to imply that it was sort of a handicap of Windows Messaging. Well, correct me if I'm horribly wrong, but doesn't X transfer screen bits across the wire? Isn't that a little slow? And doesn't having this feature built-in tempt users to just use it instead of doing it the harder way and getting better performance? Just a thought - both ways have their advantages and disadvantages.
|
|
|