On Sat, 08 Oct 2011 14:44:07 +0100, Orchid XP v8 wrote:

>>> 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.

That's probably a significant part of it.

>> 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.)

He didn't mean just Windows or Linux either.  And he's been around the 
software industry for longer than either of us.

>>> 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.

That's because you're not grokking the similarities between Windows and 
Linux.

Seriously.

Try installing Notepad on Windows without installing Windows Networking.

Oh, you can't do that.  Why?  Because Windows Networking is an integrated 
component of the operating system.

Guess what - it's also an integrated component of GNOME, because 
interoperability matters.

>>> 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.

It's a shame you didn't come over to the forums and ask for some help.

>> 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*...

I generally wouldn't recommend it for any OS, but it can be a bit easier 
with Linux if your /home partition is separate from the rest of the 
system.  Worst case, you do a fresh install of the root partition and 
leave the /home data alone.

>>> 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...)

Depends on the ABI in question.  Many of them are fairly stable, but some 
are not.

>> 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.

Well, again, it comes down to understanding the interdependencies, rather 
than throwing your hands up in the air and saying "it's too damned 
complex for anyone to understand."

>> but you have to take care not to add too many repositories
> 
> I don't even know how to do that.

In openSUSE:

sudo yast2 repositories

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

I figured some humour was called for. :)

>>> 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...

It's free, and you can be damned sure it works.  It's been out there for 
a few years.

>>> 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?

I can't speak to Ubuntu.  openSUSE has a pretty strict "no kernel 
upgrades" policy within a particular version.  (That doesn't mean "no 
updates" - security updates are backported by the openSUSE kernel team, 
and important enhancements frequently are as well AFAIK).  That means 
it's incredibly rare to have to deal with something like that with VMware 
once it's working.

>>> 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.

I've seen it fail, but I've seen it succeed more often than not.

It's a shame you don't ask questions in the Linux forums related to the 
distribution you use.  Those issues are often easily resolved, and 
novices can get help instead of just bitching "this damned stuff never 
works right!"

Jim

Post a reply to this message