Because some distros include things that someone else would not want in their distro at all.
Like what? Don't name arbitrary pieces of software, you can always install what you want later.
Some distros use mutually exclusive methods of configuring certain kinds of software
Examples? Where this problem does exist (can't actually think of any off the top of my head), that should be fixed through standardisation.
Some distros will include certain software that others will not; a "standard" distro, to meet everyone's needs, would have to include every single piece of software that every distro out there includes now. That would take up a few dozen CD-ROMs
No it wouldn't. Presumably a standard distro would not *need* to have a subset of all possible software distributed alongside it, you could simply post binary packages on websites and use them.
It doesn't mean anything. It's essentially a meaningless "feel-good" answer that doesn't address the underlying problem: we have bazillions of mostly but not quite compatible appliances, rather than a unified platform. The differences between most distros are negligable, and people end up choosing which one they use based on how many packages are available for it: in other words, how little of a pain-in-the-ass it is to install software. So, by "choices" the AC actually means "the ability to choose between a million minor variants on the same theme, but in which only two or three are actually usable by the masses due to the immense pain of installing and upgrading software on anything else".
Random bits embedding each other tends to lead to a a rather messy UI. "Modularity" is not an end itself, it's a means to an end, something that KDE people seem to forget sometimes.
There was some talk of doing that a few months ago, they appear to want to do it. Also Michael Meeks (a Ximian developer) has been getting into Win32 development lately, though that might be just for OpenOffice.
I think it's something they want to do, but it's a bit non-trivial.
Why? Because that's what the businesses use. Lower training costs.
Right.
When things go wrong, they're fixable via GUI. Don't need to find a guru, any convenient semi-geek can do the job.
The quality of semi-geeks must be much higher where you live. Last time I checked having a GUI didn't mean Windows could be magically managed by people who weren't trained.
The only way I could possibly learn Linux is through... my Cygwin environment at work, and my OS X Powerbook.
Huh? What's wrong with actually installing Linux? I must have missed something here... mucking about with Cygwin or a Mac does not teach you Linux, sorry.
To say that no users care about driver compatibility is just insane. It would be nice if there was some sort of API that binary device drivers could write against that never changed... but who knows thats probably really hard (I don't know anything about kernel devel)
It's not hard. Backwards compatibility isn't rocket science, it just requires you to value utility above artistic license.
The kernel, regardless of what some of its developers may think, is not an art project. The most fundamental mission of an operating system is to run the users software and hardware - an OS that refuses to do that on the grounds of API prettyness has got its priorities wrong.
The techniques of maintaining backwards compatibility are well known. You use structure padding, create a new foo_function2() rather than change the prototype of foo_function(), ensure you don't make semantically breaking changes to the behaviour of the APIs, and so on. Most of all you have good testing procedures in place, long beta cycles and such to catch any breaking changes you made that slip through the cracks. It's about management of change.
The arguments about keeping old cruft around are mostly bogus. Backwards compatibility doesn't imply keeping it for ever, even keeping it within stable kernel series would be a big improvements. Likewise, if you take "cruft" out that people are relying on they simply won't upgrade to the newest version and people will be evaluating your software based on buggy, old versions which is no good at all.
The fact that key kernel developers are so far removed from reality is something that should worry us all. Backwards compatibility is viewed as "evil" by far too many people without understanding how essential it is in mass-market software (no, an OS with 1% of the desktop market is not mass-market software, sorry). If you want to make the most academically perfect kernel possible fine, go do it but for heavens sake don't pretend you're writing a production kernel!
I'd go further than that, I'd say it was the one of the biggest piles of self-righteous wanking I've read for a long time.
There are so many pathetic, useless "arguments" in that rebuttal I don't know where to start. He tries to claim that binary compatibility for drivers is "impossible" and anybody who thinks otherwise doesn't "understand the technology". Say what? Solaris engineers don't understand UNIX kernel technology? Microsoft engineers don't understand backwards compatibility?
He brings up pointless details like gcc alignment (Wine uses gcc and controls struct alignment exactly to be compatible with Win32), config options like CONFIG_SMP as if this is some fundamental unarguably facet of kernel design (it's not), and driver interfaces taking up memory (that's what modularity is for, yo).
He seems to live in a fantasy world where the total lack of backwards compatibility doesn't hurt users, it actually makes them happy, and where it's impossible to have both a good kernel and a backwards compatible one - the NT kernel is a 'good' kernel in many respects, yet it still preserves compatibility. Ditto for the Solaris kernel.
He also makes some incorrect statements. Apps written for Linux 1.0 will not necessarily work correctly on 2.6, not if they were broken by NPTL, or if they were shipped as static binaries (which also were broken at some point). OK, these aren't totally problems with the kernel, but if you ignore userspace entirely then you might as well stop talking about "users" and "apps" and go back to embedded work or whatever.
Basically, if there was ever an issue that'd cause the kernel project to fork, it'd be this one. So-called rebuttals from people more interested in straw men and insults aren't going to make that any less likely.
Ah, I was thinking about how useful a safe C dialect would be only the other day. If Cyclone is the real thing, then getting a GCC frontend for it up and running then convincing maintainers of important libraries to port to it (or forking) might be a great way to help out open source security.
It's about turning a big heap of user-contributed software, into a single consistent centralized system. That's where distros come in, but at the moment, those distros aren't really doing their job.
I disagree. This is the "appliance" mentality. We don't want a centralized heap of software, we want a *platform* on which 3rd parties can build with confidence. Right now we're sort of teetering between the two.
The level of polish and craftsmanship of open source software
Open source software has plenty of bugs, duh.
In fact, there are similar problems with parsing image files on Linux as well. Except that Windows is actually more secure, because it has auto-updates turned on by default from XP2 onwards, and stack protection type patches built in by default. On Fedora you have execshield, but that hasn't been fully upstreamed yet so only a small subset of Linux users are protected. I don't know of any distros that download and apply security patches with no user intervention out of the box.
(recall OS X's open source roots)
Even if open source software was perfect (which it isn't) large parts of MacOS X are not open source. Most of the important bits aren't, in fact. Surprise surprise, the Mac has had serious URL handler exploits which are like this JPEG problem: arbitrary code execution via a web browser. Except in the case of the Mac URL handler problems it was a design problem not just an unchecked buffer, to do with insecure-by-design features. D'oh. ActiveX all over again.
So, no, I don't trust Apple any more than Microsoft when it comes to security. How can you? They are both proprietary OS companies, with all the issues that implies.
can never be duplicated by Microsoft's paranoid and closed-doors efforts
These days Microsoft have dedicated programs scanning their code looking for suspicious patterns, security testing teams, and give their developers extensive training in how to write secure code. These are advantages not available to open source coders. If anything I'd say they're close to taking the lead in absolute terms for security (by which I mean, assume equal market share for Windows, Linux, Macintosh - which is more secure).
Correct, with sponsers such as HP, Sun & Red Hat, Gnome is aimed squarely at the corporate desktop where consistency and manageability are watch words.
I disagree. I find it a perfectly usable hacker desktop as well, and I know quite a few other developers who like it also. If I had to give a Linux desktop to a non-technical friend or family member, I'd choose GNOME. It looks and feels a lot more professional - more like Windows or MacOS in terms of usability ethos.
KDE is more volunteer driven, hence it aims to appeal to fellow developers and home power users, for whom configurability and features are wanted.
I don't think you can draw a line between "volunteer driven" and "corporate driven". KDE is based on a commercial toolkit, which is developed privately by paid developers. Quite a few core KDE developers are paid by SuSE or TrollTech. Meanwhile the volunteer community in GNOME is alive and kicking. It's not anywhere near as polarised as you think.
Finally I'd note that "usability" doesn't mean "stripping out options". It means having software that Just Works without needing tweaking, having sensible options (ie, not "Minimize memory usage"), software designed with the user in mind first and implementation following that, and so on. Lots of things. Don't equate it with dumbed down though, because that's not what usability is about.
It could well be a form of self-protection rather than a "hey let's get into every business we can" move.
Back before Microsoft got involved, Netscape had a near monopoly on browsing. They were the de-facto standard. Today, Google is pretty much the de-facto standard for search though I doubt they have as much market share as Netscape did back then.
Behold the power of bundling with Windows. Netscape is no more. Why? Because Microsoft controlled the gateway through which people accessed their software. Given the noises MS has been making about competing "strongly" with Google lately, they must be scared the same would happen to them except via IE instead of the operating system.
So, they want to produce their own browser, so it gets market share. That way nothing Microsoft does to IE (integrated search etc) can hurt them too much, because not many people are using IE.
It would make sense for them to base it on Firefox. It's a best-of-breed browser, portable, and is going places. But, it lacks marketing! While the current Mozilla efforts are commendable, they'd be nothing compared to being promoted on the Google webpages.
At least, this is the reasoning I'd use if I were them. It's not so much to branch out into new business, as to protect existing ones...
OK, I'll take your word for it. I said that because the guy who originally published the shatter attack claimed that on non-Administrator users in a default XP install, there were processes running with elevated privs which had hidden windows etc. But, I don't really know for sure.
The so-called "secret" file format parsers aren't really secret at all, you can license the specs from Microsoft if you have enough $$$.
The main problem is that they come with lots of nasty license clauses that prevent you from redistributing the knowledge and such, so it's not helpful for open source projects.
I'd never heard of these guidelines, or that API before now. Given that on a default Windows XP desktop there were (are?) processes with elevated priviledges running on the interactive desktop, I guess most of the Windows developers hadn't heard of them either.
You can avoid that hole. Well, sometimes you can avoid that hole. Anywhere that you control the message loop, you can validate WM_TIMER messages before handing them over to DispatchMessage.
Wrong, there are quite a lot of messages you can use to cause another program to run arbitrary code. WM_TIMER is only one. That hole was patched but there are other messages with similar properties, searching MSDN will reveal them. New messages are added all the time, you cannot filter them all.
Actually you can't filter WM_TIMER anyway. It's dealt with directly inside GetMessage(), iirc.
Given that one of my friends back home is a serious Mac fanatic (he wants to work for Apple and already works for a reseller, he goes to the expos etc) and has no qualms at all about warezing new OS X versions for his Mac I think releasing MacOS for IA32 would be a fast way to get lots of copies of the OS out there and zero profit for Apple.
Memory may be cheap but the increased performance gained from optimizing for code size isn't negligable.
In particular small code can make apps start faster, and the whole computer feel more responsive. The day computers never swap and disk I/O isn't a bottleneck will be the day we can ignore code size in compiler benchmarks.
I've worked on supporting software for both Windows and Linux commercially, and I can assure you the problem is real.
Linux is far, far, far more unstable than Windows is. There are millions of more variations, quite a few of the smaller distros aren't done competently, and the most popular distros like Fedora, Debian, Gentoo rev extremely rapidly. It's not uncommon to do a release then find that a distro which came out a week later contains a bleeding edge new kewl feature which breaks things. In some cases you even get bug reports due to transient packaging issues with distros like Gentoo, in which users routinely upgrade to whatever happens to be newest.
Here's an interesting experiment to try. Grab old versions of minor, unimportant programs like the Sun JVM, RealPlayer, Wine. Now try running them on a modern version of Fedora. They break, often in mysterious ways.
That doesn't happen anywhere near as often on Windows.
Doesn't do any good if Joe Sixpack doesn't download the patch because the mirrors are overloaded (red hat/fedora), because their distro doesn't check for updates automatically out of the box with GUI notification (pretty much any non-fedora/mdk/suse distro), or because their distro doesn't download and apply them automatically (all distros).
Linux isn't really more secure. Most (all?) distros don't perform automatic updates, at most they will notify you that updates are available but I've yet to encounter one that in the default install profile downloads and applies them automatically.
If you know enough to be enabling updates in a cron job, then you aren't the sort of person who's most at risk anyway.
Until Linux distros nearly universally apply updates automatically, without requiring user interaction, and grab them quickly even on dial-up we won't be more secure than Windows. Updates and patches are basically THE best way of staying secure.
Slashdot Mirror
Because it's (a) legal, so they aren't criminals (if they care about this), and (b) Windows, so it runs the applications they want.
Like what? Don't name arbitrary pieces of software, you can always install what you want later.
Some distros use mutually exclusive methods of configuring certain kinds of software
Examples? Where this problem does exist (can't actually think of any off the top of my head), that should be fixed through standardisation.
Some distros will include certain software that others will not; a "standard" distro, to meet everyone's needs, would have to include every single piece of software that every distro out there includes now. That would take up a few dozen CD-ROMs
No it wouldn't. Presumably a standard distro would not *need* to have a subset of all possible software distributed alongside it, you could simply post binary packages on websites and use them.
Random bits embedding each other tends to lead to a a rather messy UI. "Modularity" is not an end itself, it's a means to an end, something that KDE people seem to forget sometimes.
I think it's something they want to do, but it's a bit non-trivial.
Right.
When things go wrong, they're fixable via GUI. Don't need to find a guru, any convenient semi-geek can do the job.
The quality of semi-geeks must be much higher where you live. Last time I checked having a GUI didn't mean Windows could be magically managed by people who weren't trained.
Huh? What's wrong with actually installing Linux? I must have missed something here ... mucking about with Cygwin or a Mac does not teach you Linux, sorry.
To understand what the grandparent is talking about read the primer in the Future Of Money book, or research the fractional reserve system.
It's not hard. Backwards compatibility isn't rocket science, it just requires you to value utility above artistic license.
The kernel, regardless of what some of its developers may think, is not an art project. The most fundamental mission of an operating system is to run the users software and hardware - an OS that refuses to do that on the grounds of API prettyness has got its priorities wrong.
The techniques of maintaining backwards compatibility are well known. You use structure padding, create a new foo_function2() rather than change the prototype of foo_function(), ensure you don't make semantically breaking changes to the behaviour of the APIs, and so on. Most of all you have good testing procedures in place, long beta cycles and such to catch any breaking changes you made that slip through the cracks. It's about management of change.
The arguments about keeping old cruft around are mostly bogus. Backwards compatibility doesn't imply keeping it for ever, even keeping it within stable kernel series would be a big improvements. Likewise, if you take "cruft" out that people are relying on they simply won't upgrade to the newest version and people will be evaluating your software based on buggy, old versions which is no good at all.
The fact that key kernel developers are so far removed from reality is something that should worry us all. Backwards compatibility is viewed as "evil" by far too many people without understanding how essential it is in mass-market software (no, an OS with 1% of the desktop market is not mass-market software, sorry). If you want to make the most academically perfect kernel possible fine, go do it but for heavens sake don't pretend you're writing a production kernel!
I'd go further than that, I'd say it was the one of the biggest piles of self-righteous wanking I've read for a long time.
There are so many pathetic, useless "arguments" in that rebuttal I don't know where to start. He tries to claim that binary compatibility for drivers is "impossible" and anybody who thinks otherwise doesn't "understand the technology". Say what? Solaris engineers don't understand UNIX kernel technology? Microsoft engineers don't understand backwards compatibility?
He brings up pointless details like gcc alignment (Wine uses gcc and controls struct alignment exactly to be compatible with Win32), config options like CONFIG_SMP as if this is some fundamental unarguably facet of kernel design (it's not), and driver interfaces taking up memory (that's what modularity is for, yo).
He seems to live in a fantasy world where the total lack of backwards compatibility doesn't hurt users, it actually makes them happy, and where it's impossible to have both a good kernel and a backwards compatible one - the NT kernel is a 'good' kernel in many respects, yet it still preserves compatibility. Ditto for the Solaris kernel.
He also makes some incorrect statements. Apps written for Linux 1.0 will not necessarily work correctly on 2.6, not if they were broken by NPTL, or if they were shipped as static binaries (which also were broken at some point). OK, these aren't totally problems with the kernel, but if you ignore userspace entirely then you might as well stop talking about "users" and "apps" and go back to embedded work or whatever.
Basically, if there was ever an issue that'd cause the kernel project to fork, it'd be this one. So-called rebuttals from people more interested in straw men and insults aren't going to make that any less likely.
I disagree. This is the "appliance" mentality. We don't want a centralized heap of software, we want a *platform* on which 3rd parties can build with confidence. Right now we're sort of teetering between the two.
Open source software has plenty of bugs, duh.
In fact, there are similar problems with parsing image files on Linux as well. Except that Windows is actually more secure, because it has auto-updates turned on by default from XP2 onwards, and stack protection type patches built in by default. On Fedora you have execshield, but that hasn't been fully upstreamed yet so only a small subset of Linux users are protected. I don't know of any distros that download and apply security patches with no user intervention out of the box.
(recall OS X's open source roots)
Even if open source software was perfect (which it isn't) large parts of MacOS X are not open source. Most of the important bits aren't, in fact. Surprise surprise, the Mac has had serious URL handler exploits which are like this JPEG problem: arbitrary code execution via a web browser. Except in the case of the Mac URL handler problems it was a design problem not just an unchecked buffer, to do with insecure-by-design features. D'oh. ActiveX all over again.
So, no, I don't trust Apple any more than Microsoft when it comes to security. How can you? They are both proprietary OS companies, with all the issues that implies.
can never be duplicated by Microsoft's paranoid and closed-doors efforts
These days Microsoft have dedicated programs scanning their code looking for suspicious patterns, security testing teams, and give their developers extensive training in how to write secure code. These are advantages not available to open source coders. If anything I'd say they're close to taking the lead in absolute terms for security (by which I mean, assume equal market share for Windows, Linux, Macintosh - which is more secure).
I disagree. I find it a perfectly usable hacker desktop as well, and I know quite a few other developers who like it also. If I had to give a Linux desktop to a non-technical friend or family member, I'd choose GNOME. It looks and feels a lot more professional - more like Windows or MacOS in terms of usability ethos.
KDE is more volunteer driven, hence it aims to appeal to fellow developers and home power users, for whom configurability and features are wanted.
I don't think you can draw a line between "volunteer driven" and "corporate driven". KDE is based on a commercial toolkit, which is developed privately by paid developers. Quite a few core KDE developers are paid by SuSE or TrollTech. Meanwhile the volunteer community in GNOME is alive and kicking. It's not anywhere near as polarised as you think.
Finally I'd note that "usability" doesn't mean "stripping out options". It means having software that Just Works without needing tweaking, having sensible options (ie, not "Minimize memory usage"), software designed with the user in mind first and implementation following that, and so on. Lots of things. Don't equate it with dumbed down though, because that's not what usability is about.
Back before Microsoft got involved, Netscape had a near monopoly on browsing. They were the de-facto standard. Today, Google is pretty much the de-facto standard for search though I doubt they have as much market share as Netscape did back then.
Behold the power of bundling with Windows. Netscape is no more. Why? Because Microsoft controlled the gateway through which people accessed their software. Given the noises MS has been making about competing "strongly" with Google lately, they must be scared the same would happen to them except via IE instead of the operating system.
So, they want to produce their own browser, so it gets market share. That way nothing Microsoft does to IE (integrated search etc) can hurt them too much, because not many people are using IE.
It would make sense for them to base it on Firefox. It's a best-of-breed browser, portable, and is going places. But, it lacks marketing! While the current Mozilla efforts are commendable, they'd be nothing compared to being promoted on the Google webpages.
At least, this is the reasoning I'd use if I were them. It's not so much to branch out into new business, as to protect existing ones ...
OK, I'll take your word for it. I said that because the guy who originally published the shatter attack claimed that on non-Administrator users in a default XP install, there were processes running with elevated privs which had hidden windows etc. But, I don't really know for sure.
The main problem is that they come with lots of nasty license clauses that prevent you from redistributing the knowledge and such, so it's not helpful for open source projects.
I'd never heard of these guidelines, or that API before now. Given that on a default Windows XP desktop there were (are?) processes with elevated priviledges running on the interactive desktop, I guess most of the Windows developers hadn't heard of them either.
Wrong, there are quite a lot of messages you can use to cause another program to run arbitrary code. WM_TIMER is only one. That hole was patched but there are other messages with similar properties, searching MSDN will reveal them. New messages are added all the time, you cannot filter them all.
Actually you can't filter WM_TIMER anyway. It's dealt with directly inside GetMessage(), iirc.
Given that one of my friends back home is a serious Mac fanatic (he wants to work for Apple and already works for a reseller, he goes to the expos etc) and has no qualms at all about warezing new OS X versions for his Mac I think releasing MacOS for IA32 would be a fast way to get lots of copies of the OS out there and zero profit for Apple.
In particular small code can make apps start faster, and the whole computer feel more responsive. The day computers never swap and disk I/O isn't a bottleneck will be the day we can ignore code size in compiler benchmarks.
Spoken like somebody who hasn't actually had to do it.
Linux is far, far, far more unstable than Windows is. There are millions of more variations, quite a few of the smaller distros aren't done competently, and the most popular distros like Fedora, Debian, Gentoo rev extremely rapidly. It's not uncommon to do a release then find that a distro which came out a week later contains a bleeding edge new kewl feature which breaks things. In some cases you even get bug reports due to transient packaging issues with distros like Gentoo, in which users routinely upgrade to whatever happens to be newest.
Here's an interesting experiment to try. Grab old versions of minor, unimportant programs like the Sun JVM, RealPlayer, Wine. Now try running them on a modern version of Fedora. They break, often in mysterious ways.
That doesn't happen anywhere near as often on Windows.
Doesn't do any good if Joe Sixpack doesn't download the patch because the mirrors are overloaded (red hat/fedora), because their distro doesn't check for updates automatically out of the box with GUI notification (pretty much any non-fedora/mdk/suse distro), or because their distro doesn't download and apply them automatically (all distros).
If you know enough to be enabling updates in a cron job, then you aren't the sort of person who's most at risk anyway.
Until Linux distros nearly universally apply updates automatically, without requiring user interaction, and grab them quickly even on dial-up we won't be more secure than Windows. Updates and patches are basically THE best way of staying secure.