A major obstacle facing widespread Linux adoption... And a proposal.

Gullible Jones · 2010-08-16 03:31:33

Updates.

No, this isn't a troll. Or a joke.

Some of you might know of the Linux Haters blog. I'm not sure who the author is, but he clearly has even less of a life than us Linux enthusiasts, given the amount of time his spends bashing both Linux and its users. However, I've seen him make one valid point, and that's this: on Linux, you can't update an application without updating the whole OS. And though there are clearly exceptions, for the most part that's true; if you keep updating one app but avoid library updates, the app will eventually break.

This doesn't happen on Windows, because apps on that platform are either shipped with their shared libraries in a nice installer, or compiled statically.

To expand on what I'm saying: backwards compatibility on Windows is fantastic. Nothing ever needs to be recompiled against a new library, because all the libraries that matter are shipped with the apps that need them or compiled into the EXEs. You can install the same Firefox package on Windows 7 or Windows 2000. When an OS stops being supported, you don't have to upgrade everything for a while, especially if you know what you're doing on the security end of things. (Think of the limited account and SRP setup I mentioned in another thread.)

On Linux, not so much. You have to update all the damn time. Not only is this confusing and scary for new users, and not only does it run the risk of breaking things, it eats up time and bandwidth - both especially if the $50 a month broadband you're paying for decides not to be so broad. (glares at ISP)

Now, Arch is a pretty specialized OS; it stays on the bleeding edge, so tons of updates are okay for it. But for Ubuntu and such... Oy. And new releases every six months, with support only lasting a year and a half to three years! Windows XP will have had eleven years of support by the time it dies!

Maybe this works for servers; I don't know, I've never administered a server. For desktops, it's a pain in the ass.

Now this is not to say that Linux is bad... Actually it has some huge advantages over Windows IMO, and being free is near the bottom of the list. For those advantages, I can put up with its annoyances. But I think that, for a lot of people, the need for constant bandwidth-hogging updates and the lack of backwards compatibility would be deal killers.

So I'm going to float a modest proposal for a desktop distribution design...

