Comments on: Debian- What It Means To Me Linux. GNU. Freedom. Thu, 15 Feb 2018 18:04:15 +0000 hourly 1 By: Patrick Sat, 27 Dec 2008 16:08:25 +0000 So now you either want to prove your ignorance to the real job of package maintainers or you just want to flame (ok flaming is actually all this post and most of the comments is about, but well, you can think of what I mean).

So what about bug triaging, analysing crash reports, analyse and setup steps to get upgrades and transitions done? Adapting software to distribution-specific needs? (e.g. setting up alternatives) Testing? Reporting Bugs upstream? Suggesting fixes to upstream? Are this things that you think can be done by a robot?

By: Patrick Sat, 27 Dec 2008 16:01:05 +0000 "RPM does have pre scripts, and they work rather well. What you’re describing about the upgrade scripts is exactly how it should behave."

Really? How - for example - do you handle something like diversions with this approach?

"RPM unpacks what’s needed, runs the rest of the pre scripts, then installs, then runs any post scripts that may be present."

The "whats needed" part is confusing. Does that mean you can mark certain files as not to be installed before certain parts of the preinst script(s) ran? If so, this would be interesting, but a rather strange workaround to the problem that is to be solved.

By: Patrick Sat, 27 Dec 2008 15:52:45 +0000 Uh? I can say a lot of bad things about aptitude (e.g. that it is horrible slow) but argueing that the dependency resolver is 'utterly broken' appears to be just untrue.
In my personal experience (when administrating some couples of Debian systems) my feeling is that the dependency resolver of aptitude works in a more consistent and reliable way then apt-get ever did. I always smile about the moments where it makes a suggestion (not always the one I want, yeah), where apt-get would have failed and asked me to enter a solution on my own.
But I must indeed confess that I did not really use apt-get for at least 6 months, so I cannot really made statements about the eventual progress apt-get made.

Regardless of that I don't see how this is a bad example. It is relative new, incorporates a clear enhancement to the previous approaches to fix the system (the fact that I don't need to it manually) and it is an example that in this area something new *has* emerged (contrary to what Aaron said)

By: Patrick Sat, 27 Dec 2008 15:44:23 +0000 "Aptitude is merely a front end to apt-get."

You don't actually believe what you say, do you?

"It’s nothing really innovative."

Oho. But Launchpad is? You know that you run out of good examples, if you argue against what makes your own examples innovative?

By: Aaron Fri, 26 Dec 2008 10:42:33 +0000 Yeah, I've read that. It's been ridiculed fairly hard on a number of topics:

1. He's pulling from Git logs, which is only a recent tracker of the kernel development.
2. He's only using vanity email addresses, which until recently, Canonical and Ubuntu didn't hand out.
3. Classic example of the pot calling the kettle black.
4. Ubuntu has giving back to the Linux community 100 times more than any kernel developer has done. If it weren't for Ubuntu, Linux on the desktop would not be where it is today.

By: Aaron Fri, 26 Dec 2008 10:38:20 +0000 Bazaar fills needs that other VCS software doesn't give. Isn't this the whole point of Free Software? If it doesn't have Feature X, then either patch it, fork it, or create anew.

Also, graphics and overall look and feel can be called innovation. Novell artwork in the SUSE distributions is beautiful, and frankly, no distro even comes close.

And yes, Canonical was "slammed" for not doing kernel development by a Novell employee who also had done little kernel development. Isn't this the pot calling the kettle black? Further, where are the "Debian Developer" contributions to the kernel? Oh, not as much as expected, eh?

By: Aaron Fri, 26 Dec 2008 10:34:43 +0000 LinuxCanuck is free to express his opinions and feelings towards Debian. I don't see anything in the post that would compromise the Code of Conduct. He did get a few facts wrong, which were mentioned to him in the comments, but his post is expressing his feelings, and I hope he can do that on his own blog.

By: Aaron Fri, 26 Dec 2008 10:19:16 +0000 The storm ORM is quite a bit different than MySQL. The ORM is sheer code to power MySQL or other databases, where MySQL is the database itself, so your analogy fails.

By: Aaron Fri, 26 Dec 2008 10:17:19 +0000 I agree that Ubuntu should be taking greater advantage of Upstart. Right now, it's in SysVInit backwards compatibility mode, and it seems the Ubuntu developers are sitting on their hands, waiting for something magical to happen before taking full advantage of it. The same can be said with Fedora.

