>> This is something Microsoft has always historically not seemed to
>> understand.
>
> Well, in defense of my friend at Microsoft, he was in the consulting
> organisation, and they ordered *15,000* laptops from a particular
> manufacturer just for their consultants.
>
> It's hard to understand why people have trouble affording a single hard
> drive when you buy in such bulk quantities.

Yeah, I guess that's what it comes down to.

> But he's a funny guy - actually quite cynical about the tech industry as
> a whole.  He's called the whole thing a 'scam' for years.

He's right...

(And I don't just mean Windows, or Linux. I mean the entire software 
industry.)

>> I understand /why/ this happens. It's just frustrating, is all. I don't
>> see why I should need to install Samba. Why can't I just install, you
>> know, the GTK+ widgets? It seems to me that Linux dependency chains are
>> just /way/ too coarse.
>
> That's because you've never spent time looking at those interdependencies.
>
> After all, on Windows, you have CIFS/SMB available on all systems by
> default.  You take it for granted on Windows, but for the rest of the
> world, there is a choice.

I still don't see why it's necessary to install a network protocl just 
to run a text editor.

>> OK, that's astonishing. Every attempt I've never made at upgrading an
>> existing Linux install from one distro release to another has /always/
>> ended in massive breakage, usually to the point that when I boot the
>> system the kernel just panics and stops. You would have thought clicking
>> "upgrade now" and waiting for the progress bar to finish would work, but
>> noooo...
>
> I've upgraded openSUSE from 11.0->11.1->11.2->11.4 (I gave 11.3 a miss).

Me and my dad tried updating OpenSUSE one time. After several days of 
hell, we decided never to attempt this ever again.

> The worst upgrade hell I've ever heard of, though, was MS' own corporate
> upgrade from Windows Server 2000 to Windows Server 2003.  I was told they
> upgraded to each incremental pre-release alpha, beta, and release
> candidate on several of their internal servers.  It was a nightmare, and
> the basis of their recommendation to do rip-and-replace upgrades rather
> than in-place upgrades.

Uh, yeah. Updating Windows in-place isn't something I'd recommend 
*either*...

>> Really, I'd just be happier if I could install just the functionallity
>> that's strictly necessary, rather than installing everything even
>> remotely related. Linux package manages seem to do a really poor job of
>> dependency management. (Don't get me started on when one random program
>> decides it wants a different version of the Linux kernel or
>> something...)
>
> Programs usually don't care about the kernel version, unless they're
> kernel modules (or provide them).

Or use features that are built into the kernel. (Stuff like 
cryptographic primitives, sound support, file change monitoring...)

> RPM does a pretty good job of dependency management

Well, some distros use RPM, some use .deb, some use something else 
entirely. I've yet to see a package manager where it's entirely clear 
what the heck is going on, or why selecting one small application 
requires a 2GB download.

> but you have to take care not to add too many repositories

I don't even know how to do that.

> But, in true Linux fashion, you'll get to choose the 2 remaining
> fingers. ;)

LOL.

>> Still, the problem escalates to a whole new level if you try to install
>> something /not/ available from your distro's package manager. Everybody
>> raves about how great it is that you can install everything from a big
>> old list. But you can't, of course. There will be packages that aren't
>> in the list.
>
> Actually, with openSUSE's Open Build Service, you can.

That's a nice idea. I can't comment on whether it works or not (given 
tha I've never heard of it before). I guess it doesn't help if you have 
time pressure - but hey, it's free...

>> Under Windows, if you want to install something, you just download it
>> and install it. Under Linux, you probably have to download a tarball,
>> work out how to unzip and untar it, figure out where the "install me
>> now" script is, and then watch as it directs you to install a different
>> version of gcc, asks where the kernel header files are, tries to
>> auto-detect the stuff it needs... It almost never works.
>
> Certainly if you don't know what you're doing, it almost never works.  If
> you know what you're doing, then it almost never fails (and when it does,
> it's usually a dependency version issue or a bug in the code that
> prevents the compile from happening).

Last time I tried this with VMware tools, it went something like this:
- Where are the kernel headers?
- No, the headers for the *running* kernel?
- OK, now install gcc please.
- No, the version of gcc that the kernel was compiled with.
At that point, I discovered that the version of gcc in question isn't 
available for this release of Ubuntu. WTF?

>> To the point
>> where which Linux I use on my VM depends mostly on which one has VMware
>> driver packages provided.
>
> VMware provides their own tools, but there are free (as in OSS) tools as
> well.  ISTR they're included with openSUSE, in fact.

Yeah, I tried several distros, and some of them just had no VMware 
support at all, some of them you could install packages for VMware as an 
option [not that it explains WTF each package does], and some of them 
automatically installed a bunch of VMware stuff without me even asking. 
It's as if the software somehow "knows" it's running in a VM...

VMware Tools comes with a script that's supposed to compile and install 
the necessary kernel modules, but I have never, ever seen it work. It 
always fails. Not that I blame them; there are such radical differences 
between distros that targetting all of them looks like a hopelessly 
difficult task.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message