there_is_no_spoon

Beer28 wrote:

I'm going to dispute Bill's final statement about RPMs in this segment.

RPM will not allow you to install a package that breaks another package(.so bin libs, app binaries, or otherwise), it just won't. Unless the RPM has been mispackaged in it's dependancy list. OR unless you --nodeps it, or --force it.

My point was not that it breaks a package, but that it can (and frequently does) generate a variety of RPM dependency errors, reported back by 'rpm', that need to be resolved before the package can successfully install.  My point in this segment is chasing down these dependencies can take time.

Beer28 wrote:

All those latter cases are big no-no's unless you absolutely know what you're doing.

I've managed many Linux admins over the past decade and unfortunately using rpm '--force' or '--nodeps' happens much more frequently than you might think.

Beer28 wrote:

When you do update with an RPM updater such as yum, up2date or urpmi, the updater program will scan all the headers from the repositories that are listed in the sources file to try to fill the chain of depdancies for the update, and will solve the RPM's that need to be upgraded or installed before your target package(s) is.

If the dependancies are not all found in the source headers from the repo's it will NOT install by default to break any system applications you have on the machine.

The difference is that these dependency errors need to be chased down by the user.  My point in this segment (and in the other blog reply) was that we do a tremendous amount of work in testing and in servicing so that our customers don't need to chase these types of low level errors when doing an update or install.

Again, just differences in how we service our software - not a good or bad judgement call.  -Bill

Beer28 wrote:

up2date systray icon in Gnome. So here we go, up2date, yum, urpmi

You don't know much about linux or rpm or package updaters do you?
We have the equivalent of windows update.

But you are missing a key concept here in the model differences, which is the amount of formal, methodical and deep testing (backwards and upwards) that goes into how Microsoft validates and releases an update and how an update is released via any of the technologies you list above. -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

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