By: Aaron Fri, 26 Dec 2008 10:15:47 +0000 No, this is the biggest misunderstanding with the whole Firefox-IceWeasel fiasco. The Firefox artwork is free, it's just trademarked. Debian also has a trademarked logo. Does this make Debian non-free? Trademarks protect the organization and their product. Mozilla is more than happy for you to use the trademark, as long as you follow trademark law, and call it "Mozilla Firefox".

By: Aaron Fri, 26 Dec 2008 10:13:25 +0000 No, I fully understand what is at task for a package maintainer. Debian has a man page policy for every .deb packaged. Also, they are scrutinized to the rules of the DFSG. Any artwork, documentation, code, or anything else that doesn't fully comply with the DFSG is rejected or removed. Robots can't do this, people can.

By: Aaron Fri, 26 Dec 2008 10:11:26 +0000 I don't get this "bunch of files on your disk" stuff. Are you suggesting that RPM just downloads whatever it wants, and litters your disk with useless crap? Because if you are, that shows your ignorance towards RPM.

RPM does have pre scripts, and they work rather well. What you're describing about the upgrade scripts is exactly how it should behave. I believe your confusing "unpacked" with "installed". RPM unpacks what's needed, runs the rest of the pre scripts, then installs, then runs any post scripts that may be present.

By: Aaron Fri, 26 Dec 2008 10:08:52 +0000 This boils down to philosophy, and I think we should agree to disagree on this. You feel if you install a service, it should be setup for you listening for connections. I don't. We'll leave it at that.

By: Aaron Fri, 26 Dec 2008 10:07:45 +0000 I still count AppArmor and innovation, even if I find SELinux vastly superior. I didn't just add it to the post, if I didn't feel that Novell produced it. I don't just throw random things in the post for nothing.

By: Aaron Fri, 26 Dec 2008 10:06:24 +0000 How is the dependency resolver in aptitude broken? Before aptitude, APT had no way of knowing about orphaned dependencies. Now there's 'apt-get autoremove', which was inspired by the way aptitude handled these orphaned dependencies. Aptitude is a superior APT.

By: Asheesh Laroia Fri, 26 Dec 2008 00:52:12 +0000 First of all, it's nice to hear a diversity of voices in discussing all these distributions. I've contributed (in a humble way) to Fedora and Ubuntu, and I maintain some packages in Debian. I like your conclusion about what Debian means to you, that it is the universal operating system, a good base for Ubuntu, and dedicated to its users and Free Software.

I want to touch one specific thing. You wrote, "Launchpad is open source through the Storm ORM, written in Python."

This strikes me as strange; it is like declaring Facebook open source because they use MySQL. As far as I know, the Launchpad code is not available for download from Canonical. Has that changed?

These are good conversations to have, and I appreciate your respectful tone.

By: Np237 Thu, 25 Dec 2008 22:32:34 +0000 Actually upstart is probably the best init system that was ever designed. The problem with it is that Ubuntu never cared to make it mainstream. Instead of polishing it so that it can become the new standard, they just keep it in their own niche.

On the contrary I wouldn’t call Rosetta wonderful. It has the very visible effect of lowering the quality of translations.

By: Np237 Thu, 25 Dec 2008 22:27:52 +0000 Firefox includes non-free artwork; the licensing doesn’t allow to call it Firefox without it.

By: Np237 Thu, 25 Dec 2008 22:24:23 +0000 Well, sorry if you just want a bunch of files on your disk That’s indeed much easier to implement that what Debian gives.

Oh, and if you want to know about a real design flaw in RPM that makes it unsuitable for a reliable distribution: it has no pre-upgrade scripts. Actually, it claims to have, but they are executed after the files have been unpacked. This is absolutely broken and makes it impossible to cleanly upgrade packages using e.g. GConf or Python modules.

By: Np237 Thu, 25 Dec 2008 22:20:29 +0000 No, that’s something Red Hat gets very wrong, and I already explained why earlier.

By: Np237 Thu, 25 Dec 2008 22:18:30 +0000 What a bad example. The dependency resolver in aptitude is utterly broken and makes it very hard to do major updates. Meanwhile, the dependency resolver in APT (which is also used by e.g. synaptic) has been rewritten as well and is much more reliable.

