61–70 of 136 posts
Earlier quoted context omitted.
I would add politeness. Not sure about Linus, though...
Leadership doesn't require politeness. Fairness is probably what you really want.
Earlier quoted context omitted.
I've never had to upgrade Windows (including all installed apps) to be able to install some other random app. 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
If you claim that you "never had to upgrade Windows to be able to install some other random app" you probably haven't used Windows much then. There are games that need explicit version or newer of DirectX. You can't even produce from the C or C++ sources the binary application that runs on any Windows XP with the latest Visual Studio (11). Any C/C++ application built with Visual Studio 2010 won't run on Windows 2000…
By default you can't but you can adjust the build settings and it works fine.
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.
In my experience binary compatibility on linux is a train wreck. Ever tried to get a binary compiled 5 years ago to run on a fresh install of linux? 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 optio…
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
In my experience binary compatibility on linux is a train wreck. Ever tried to get a binary compiled 5 years ago to run on a fresh install of linux? 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 optio…
> 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.