Right but that's my point - there is a very limited amount of time on your average CS course (3 years here). Given that limited time, something has to give, and right now the bias is so heavily in favour of theory that fundamental and vital practical skills are missing entirely. So right now, it is an either/or situation. Shouldn't be, but that's the reality of student economics.
Yeah. If numbers are dropping it wouldn't surprise me - most courses are so out of touch with the reality of what the students will end up doing, it's just not funny.
It's fashionable around here to bash vocational training and laud theory as "higher". BS. I don't have any statistics but I am totally sure that most CS graduates do not go on to become theoretical computer scientists. If they enter the industry at all they'll probably become programmers or some related field (networking, systems administration etc). So I think it's pretty stupid that students end up graduating with a deep knowledge of theorem proving but about one lectures worth of knowledge on such fundamental things as debugging. It's not equipping them for the real world.
Now I'm sure somebody will get up on their high horse and bitch about how the worlds problems are all due to people who don't understand the difference between O(n) and O(n^2), but consider the inverse: how many unstable, insecure, difficult to use, slow and badly coded programs are there out there simply because graduates are being dumped into the workforce and being forced to learn nearly all of it on the job? I know of at least one, because I've worked on it. Which end is society better served by: a workforce of mathematicians trying to be coders in order to earn a wage outside of HE, or of competent developers?
No, Red Hat and so on may (sometimes) patch GCC but those patches are nicely available in separate files from the vendor. Apples changes are undocumented and not available in a separate form. I know because I've asked Apple for some of them and was told to scrub them out of the tree myself (pretty hard if you aren't intimitely familiar with the internals of gcc). In my mind that is the difference between merely patching and a fork.
Newer versions of GCC have refused to compile more and more code. This is annoying but not the end of the world, you can always just install an older version and use that.
GCC changes do not really break existing binaries. You are thinking of glibc.
Most distros will migrate to GCC4 very soon now. In fact many are already doing so. It's tricky because of the aforementioned refusal to compile particular code so the smaller distros that can't patch every package have to wait for upstream developers to migrate and update their code.
The MIME sniffing isn't hard coded, it's controllable via the freedesktop.org specifications. To add a new MIME type to the system, just add an XML file when you install (or submit it upstream).
Types that don't match any MIME sniffer are assigned an artificial MIME type so the security warning won't trigger.
A menu editor is in development.
Yes, the.desktop thing is an issue. Various solutions have been proposed. The one I like the most (because I proposed it;) is to simply prevent.desktop files with an Exec key or Type=Application from using MIME type icons.
Menus that scroll like win95... if you have menus that long then they probably need to be redesigned. But yes GTK+ could handle this case better.
The point is, what would GNOME 3 be? Something wild and crazy and new? Probably. Does anybody know what that is yet? No. So it makes sense to fork and go off and do this in another branch so the experiment can be tested without affecting mainline GNOME.
The reason they don't do that in the regular unstable dev cycle is because they're 6 months (and also, nobody really knows what would be done for GNOME 3 anyway).
Disagree - if that were true, nobody would work on software that didn't obviously lead to reward. But people hack on open source games like bzFlag that'll never get them a consultancy gig or a book. Do you think Stallman was motivated by kudos? No.
I don't think it's worth speculating too much about the motivations people have for working on free software. For some it's just fun, for others it's an ego trip, for others it's their job and for yet others it's a war against corporate power and the ills of society. It's better to concentrate on the lessons to be learned from the movement, which is what the guys in the article are doing. Good for them, I say.
Speaking as somebody who has had their software shipped by a Linux magazine on the coverdisk, I can tell you they normally use tarballs (or whatever packages the project provides themselves). And no, they don't "know" that the deps are satisfied, most distros suck at this sort of stuff. Do you have GNUtls 8, 9, 10, 11 or 12? For Gaim, it matters.
In the case of a hijacked website, where do you get the key from? Bearing in mind, you can sign autopackages if you like, but then the trick becomes "how do you trust the key". That's what the web of trust is for, but making the web of trust easy to use is somewhat tricky.
No, again, you missed my main point. You don't get autopackages from repositories like Freshrpms, Dag, Livna etc. They come from inkscape.org, gaim.sf.net or wherever. Do you trust the Inkscape developers? If you do, then you should trust their.packages because they are the same people behind both. Again, read the FAQ closely, it's discussed there.
It is a issue, a signed package has the warranty that this is what my packager meant for me to get it, so if I trust my packager I can trust this package. The problem of running a package I downloaded from a random link in the net is that it could have been tampered, I could easily get a.package add a few lines to the script and own me a (few) linux(es) box(es).
I think you missed a vital point about autopackage, which is that they are supposed to be produced by the upstream developers themselves - like DMG/AppFolders/PKG on MacOS or installers on Windows.
So if you trust upstream - the people actually writing the software - you also trust the package. Because they are one and the same.
I'm afraid you also make the mistake of trusting your distribution too much. Large, big name distros have managed before to develop and QA security patches for vulnerabilities that don't exist. This is a fairly basic mistake to make. Don't blindly assume that packagers always add value.
That's correct for Cedega but incorrect for Crossover. Codeweavers base Crossover entirely on the LGPL version of WineHQ, and the vast majority of the work done goes back to HQ as patches. Crossover is rebased to a WineHQ snapshot for every major (3.x, 4.x, 5.x) release.
So yes, it's certainly possible to build a business this way. Hard but possible.
Well, go read the FAQ. It discusses spyware and these sorts of issues. It's not a definitive discussion by any means, but it's a start.
Running a package from an "untrusted source" really isn't an issue, because presumably you're about to run the program anyway. If you aren't, why do you have the package in the first place? If you don't trust upstream, it's a bad idea to be running their software in the first place.
The problem with your proposal is that often there won't be a package for the users distro, or there will be but it's out of date. This would lead to you being able to install an app by clicking the link on your desktop machine, but not your laptop (because laptop is running an older version of the distro, or a different distro). It's addressing the usability aspects without dealing with the underlying issues. And a deeper usability issue is unpredictability.
Ah well. That's the crux of the issue isn't it. The differences between Ubuntu and Fedora are marginal. The desktops are similar. They are based on the same components (or will be, once FC4 is out). They are neck and neck on features: Ubuntu has nicer auto-update and package management tools, Fedora has nicer and more comprehensive config tools.
One reason that people like Ubuntu is Synaptic and Universe. Because, put bluntly, installing things on Ubuntu is marginally less of a pain in the ass on this distro than on others. I think this is a poor way to compete. It takes peoples eye off the ball: even if Ubuntu has more packages and apt-get is nicer than yum, they all suck compared to the user experience on MacOS X or Windows. For Ubuntu you have to manually enable extra repositories, and there are no guarantees it will work (that's kinda why Sid is called "unstable"). For Fedora, there is no GUI and even if there was, Extras is quite small.
If instead of getting into a pointless pissing match over who has the most packages, these organisations focussed purely on making a slick desktop a la the Mac, I do believe Linux would get better faster. I think this is the most sensible thing to do. But then... what would distinguish Ubuntu from Fedora?
Good question. Great question, in fact. I think the answer is that there'd be little to no real differences. Maybe having two going at it at once keeps some flexibility in the system: if one group rejects a solution due to personality politics or whatever, the other can pick it up and carry on. But given Marks money, was creating Yet Another Distribution really the best way to spend it? There were other ways of advancing the cause of free software: sponsoring individual projects for instance.
Actually the distro development team at Red Hat was at least a few years ago about 10 people too. At least, this is what one RH employee told me. They have other teams of course who work on the toolchain, GNOME etc, but up until Fedora was launched I think only about 10 people assembled the distro and worked on the config tools/installer.
Even if every member of RH Engineering (~100 people a few years ago, more now) had worked on the distro, so what? Debian has nearly 1000 developers!
Even though the Inkscape package is a version old, I think it's still very valuable to have. I know that I can install Inkscape and it will work. I don't think that the few extra features that are developed in six months time are worth sacrificing stability and reliability.
You are conflating two different things: stability of the package repository and stability of the software. Inkscape 0.41 includes bug fixes that weren't necessarily in 0.40. Generally, software gets better the more it is developed. In a few cases this sometimes isn't true, but generally it is.
One thing I've seen Debian supporters say more and more often lately is that it's OK that Debian Stable is old, because when you're working you need stability. Fine. But the "stable" in Debian stable does not refer to the software. It refers to the behaviour of apt. There are lots of bugs in old versions of Mozilla etc shipping in Woody which were fixed in later versions.
All distributions do is take free software and put it together in a package that works.
No, this is what Debian does. Other distributions like Fedora or Xandros take free software, integrate it, improve it, and produce an installable operating system out of it. Yes a lot of this work involves packaging, but other parts involve writing new software, working on things upstream. Distributions are useful because they are a grounding point at which you can tie together all the loose ends that otherwise might not be connected by upstream projects. It lets you take a look at the Big Picture and work on new things relative to that.
When there are problems with a program, you go to the distro first. They figure out what's wrong, and either fix it or notify upstream if that's where the problem is.
No, no they don't. I know this is what is supposed to happen, but it doesn't. Instead end users who can't tell the difference between broken software and broken packages report it upstream.
In this utopian vision where everybody uses free software, where everybody uses Debian, where nobody reports bugs to upstream etc, this ideal might stand a chance of working. But we don't live in anything even resembling an approximation of this world. Instead of trying to control everything and constantly having the details slip through your fingers, it's better to provide the land on which others can build their houses and let the free market take care of the rest.
Well, I'm not really convinced that Debian can grow to an infinite size. While I certainly think it's true that the larger Linux community can, because that's not really a formal organisation per se, Debian does empirically seem to have problems with it.
Now it's true that Fedora is a bit of a mess when it comes to 3rd party package repositories, maybe this will start getting sorted out with FC4 when Fedora Extras is enabled by default, but still... fundamentally Fedora seem to be bombing down the same path that Debian/Ubuntu are, and quite apart from whether or not this can scale the usability implications are serious.
Personally, I'm not convinced it can. While more and more people can dump packages into the Debian pool with no real limits, it's not just the number of packagable programs that are increasing exponentially, it's also the number of distributions. Maybe this system could work if people only used Debian, but they don't - the community is not increasing in size so fast that every distro can have every possible package and keep it up to date. Something has to give.
Now, let's say that Debian did formally decide to disconnect the bulk of its packages from itself. Maybe they'd spin off into third party repositories, or maybe they'd disappear entirely and be replaced with multi-distro packages developed by upstream. The total number of people attacking the problem doesn't decrease, in fact if you go for packages that work on any distro the amount of testing increases because a bug in the package can be picked up much faster.
For instance, in Wine there are a large number of packages and nearly every one has its own quirks. Fixes from one don't migrate to another, in fact often packages sprout new bugs as distribution packagers try to improve them with no real understanding of the software. If most Linux users got the software from a single package, it could be sensibly maintained in CVS like the rest of the code, worked on by the entire community and so on.
Effort can be combined to produce a better quality package.
Actually, last time you ranted on Slashdot you got roundly thrashed by people replying to you, who I seem to recall thought you were "incredibly elitest" amongst other things.
So far you have explained nothing, you've just flamed. This behaviour does not impress me. You apparently haven't even read the FAQ or the discussions on OSNews about malware and spyware. Once you managed to gather some arguments, instead of wildly waving around assertions, I might take you more seriously.
What I think both Debian and Ubuntu should do is forget about their huge package repositories, on the grounds that it's an unscalable way to distribute software and focus purely on making a great OS. That means things like UTF8, graphical installers, graphical config tools, SELinux integration.
These are all being worked on. But see how Fedora was ahead of them in all of these areas, and in some still is. That's because the Red Hat team focussed purely on the base distro instead of trying to package everything in the world, which is impossible.
Now, Ubuntu basically has a chance to do this. Strip even more out of main - why is Inkscape there? How many Ubuntu users are also vector graphics artists? It's out of date already, and has been for months, yet you can get up to date packages direct from inkscape.org. Take it to the logical conclusion: make Ubuntu a base operating system that is super easy to extend, with only the basics in main (music player, web browser etc).
Now support 3rd party packaging, so users can go to inkscape.org if they want a graphical editor and install it straight from there. I think they should use autopackage to do that, but I'm biased. There could be any number of ways of doing it. The point is, stop being packagers and become OS developers.
Ubuntu could do this without too much pain. Debian, on the other hand, never could. When you think of Debian, do you think of a slick, modern desktop OS? No? Neither do I. I think of 18,000 packages. But who cares how many packages you have, if the OS sucks. If Debian were to deprecate most of the packages, it would cease to have a purpose on the desktop because it's such a poor desktop OS (as Ubuntu has made clear). It could refocus and with time, catch up, but it would take a lot of effort and dedication and belief in the new way. I don't think Debian can do that. I think it'll fade away rather than change.
Attempting to package everything the user wants is sinking Debian, and it'll sink Ubuntu too unless they change the philosophy instead of just doing minor tweaks. Ubuntu universe includes Coq, a theorem prover whos own authors estimate that it has only 100 regular users, yet does not include gaim-vv, which adds webcam support to Gaim. What is wrong here?
Yes. I mean this is a total non-issue, you can't take an arbitrary Debian package and install it on any Debian system anyway, and never could. For instance if you add the Debian repositories to a Mepis or Xandros system, you can break it quite badly. Also of course, in Debian unstable package names change, they get split up, merged, sometimes they disappear entirely. So this incompatibility already exists.
It's also rather annoying that Murdoch witters on about "avoiding the fate of the RPM world" - uh, hello? Last time I checked we're all Linux users. And Linux ISVs hate the current situation because they already have to produce lots of packages, or more likely simply not bother and produce a Loki Setup or a tarball (tarball! how DOS is that?).
Debians problems seem to be directly tracable to:
Too many packages, meaning it's too hard to stabilise them all. You can't release until they're all stabilised, but the need to keep up to date means a constant influx of new packages
Too many architectures - if a package doesn't work on one, it blocks all of them
Too little vision, too little radical leadership. The idea of reducing the repository sizes, or splitting them off into unsupported third party repos and having Debian just provide a base system, is apparently unthinkable to the Debian leaders. So the project bumbles along with no real clear ideas of how to extract themselves from the quicksand they're in.
The end result is Ubuntu - a fork. Unfortunately Ubuntu doesn't really tackle the packaging problem seriously: it improves on Debian by only stabilising a small base system, but this means you get to choose between (a) an out of date and small but stable repository (main) or (b) a large and up to date but often broken repository (universe). And I still haven't figured out WTF the "metaverse" is yet.
Unfortunately the Ubuntu developers only go so far - they still believe it's possible for Ubuntu to package everything end users will ever need, even though at least in Warty, universe wasn't even enabled by default. I don't see any way for Ubuntu to stabilise universe without getting bogged down in the same mud that Debian did.
Importing CVS branches is really hard because CVS itself is just a huge hack. I've been using SVK lately for local Wine development and it's worked pretty well. The startup time is a pain in the ass, but there are ways around it and I think that's been much improved in the recent versions. I'd definitely say it's mature.
Best of all, the SVK maintainers are incredible. If I find a problem, I literally report it to them on IRC and a few minutes later it's fixed. I've yet to encounter a bug in SVK that required more than a 20 line patch from them to fix. It also has test coverage of over 90% - unbelievable.
Basically, I don't see why Linus is not giving SVK more attention. It's pretty fast, already stores the kernel tree (this is one of its main test cases), has the same sort of features as Arch or BitKeeper except with a friendly interface, and the code is clean and robust. The only downside is the tricky install - if CPAN bails out, things get tough.
Uh, why not? You're running an implementation that you can see the source to, so the only difference is that presumably you've been doing it on Windows for longer and therefore trust it more. But Windows is not a static thing (or shouldn't be) - there are patches for it all the time. So why don't you trust a stable, tested codebase that you control and don't have to patch for security every Tuesday, but you do trust Microsofts equivalent?
I think you are generalising a bad experience with broken packages and consumer software up to everything, which isn't valid.
I'm thinking more of the fact that they try hard to exclude binary only drivers even when there's no GPL equivalent. Doing it for arch reasons is screwing over the vast majority who use x86 for the benefit of the minority, who don't get drivers anyway because being annoying and fiddly to make Linux drivers apparently just encourages workarounds like the nVidia wrapper rather than causing drivers to be opened up.
Slashdot Mirror
Right but that's my point - there is a very limited amount of time on your average CS course (3 years here). Given that limited time, something has to give, and right now the bias is so heavily in favour of theory that fundamental and vital practical skills are missing entirely. So right now, it is an either/or situation. Shouldn't be, but that's the reality of student economics.
It's fashionable around here to bash vocational training and laud theory as "higher". BS. I don't have any statistics but I am totally sure that most CS graduates do not go on to become theoretical computer scientists. If they enter the industry at all they'll probably become programmers or some related field (networking, systems administration etc). So I think it's pretty stupid that students end up graduating with a deep knowledge of theorem proving but about one lectures worth of knowledge on such fundamental things as debugging. It's not equipping them for the real world.
Now I'm sure somebody will get up on their high horse and bitch about how the worlds problems are all due to people who don't understand the difference between O(n) and O(n^2), but consider the inverse: how many unstable, insecure, difficult to use, slow and badly coded programs are there out there simply because graduates are being dumped into the workforce and being forced to learn nearly all of it on the job? I know of at least one, because I've worked on it. Which end is society better served by: a workforce of mathematicians trying to be coders in order to earn a wage outside of HE, or of competent developers?
No, Red Hat and so on may (sometimes) patch GCC but those patches are nicely available in separate files from the vendor. Apples changes are undocumented and not available in a separate form. I know because I've asked Apple for some of them and was told to scrub them out of the tree myself (pretty hard if you aren't intimitely familiar with the internals of gcc). In my mind that is the difference between merely patching and a fork.
GCC changes do not really break existing binaries. You are thinking of glibc.
Most distros will migrate to GCC4 very soon now. In fact many are already doing so. It's tricky because of the aforementioned refusal to compile particular code so the smaller distros that can't patch every package have to wait for upstream developers to migrate and update their code.
Types that don't match any MIME sniffer are assigned an artificial MIME type so the security warning won't trigger.
A menu editor is in development.
Yes, the .desktop thing is an issue. Various solutions have been proposed. The one I like the most (because I proposed it ;) is to simply prevent .desktop files with an Exec key or Type=Application from using MIME type icons.
Menus that scroll like win95 ... if you have menus that long then they probably need to be redesigned. But yes GTK+ could handle this case better.
The point is, what would GNOME 3 be? Something wild and crazy and new? Probably. Does anybody know what that is yet? No. So it makes sense to fork and go off and do this in another branch so the experiment can be tested without affecting mainline GNOME.
The reason they don't do that in the regular unstable dev cycle is because they're 6 months (and also, nobody really knows what would be done for GNOME 3 anyway).
I don't think it's worth speculating too much about the motivations people have for working on free software. For some it's just fun, for others it's an ego trip, for others it's their job and for yet others it's a war against corporate power and the ills of society. It's better to concentrate on the lessons to be learned from the movement, which is what the guys in the article are doing. Good for them, I say.
Speaking as somebody who has had their software shipped by a Linux magazine on the coverdisk, I can tell you they normally use tarballs (or whatever packages the project provides themselves). And no, they don't "know" that the deps are satisfied, most distros suck at this sort of stuff. Do you have GNUtls 8, 9, 10, 11 or 12? For Gaim, it matters.
No there doesn't, nothing stops you putting many packages from different places onto one CD. Magazines do it with their coverdisks all the time.
In the case of a hijacked website, where do you get the key from? Bearing in mind, you can sign autopackages if you like, but then the trick becomes "how do you trust the key". That's what the web of trust is for, but making the web of trust easy to use is somewhat tricky.
No, again, you missed my main point. You don't get autopackages from repositories like Freshrpms, Dag, Livna etc. They come from inkscape.org, gaim.sf.net or wherever. Do you trust the Inkscape developers? If you do, then you should trust their .packages because they are the same people behind both. Again, read the FAQ closely, it's discussed there.
I think you missed a vital point about autopackage, which is that they are supposed to be produced by the upstream developers themselves - like DMG/AppFolders/PKG on MacOS or installers on Windows.
So if you trust upstream - the people actually writing the software - you also trust the package. Because they are one and the same.
I'm afraid you also make the mistake of trusting your distribution too much. Large, big name distros have managed before to develop and QA security patches for vulnerabilities that don't exist. This is a fairly basic mistake to make. Don't blindly assume that packagers always add value.
So yes, it's certainly possible to build a business this way. Hard but possible.
Running a package from an "untrusted source" really isn't an issue, because presumably you're about to run the program anyway. If you aren't, why do you have the package in the first place? If you don't trust upstream, it's a bad idea to be running their software in the first place.
The problem with your proposal is that often there won't be a package for the users distro, or there will be but it's out of date. This would lead to you being able to install an app by clicking the link on your desktop machine, but not your laptop (because laptop is running an older version of the distro, or a different distro). It's addressing the usability aspects without dealing with the underlying issues. And a deeper usability issue is unpredictability.
One reason that people like Ubuntu is Synaptic and Universe. Because, put bluntly, installing things on Ubuntu is marginally less of a pain in the ass on this distro than on others. I think this is a poor way to compete. It takes peoples eye off the ball: even if Ubuntu has more packages and apt-get is nicer than yum, they all suck compared to the user experience on MacOS X or Windows. For Ubuntu you have to manually enable extra repositories, and there are no guarantees it will work (that's kinda why Sid is called "unstable"). For Fedora, there is no GUI and even if there was, Extras is quite small.
If instead of getting into a pointless pissing match over who has the most packages, these organisations focussed purely on making a slick desktop a la the Mac, I do believe Linux would get better faster. I think this is the most sensible thing to do. But then ... what would distinguish Ubuntu from Fedora?
Good question. Great question, in fact. I think the answer is that there'd be little to no real differences. Maybe having two going at it at once keeps some flexibility in the system: if one group rejects a solution due to personality politics or whatever, the other can pick it up and carry on. But given Marks money, was creating Yet Another Distribution really the best way to spend it? There were other ways of advancing the cause of free software: sponsoring individual projects for instance.
Has it occurred to you that distribution independent packages don't necessary need an internet connection? You can put them on CDs too.
Even if every member of RH Engineering (~100 people a few years ago, more now) had worked on the distro, so what? Debian has nearly 1000 developers!
You are conflating two different things: stability of the package repository and stability of the software. Inkscape 0.41 includes bug fixes that weren't necessarily in 0.40. Generally, software gets better the more it is developed. In a few cases this sometimes isn't true, but generally it is.One thing I've seen Debian supporters say more and more often lately is that it's OK that Debian Stable is old, because when you're working you need stability. Fine. But the "stable" in Debian stable does not refer to the software. It refers to the behaviour of apt. There are lots of bugs in old versions of Mozilla etc shipping in Woody which were fixed in later versions.
No, this is what Debian does. Other distributions like Fedora or Xandros take free software, integrate it, improve it, and produce an installable operating system out of it. Yes a lot of this work involves packaging, but other parts involve writing new software, working on things upstream. Distributions are useful because they are a grounding point at which you can tie together all the loose ends that otherwise might not be connected by upstream projects. It lets you take a look at the Big Picture and work on new things relative to that.
No, no they don't. I know this is what is supposed to happen, but it doesn't. Instead end users who can't tell the difference between broken software and broken packages report it upstream.
In this utopian vision where everybody uses free software, where everybody uses Debian, where nobody reports bugs to upstream etc, this ideal might stand a chance of working. But we don't live in anything even resembling an approximation of this world. Instead of trying to control everything and constantly having the details slip through your fingers, it's better to provide the land on which others can build their houses and let the free market take care of the rest.
Now it's true that Fedora is a bit of a mess when it comes to 3rd party package repositories, maybe this will start getting sorted out with FC4 when Fedora Extras is enabled by default, but still ... fundamentally Fedora seem to be bombing down the same path that Debian/Ubuntu are, and quite apart from whether or not this can scale the usability implications are serious.
Personally, I'm not convinced it can. While more and more people can dump packages into the Debian pool with no real limits, it's not just the number of packagable programs that are increasing exponentially, it's also the number of distributions. Maybe this system could work if people only used Debian, but they don't - the community is not increasing in size so fast that every distro can have every possible package and keep it up to date. Something has to give.
Now, let's say that Debian did formally decide to disconnect the bulk of its packages from itself. Maybe they'd spin off into third party repositories, or maybe they'd disappear entirely and be replaced with multi-distro packages developed by upstream. The total number of people attacking the problem doesn't decrease, in fact if you go for packages that work on any distro the amount of testing increases because a bug in the package can be picked up much faster.
For instance, in Wine there are a large number of packages and nearly every one has its own quirks. Fixes from one don't migrate to another, in fact often packages sprout new bugs as distribution packagers try to improve them with no real understanding of the software. If most Linux users got the software from a single package, it could be sensibly maintained in CVS like the rest of the code, worked on by the entire community and so on. Effort can be combined to produce a better quality package.
So far you have explained nothing, you've just flamed. This behaviour does not impress me. You apparently haven't even read the FAQ or the discussions on OSNews about malware and spyware. Once you managed to gather some arguments, instead of wildly waving around assertions, I might take you more seriously.
How can a GPLd tool that is used by several competing vendors (Red Hat, Mandrake, SuSE) possibly be a tool for vendor lockin?
What I think both Debian and Ubuntu should do is forget about their huge package repositories, on the grounds that it's an unscalable way to distribute software and focus purely on making a great OS. That means things like UTF8, graphical installers, graphical config tools, SELinux integration.
These are all being worked on. But see how Fedora was ahead of them in all of these areas, and in some still is. That's because the Red Hat team focussed purely on the base distro instead of trying to package everything in the world, which is impossible.
Now, Ubuntu basically has a chance to do this. Strip even more out of main - why is Inkscape there? How many Ubuntu users are also vector graphics artists? It's out of date already, and has been for months, yet you can get up to date packages direct from inkscape.org. Take it to the logical conclusion: make Ubuntu a base operating system that is super easy to extend, with only the basics in main (music player, web browser etc).
Now support 3rd party packaging, so users can go to inkscape.org if they want a graphical editor and install it straight from there. I think they should use autopackage to do that, but I'm biased. There could be any number of ways of doing it. The point is, stop being packagers and become OS developers.
Ubuntu could do this without too much pain. Debian, on the other hand, never could. When you think of Debian, do you think of a slick, modern desktop OS? No? Neither do I. I think of 18,000 packages. But who cares how many packages you have, if the OS sucks. If Debian were to deprecate most of the packages, it would cease to have a purpose on the desktop because it's such a poor desktop OS (as Ubuntu has made clear). It could refocus and with time, catch up, but it would take a lot of effort and dedication and belief in the new way. I don't think Debian can do that. I think it'll fade away rather than change.
Attempting to package everything the user wants is sinking Debian, and it'll sink Ubuntu too unless they change the philosophy instead of just doing minor tweaks. Ubuntu universe includes Coq, a theorem prover whos own authors estimate that it has only 100 regular users, yet does not include gaim-vv, which adds webcam support to Gaim. What is wrong here?
It's also rather annoying that Murdoch witters on about "avoiding the fate of the RPM world" - uh, hello? Last time I checked we're all Linux users. And Linux ISVs hate the current situation because they already have to produce lots of packages, or more likely simply not bother and produce a Loki Setup or a tarball (tarball! how DOS is that?).
Debians problems seem to be directly tracable to:
The end result is Ubuntu - a fork. Unfortunately Ubuntu doesn't really tackle the packaging problem seriously: it improves on Debian by only stabilising a small base system, but this means you get to choose between (a) an out of date and small but stable repository (main) or (b) a large and up to date but often broken repository (universe). And I still haven't figured out WTF the "metaverse" is yet.
Unfortunately the Ubuntu developers only go so far - they still believe it's possible for Ubuntu to package everything end users will ever need, even though at least in Warty, universe wasn't even enabled by default. I don't see any way for Ubuntu to stabilise universe without getting bogged down in the same mud that Debian did.
Best of all, the SVK maintainers are incredible. If I find a problem, I literally report it to them on IRC and a few minutes later it's fixed. I've yet to encounter a bug in SVK that required more than a 20 line patch from them to fix. It also has test coverage of over 90% - unbelievable.
Basically, I don't see why Linus is not giving SVK more attention. It's pretty fast, already stores the kernel tree (this is one of its main test cases), has the same sort of features as Arch or BitKeeper except with a friendly interface, and the code is clean and robust. The only downside is the tricky install - if CPAN bails out, things get tough.
I think you are generalising a bad experience with broken packages and consumer software up to everything, which isn't valid.
I'm thinking more of the fact that they try hard to exclude binary only drivers even when there's no GPL equivalent. Doing it for arch reasons is screwing over the vast majority who use x86 for the benefit of the minority, who don't get drivers anyway because being annoying and fiddly to make Linux drivers apparently just encourages workarounds like the nVidia wrapper rather than causing drivers to be opened up.