By: Aaron Thu, 25 Dec 2008 14:35:46 +0000 No, debsums only works on MOST packages, not ALL. Further, debsums is not installed by default on a Debian system, and many sys admins may not know about it.

Further, RPM will not break an installation. As I mentioned, RPM will install the new config as or It will not replace the current configuration in place. DPKG has to interrupt your workflow asking you what to do.

Lastly, the statement "it installs gazillions of packages you don't need by default" is ignorance. I have full control over what I want installed "by default" and what I don't with Anaconda when installing a system from scratch. With YUM, it installs the same dependencies that APT would. Also, when I install a service package, I want it installed. I don't want it installed, listening for connections, and configured to start every time I enter a runlevel. I asked to just install a package, no execute it. I'll do that when I'm ready.

By: Aaron Thu, 25 Dec 2008 14:29:31 +0000 rpm -V has become a valuable too to me as a sys admin. I have fixed package installs knowing that an incorrect binary is installed. I've fixed config files seeing the md5sum is different. I've corrected user and group permissions. RPM as a basic HIDS has been rock solid for troubleshooting broken software.

Timestamps have saved me numerous times on Red Hat systems. The most recent example is when I found I had a new library installed. Not knowing where it came from, I found the package that owned it, then when that package was installed. Knowing that, I was able to recall why I installed that package at the time. I didn't need it now, and removed it. I've also had bosses ask me when I installed a piece of software, and it was trivial to retrieve this information. I've also wondered about when I installed software on my Debian server, and it's been pulling teeth to get that info.

Let's agree to disagree. I know my tools. I know the apt-* tools. I know dpkg-* fairly well. I've written courseware covering the Debian package format for Guru Labs. I've also updated courseware for RPM. I've taught both extensively. I know RPM versus DPKG, and my opinion is that DPKG, while an overall solid tool, is inferior to the latest version of RPM.

By: Aaron Thu, 25 Dec 2008 14:21:22 +0000 Sure. Another reason Red Hat gets it right, and Debian doesn't.

By: Aaron Thu, 25 Dec 2008 14:19:18 +0000 Aptitude is merely a front end to apt-get. It's nothing really innovative. It does have better orphaned dependency handling, but there have been tools for handling those before aptitude came along.

By: Aaron Thu, 25 Dec 2008 14:16:55 +0000 One thing that really bothers me about Free Software extremists is the extreme. Ubuntu never has been, and probably never will be about 100% Free Software. If they were, we wouldn't have the restricted and multiverse repositories available. No, Ubuntu is about getting stuff done. It's about practicality. Canonical realizes that the world wants proprietary software. Canonical realizes that not every developer in the world is going to develop Free Software. Canonical realizes that there are great software out there that are proprietary. No, Ubuntu is about getting your job done with the best tool, not geeking it up. This is why Ubuntu has outdone every other Linux distro, including Fedora.

By the way, Firefox is Free Software.

By: Carl van Tonder Wed, 24 Dec 2008 23:23:34 +0000 Aaron, whilst I disagree completely with your points about Debian, you have done the community a massive favour in one way: the icons per-post showing browser and operating system, right down to distribution.

Notably, there is _no_ Ubuntu user using anything other than Firefox, which I think makes the generalisation that Ubuntu does not generally "get" Free software a little fairer than it would otherwise be, Not having flashy press-conference releases, closed-shop development processes and swish wiki pages for every item a project has ever created does not identify a stagnant entity by any means.

If you measure Ubuntu's input by help to other distributions, as you seem to do for every other distribution's software, the only item on the list is Upstart --- in itself not an amazing innovation and not particularly interesting. bzr failed the 'is there actually a niche for this' test, Launchpad and Rosetta - whilst wonderful for Ubuntu - don't help the rest of the Linux ecosystem at all.

Of course, Debian is not all love and hugs, and Planet Debian is only marginally more interesting to read than painful (and uniquely the only Planet that makes me want to send angry e-mails almost every time I read it). The governance structure is pretty misunderstood (as the recent voting fracas has shown) and it probably lacks well-defined goals, but I will make a controversial statement and say that it gives more to the community than Ubuntu.