The core system (X included) is put in a bunch of big archives, with an advanced install option to select which ones instead of all of them. The core system stays static. In the event that an awful security bug is discovered and fixed, new install images are released, and new archives are made downloadable (they can just be tar -xjvpf'ed into the root directory).

(The exception would be kernel archives, for which new versions would be made available every few kernel releases. These updates would be purely optional, and could coexist side by side with the old versions.)

Packages for various extra applications would also be available. Packages would be installed to /usr/local to separate them from system stuff, and only updated in the event of major bugs. If you wanted to install the latest version of something, you could get their third-party package.

Actual package management would have dependency resolution, but use a tar.gz or tar.bz2 format...

If this all sounds familiar, that's because it's basically BSD, just with some tweaks to make it work for a Linux distro. Why it's never been done before I have absolutely no idea. I mean, pkgsrc is available for Linux, yet there are only 3 distros that have ever used it, one developing slowly and two quite dead.

Maybe I'll make a project of this idea when I have the time. Though "when I have the time" will probably be when Linux and Windows are both considered horribly obsolete. Nonetheless, I figured I might as well mention this idea and the reasons for it, and see what people think.

[/nerdy monolog]

Last edited by Gullible Jones (2010-08-16 03:32:28)

Google · 2010-08-16 04:03:07

I didn't read everything you wrote, but...

If you separate dependencies by application then you would duplicate a lot of dependencies no? The result would be a system with a lot of duplicates and bloated software because of it? That could be pretty nasty if each and every dependency was loaded when you use the applications, the result is a lot of wasted disk space and RAM. It seems more practical to have system wide dependencies and keep them updated even if it may break an application.

Gullible Jones · 2010-08-16 04:12:07

Yeah, you didn't read what I wrote, because I didn't propose that.

At any rate, static compilation and non-shared libraries seem to work perfectly fine on Windows...

some-guy94 · 2010-08-16 04:12:19

Some things:
* Getting that many projects to collaborate on a stable release is impossible, doing it downstream (distros) would require a lot of money.
* What should apps target for development? Older libraries for backwards compatibility? Newer libraries for speed, bugfixes, features, etc?
* The graphics stack is not 'great' yet, until the open source drivers catch up with the proprietary ones in terms of features, they will always be in a state of flux, this will probably last at least a few more yeas (and even longer for nouveau)

This sounds very similar to an enterprise distro like RHEL or SLES/SLED. Those have long term support (unlike ubuntu), and have bugfixes backported.

bangkok_manouel · 2010-08-16 04:14:13

Updates ? Most people do not care about updates, they just use what's installed on their machine. And (not 100% sure about this one) don't distributions like ubuntu offer transparent updates (the OS is doing it for you, without you even noticing it) ? People are not scared about updates, they're scared about the unknown.

jasonwryan · 2010-08-16 04:30:13

bangkok_manouel wrote:

Updates ? Most people do not care about updates, they just use what's installed on their machine [...]People are not scared about updates, they're scared about the unknown.

My thought. I installed Ubuntu 8.04 LTS on my mother-in-law's machine a couple of months after it came out. I configured it to automagically download and install security fixes. I recently updated her to the next LTS (10.04). Number of times I had to intervene, assist, debug etc in between? 0.

Granted, I still had to set it up for her. But she was paying someone to do that for her under Windows anyway -- as well as to remove all the malware etc that she would periodically accumulate...

I think postioning this as a "major obstacle" overstates the case. In marketing terms, I'd refer to it as a point of difference.

Google · 2010-08-16 04:31:46

^ Arch updates can be scary.

azalou · 2010-08-16 04:35:04

^ Well I'd argue that even if updates are transparant, they still eat at your bandwich. That said, there are advantages to a system wide library system, I think. less Hardware space needed for instance. look at Windows 7, it needs at least 30Gb of space, compared to 4-5 Gb for a linux system. And it's not like you *can't compile a software staticaly. Pretty much, only FOSS software uses heavily this design. The closed sources souftwares are more static and can be used everywhere as they are. One that I use is Matlab. I installed it once in the home partition on my fedora 8 box, and it worked regardless of the distribution I used ever since.

It comes down to a choice really. The FOSS devellopers wouldn't want to devellop their own library to make their software work if an equivalent is already available (I guess). They don't have licencing issues, and I think I can put up with the disavantage of updrading all my library, if that permits me to save space on my hard drive. Of course if my bandwitch was limited I'd not update my system as often

Inxsible · 2010-08-16 04:36:10

Google wrote:

^ Arch updates can be scary.

Only if you don't pay attention to details. I haven't had any problems with updates. Read the rss feeds or the homepage for arch and you will be prepared.

Granted, you cannot assume that a novice user would do the same.

mcmillan · 2010-08-16 04:37:42

Actually I think your proposal sounds a bit like the approach the chakra folks are using for their independent distro. I've gone back to the vanilla arch KDE, so I haven't been following the progress, but my impression was that they'd try to keep a stable core system (though it might be more like other distro's release schedule than the longer term stability you want), keep the KDE stuff updated with the new releases, and anything else was going into self-contained bundles (similar to the way programs for Mac are distributed).

That said, I've never really seen much of a problem with keeping everything updated, though I'll admit that is one of the appeals of Arch for me and may not be representative as a whole. But I'm with bangkok_manouel, that my impression is a lot of distros that this would be be an issue for deal with it by making the updates go on without needing interaction (I'd disagree with calling it transparent, I'd see it as the opposite of transparent). The problem with that is if something goes wrong it's hard to know why.

The main problem I see in your proposal is with this paragraph:

Packages for various extra applications would also be available. Packages would be installed to /usr/local to separate them from system stuff, and only updated in the event of major bugs. If you wanted to install the latest version of something, you could get their third-party package.

I think one of the advantages of the linux package distribution model is that all software is dealt with all together through the same system. I find it much simpler than having go to websites to download things if I want a new version.

Last edited by mcmillan (2010-08-16 04:38:12)

Acecero · 2010-08-16 08:31:11

So hypothetically, if you update a static library to a new one, you wouldn't have to worry about compiling every application that relies on a dependency to another dependency and so forth until you get the resolution of the static library? That idea could save the Arch Devs/TUs a lot of hassle from another libjpeg/libpng epidemic. Although you would still need to update applications and libraries, there would be significantly less work involved in keeping a system updated.

Edit: Ah this is my 1337 post.

Last edited by Acecero (2010-08-16 08:32:30)

Vermillion · 2010-08-16 09:21:41

Gullible Jones got some good points. I used Ubuntu and it was always a great pain to upgrade from one release to another because there was always a good possibility to break your system (Just take a look at the Ubuntu forums after a release there are always some people with the same problem).

Static compilation and none shared libs will end up consuming more disk space but whats 1 GB disk space today? I would pay the price of using more space on my hard drive for having a more stable system.

I am not familiar with BSD (never used it) but if this concept already exists it may not be so difficult to port it to Linux.

