What I find impressive is that Alan continues to assist on the issue after he has "had enough", providing in-detail responses to questions and correcting part of Linus's patch. I think he also responded to Linus's initial complaint with grace and aplomb.
I'd like to think I am poised and dedicated, but I doubt I am even half so as Alan.
From TFA - "After reading the thread on a mirror, it's important to note that after the argument, Alan and Linus continued to debate the technical merits of how to patch the bugs. The ongoing conversation was civilized and concise. Of course Linus is too much of a pompous ass to apologize to Alan for completely misunderstanding the problem and proposing dangerous and useless ways of fixing it, then arguing about it ad nauseum. Oddly, this doesn't seem to bother Alan or maybe he's just used to it."
This is one thing I have found true of great open source developers in general: regardless of their attitude, regardless of past events, regardless of the situation, they can carry on technical debates on how to deal with an issue.
In other words, for such people, the technical merits of an idea supersede all other aspects.
I read the thread (didn't understand most of it) but Torvalds describes Cox work as "crap" and tells him "you're full of crap". Way to stick to the technical merits there ...
> This code worked with the older TTY code, but broke with 2.6.31. There is probably no way to fix it which doesn't saddle the kernel with maintaining weird legacy bug-compatibility code
"Maintaining weird legacy bug-compatibility code" is the essence of professional and responsible platform software engineering - the software that other software relies upon. It's one of the reasons why platform software development is so hard and why software engineers are paid as much as they are.
There's another misguided notion mentioned that I see a lot in both open source and Wikipedia, two kinds of crowd-sourcing efforts which generally desperately seek authority-figures of some kind, like "standards":
> Alan thinks this behavior is reasonable; it complies with the applicable standards
Compliance to the "applicable standards" isn't worth anything if it breaks software and makes users' lives worse. It's not for nothing than POSIXLY_CORRECT applies to many GNU apps, and is not enabled by default.
I disagree completely. Maintaining ABI compatibility is crucially important, and the kernel development community understands that. But ABI compatibility does not mean going to all lengths to enabling buggy code to continue to work. In this case, "fixing" kdesu would have required putting in code to recognize this specific data stream and ensure that a read terminated exactly where it always used to so kdesu wouldn't get confused and throw away good data. It would be an albatross around the neck of any developer working in the TTY layer for years, and those developers are already up to their asses in albatrosses. All to perpetuate an easily-fixed bug in an open-source application.
That kind of "compatibility" wrecks your platform over the course of a few years; you simply can't maintain code like that. A "professional and responsible" software engineer needs to recognize that and avoid it.
Maybe Linux (and other similar projects) ought to divide into separate streams - one "research" trunk, that focuses on cleanliness, elegance, and standards compliance and is not constrained by backward compatibility commitments, and from which multiple "practical" branches might diverge, each always maintaining compatibility to its point of origin, despite the tendency to accumulate cruft as it evolves.
Software development is about trade-offs and apparently linux wasn't hurt as bad by the occassional ABI breakage as solaris was hurt by the "backwards compatibility above all" mindset (which ofcourse reaches way beyond the basic ABI).
I was arguing more in terms of market- and mindshare than in terms of technical merit. Yes, Solaris grew a few very strong subsystems. The problem is that your list ends very shortly after Dtrace, ZFS and Zones (which is already matched by OpenVZ anyways). Those few bright spots are simply not enough reason for most people to put up with with an OS that is otherwise firmly stuck in the 90s (horrible userland, absence of a package manager, no worthwhile mass provisioning options, etc.).
What came first, Jumpstart or Kickstart? Again, Linux is playing catch-up.
Jumpstart, Kickstart? Well, I guess they were hot in 2001, yes.
All sizable solaris deployments I know today are struggling with FAI, puppet and a lot of custom glue scriptery to enable at least a basic grasp on their deployments. JET and the ilk is just not even touching a worthwhile real-world problem.
And the userland/package manager problem is neatly addressed by Blastwave.org.
Likewise I can only scratch my head over reading blastwave and "neat" in the same sentence. Have you even used it?
I'm in fact a bit surprised it still exists because most solaris admins seem to either scoff at the idea altogether and stick with the regular pkgadd, or look for greener pastures in OpenSolaris - which wisely refrained from any attempts to re-invent apt.
Well, but as said, my initial point wasn't even about discussing implementation details in one way or another. There is no doubt solaris displays great technical excellence in some areas. Unfortunately too often these are not the areas that people in the real world care about.
Yes of course I've used it. Updated all my packages yesterday in fact, went perfectly smoothly. YMMV but all the full-time Solaris admins I know are Blastwave fans.
The point I am making it: a serious OS doesn't break backwards compatibility on an individual developer's whim, no matter how famous they are.
a serious OS doesn't break backwards compatibility on an individual developer's whim, no matter how famous they are.
Well, most people seem to like their OS a little bit less serious nowadays.
Or, more seriously, over here in the real world this is simply a non-issue for almost everybody. Binary compatibility between OS revisions was important when compile-runs would take days. Nowadays you just compile for your target platform and move on.
That's why (for example) Windows has compartmentalized and "pluginized" its AppCompat infrastructure. ABI compatibility trumps almost every other concern, IMHO.
""Maintaining weird legacy bug-compatibility code" is the essence of professional and responsible platform software engineering"
I couldn't disagree more with your point.
Open source is about openness. This is about evolving a platform in a clean and open way. If someone's program is buggy and does weird things it shouldn't do, then the bug should get fixed, not a bug be added to another piece of software in order to make the buggy program (that worked properly only by accident) still work. A feature that is not needed is a bug all in itself.
If your old program won't work with your new OS, then don't upgrade. There is no pressing need to run the latest and greatest OS, at least not in "professional and responsible" environments.
Being a fan of the BSDs I have to point out that this type of decision would not happen there. The reason being that the kernel and userland are not separate entities; they are a system. If you update your kernel the userland has to update with it, and that is to accommodate changes just like this.
I would point out that the userland in BSDs that would update with the kernel would be the CORE utilities and programs. Say, like GNU utils on a linux distro. kdesu is part of KDE, which is an application installed on top of the OS, not something maintained as part of the OS. Would you say there wouldn't be any issue with a BSD kernel update breaking an extremely widely used application such as, say, Apache?
There would be issues, but the BSDs tend to break the ABIs on the development branches only, not the stable branches (e.g. CURRENT vs STABLE in FreeBSD). This usually gives port maintainers enough time to patch their ports appropriately or to send their patches upstream. Users should never see any breakage unless they choose to use the development branches.
Your point is precisely the example I mean. In *BSD the kernel, core, and packages/ports are all tied to one ABI at any time. Linux/GNU's system is more free from, and as a result can result in these problems.
Evolving the API is a fact of life. It your critical program breaks with the most current bleeding-edge version, then either fix it (or have your vendor do it for you) or don't run the latest release. It's not like someone will die for having an earlier release.
That's also why Linux distros don't use the latest kernels: to allow the userland programs they package into them to run until they get fixed and the latest kernel can be added. While I know my Ubuntu doesn't run yesterday's kernel, I am happy it runs perfectly well with last month's kernel.
Yeaaaah.. they were summaries of positions. Thanks for insinuating that I was being misleading. Did you really think 'Coda' was a person?
I've been watching parent get upmodded and my comment get downmodded with increasing disbelief. Time was that +16 used to mean it was not to be missed, and -4 was a troll or ad hominem.
This is the typical example where Linux suffers from lack of true engineering. The kernel API and libs should be stable, predictable and well documented. There should be no hacks to support odd behaviour because odd behaviour should not be specified. Isn't that why we have POSIX?
What with recent issues with egotistical libc maintainers, people throwing their pacifiers over having to support junk, people moaning about ext4 (even though it works fine and is poor app behaviour), it doesn't give people much confidence.
> The kernel API and libs should be stable, predictable and well documented. There should be no hacks to support odd behaviour because odd behaviour should not be specified.
There should be a pony too.
How can the kernel not have lots of hacks? It deals with hardware, which is often weird.
Certainly you understand why Win32 still runs old Windows 3.1 code from 1991? It does so because of countless little hacks and "compatabilty mode" switches in the OS that emulate old bugs that existed in old versions that badly behaved software was taking advantage of.
I have seen the win32 subsystem source (legitimately through shared source - I used to work for the British Ministry of Defence). It's very clean and tidy and not full of junk like that believe it or not.
The reason it still works is that they thought about it properly to start with. There have been very few extensions. The main one being adjusting pointer sizes (which are hidden behind a typedef like LPSTR anyway so that is irrelevent).
And for the record I take anything Joel says with a pinch of salt. The guy is a trendy blog mouth piece.
This is just the tip of the iceberg with respect to application compatibility. I could probably write for months solely about bad things apps do and what we had to do to get them to work again (often in spite of themselves). Which is why I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure. I spent many sleepless nights fixing bugs in third-party programs just so they could keep running on Windows 95.
I've seen dozens of those "personal failures." :-)
Granted, backwards ABI compatibility is a huge, complicated, thankless task for which you get no notice if you do the job perfectly. The ideal spot for the "break old programs" vs. "cripple new programs to avoid breaking old ones" dial is different for every project. Sometimes the right thing to do is keep the code base from degenerating into a pile of back-hacks. Sometimes it's all about bending over backwards to keep a long-gone vendor's bug from biting your end users.
Windows 9x was a mess. That same is not true with NT which is really nicely put together.
I've dragged some stuff which we wrote for NT4, recompiled it with VC++ 2008 (plus spent some time frigging VS settings) and it just worked on Win2k8. The original binaries, even though they were compiled 12 years ago, still run on Win2k3 fine and past the test suite (!).
It sounds like your default state is "Full Confidence", and so Confidence is 'eaten away' in your description
The better definition concerning Linux is that Confidence is "Built Up". Linux started as an unknown and has forced itself into people's confidence.
Linux operates well 24x7x365 in many places, and that
rate of Confidence build up is way more than any rate of loss due to Steering Committee squabbles.
I'd like to think I am poised and dedicated, but I doubt I am even half so as Alan.