By: Jon Wed, 24 Dec 2008 13:59:19 +0000 Whilst its true that a lot of the innovations that Debian Developers have been responsible for were some time ago (dpkg/apt/dependency based packaging that worked; the alternatives system; alien), there have been others more recently -- jetring springs to mind. A lot of the work that has gone on by DDs has been in areas that might not be of interest to the average x86 user: a lot of upstream kernel work on the ARM port of Linux, and the armel ABI toolchain and suchlike, which Ubuntu are now benefiting from now that you have deemed ARM interesting.

In terms of ratio, it's probably true that most debian developers perform nothing more than packaging; Then again, there are thousands of developers, the vast majority of which fullfil a role very much like your universe/motu people (although are first-class citizens, unlike your motu people).

I've yet to meet a better installer than d-i. I've used it to install Debian on vastly different types of machines and it's been flexible enough to work in each situation. The solaris 10 installer is horrid (try typing a ? in a password input dialog); the Ubuntu python-based thing and anaconda frequently crash for me in the middle of trying to do things and don't seem to allow me to do anything remotely off-the-map. I haven't looked at the slackware installer for about 10 years (and it segfaulted then too).

By: Patrick Wed, 24 Dec 2008 10:02:20 +0000 "rpm -V does a lot more than check md5sums. Nothing exists in dpkg that compares."

Aha. And what of this is actually needed? Actually it serves little to no purpose.
Did you know that on the other side their is no mirror security for yum and co? Do you know that it would be absolutely no problem to flaw a mirror with poisoned packages in a Redhat system because yum and co does not have protections against it? At least IIRC.

"Timestamps in the RPM database make it easy for me to discover when a package was installed."

I still don't know what you need to know this for. I'm working as a full-time administrator so far and never felt the need for this. Except to reproduce which upgrade could have caused a regression. For that the dpkg and the aptitude logs serve well.

"I’m familiar with invoke-rc.d. The ’sysv-rc-conf’ script is much more mature for manipulating the runlevel scripts for Debian."

Might be, but it works for me. No problem with it.

"RPM gets this right, DPKG does not."

Statements like this (as the end of an article comparing different init systems) make the impression that you don't know what you are talking about. Obviously you confuse apples with bananas here, because the init system is neither a part of RPM nor of dpkg.

"It’s statements like “DPKG is superior to RPM” that show me the speaker is ignorant and uninformed. I am deeply familiar with DPKG and RPM, and RPM just wins out."

By just repeating your telling again and again your point does not get more authenticity. You failed to present arguments for this claim, so it still needs a proof. I canot backup this claim, because in practice rpm failed again and again and again. And if you bring examples of useless features that no one needs, then this does not impress me much and it still leaves the feeling that dpkg is doing its job well, while rpm is doing it so-la-la. Nothing superior to detect.

By: Patrick Wed, 24 Dec 2008 09:52:32 +0000 Or to rephrase it: You needed an "innovation" to count up, no matter how bad it is.
But you know already that innovation needs some sort of quality to be an innovation, yeah?

By: Patrick Wed, 24 Dec 2008 09:49:57 +0000 "Also, the tools your refer to have been in Debian for a long, long time. Nothing new has emerged."

Wrong. Over the last few years aptitude as a new tool emerged, which has an even better dependency solving algorithm and new features that ease house-keeping on Debian systems (and effectively make additional tools like debfoster mostly obsolete).

By: Patrick Wed, 24 Dec 2008 09:48:16 +0000 > The point is, debian solved a major problem > with aptitude that rpm did not address. The > rpm-based distros had to copy debian’s
> innovation.

Replace aptitude with apt-get in your sentence, because that is the tool that solved a major problem that no distribution solved so far. But else I agree to this.

The interesting thing is: Redhat & Co did not even innovate a new tool with an old solution for a known problem. They used tools others built. First they used 'apt-get' itself in a modified variant. Later they used yum. And guess what? They still have an inferior tool. yum might have some features that apt-get or aptitude have, but still the dependency solving _is_ superior compared to yum. Which is something I learned the hard way, when working with Fedora.

By: Patrick Wed, 24 Dec 2008 09:39:14 +0000 > If the distribution innovates as well, and
> gives back, then they have the upper hand.

Well, Debian _does_ innovate. Its just not all these bling-bling kind of innovation that every user sees. Its stuff that improves Debian for the developers, which in the end adds a benefit for the users, because it makes our distribution better. Did you for example know our patch tracker? [1] There are several examples, you just have to look for them (or notice them without problem if you are involved with the development). But actually it seems that polemics and flames are your only interest.


