I'm inclined to agree, but, apparently, there are hardware manufacturers who sue anyone who distributes their binary blobs without permission, but are quite happy to give Ubuntu and Debian and Redhat permission.. Freedom is not having to ask permission.
The Debian Free Software Guidelines (paragraph 8) clearly says that "License Must Not Be Specific to Debian".
Like the article tells, Debian developers are currently negotiating if the firmware blobs should be removed before or after the Lenny release. In any case, Debian developers are removing all the kernel binary blobs from their main repository and they won't distribute any software where the distribution license is not the same for everyone.
AFAIK, the Debian installer for Lenny already checks your hardware and it prompts for additional non-free packages of drivers or firmware (which the user needs to download separately from the installer) if your hardware needs them to work properly. Then it's up to the user to decide if non-free drivers or firmware will be installed.
Also Debian has release cycles, you know. But while Ubuntu's release cycles are inflexible and tied to arbitrary release dates, Debian's release cycles are more flexible and they can afford to wait until the release has actually become stable and ready.
You mention GNOME and Linux as examples that other projects should follow, but you should remember that the early GNOME2 releases were unusable crap, as were were the early Linux 2.6 releases. KDE4 also makes time-based releases now, and so far their releases have been crap. But once GNOME2 and Linux 2.6 matured, they started to make quite usable releases. And it looks like KDE4 will also mature soon, so I'd expect they'll too start making usable releases in the near future.
With distros it's a bit different, though. Distros package software from various sources, and they can refuse to include software that they consider to be just development previews (like early GNOME2, early Linux 2.6, or early KDE4). Distros can cherry-pick stuff that is known to work without problems, if they want to. Or they can include the latest and greatest versions of software and then put their hands together in prayer, hoping that everything works -- even if they haven't really had time to test it.
Ubuntu wants to include the latest versions of software in their releases (even in the so called "LTS" releases), and they have a strict release schedule they need to obey. Quite often this means that they don't have much time to test the software that they include in their releases. Ubuntu is also known to ship with pre-release versions of some popular software programs, even in the "LTS" releases. With such a misguided release policy, Ubuntu can never become mature enough to make releases that are actually stable and well-tested.
Debian, on the other hand, cherry-picks software that is known to work, and they also take time to carefully test software that goes into their stable releases. They only release when the developers think that all the serious bugs have been fixed and the release has really become stable. That's really the reason why Debian releases are so much more stable and trouble-free than Ubuntu releases.
Only two months later than expected, the Debian project has completed the first release candidate of Lenny's installer.
Unfortunately, an installer RC is not the final distribution release.
Lookout, world, Debian releases are picking up speed!
I don't think so. It'll still take a couple more months before the final Lenny release will be out. There will yet be another installer release candidate (RC2), and that will also need some further testing before the final release.
Still, I think the Lenny release will be well worth the wait for users who want a stable server OS. (Desktop users would prefer Debian's "testing" branch because it has more up-to-date software.) Debian doesn't put out half-assed and buggy releases just to meet arbitrary release dates, like Ubuntu does. Debian won't make a stable release until it's really ready and stable.
Ubuntu, AIUI, made a deliberate decision to be slightly less anal about rock solid stability and nailing every last bug, in order to be able to ship more up-to-date versions of the applications that most people use day to day. Crashes are undesirable, but having features missing that you want to use is also undesirable. And having said that, Ubuntu is usually pretty bomb-proof too.
Unfortunately, it appears that only a small minority of users have found the latest Ubuntu release (which is also their "Long Term Support" release) "bomb-proof".
It is also worth noticing that Ubuntu doesn't officially support their "universe" component (although there are some community members who try to support "universe" packages on a best-efforts basis). This means that the Ubuntu Security Team doesn't scan packages in "universe" for potential vulnerabilities, although "universe" in enabled by default. This is another deliberate decision that Ubuntu has made -- they have decided to be less anal about both security and stability in order to meet arbitrary release deadlines.
Notice that Debian fixed the OpenSSL vulnerability as soon as somebody found it and filed a bug report about it. (In this case, the person who discovered the bug was a Debian developer.)
Obviously, Debian developers can't fix bugs that they don't know about. It's just as important to report bugs as it is to fix them. Making a stable Debian release is a community effort -- users report any bugs they can find and developers do their best to fix the important bugs that actually affect usability, stability, or security of the programs that Debian packages.
So let's fix that sentence you quoted:
There needs to be distros like Debian which, while always delayed, has all the reported important bugs ironed out.
You can say "It's disappointing that Debian missed their internal goal of releasing Lenny in early September 2008". But you can't really say "It's disappointing that Debian failed to release Lenny in September as they promised", because the official release schedule clearly says that Lenny will be released "in the second half of 2008".
So that's what they've actually promised, and there's still plenty of time to keep that promise. Just a week ago the number of RC bugs in Debian was over 270. Now it's a bit more than 200. It'll be interesting to see what the RC bugs count shows one week from now.
I've used sourcemage for a about year or so and I absolutely love its package manager, "sorcery". You type "sorcery" in terminal and it opens an ncurses menu where you can set compile flags and other package manager settings. You can also use the same sorcery menu for browsing/installing/upgrading/removing packages but it's really quicker to check out the man pages for "cast", "dispel", "gaze", and "cleanse", and then just use the command line for package management. When sorcery installs packages, it asks a bunch of questions about dependencies and the next time you upgrade the same package, it remembers the dependencies you chose last time.
I also tried lunar recently. Lunar seems to be rather similar to sourcemage, except they call their package manager "lunar", and they have also different names for the other package management commands. Lunar doesn't appear to support rebuilding the whole system, which I like to do after upgrading gcc, glibc, or binutils. In sourcemage I type "sorcery rebuild" and it rebuilds all the installed packages. In lunar the equivalent command "lunar rebuild" didn't seem to do much anything. I also feel that I get much better control over optional dependencies and build options for individual packages in sourcemage, so I decided to dump lunar.
Sourcemage has pretty up-to-date packages: gcc 4.3.1, glibc 2.7, and so on. Openoffice2 (2.4.1) is only available as a binary package. In sourcemage it's really easy to track the latest development versions of KDE4. There are two alternative package collections ("grimoires") that you can choose from: "test" that is updated every day, and "stable" that is updated once every month. And then there's an additional "grimoire" for games ("games") and also one for non-free and/or binary-only packages ("z-rejected"). There are over 5000 source packages available in sourcemage -- that's more than in most other distros. Sourcemage follows a similar policy as slackware: they prefer not to modify upstream packages by adding any distro-specific patches, except when packages fail to compile.
I see currently only two problems in sourcemage: they haven't released a new installer for a while, and they still officially have only xorg version 6.9 (newer versions of xorg are unofficially available, but you need to jump through extra hoops to install one). The sourcemage mailing list discussions suggest that both of these issues might be solved before the end of this summer. In the meanwhile I'm using xorg 1.3.0 that is not overly difficult to install (the instructions can be found in the sourcemage wiki's xorg-howto, under "using old repository").
Here are links to the mailing list archives and xorg-howto, in case anyone is interested to learn more:
Yea, I've used debian with/bin/sh pointing to/bin/dash long before ubuntu made it the default setting. The command that does the switching is "dpkg-reconfigure dash".
I checked the Wikipedia article about dash and it seems that ubuntu switched to dash a bit hurriedly. The article says that "the transition in Ubuntu to making dash/bin/sh broke numerous shell scripts that relied upon Bash-specific functionality". Typical of ubuntu.
The same article says that debian will switch to using dash as the default/bin/sh with the release of Lenny (scheduled for September 2008).
http://en.wikipedia.org/wiki/Debian_Almquist_shell
Thanks. Your reply adds useful information to your original post.
So we can agree that the process isn't really quite as automatic as your original description indicates. Packages that don't have complex dependencies or reported release-critical bugs can pass from unstable to testing automatically but many important packages with complex dependencies (like linux, gcc, glibc, dpkg, python, xorg, gnome, kde,...) nearly never migrate to testing without careful planning and manual pushing.
> Debian "testing" is upgraded several times a month.
Wrong. Debian testing is updated automatically from packages in Debian unstable. The difference is simply that a package has to sit in Debian unstable for a few days, and no significant bugs can be introduced by the new package, before it is updated. Since the process is automatic, Debian testing is updated just slightly less continuously as unstable (it depends on the robot to check the package dependencies and bug reports rather than the maintainer to upload a new version).
There are robots among debian developers, eh?;-)
I don't think the process of migrating packages from unstable to testing is quite as automatic as you describe. At least, the most important packages (like linux, gcc, glibc, dpkg, python, xorg, gnome, kde,...) don't migrate automatically. These transitions are made only when the maintainers think they're ready to be included in the next stable debian release and when they're sure that they don't break anything.
> Debian "stable" is upgraded every one or two years.
It usually takes slightly longer than two years.
Yes, but haven't you noticed a definite change with the release timetables for etch and lenny? Etch was originally planned to be released 18 months after sarge, although it actually took 22 months because there was a four-month long delay. And now lenny is planned to be released in September 2008, which would be 17 months after the etch release. To me this seems like debian has lately adopted the goal of a 18-month long release cycle, although slight alterations are always possible because debian stable is only released "when it's ready."
Why does it have to be so damn hard to insert page numbers to documents in OpenOffice.org Writer?
When I click the drop down menu "Help" -> "OpenOffice.org Help F1" and type "page numbers" as the search term and then "footers," I get this advice:
Inserting Page Numbers in Footers 1.Choose Insert - Footer and select the page style that you want to add the footer to. 2.Choose Insert - Fields - Page Number.
So far so good, I follow the instructions and my document gets page numbers. By default, the page numbers are aligned to the left side of the page, so next I need to click the "Styles and Formatting" button and in the box that opens next, I need to right-click "Footer" and choose "Modify..." Then a new box opens and there I need to click the "Alignment" tab and then choose "Center" and then click the "OK" button.
Well, now I've got page numbers on the bottom of my document pages, aligned to the center -- just the way I like them. But adding the page numbers has changed my document's layout, decreasing the hight of pages. So now I need to adjust the top margins of my document. So it's time for "Styles and Formatting" again, and there I need to click "Page Styles" and then right-click "Default" and choose "Modify..." Then I need to click the "Page" tab and change Top Margin from 2,00cm to 1,00cm and then hit the "OK" button.
After all these actions, I've got page numbers in my document and the document layout is just like it was before adding the page numbers. But it just seems an awful lot of trouble for doing such a simple operation. And I have to repeat the same routine again with every new document where I want to add page numbers. In Microsoft Word and Abiword you can add page numbers with just a couple of simple clicks, without altering the document's layout.
I haven't tried OpenOffice.org 2.3 yet but I don't really expect they've made adding page numbers any easier in this new version.:-(
Yeah, but do you know where the "Gutsy Gibbon" name originally comes from?
Well, you just need to give computers to an infinite number of gibbons (the "One Laptop Per Gibbon" campaign, OLPG) and if the gibbons are gutsy enough, you can rest assured that they'll eventually manage to write the code for Ubuntu 7.10.
I remember a time when ck-patches for the 2.4 kernels made openoffice start in half the time it took with an unpatched kernel. In those days a Debian derivative distro called Libranet used ck-patched 2.4 kernels and Libranet was called "Debian on steroids", for a good reason.
I've lately used a source-based distro called Source Mage and they make it very easy to apply the most commonly used kernel patches (you can choose the patches you want from a menu when you start to compile a new kernel) and so I tested some current ck-patches on recent 2.6 kernels but I didn't notice any speed improvements while using desktop applications.
So I guess there's not much need for those ck-patches any more. I recall that the kernel upgrade 2.4 -> 2.6 made desktop apps a lot more responsive. Maybe the kernel developers accepted some of Con's improvements to the mainline 2.6 kernel. So long, Con, and thanks for all the fish!
The interviewer asks some very good questions about the weak areas in Ubuntu-Canonical's business strategy and Shuttleworth has to dodge many questions and hide behind half-truths, handwaving and his usual marketing gobbledygook.
Ubuntu allegedly has a "policy of not doing our own software development, but only packaging what others have developed" -- with the few rare exceptions like the Upstart init system. Ubuntu-Canonical doesn't hire any top developers to do upstream development like some other commercial distros, Red Hat and Novell, do. For this precise reason, the GNOME hacker Jeff Waugh had to leave Ubuntu when he wanted to concentrate on developing GNOME.
Given this background, I'm inclined to believe that Shuttleworth is heavily distorting the reality when he claims that a lot of KDE 4 development is now happening inside of Ubuntu. This is one of the several points where I would have wished the interviewer to be a bit tougher and to push a bit harder in order to dig out the truth behind Shuttleworth's marketing talk. Of course, if Ubuntu-Canonical has indeed changed their policy lately and if they are now hiring KDE developers to do upstream development for KDE 4, then this revelation would have greatly added the news value of the interview. It's unfortunate that the interviewer didn't push this question (and some other questions) any further but, instead, left Shuttleworth's dubious claims open for speculations.
Ubuntu is a Debian daughter, and its own success depends on the success of the Debian project.
Yup, Ubuntu-daughter leads a largely independent life of her own but she still comes home every once in a while to grab the food (new packages) that Debian-mother has made. Without these regular food supplies from mother, Ubuntu would be in a serious danger of starving. And Ubuntu also sends a lot of her clothes (bug reports) home for Debian-mother to wash and iron.
Many of Ubuntu's strengths are inherited directly from Debian. It's quite amazing that there currently doesn't seem to be any worthwhile competition to Ubuntu on the desktop arena. A Debian-based system with some desktop polish seems to be a hot item today. Some other desktop-oriented distros have features that Ubuntu lacks, but Ubuntu's Debian-inheritance is a great advantage that those other distros lack.
Debian's release cycle fits the needs of Linux servers but Debian has traditionally lacked a clear and consistent desktop strategy. Sometimes I think that it might actually be a good thing for Ubuntu if Debian started competing with Ubuntu by improving the desktop strategy in Debian. A friendly competition and exchange of new features and ideas between Ubuntu and Debian could potentially benefit both distros.
For this to happen, Debian would need additional releases that are targeted to desktop users, and it would also need additional artwork/themes and special developer teams that concentrate on desktop issues. Also the Debian website needs an overhaul and an official Debian user forum would also be nice.
These changes would need a lot of work but I don't think it would be totally impossible if there is enough interest among the developers to push Debian in this direction. Actually, the new Debian Project Leader Sam Hocevar has already suggested some of these things in his candidate platform and the fact that Sam was elected suggests that also other developers support these ideas.
If one may ask: why does it not look to you as though the DPL would have much power to change things?
It's just the general impression I got after reading a former DPL's blog note, written about a year ago.[1] It looks like the DPL needs to be a resourceful negotiator rather than a strong leader in order to push changes into debian. If he can "sell" his ideas to other developers and convince them that the kind of changes he wants to make are desirable and good for debian, then things start happening. But it will be very hard to persuade so many developers to agree on which new direction will be the best.
Take, for instance, the various proposals to improve the release methodologies for Debian.[2] I would very much like to see debian testing to become a constantly usable "rolling release" with "beta" snapshot releases (a la "DebianInstallerReleasesAreDebianReleases"). Then there could be the actual high quality stable releases just like they currently are, and unstable would stay the free playground for developers to break things and to introduce new ideas and new versions of software. But I doubt that this kind of big change in the release methodology would be possible for the DPL to push without causing major flame wars.;)
Ah, Etch is finally out the door and it's time to start tracking Lenny. Congrats to all you developers whose amazing skill and hard work ensures that debian stays my favourite distro!
Sam Hocevar had this year the most interesting DPL candidate platform, IMHO. Not that my opinion matters 'cause I'm not a developer myself and, hence, not qualified to vote. Also, it doesn't look like the DPL would have much power to change things. Best of luck Sam -- this time next year we'll know how good you are in herding cats. And don't forget to write those regular DPL reports you promised in your platform.
BTW, does anyone have any idea why so many votes were rejected in this year's DPL election?
Don't you worry, Etch will be out soon enough. The number of release-critical bugs is now going down nicely and the final version of the installer, RC2, will probably be announced during this week. But you don't have to wait for the Etch release. You can download and install Etch right now. It has been ready for normal use for several months now.
The Etch release process has also significantly decreased the number of release-critical bugs in Sid -- and Ubuntu has updated their sources from the Debian pool several times during the Feisty release cycle. This means that Feisty will be more solid than several earlier Ubuntu releases, while Feisty+1 will again be a hayride to Hell for Ubuntu when Debian Sid goes bonkers after the Etch release.:-P
Debian has now way better installer than Ubuntu (for instance, there are options for creating a degraded RAID array and for inserting a LUKS encryption layer at any level). And if you boot it with "installgui", you get this:
IMO, this is a bad article. It's full of misinformation and factual errors, and it paints a very inaccurate picture of the current state of Debian.
From the article:
Debian has a long history of being late, ever since its first version in 1997. This is one of the reasons why entrepreneur Mark Shuttleworth launched alternative Linux distribution Ubuntu two years ago.
The date of Debian's first release given in this article is only one of the many factual errors that it contains. The Wikipedia article on Debian ( http://en.wikipedia.org/wiki/Debian ) tells that "The Debian distribution was first announced on August 16, 1993 by Ian Murdock" and "The Debian Project grew slowly at first and released its first 0.9x versions in 1994 and 1995." Debian version 1.1 was released in June 1996, version 1.2 in December 1996, and version 1.3 in June 1997.
Of course, the article also fails to mention that the Ubuntu distribution is based on Debian and Ubuntu's each new release relies heavily on the work that is constantly being done in Debian, and the article also fails to tell that Ubuntu takes most of the code it releases from Debian's development branch.
The upcoming release of Debian is being delayed because of a slowdown by key developers.
Actually, there's no factual evidence at all that the delay in Debian's release schedule is caused by developers doing their work slower than usual. It is not easy to grasp how large and complex the Debian project has grown and many journalists also obviously fail to understand the not-for-profit and volunteer nature of the work that is done in Debian. The huge size of the project and the volunteer nature of its work are sufficient reasons alone to explain why the release has been delayed for a month or two. Such delays can happen for purely organizational reasons even if every developer is working as hard as they can.
Debian is a non-profit volunteer organization where all the important decisions are made democratically. ( http://en.wikipedia.org/wiki/Democracy ) This means that all important issues in the project management are openly discussed over a period of time and every developer has a chance to get their voice heard. From time to time there are disagreements among the developers and these disagreements are settled by voting where the opinion of the majority wins.
There was recently some disagreement among the Debian Developers about the experimental idea to fund two release managers' full-time work for a short period of time just before the upcoming Debian release. The Debian Developers voted about this issue and the majority of them decided to support the experiment. ( http://lists.debian.org/debian-devel-announce/2006/10/msg00019.html ) Most of the developers accepted this result but 17 of them have been protesting even after the results of the voting were published. It is perhaps worth mentioning here that Debian has over one thousand officially accepted developers and many more who contribute to the project without having the official developer status. 17 developers out of 1000 is a small minority but they can still make a lot of noise. Those other developers concentrate on coding instead of public arguing, so it is only too easy for the scandal-hungry journalists to ignore all these hard-working silent developers and concentrate on the loud complainers.
Slashdot Mirror
The Debian Free Software Guidelines (paragraph 8) clearly says that "License Must Not Be Specific to Debian".
http://www.debian.org/social_contract
Like the article tells, Debian developers are currently negotiating if the firmware blobs should be removed before or after the Lenny release. In any case, Debian developers are removing all the kernel binary blobs from their main repository and they won't distribute any software where the distribution license is not the same for everyone.
AFAIK, the Debian installer for Lenny already checks your hardware and it prompts for additional non-free packages of drivers or firmware (which the user needs to download separately from the installer) if your hardware needs them to work properly. Then it's up to the user to decide if non-free drivers or firmware will be installed.
Also Debian has release cycles, you know. But while Ubuntu's release cycles are inflexible and tied to arbitrary release dates, Debian's release cycles are more flexible and they can afford to wait until the release has actually become stable and ready.
You mention GNOME and Linux as examples that other projects should follow, but you should remember that the early GNOME2 releases were unusable crap, as were were the early Linux 2.6 releases. KDE4 also makes time-based releases now, and so far their releases have been crap. But once GNOME2 and Linux 2.6 matured, they started to make quite usable releases. And it looks like KDE4 will also mature soon, so I'd expect they'll too start making usable releases in the near future.
With distros it's a bit different, though. Distros package software from various sources, and they can refuse to include software that they consider to be just development previews (like early GNOME2, early Linux 2.6, or early KDE4). Distros can cherry-pick stuff that is known to work without problems, if they want to. Or they can include the latest and greatest versions of software and then put their hands together in prayer, hoping that everything works -- even if they haven't really had time to test it.
Ubuntu wants to include the latest versions of software in their releases (even in the so called "LTS" releases), and they have a strict release schedule they need to obey. Quite often this means that they don't have much time to test the software that they include in their releases. Ubuntu is also known to ship with pre-release versions of some popular software programs, even in the "LTS" releases. With such a misguided release policy, Ubuntu can never become mature enough to make releases that are actually stable and well-tested.
Debian, on the other hand, cherry-picks software that is known to work, and they also take time to carefully test software that goes into their stable releases. They only release when the developers think that all the serious bugs have been fixed and the release has really become stable. That's really the reason why Debian releases are so much more stable and trouble-free than Ubuntu releases.
Unfortunately, an installer RC is not the final distribution release.
I don't think so. It'll still take a couple more months before the final Lenny release will be out. There will yet be another installer release candidate (RC2), and that will also need some further testing before the final release.
Still, I think the Lenny release will be well worth the wait for users who want a stable server OS. (Desktop users would prefer Debian's "testing" branch because it has more up-to-date software.) Debian doesn't put out half-assed and buggy releases just to meet arbitrary release dates, like Ubuntu does. Debian won't make a stable release until it's really ready and stable.
Ubuntu, AIUI, made a deliberate decision to be slightly less anal about rock solid stability and nailing every last bug, in order to be able to ship more up-to-date versions of the applications that most people use day to day. Crashes are undesirable, but having features missing that you want to use is also undesirable. And having said that, Ubuntu is usually pretty bomb-proof too.
Unfortunately, it appears that only a small minority of users have found the latest Ubuntu release (which is also their "Long Term Support" release) "bomb-proof".
http://ubuntuforums.org/showthread.php?t=764847
It is also worth noticing that Ubuntu doesn't officially support their "universe" component (although there are some community members who try to support "universe" packages on a best-efforts basis). This means that the Ubuntu Security Team doesn't scan packages in "universe" for potential vulnerabilities, although "universe" in enabled by default. This is another deliberate decision that Ubuntu has made -- they have decided to be less anal about both security and stability in order to meet arbitrary release deadlines.
Notice that Debian fixed the OpenSSL vulnerability as soon as somebody found it and filed a bug report about it. (In this case, the person who discovered the bug was a Debian developer.)
Obviously, Debian developers can't fix bugs that they don't know about. It's just as important to report bugs as it is to fix them. Making a stable Debian release is a community effort -- users report any bugs they can find and developers do their best to fix the important bugs that actually affect usability, stability, or security of the programs that Debian packages.
So let's fix that sentence you quoted:
You can say "It's disappointing that Debian missed their internal goal of releasing Lenny in early September 2008". But you can't really say "It's disappointing that Debian failed to release Lenny in September as they promised", because the official release schedule clearly says that Lenny will be released "in the second half of 2008".
http://lists.debian.org/debian-devel-announce/2007/06/msg00005.html
So that's what they've actually promised, and there's still plenty of time to keep that promise. Just a week ago the number of RC bugs in Debian was over 270. Now it's a bit more than 200. It'll be interesting to see what the RC bugs count shows one week from now.
Is this bug in OpenSSH related to the one that was found in Debian-related distros back about April?
Debian had a security vulnerability in their openssl package (and it was found in May).
http://www.debian.org/security/2008/dsa-1571
I've used sourcemage for a about year or so and I absolutely love its package manager, "sorcery". You type "sorcery" in terminal and it opens an ncurses menu where you can set compile flags and other package manager settings. You can also use the same sorcery menu for browsing/installing/upgrading/removing packages but it's really quicker to check out the man pages for "cast", "dispel", "gaze", and "cleanse", and then just use the command line for package management. When sorcery installs packages, it asks a bunch of questions about dependencies and the next time you upgrade the same package, it remembers the dependencies you chose last time.
I also tried lunar recently. Lunar seems to be rather similar to sourcemage, except they call their package manager "lunar", and they have also different names for the other package management commands. Lunar doesn't appear to support rebuilding the whole system, which I like to do after upgrading gcc, glibc, or binutils. In sourcemage I type "sorcery rebuild" and it rebuilds all the installed packages. In lunar the equivalent command "lunar rebuild" didn't seem to do much anything. I also feel that I get much better control over optional dependencies and build options for individual packages in sourcemage, so I decided to dump lunar.
Sourcemage has pretty up-to-date packages: gcc 4.3.1, glibc 2.7, and so on. Openoffice2 (2.4.1) is only available as a binary package. In sourcemage it's really easy to track the latest development versions of KDE4. There are two alternative package collections ("grimoires") that you can choose from: "test" that is updated every day, and "stable" that is updated once every month. And then there's an additional "grimoire" for games ("games") and also one for non-free and/or binary-only packages ("z-rejected"). There are over 5000 source packages available in sourcemage -- that's more than in most other distros. Sourcemage follows a similar policy as slackware: they prefer not to modify upstream packages by adding any distro-specific patches, except when packages fail to compile.
I see currently only two problems in sourcemage: they haven't released a new installer for a while, and they still officially have only xorg version 6.9 (newer versions of xorg are unofficially available, but you need to jump through extra hoops to install one). The sourcemage mailing list discussions suggest that both of these issues might be solved before the end of this summer. In the meanwhile I'm using xorg 1.3.0 that is not overly difficult to install (the instructions can be found in the sourcemage wiki's xorg-howto, under "using old repository").
Here are links to the mailing list archives and xorg-howto, in case anyone is interested to learn more:
http://lists.ibiblio.org/pipermail/sm-discuss/
http://wiki.sourcemage.org/HOWTO-xorg
Yea, I've used debian with /bin/sh pointing to /bin/dash long before ubuntu made it the default setting. The command that does the switching is "dpkg-reconfigure dash".
I checked the Wikipedia article about dash and it seems that ubuntu switched to dash a bit hurriedly. The article says that "the transition in Ubuntu to making dash /bin/sh broke numerous shell scripts that relied upon Bash-specific functionality". Typical of ubuntu.
The same article says that debian will switch to using dash as the default /bin/sh with the release of Lenny (scheduled for September 2008).
http://en.wikipedia.org/wiki/Debian_Almquist_shell
Thanks. Your reply adds useful information to your original post.
So we can agree that the process isn't really quite as automatic as your original description indicates. Packages that don't have complex dependencies or reported release-critical bugs can pass from unstable to testing automatically but many important packages with complex dependencies (like linux, gcc, glibc, dpkg, python, xorg, gnome, kde, ...) nearly never migrate to testing without careful planning and manual pushing.
There are robots among debian developers, eh? ;-)
I don't think the process of migrating packages from unstable to testing is quite as automatic as you describe. At least, the most important packages (like linux, gcc, glibc, dpkg, python, xorg, gnome, kde, ...) don't migrate automatically. These transitions are made only when the maintainers think they're ready to be included in the next stable debian release and when they're sure that they don't break anything.
Yes, but haven't you noticed a definite change with the release timetables for etch and lenny? Etch was originally planned to be released 18 months after sarge, although it actually took 22 months because there was a four-month long delay. And now lenny is planned to be released in September 2008, which would be 17 months after the etch release. To me this seems like debian has lately adopted the goal of a 18-month long release cycle, although slight alterations are always possible because debian stable is only released "when it's ready."
Why does it have to be so damn hard to insert page numbers to documents in OpenOffice.org Writer?
When I click the drop down menu "Help" -> "OpenOffice.org Help F1" and type "page numbers" as the search term and then "footers," I get this advice:
So far so good, I follow the instructions and my document gets page numbers. By default, the page numbers are aligned to the left side of the page, so next I need to click the "Styles and Formatting" button and in the box that opens next, I need to right-click "Footer" and choose "Modify..." Then a new box opens and there I need to click the "Alignment" tab and then choose "Center" and then click the "OK" button.
Well, now I've got page numbers on the bottom of my document pages, aligned to the center -- just the way I like them. But adding the page numbers has changed my document's layout, decreasing the hight of pages. So now I need to adjust the top margins of my document. So it's time for "Styles and Formatting" again, and there I need to click "Page Styles" and then right-click "Default" and choose "Modify..." Then I need to click the "Page" tab and change Top Margin from 2,00cm to 1,00cm and then hit the "OK" button.
After all these actions, I've got page numbers in my document and the document layout is just like it was before adding the page numbers. But it just seems an awful lot of trouble for doing such a simple operation. And I have to repeat the same routine again with every new document where I want to add page numbers. In Microsoft Word and Abiword you can add page numbers with just a couple of simple clicks, without altering the document's layout.
I haven't tried OpenOffice.org 2.3 yet but I don't really expect they've made adding page numbers any easier in this new version. :-(
Yeah, but do you know where the "Gutsy Gibbon" name originally comes from?
Well, you just need to give computers to an infinite number of gibbons (the "One Laptop Per Gibbon" campaign, OLPG) and if the gibbons are gutsy enough, you can rest assured that they'll eventually manage to write the code for Ubuntu 7.10.
I remember a time when ck-patches for the 2.4 kernels made openoffice start in half the time it took with an unpatched kernel. In those days a Debian derivative distro called Libranet used ck-patched 2.4 kernels and Libranet was called "Debian on steroids", for a good reason.
I've lately used a source-based distro called Source Mage and they make it very easy to apply the most commonly used kernel patches (you can choose the patches you want from a menu when you start to compile a new kernel) and so I tested some current ck-patches on recent 2.6 kernels but I didn't notice any speed improvements while using desktop applications.
So I guess there's not much need for those ck-patches any more. I recall that the kernel upgrade 2.4 -> 2.6 made desktop apps a lot more responsive. Maybe the kernel developers accepted some of Con's improvements to the mainline 2.6 kernel. So long, Con, and thanks for all the fish!
The interviewer asks some very good questions about the weak areas in Ubuntu-Canonical's business strategy and Shuttleworth has to dodge many questions and hide behind half-truths, handwaving and his usual marketing gobbledygook.
Ubuntu allegedly has a "policy of not doing our own software development, but only packaging what others have developed" -- with the few rare exceptions like the Upstart init system. Ubuntu-Canonical doesn't hire any top developers to do upstream development like some other commercial distros, Red Hat and Novell, do. For this precise reason, the GNOME hacker Jeff Waugh had to leave Ubuntu when he wanted to concentrate on developing GNOME.
Given this background, I'm inclined to believe that Shuttleworth is heavily distorting the reality when he claims that a lot of KDE 4 development is now happening inside of Ubuntu. This is one of the several points where I would have wished the interviewer to be a bit tougher and to push a bit harder in order to dig out the truth behind Shuttleworth's marketing talk. Of course, if Ubuntu-Canonical has indeed changed their policy lately and if they are now hiring KDE developers to do upstream development for KDE 4, then this revelation would have greatly added the news value of the interview. It's unfortunate that the interviewer didn't push this question (and some other questions) any further but, instead, left Shuttleworth's dubious claims open for speculations.
Yup, Ubuntu-daughter leads a largely independent life of her own but she still comes home every once in a while to grab the food (new packages) that Debian-mother has made. Without these regular food supplies from mother, Ubuntu would be in a serious danger of starving. And Ubuntu also sends a lot of her clothes (bug reports) home for Debian-mother to wash and iron.
Many of Ubuntu's strengths are inherited directly from Debian. It's quite amazing that there currently doesn't seem to be any worthwhile competition to Ubuntu on the desktop arena. A Debian-based system with some desktop polish seems to be a hot item today. Some other desktop-oriented distros have features that Ubuntu lacks, but Ubuntu's Debian-inheritance is a great advantage that those other distros lack.
Debian's release cycle fits the needs of Linux servers but Debian has traditionally lacked a clear and consistent desktop strategy. Sometimes I think that it might actually be a good thing for Ubuntu if Debian started competing with Ubuntu by improving the desktop strategy in Debian. A friendly competition and exchange of new features and ideas between Ubuntu and Debian could potentially benefit both distros.
For this to happen, Debian would need additional releases that are targeted to desktop users, and it would also need additional artwork/themes and special developer teams that concentrate on desktop issues. Also the Debian website needs an overhaul and an official Debian user forum would also be nice.
These changes would need a lot of work but I don't think it would be totally impossible if there is enough interest among the developers to push Debian in this direction. Actually, the new Debian Project Leader Sam Hocevar has already suggested some of these things in his candidate platform and the fact that Sam was elected suggests that also other developers support these ideas.
It's better to read the release notes first -- these notes warn about some potential SargeToEtch upgrade problems and point out a safe upgrade path.
http://www.debian.org/releases/etch/releasenotesIt's just the general impression I got after reading a former DPL's blog note, written about a year ago.[1] It looks like the DPL needs to be a resourceful negotiator rather than a strong leader in order to push changes into debian. If he can "sell" his ideas to other developers and convince them that the kind of changes he wants to make are desirable and good for debian, then things start happening. But it will be very hard to persuade so many developers to agree on which new direction will be the best.
Take, for instance, the various proposals to improve the release methodologies for Debian.[2] I would very much like to see debian testing to become a constantly usable "rolling release" with "beta" snapshot releases (a la "DebianInstallerReleasesAreDebianReleases"). Then there could be the actual high quality stable releases just like they currently are, and unstable would stay the free playground for developers to break things and to introduce new ideas and new versions of software. But I doubt that this kind of big change in the release methodology would be possible for the DPL to push without causing major flame wars. ;)
[1] http://www.cyrius.com/journal/2006/03/09[2] http://wiki.debian.org/ReleaseProposals
Download mirrors:
http://www.debian.org/mirror/mirrors_fullAh, Etch is finally out the door and it's time to start tracking Lenny. Congrats to all you developers whose amazing skill and hard work ensures that debian stays my favourite distro!
Sam Hocevar had this year the most interesting DPL candidate platform, IMHO. Not that my opinion matters 'cause I'm not a developer myself and, hence, not qualified to vote. Also, it doesn't look like the DPL would have much power to change things. Best of luck Sam -- this time next year we'll know how good you are in herding cats. And don't forget to write those regular DPL reports you promised in your platform.
BTW, does anyone have any idea why so many votes were rejected in this year's DPL election?
Maybe Linux App Finder is what you're looking for? It allows users to rate applications.
http://linuxappfinder.com/Don't you worry, Etch will be out soon enough. The number of release-critical bugs is now going down nicely and the final version of the installer, RC2, will probably be announced during this week. But you don't have to wait for the Etch release. You can download and install Etch right now. It has been ready for normal use for several months now.
http://www.debian.org/devel/debian-installer/The Etch release process has also significantly decreased the number of release-critical bugs in Sid -- and Ubuntu has updated their sources from the Debian pool several times during the Feisty release cycle. This means that Feisty will be more solid than several earlier Ubuntu releases, while Feisty+1 will again be a hayride to Hell for Ubuntu when Debian Sid goes bonkers after the Etch release. :-P
Debian has now way better installer than Ubuntu (for instance, there are options for creating a degraded RAID array and for inserting a LUKS encryption layer at any level). And if you boot it with "installgui", you get this:
http://www.thecodingstudio.com/opensource/linux/sSo, why wait for the release? You can install Debian Etch right now (like the dude who wrote this article did).
IMO, this is a bad article. It's full of misinformation and factual errors, and it paints a very inaccurate picture of the current state of Debian.
From the article:
The date of Debian's first release given in this article is only one of the many factual errors that it contains. The Wikipedia article on Debian ( http://en.wikipedia.org/wiki/Debian ) tells that "The Debian distribution was first announced on August 16, 1993 by Ian Murdock" and "The Debian Project grew slowly at first and released its first 0.9x versions in 1994 and 1995." Debian version 1.1 was released in June 1996, version 1.2 in December 1996, and version 1.3 in June 1997.
Of course, the article also fails to mention that the Ubuntu distribution is based on Debian and Ubuntu's each new release relies heavily on the work that is constantly being done in Debian, and the article also fails to tell that Ubuntu takes most of the code it releases from Debian's development branch.
http://mako.cc/writing/to_fork_or_not_to_fork.html
From the article:
Actually, there's no factual evidence at all that the delay in Debian's release schedule is caused by developers doing their work slower than usual. It is not easy to grasp how large and complex the Debian project has grown and many journalists also obviously fail to understand the not-for-profit and volunteer nature of the work that is done in Debian. The huge size of the project and the volunteer nature of its work are sufficient reasons alone to explain why the release has been delayed for a month or two. Such delays can happen for purely organizational reasons even if every developer is working as hard as they can.
Debian is a non-profit volunteer organization where all the important decisions are made democratically. ( http://en.wikipedia.org/wiki/Democracy ) This means that all important issues in the project management are openly discussed over a period of time and every developer has a chance to get their voice heard. From time to time there are disagreements among the developers and these disagreements are settled by voting where the opinion of the majority wins.
There was recently some disagreement among the Debian Developers about the experimental idea to fund two release managers' full-time work for a short period of time just before the upcoming Debian release. The Debian Developers voted about this issue and the majority of them decided to support the experiment. ( http://lists.debian.org/debian-devel-announce/2006 /10/msg00019.html ) Most of the developers accepted this result but 17 of them have been protesting even after the results of the voting were published. It is perhaps worth mentioning here that Debian has over one thousand officially accepted developers and many more who contribute to the project without having the official developer status. 17 developers out of 1000 is a small minority but they can still make a lot of noise. Those other developers concentrate on coding instead of public arguing, so it is only too easy for the scandal-hungry journalists to ignore all these hard-working silent developers and concentrate on the loud complainers.
http://lists.debian.org/debian-devel-announce/2006 /10/msg00026.html