KimTjik · 2010-08-16 09:23:19

I might misunderstand your proposal, but doesn't this sound a bit like GoboLinux? At least to some degree.

I'm not at as knowledgeable as many users here, I however wonder if such an approach wouldn't put several pieces of software at risk of deviating from the overall progress of key pieces of software. If we implemented such solutions on a greater scale, e g changing system design, wouldn't that make developers less keen on updating their software according to new versions of libraries and such?

.:B:. · 2010-08-16 09:33:49

Gullible Jones wrote:

Yeah, you didn't read what I wrote, because I didn't propose that.
At any rate, static compilation and non-shared libraries seem to work perfectly fine on Windows...

They do. Yet 'tradition' wills it that a Linux binary uses shared libraries. That's how Unices work. Of course nowadays lots of proprietary apps have statical libs built in, but software manufacturers used to sell source code instead of binaries (!) to companies so those could make it compile (and work) on their own Unix flavour. But it seems those were the olden days .

Stefan Husmann · 2010-08-16 10:44:42

Some thoughts:

Nothing ever needs to be recompiled against a new library, because all the libraries that matter are shipped with the apps that need them or compiled into the EXEs.

Also Windows has a concept of shared libraries, called DLLs. And because of a lacking package manager this can be a nightmare with difficult to find incompabilities. On the other hand, you can also build a Linux system with everything statically compiled. The people from suckless.org try to do this. But nobody wants that.

And Windows XP is painfully slow, I have to use it at work. Never saw Windows 7, but it should be even slower. And that is because of missing shared libraries I think.

So I'm going to float a modest proposal for a desktop distribution design...

As someone said before, try GoboLinux.

Windows XP will have had eleven years of support by the time it dies!

XP is only supported because Vista was such a disaster in quality and hardware requirements. XP is imho the best Windows, but regarding usability it is bad enough. On every edge you have popups that steal your focus. You cannot get rid of your mouse. The command line is sucking. And the system is far to complex. The permissions-concept is maybe even finer than that of unixoide systems, but nobody understands it and so nobody uses it. Same about the registry.

Last edited by Stefan Husmann (2010-08-16 10:46:06)

fukawi2 · 2010-08-16 11:25:50

Very BSD like, apart from the static linking.

It "works" for Windows in the same way that wearing a face-mask protects you from bird-flu, but doesn't stop you falling over and breaking a leg. If that makes sense..... So many security holes in Windows, I'm sure a lot could be fixed with dynamic linking instead of so much staticness. More specifically, they are fixed, but not everyone updates everything on their system that is vulnerable.

karol · 2010-08-16 12:44:20

http://sta.li/ ;P

yngwin · 2010-08-16 12:51:33

Gullible Jones wrote:

on Linux, you can't update an application without updating the whole OS.

That depends very much on your distro. On Arch, this is mostly true. On Gentoo, not at all.

DonVla · 2010-08-16 13:14:57

karol wrote:

http://sta.li/ ;P

Hey, that's really interesting!
Thanks for the link

drcouzelis · 2010-08-16 13:41:27

A huge difference between Windows / Mac OS X and Linux / FreeBSD is the concept of a standard API.

On reason Windows has very good backwards compatibility is because the API has been stable for so many years. This includes functionality for GUI, networking, hardware control, and so on. The same for Mac OS X.

Linux doesn't have this concept. There is no standard API for all functionality. Instead, there are many different libraries, such as GTK, Qt, GNOME libraries, KDE libraries, and so on that not only change API between major versions, but also can have incompatibilities between small version updates.

Both the "Windows way" and the "Linux way" have great benefits and drawbacks, but I think it's very unlikely that the Linux way of doing things will ever change. It's just not in its nature.

Haiku is a free and open source operating system that is designed like the Windows way. It has a full featured and VERY stable API. Any application, GUI or CLI, that is compiled for Haiku will be able to run on old or future versions. At the same time, it has a lot of Unix compatibility, and libraries like Qt can be installed on it. But, installing Kopete on Haiku isn't any different from installing it on Linux, i.e., if you don't have the proper version of Qt installed then Kopete won't work correctly.

As for me, I'm terribly happy using Arch Linux (and Haiku), but I deny the idea that Linux even wants widespread adoption. Instead, it's used by those who want to use it, and that's pretty much it.

Inxsible · 2010-08-16 13:54:30

I have read a couple of posts that talk about Windows being backward compatible. However, that might not be true every time.