By: catnap Wed, 24 Dec 2008 09:00:44 +0000 LinuxCanuck, I've read your recent rant about your "problem" with Debian.[1] In the comments section several people tried to correct the misinformation you spread, but it's sad to see that those corrections had no effect at all, and you still have the same attitude problem and the same hostility toward Debian.

Since you are a Ubuntu user, I think you should study carefully the Ubuntu Code of Conduct.[2] Mud-slinging and malicious rants do not go well together with the principles of being considerate, respectful, and collaborative.


By: Jef Spaleta Tue, 23 Dec 2008 23:12:31 +0000 Speaking of poor moves associated with Apparmor. Now that Novell is no longer championing Apparmor as strong as it once did, why isn't Canonical taking up the ball and assigning some manhours into supporting its upstream development as a critical piece of Ubuntu technology? Apparmor provides part of the security associated with the Ubuntu guest account functionality for example.

How is the upstreaming of AppArmor related kernel patches into the mainline kernel fairing? Wouldn't it be great if Canonical helped with that?


By: LinuxCanuck Tue, 23 Dec 2008 22:59:39 +0000 This is the most honest discussion that I have seen on Debian and its fading hopes.

There are many problems with Debian and most have been mentioned. My problem is that they wish to blame others for their misfortune. They want to stand on high principles and act in ways that turn people off and then blame Ubuntu for their plight. Ubuntu is only four years old and yes it is a fork, but now it is maturing, contributing back and showing leadership.

Most people do not have the patience of a saint. They cannot wait for Debian to get its act together and they move on. That's the essence of open source. People have choice and nobody is forcing them to use Ubuntu. They go there because they feel welcome and because it is flexible. You won't be called an idiot if you want to install flash, mp3 compatibility or use Firefox instead of Ice Weasel.

Time is passing Debian by. It is already looking long in the tooth. It looks like the users all wear sandals and socks year round.

By: Justin Dugger Tue, 23 Dec 2008 21:34:23 +0000 Trying to lead Debian with an Ubuntu hat on is something close to herding cats squared. And Debian is not a cat I'd want to "hug" without paramedics nearby.

You're right about Shuttleworth's quote; the idea that Ubuntu developers can stop by and share a patch with Debian is slightly flawed. I've tried cooperating with the Debian fingerprint reader team to improve the experience, share code and review fixes. In particular, I tried to fix a behavior of thinkfinger that didn't gksudo didn't appreciate. The patch was refused, not because it was bad, but because the bug was in someone else's package. No fix has been forthcoming from the team. Thinkfinger is dead upstream, but the general opinion of the upstream author is that easy hacks are fine, and if someone disagrees they're welcome to do the work to fix it "the right way." I've suggested a two line patch is trivial to remove once the "right fix" is in place but it's become clear that out of box experience doesn't matter to that team.

The best Ubuntu can probably do is "leadership by example," and let best practices permeate Debian slowly. Relaxed package ownership, CoC, release schedules, blueprints, SRU policies are all things I hope Debian will adopt eventually. Some I think they already have.

By: Daniel Moerner Tue, 23 Dec 2008 18:10:14 +0000 If it ain't broke, don't fix it.

You don't even try to say why we need ANOTHER vcs when git and mercurial work just fine. Why was Canonical wasting its time on this? By your own logic, it could have been doing X or Y or Z thing to actually "innovate." Most of the innovations you cite are re-implementations of current tools. I also find it amusing that you cite Storm ORM as free software right after lauding the non-free Launchpad.

"all around, the SUSE Linux Enterprise Desktop yields a very familiar Microsoft Windows look."

Great innovation.

Wasn't Canonical the very company that was recently slammed for not doing enough to support kernel development? I don't see that in your article either.

Innovation is only one part of software development. Debian has established an unmatched project infrastructure that other projects are still struggling to match (debbug, wanna-build, dak, alioth, constitution/social contract). There isn't as much need for innovation when this is the backbone for the project.

By: Jeff Schroeder Tue, 23 Dec 2008 17:15:57 +0000 @Aaron, here is a nice response that didn't leave a pingback.

