Linus Torvalds: Programs exist for their users
lkml.org
lkml.org
> Programs exist for their users
> The *only* reason for an OS kernel existing in the
> first place is to serve user-space.
Sometimes programs don't exist for their users. Take DRM for example - it is explicitly against the user.
Some examples:
"The customer is always right." -> "You're the product, not the customer."
"Software is made for users." -> "The publisher is the user, not you."
Sure, these things sound clever at first, but they only serve to increase our acceptance of these encroachments upon the rights of consumers and responsibilities of corporations by altering our vocabulary to fit these practices. Let's just stick with the traditional definitions (e.g. user: "the one sitting at the computer") and stop twisting words to accommodate things like DRM and privacy-invasive tracking.
This isn't a redefinition of words. It's a clarification of the true situation. Again: if you're not paying for the product, and somebody else is, then you're the product, and your use of a system or viewing content, etc., is an intentional objective of the payer. You'd be well advised to be aware of this, because you're being manipulated.
And the fact that someone else is paying for the system doesn't make it right. Just because I'm not paying for a DRM'd product (and very often you do pay) doesn't make it "right". In this case, usually, there are to goods in question: the information good for which you are the customer, that's covered by a DRM "service", for which the publisher is the customer.
There are also goods for which there is no intrinsic monetary market, or for which the market is at best diffuse. Language is one such good (there are very few people whose paycheck is based on maintaining, debugging, and extending the English language, for example). Free Software is another, though there are both paid and unpaid contributors. And you might well ask what the objectives of those who are actively contributing are (propagandists and marketing types influence English, device manufacturers and standards promoters write significant amounts of Free Software).
For me that isn't twisting words to accomodate things like DRM and privacy-invasive tracking. If you tried to mask "You're the product, not the customer." as "The customer is always right." and "The publisher is the user, not you." as "Software is made for users." you'd be twisting words.
If I'm the product or the publisher is the user I'm very careful with what I share or do on the service. One of the many reasons for why it wouldn't affect me much at all if google disappeared tomorrow.
In the same way, the user of DirectX is the game publisher, not the consumer who buys the game.
If it was written for me - the user - it would allow me to bypass all content and jump directly to the first title of every disc I inserted. The producers of this software have explicitly made it hostile to the user. I'm not saying this is not within their rights - I'm just saying it is.
But this is a rat hole. My point was that this is not what Linus was saying. He was merely describing the purpose of one software component. A kernel is a hardware abstraction - a platform for building applications without concern for the details of components - including the version of the kernel itself. He was arguing against breaking that contract by introducing a change which fit the whims of the contributor but would break an unknown number of binaries compiled against that contract.
tl;dr - "user" is not the same as "user-space"
In many or most cases, the end-user is paying for this product.
The publisher is paying for, and benefitting from, the DRM capabilities or service, offered by the DRM system/software.
There are two markets and products at play here.
Linus then goes on to say:
Even when Linux was young, the whole and
only point was to make a *usable* system.
Linux exists to be used
Programs exist to be usedhttp://markmail.org/thread/wwi2aynfiliqanil
I don't understand why Mark Mail doesn't get more love. I wish they had better SEO or something, it's so much easier to read a long thread on their site then most mailing list archives.
Linus has it.
Though I'm not so sure I want Nice Guys(tm) writing my software...
Another difference is that a lot of people working for Jobs (again, at least during the Apple 2.0 days) made f* you money for their efforts. There are engineers making a living working on Linux, but not on that scale, I think.
Jobs was running a company, and paying people directly for results..... (all other judgement aside)
Seriously, Linux has had MAJOR advantages, people HATE M$ and the Mac has shown ZERO interest in taking over anything other than the elite market segment.
I tried using Linux for a while, and it is a major pain in the ass. I've been using a Mac for everything since 2009, and it is so much easier. I really miss some Windows apps, so I'm going to have to get another machine just to run those apps, and of course I will install Windows. But there are no killer apps for Linux on the desktop.
Running a server farm? Of course I'll use Linux. No point in using anything else. But on the desktop, what's the point?
If you use Linux, it's like tithing. It's free, but you have to give up 10% of your life just to get by. If you're a sysadmin, that IS your life, and you can kernel hack all day and night. This is why Linux controls the server market.
But Linus has no conception of what the average user wants and needs in an OS. For example: if I'm using Linux, I'd like to be able to seamlessly run lots of Windows software. Linux should have an executive suite for Wine.
The charitable interpretation of his antics is "Lilliputian victim". He sounds like a 13 year old.
On top of that, the vitriol is a waste of breath. The Mac broke binary compatibility two times - Motorolla to PPC and PPC to intel. There were VMs available and fat binary alternatives available for both changes, and Mac users and developers just rolled over.
Linus does some things very well, but I would not describe him as a model leader.
What you're saying is like judging the guy who build the road when it's the car that sucks.
It seems like you have some bone to pick with Linus, because there isn't any real criticism here. Binary compatibility is a very nice feature for Linux users, you haven't written a word about why that is not so.
Linux can run statically compiled binaries from 1993, but not the Firefox binaries from 2006.
One problem that you encounter if you do that is that glibc has an option to disable support for older kernels in exchange for better performance, so you lose backwards compatibility unless you are very careful about how you compile glibc (it fails with an error that the kernel is too old).
Good luck.
If you still have the specific version of every shared library that it loaded you might be able to get it to work.
This isn't the fault of the kernel team though.
It is probably to be expected on platforms in which distributing source code is the default option, but it makes the platform very hostile to closed source applications, particularly games.
The kernel is doing its job. Userspace, not so much. Though it's not nearly as bad as you think. In general, any desktop application compiled in the last 5 years will run unmodified on any modern distro. Really, it will, and I'd challenge you to find a counterexample.
But I suspect you're talking about the dependency issue. Installing something with a bunch of dependencies (because modern software has a dependency graph that looks a lot like seaweed) requires finding and installing all that stuff on your modern distro. And package names have changed, and some have been dropped from the core distro, etc... And yes, this is a mess.
But seriously: if you have a binary that works alone on, say, Ubuntu Dapper, it almost certainly will run on Fedora 16 or RHEL 6.2
$ fgrep DNOTIFY /boot/config-3.2.9-1.fc16.x86_64
CONFIG_DNOTIFY=y
It is the result of having no unified platform and library release coordination, no long term plans, nothing, just chaos. Everybody just releases when he is in the mood for it. And since nothing is complete when released, devs further down the chain always go for the latest and greatest to get additional functionality. And to upgrade app1, you have to upgrade lib1 which triggers the updates of app2, app3, app4, lib3, etc. Sometimes you cant update a simple app without updating the whole desktop. The Linux dependency net appears nightmarish to everyone coming from Windows, where you have a reliable, stable base system which doesnt change for a decade and every app targets the same base system.
Linux, the kernel, is only running that great because it has a dictator. But Linus' dictatorship ends at the kernel borders, he has little influence outside. The Linux desktop also needs a dictator to massively slow down the rate of uncoordinated changes and force-stabilize the ecosystem. I hoped that Mark Shuttleworth could be that man, but he then introduced Unity... but even with unity, Ubuntu is the only chance for the Linux desktop for having a single defined set of libs attractive and influential enough for app devs as a primary target so they can safely go with the library versions in Ubuntu, instead of constantly chasing the latest and greatest versions from the upstream.
Now, you are being plain funny. Haven't you heard of 'DLL Hell' in Windows platform?.
You never had 'windows update' break your software for no reason?
On 16-bit Windows there was a single address space and only a single version of a DLL could be loaded by all processes: the first one to load would "win", and the others would get screwed with the old copy. This was due to 16-bit Windows not having memory protection: it was more of a GUI over DOS, and thereby had cooperative multi-tasking.
Even with that fixed, many developers would require a slightly newer version of a library, and rather than ask the user to upgrade their system (an irritating consequence of not having packages or dependencies; APT FTW ;P) would just include the DLL in their installer and unconditionally overwrite any existing copy.
After the dynamic loader started supporting "local" versions of libraries (installed to the same folder as the application), a similar problem happened with COM objects, which are centrally registered: someone would install their own version of a shared GUI component, register it with the shared name, overwriting possibly-installed newer copies.
Both of these problems were actually solved, but way too many developers simply gave up on Microsoft and Windows beforehand, and then refuse to spend the time to learn about the improvements. In essence, Windows now has reasonable-ish package management, with dependencies: Windows Installer.
In addition to dependencies and versioning of packages (which can then be correctly tracked by Windows, much like APT on a Debian/Ubuntu box), Windows Installer supports the notion of "unified installer program" with "merge modules": in essence, you can include someone else's package inside of your package; that way the dependencies can correctly be checked, and old versions won't get overwritten.
There are still a few cases that are quite difficult to manage (involving libraries that require a modified ABI over time, but still receive updates), and Microsoft's solution to those is WinSxS. Honestly, while I'm much less familiar with it than on Unix, it only seems a constant multiple more crazy than .la files, which I believe solve a similar problem.
These technologies and improvements were all introduced at or before Windows XP, an operating system that was released just over a decade ago. Of course, these are all solutions that developers sometimes ignore, but if you download software for Linux that comes with a .sh installer that scribbles into /lib, you are in for similar "hell".
On Linux, having to upgrade the distro (including getting a new desktop environment force-installed) to get a new version of any random app is established practice. Example: http://esr.ibiblio.org/?p=3822
See the various opinions on MSFT intentionally removing the binary compatibility which already existed in their libraries here:
By default you can't but you can adjust the build settings and it works fine.
When you are dealing with different distributions that provide different versions of core libraries, different sound architectures , package managers and put things like executables and config files into different parts of the filesystem.
I thought that the Linux standard base would be the way to solve this.
After two sentences i thought "he probably works for microsoft or another big corporation", not because it's flame, but because of the attitude to regard this as pure chaos (and having no big plan as bad). I even looked up the profile.
There is kind of a release-plan, not for the whole eco-system, but that's what stable distros are for. So the remark to Ubuntu is right. But it's wrong to mix library-stability with perceived frontend-issues with Unity. Ubuntu still fulfills that role for some apps. And besides that, it isn't necessarily wrong to write new programs against new libraries. They have new features and new bugfixes.
I wouldn't want the ecosystem to stagnate right now. Or ever.
The problem is that no app dev targets stable distros, but always goes for the latest and greatest from the upstream so distros are constantly forced to update libs and change the base system.
So with a stable distro, you cant get a new version of an app, because the libs of your distro are too old, and you need to upgrade the whole distro just to be able to get that new app you want.
The Linux ecosystem needs one distro (say Ubuntu) to become so influential, that app devs start to primarily target it instead of the upstream. Only then will the library space stop being a moving target for end users, and only then it will be possible to upgrade app1 without triggering an automatic update of app2, which both happen to depend on the same lib. Only then will these useless practices of "packaging" and "backporting" finally stop, and devs will be simply make packages themselves, like they do on windows or osx. Only then will users be able to install a distro once, and then be able to install new apps for 5-10 years without having to upgrade the whole distro every 6 months.
> I wouldn't want the ecosystem to stagnate right now. Or ever.
But with an ecosystem as unstable as the current one you wont get more than 1% of the market right now. Or ever.
Normal users and especially businesses simply dont want to constantly update their systems. Force them to do that, and they simply walk away.
What happens in Windows is not what you're describing; developers are simply forced to distribute their own copies of the libraries (as DLLs or statically compiled) since there is no package manager. What then happens is that there are dozens of copies of the same libraries, most of them lacking bugfixes and even security patches.
The dependency system used by Linux distros may have its problems, but it surely beats ad-hoc dependency management, even if it requires backporting.
Normal users and especially businesses simply dont want to constantly update their systems. Force them to do that, and they simply walk away.
Right. If you use Windows, have you tried counting the number of update managers running in the background, the number of applications that ask you on launch to "verify updates", the number of times Windows Update alerts you, etc?
Windows machines are constantly updating. Unlike Ubuntu, they just do it incrementally instead of once every six months (except for security patches). But that's better fixed by moving to a rolling release scheme.
It's just not commonly done (with exceptions like http://sta.li/), and as a user, I'm thankful for that.
The bigger development teams don't focus on a single distro, as their development base is probably diverse enough to demand a certain degree of platform compatibility.
However, many of the smaller development teams will focus almost exclusively on Ubuntu, as it is the distro they will most likely have.
I know, from my own limited experience, that I have only ever attempted to make my systems work on Ubuntu and just allowed others to push their changes into the main development if they have specific platform that they prefer to use.
In fact, usually when we run into problems, it's a new version, not an old one.
This used to be RedHat: software for Linux would often come as either 1) source code (if open), 2) a crazy .sh install script, and 3) an RPM package for RedHat 5.
See how jwz shows you how to run a binary of Nestcape from 1995 (17 years old) on the latest Linuxen:
http://www.jwz.org/blog/2008/03/happy-run-some-old-web-brows...
Your major problem if you want to make a closed source application is that the user space dynamic libraries are mostly (L)GPL licensed, so you have to avoid (L)GPL libraries to have a legally fully-library-independent closed source application. LGPL license allows closed source linking only if you link dynamically to the LGPL library (meaning: your application must depend on the externally present library which can be replaced at any time). Which is really fair, IMHO.
http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_Licen...
I did have to fish around a bit for an old version of curses and create a symlink. It only took a few moments though.
Just a data point to consider.
Speaking of that, I wonder if there's some point at which dynamic libraries don't really help you that much. These days, even shared libraries don't seem to stop a GNOME desktop running a browser from sucking down a gig of memory; would it really kill them to have a couple more megs of static library in each program? With copy-on-write, I think things like Chrome which spawn many children would come out pretty well.
Even using an SSD I suspect the difference would be noticable for most applications.
I run older binaries on Linux all the time.
And yet it's the top story on HN right now. When do we start giving tl;dr's for the headlines?
[EDIT] managed to find a mirror. This mail in the thread gives a bit more context: http://lkml.indiana.edu/hypermail/linux/kernel/1203.1/00446....
Linus said the whole thing was dumb, the patch wasn't worth it, and that programs exist for users, so we can't just break things for the hell of it and expect people to use Linux.
edit: also ttt_ and father posted it and got auto killed.
The Debian kernel team tries to do a reasonable job of tracking kernel ABI compatibility changes, and updating the number when the ABI does change, to avoid having to recompile and reinstall everything for every patch to the stable tree. In this case, they decided that the ABI change was only intended for a single, in-tree module (KVM), and that they didn't have to increment the ABI number for a change that shouldn't affect anything else.
This is really just an example of the Linux kernel developers' two approaches to compatibility. For the kernel ABI, they make no guarantees whatsoever about compatibility. For the user space interface, they are supposed to never, ever change the interface in ways that will break existing programs, though there are sometimes disagreements about what precisely constitutes this interface and what is outside the bounds of it.
Take this example. Now I realise this isn't a company-client relationship we're looking at, but am I alone in thinking a bit more diplomacy wouldn't have gone amiss?
There are two major products that came out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence. (Jeremy S. Anderson)
http://groups.google.com/group/comp.os.minix/browse_frm/thre...
Linus was a kid in 1992, and got scolded by one of the greatest icons of the field. That could still sting 20 years later.
Ouch, history hurts.
However, it is a betrayal of UNIX's history.
That was when AT&T first entered into anti-trust restrictions as a result of its anticomptitive practices in the long-distance telephone market, resulting among other things a 1958 DoJ consent decree preventing the company from marketing computer systems, which meant that in 1969, when Ritchie and Thompson wrote UNIX while at AT&T the company couldn't sell the software, and gave it away (with love, from Ken), resulting in most effective development moving outside the company by the mid/late 1970s (notably to UC Berkeley and MIT), a fact ultimately recognized by AT&T when it sold UNIX to Novell, who transferred the official UNIX trade mark to The Open Group in 1994.
GNU is definitely not Unix.
http://webcache.googleusercontent.com/search?q=cache:https:/...
And then Linus (the guy behind Linux) goes on to explain that the OS should serve its users, and that keeping compatibility with existing programs, no matter how old they are is of utmost importance for users to be able to use that system.
I don't know if I helped, or if I addressed your doubts. I hope so :)
The current counting that we do gives the wrong numbers, in the
edge cases. To my knowledge a deleted sysfs directory has never
returned nlink == 0.
Keeping compatibility is easy enough that it looks like it is worth
doing, but maintaining 30+ years of backwards compatibility is what
nlink >1 in unix filesystem directories is. I don't see any practical
sense in keeping . and .. directories on disk or upping the unix
nlink directory count because of them. To me it looks like just one
of those things you do. Like hash directory entries so you can
have a big directory and still be able to have a 32bit offset you
can pass to lseek that is stable across renames and deletes.
Linus's quote was "drug induced microkernel", however. It wasn't "drug induced microkernel or hybrid architecture" --- although if you run Windows or are forced by a family member to be a Windows support desk, you have my pity....
Thank you - it's nice to know there are people out there thinking about us :(
AFAIR micro- ones are used by QNX and Minix. Monolithic kernels are used by Linux, *BSD (with an exception for Dragonfly, which uses hybrid kernel), Solaris, AIX(?) and more SysV descendants.
Count me out of 'the rest of the world' then. Perhaps you can point me to the what part of NT which would make it a hybrid kernel as opposed to Linux. I've never seen any explanation of this.