Am I the only one who remembers the "incompatible with Vista" thingy a couple years ago? Everyone had to upgrade hardware and software. That's future incompatibility which exists in many cases, linux included.

But there are many other software which had different versions for XP, Vista and Windows 7. Prime example is the ATI drivers which I tried on Windows 7 and they worked but did not work on XP. I had to download the XP version for the same card. If they were all backward compatible, couldn't they have just been "Windows 7 compatible" with the implicit meaning that they would also work in XP and Vista?

Am I missing something here?

KimTjik · 2010-08-16 14:13:27

A stable API in Windows also means you have USB and network stacks that grow and grow for every added standard. So it's not really one stable API. The Linux approach is to adjust the one stack to get needed hardware support.

You're right Inxsible, Windows' backward compatibility is overstated. At the company we've also dealt with incompatibilities and the need to upgrade software, not only to get Vista clients to work in our network, but even Windows 7 meant changes.

drcouzelis, Linux changes all the time. It's not set to always work one way or other. It's another thing though that it won't adopt stable APIs. In my opinion time has proved it to be a wise decision. At the time this design was adopted they probably couldn't foresee the change we seen in hardware. I believe there's a breaking point for Windows, when it's not just possible to build upon and add to its legacy code any more. It's a great contrast that Microsoft has to spend big money on study their own kernel, in an attempt to make it more efficient and avoid having system calls playing pinball, compared to how accessible the Linux kernel is.

shemz · 2010-08-16 15:18:47

I think the other way round holds true in fact. Because there are fewer shared libraries in Windows than in linux, almost all applications will supply their own libraries along with their binaries, and as a result a complete usable windows 7 installation on my laptop takes about 35-40 GB space, and a base installation of windows 7 x64 takes about 14 GB space. But a complete setup in linux would take about 7-8 GB.

But one of your points sounds interesting: if a user (lets say with bandwidth scarcity) completely disable updates (both automatic and manual), then the user would be exposed to security flaws in some time. But then its the same case with windows, except that threat exposure will be sooner than in linux. And besides, I think it feels that linux updates are too big as the update process in linux world is unified, while in windows each application has their own update process. When I log on into windows, i get a prompt saying 200 mb needs to downloaded for windows updates, in some time firefox will prompt saying there is a new version, then office, antivirus and it goes on. The update model of ubuntu et al. is more attractive for new users than even windows model, i guess.

yejun · 2010-08-16 16:15:53

Reading your post, it make me to double check the date of this post. Tar.giz and bz2 seriously?

Gullible Jones · 2010-08-16 18:12:37

Argh, I was going to post something long, and then I got logged out and my browser lost it.

What I was going to say, in short.

TGZ is dated

But it's not obsolete. It works just fine, and it's easier on the CPU and memory than TXZ.

Linux is changing all the time

That's fine for a niche OS like Arch. It's not fine for Granny's desktop.

Windows is insecure, Windows needs updates, no updates means insecurity

True enough. But desktop security is different from server security. For starters remote vulnerabilities don't matter as much on the desktop. And there are methods of prevention and containment of potential exploits; various kinds of execution whitelisting for instance, as well as AppArmor and SELinux sandboxing. Even the default limited user accounts on Linux, which block direct access to the keyboard device and so prevent keyloggers from working, are a form of containment.

Arch Linux

#1 2010-08-16 03:31:33

A major obstacle facing widespread Linux adoption... And a proposal.

#2 2010-08-16 04:03:07

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#3 2010-08-16 04:12:07

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#4 2010-08-16 04:12:19

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#5 2010-08-16 04:14:13

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#6 2010-08-16 04:30:13

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#7 2010-08-16 04:31:46

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#8 2010-08-16 04:35:04

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#9 2010-08-16 04:36:10

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#10 2010-08-16 04:37:42

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#11 2010-08-16 08:31:11

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#12 2010-08-16 09:21:41

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#13 2010-08-16 09:23:19

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#14 2010-08-16 09:33:49

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#15 2010-08-16 10:44:42

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#16 2010-08-16 11:25:50

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#17 2010-08-16 12:44:20

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#18 2010-08-16 12:51:33

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#19 2010-08-16 13:14:57

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#20 2010-08-16 13:41:27

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#21 2010-08-16 13:54:30

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#22 2010-08-16 14:13:27

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#23 2010-08-16 15:18:47

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#24 2010-08-16 16:15:53

Re: A major obstacle facing widespread Linux adoption... And a proposal.

#25 2010-08-16 18:12:37

Re: A major obstacle facing widespread Linux adoption... And a proposal.

Board footer