By: Daniel Tue, 23 Dec 2008 14:57:11 +0000 Debian frequency feed bug report with patches to upstream. It already recommend maintaining minimal different to the upstream.
Patches come in good documented series.

Unlike ubuntu, patch are either never pushed up, or comes in a big do everything patch

By: Np237 Tue, 23 Dec 2008 14:40:14 +0000 If you knew your system, you’d know that the init script policy has nothing to do with dpkg nor rpm, but is specific to each distribution.

By: Np237 Tue, 23 Dec 2008 14:35:16 +0000 Installation from TFTP+NFS has been supported on Debian long before other distributions, since some architectures can *only* be installed this way.

The installer also supports boot on USB devices and HDD from a DOS OS with loadlin.

I don’t think you can install directly from an ISO on the local disk (although it is certainly possible with some tweaking). However I don’t see the use case for it; if you want to install from a working Linux system, it’s much faster to simply bootstrap it.

BTW your “just package everyone else’s work” expression shows your deep misunderstanding of what packaging is about. If it was as simple as what you think, we’d use robots, not maintainers.

By: Jeremiah C. Foster Tue, 23 Dec 2008 13:19:56 +0000 1. Fedora is dependent on Red Hat. It is beholden to Red Hat, it does not get certain upgrades unless Red Hat gives it to them. Red Hat Linux went the way of the dodo once already - I don't see how you can trust them.

2. The innovation is in package handling, distributed development, and Free OS.

3. You need to have some patience, it is a difficult process but very worthwhile.

4. The point is, debian solved a major problem with aptitude that rpm did not address. The rpm-based distros had to copy debian's innovation.

By: Aaron Tue, 23 Dec 2008 12:28:10 +0000 No, I'm not suggesting that Debian is not giving back to the community. Of course they are. What I am suggesting is a caution: if a distribution does nothing but package all the innovations from upstream, regardless, that distribution would be leeching off the community. If the distribution gives back, as Debian does, then they're keeping in balance. If the distribution innovates as well, and gives back, then they have the upper hand.

By: Roger Leigh Tue, 23 Dec 2008 12:25:27 +0000 I think you might find that the current flamewars on Debian lists are somewhat blown out of proportion. Out of the total developer population, only a small and vocal minority are actually participating. You'll find that most of us developers are actually spending our time *working on Debian* productively, rather than wasting it on mailing lists.

Regarding comments about Debian Developers only packaging, not developing: this is patently untrue. Most developers are actively involved in the upstream development of the software they package. I for example am primarily an upstream developer who happens to package it for Debian (e.g. Gutenprint), while for others the upstream is also Debian (schroot, sbuild) which are being developed primarily for use within Debian, but are by no means tied to it. Many major improvements to packages come from Debian developers thinking about and implementing improvements, often from a packaging/upgrading POV which upstream developers (and other distributions) don't feel the need to tackle. As an example, take automatic upgrading of PPD files when you upgrade Gutenprint/CUPS: that is found upstream, but the initial implementation of PPD parsing/rewriting came from Debian (me), as did the distribution-independent PPD packaging guidelines (

Also, don't confuse work on Debian in particular with work on Free Software in general. Most of the work done by Debian developers doesn't have a "Debian stamp" on it--it's contributed by individuals and so won't be seen as work done by "the project" since it goes straight upstream and comes back into Debian when the release is packaged, rather than being kept as a Debian-specific change. If you take this into consideration, you'll find that Debian more than pulls its weight in the free software world alongside its corporate peers.

Working this way with upstreams has a long-term benefit in terms of manpower and time saving porting changes to new releases. This is, IMHO, something Ubuntu is going to find out the hard way as they don't actively push their changes back to their upstream (Debian, in particular), resulting in huge unwieldy diffs to merge with new Debian and Upstream releases which do have a maintenance cost. I know exactly what this cost is because I currently have to manually find and trawl through the Ubuntu diffs (which are mostly a mess, example for the curious:, and pull out the useful bits I actually need.


By: Aaron Tue, 23 Dec 2008 12:23:23 +0000 "Installation from any kind of media"

I'm going to argue this with you, as Debian is missing out here. With Anaconda, I can install from:

* HDD (using .iso images)

With the Debian installer, my understanding is I can only install from:


NFS and using .iso images from a hard drive is not supported. This makes the Debian installer less flexible than the Anaconda installer. SUSE adds all those above from Anaconda, and adds SMB support as well, which the Debian installer does not.

