On Sat, 08 Oct 2011 13:18:14 +0100, Orchid XP v8 wrote:

> On 08/10/2011 01:05 PM, Jim Henderson wrote:
>> On Sat, 08 Oct 2011 12:53:41 +0100, Orchid XP v8 wrote:
>>
>>> "Windows" is a product. You install it, or you don't install it. And
>>> that's about all there is to it.
>>>
>>> "Linux" is a huge soup of different applications and programs written
>>> by hundreds of people over the course of several decades. There are so
>>> many features and options. There are a dozen different ways to
>>> accomplish every task. And every user-level program will use a
>>> different one of those subsystems, so you have to redundantly install
>>> and configure almost all of them.
>>
>> Well, technically, "Linux" is the kernel.  GNU/Linux is the system, and
>> a distribution is GNU/Linux + applications.
> 
> Strictly speaking, that is of course true. However, that's not what is
> usually meant in common usage.

And, truth be told, most of the preconfiguration that's done during 
installation is sufficient for the majority of users.  So no, no need to 
configure "all of them".

>>> See, to some of us "a hundred bucks" is actually quite a lot of money.
>>
>> Well, yes, and that was my point to my friend.
> 
> 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.

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.

>>> Of course, it was just an example. It doesn't really matter which
>>> program you're talking about; if you have KDE and want to run a GNOME
>>> application (or vice versa), you're going to have to install two
>>> entire WMs, even though you only ever use one of them.
>>
>> If you install a GNOME application, you're using the GNOME libraries (a
>> key part of the window manager) and GTK+ widgets.
> 
> 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've never had software break my PC so badly that reinstalling was the
>>> only way to get it to work again.
>>
>> Same here with Linux.  In fact, upgrading my laptop to openSUSE 12.1
>> beta 1 right now.  My choice, and I may take it back to 11.4 as I need
>> it working on Tuesday-Friday next week.
> 
> 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).  
This upgrade I'm running now is a beta, so I expected problems.  And I 
got them, the upgrade failed and gave me the very helpful error message 
"An error occurred during the upgrade".  Nice.  That's getting reported.

Booted the system and GRUB thinks it's still 11.4 (as the grub update 
didn't apparently run) and there were a few hundred packages still to 
update.  Not sure why it failed, and the log went when I rebooted it.

So, booted the system manually, replaced the repos with the proper repos, 
and am doing a "zypper dup" to upgrade it.

Fortunately, I backed up the old partitions with partimage, so I can 
restore them if necessary.

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.

>>>> It seems you'd be happier with statically linked executables.
>>>
>>> Well, that way you would only be downloading the libraries that the
>>> problem actually /uses/...
>>
>> Well, no, you wouldn't be, because they'd be in the actual program. 
>> But then you get into poor code reuse and duplication of shareable
>> code, which eats up disk space.
> 
> Yeah, there's a down-side too.

There are always tradeoffs.

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

RPM does a pretty good job of dependency management, but you have to take 
care not to add too many repositories, and don't mix and match repo 
versions.  That'll break things quite quickly.

For openSUSE, it's generally recommended you have 4 repos and no more:

1.  OSS
2.  Non-OSS
3.  Update
4.  Packman

And that's it.  Anything more and - if you're inexperienced - you'll end 
up shooting yourself in the foot, and probably take the other foot off 
for good measure along with 3 fingers on your left hand.

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

> 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.  If you don't find 
something you need and it's OSS, ask in the forums if someone can build 
it - if it isn't already there under someone's home project in OBS, 
there's a guy on staff (malcolmlewis) who has been happy to get the 
package built.

Oh, and OBS?  Builds packages not just for openSUSE.  It can build for 
RedHat, Fedora, Debian, Ubuntu, and a few others.

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

Again, OBS solves this problem for a lot of distros, not just openSUSE.  
It even builds the packages for you on a server farm located "out there" 
somewhere.  Multiple architectures, too.  It's pretty slick.

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

Jim

Post a reply to this message