With your other statements, I am not aware of those, and will have to check them on my own.

Don't get me wrong on this post- I LOVE DEBIAN! I have mentioned in my post how I am using it, and how I advocate it. It's the single greatest operating system out there. I just want to see it back to its roots, is all. Give me reasons to use it, rather than just package everyone else's work.

By: Aaron Tue, 23 Dec 2008 12:15:50 +0000 rpm -V does a lot more than check md5sums. Nothing exists in dpkg that compares.

RPM never asks the user a thing during install and removal. DPKG does. The difference between these two philosophies is the difference between trusting a full automated system and not.

Timestamps in the RPM database make it easy for me to discover when a package was installed. I have needed this on many occasions as a system administrator, and DPKG always fails me, as it does not keep this crucial bit of information stored in its database.

I'm familiar with invoke-rc.d. The 'sysv-rc-conf' script is much more mature for manipulating the runlevel scripts for Debian. When installing a service, I just want it installed. Then I want to configure it to my needs. Thin I want to manipulate the symbolic links with 'sysv-rc-conf'. THEN I want to start the service, not before. RPM gets this right, DPKG does not.

And I know my system- very well. I was a Linux instructor teaching system administrators all over the world. It's statements like "DPKG is superior to RPM" that show me the speaker is ignorant and uninformed. I am deeply familiar with DPKG and RPM, and RPM just wins out.

By: Np237 Tue, 23 Dec 2008 11:32:08 +0000 1. Yes there is debsums, which works perfectly and anyway you shouldn’t rely on this except for checking system integrity.

2. WTF?

3a. Installing the new version of the configuration is just going to break your working system. Great. How can you even consider that a feature?

3b. The reason why Redhat does this (it has really *nothing* to do with the package format) is that it installs gazillions of packages you don’t need by default. Debian assumes that when you install a package, you want it to work. When you install a webapp, you don’t want just the files on the system: you want the database up and running with tables ready, the web server ready to respond, and the webapp actually working. This is a fundamental philosophy difference: Redhat provides a tool to download files, Debian provides a system that just works.

By: Np237 Tue, 23 Dec 2008 11:24:17 +0000 You are completely forgetting the amount of innovation that is required nowadays to make such a complex system work flawlessly. The very reason why Debian is more stable is precisely because we innovate. It’s just that we choose to innovate on different fields: we innovate in ways to keep the system working.

Real integration of GConf with the system? Came from Debian.
Flexible python packaging with support of several versions at once? Debian.
Installation from any kind of media, with encrypted/LVM root FS? Debian.
Homogeneisation of GNOME logout dialog? Debian.
Automated kernel module rebuilding? Debian.
Inter-package relationships on GTK+ modules? Debian.
Installation of multiple backends for the same software? Debian.
And I’m only talking about the small parts of the project where I am contributing. You can find hundreds of such innovations every year.

You talked about system-config-printer earlier. Debian doesn’t only package it: we introduce string freezes and release cycles so that non-English versions don’t just look like an incomprehensible mixture of languages.

When upstream innovates, it is in one hand an improvement, and in the other hand something that breaks on the system. We’re here to find solutions to go forward, so that the innovation actually benefits users. A minor bug can be a major usability issue, and we’re here to track bugs that matter, and to find solutions for them when upstream doesn’t care.

The only similar effort I can think of recently is DKMS, and it came from Dell, not from other distributions.

(BTW your OpenID support seems broken.)

By: Tim Tue, 23 Dec 2008 11:03:44 +0000 Debian is incredibly innovative. The project and its processes is amazing. People sometimes say that Microsoft was not innovative, making this judgement by the features of its products. A ridiculous statement from the shareholder's point of view: Microsoft was incredibly innovative in its business practices. Debian is even more amazing.
But that's beside the point, really. Debian and Ubuntu are actually great. I got sick of Ubuntu because I found it not to be reliable, because it seems to be manic about introducing new features with known bugs, hoping that they will be fixed after release ... but it's much wiser than Fedora, and Ubuntu is a great consumer OS. A view that Debian is a faded predecessor to the new blood of Ubuntu is silly and ignorant of what Debian is. Personally, I think demanding users would be well placed to seriously consider Debian from a technical point of view; however, I also find the aims and method of Debian inspiring.