The Debian System Explained

An anonymous reader writes "XYZComputing has a great interview with Martin F. Krafft, the author of "The Debian System". From the article: 'Despite Debian GNU/Linux's important role in today's computing environment, it is largely misunderstood and oftentimes even discounted as being an operating system which is exclusively for professionals and elite users. In this book Krafft, explains his concept of Debian, which includes not only the operating system but also its underpinnings. Debian is not only a robust and scalable Linux distribution, but it has many other features which are worth looking into, like its open development cycle and rigorous quality control.'"

Comments

Is Debian a fad?

[Anonymous Coward]

Interesting. I went through the same linux phases...

slackware, red hat, suse and now debian. Looked at Gentoo a bit but stuck with Debian.

Other Distros

[IAAP]

FTFA:Many people actively involved with Debian development are working as system administrators themselves. Thus, they know very well what their own needs are, and in case Debian doesn't meet them, they are in the position to fix that. However, ideally, one should not have to be a Debian contributor to successfully deploy Debian in production environments.

I'm not an admin - outside of my own hacking at home. But, help me out here, is Debian more of an enterprise-admin friendly-scalable distro than, say, RedHat Enterprise?

From what I've seen between various distros(No Debian), there's their add-ons (desktop add-ins, installation software, etc...), and then there's just Linux, XFree86, and all of the GNU software stuff. Is Debian that much better whe it comes for day to day operations?

Easy Install... NO install!!

[helmutvs]

Knoppix is the best tool with which to showcase Debian-based systems. No installation/configuration required. Along with Ubuntu, it is quite possibly the easiest-to-use linux out there.

Huh?

[IamTheRealMike]

Debian is not only a robust and scalable Linux distribution ...

This sort of thing reminds me of Joel Spolski's opinion on advertising:

The idea of advertising is to lie without getting caught. Most companies, when they run an advertising campaign, simply take the most unfortunate truth about their company, turn it upside down ("lie"), and drill that lie home

If Debian is so scalable, why does it take them so much longer than any other OS vendor to simply do a release? How comes the software even in the "unstable" version is so often out of date? If it's so robust, how comes that shortly after their last stable release it was revealed that their entire security infrastructure revolved around one man, and that when he went on holiday the flow of updates simply stopped?

It seems to me that if you wished to advertise Debian, scalability and robustness would be the last qualities you'd choose to highlight. Instead you might want to focus on its dedication to the ideals of free software (that doesn't entice many people to install it though ...) or the fact that it runs on so many CPU architectures (hmm ... ditto). Actually, I can't think of any compelling reasons for the majority to run Debian directly. I say this even though I use Debian on my own server .... the original reasoning for this was that I felt at least the community was big and stable so there would be a reliable supply of security updates. That was before I found out about the size of their security team and the bandwidth bottlenecks on their servers (eg, Xfree update). After that I found myself wishing I'd installed Red Hat instead.

I guess many people agree with me because these days I see very few people advertising Debian as the Wonder OS that it was promoted as when I first got into Linux. These days people tend to promote it by pointing to the (significantly more popular) operating systems built upon it, like Ubuntu or Knoppix. Of course, it's not exactly great PR to promote yourself as the base for what are effectively (policy and project-wise) forks, but marketing was never Debians strong point ...

Re:Timeline in perspective

[alfino]

I was born in 1979 and I became a beta-tester with 13. I don't think Microsoft actually ever cared about my age. I was contacted about beta testing because I completed all 6 MCPs required for the MCSE in a single day, or at least so the email said.

I still have the reports I sent to them as part of the beta testing, and mind you, even now they are everything but childish. But they clearly come from someone who was used to administering nets for 50-or-so users with Netware, and Netware wasn't the direction they wanted to take with NT 4.

For instance, I proposed to allow specification of ACLs per user, rather than per resource. Who here has used Netware and didn't come to love this feature?

-- martin

Great book, too bad about the software

[FishandChips]

Kudos to Martin Krafft for writing his book. Many dream but few ever get it together ...

That said, I spent most of 2005 running Debian Unstable and Debian Testing on different systems and ended up finding both overrated and generally a disappointmennt. Debian was too demanding of time and needed seemingly endless fiddling around and careful management. It also took a lot of time to set up, though admittedly that is a one-off when an installation is still fresh. More important, the Debian developer community seemed shot through with an obsession with doing things the Debian way, with college-level debates (aka rows), with considerable disdain for new users and with frankly pretty obscure things of little interest to many in the everyday world. Overall, I began to wonder if some of these guys would recognize an end-user if they fell over one and my faith in the Debian way rapidly dwindled.

None of this should detract from Krafft's achievement, though. It's a heck of a good thing to have done. I do find it a little odd that he should recommend that new users try Ubuntu rather than Debian. One is tempted to ask: what's the problem whereby they can't use Debian, then?

For myself, I've now gone back to another distro. It's pretty nearly as capable as Debian, with the difference that its devs are technical experts who confine themselves to delivering what works. A distro that puts out for its users without striking tiresome poses or co-opting its users into politics of some kind is much the more preferable, for me at least.

Re:Great book, too bad about the software

[FishandChips]

This is the perfect example of not understanding "The Debian System". YOU aren't supposed to use unstable. You're not even supposed to use testing. If you don't want to have to fiddle with the system, use "stable". That's what it's for. This is clearly explained in a number of places in the documentation.

Actually, that's the perfect example of why Debian doesn't work for everyone, for stictly my two cents. Not every user is in it to be hectored (an obsession with the Debian way, in full caps) or treated with disdain (must be too stupid to have read any documentation, etc.). Personally, I use Linux to get away from all that stuff about we own your ass so do what we say.

To answer another reply, I now use a mucho tweaked SuSE. Works for me. Any number of other distros, including Debian, may well work better for you, maybe more so now Martin Krafft has given everyone the gift of a full-up guide to Debian.

Re:Debian SUCKS on SPARC --- won't install, period

[raynet]

I have couple Sun Ultra 1 workstations and had no trouble installing Debian Linux (Sarge) on them. Just checked couple faqs and howtos to be sure my hardware was supported and how to change screen resolution and how to patch firmware to support 64-bit mode (though I think it was Solaris that required the firmware patch to even boot).

Either you did something wrong or just happened to have an SPARC that wasn't supported or tested.

The Community Sucks

[c_spencer100]

I've never had anything against Debian itself. My problem, as with a lot of other people, was always the arrogance that just seemed to ooze from the average Debian user. If you don't know what I'm refering to, then you probably relatively new to the Linux Community. It seemed for the longest that every question posted on every forum yielded the answer "get Debian". Debian's problem was NEVER being misunderstood - it was being misrepresented by the zealots that actually think their pretentous attitude represents the Debian Community as a whole.

Re:All I know is...

[Anonymous Coward]

Sarge is a dream, but the situation trying to run media-rich apps on it is a nightmare.

Wanna build MythTV on the just-recently-stable (recently on the Debian timescale anyway) Sarge? Sorry - about a week after Sarge went stable, MythTV moved up to the latest unstable. That's just one example - there are others. Miserable situation.

What good is a stable OS release if people won't build the apps for it?

Re:Debian is for hackers; Ubuntu is for users

[dbcad7]

I've been around the block a few times with Linux, but I am by no means an expert, and I use Debian as my primary OS at home. I think it is true not only for all Linux distro's but the Windows side too.. that you will run into "power users" who will try and demean someone with their superior knowledge when you are asking a question.

It is my experience, that Debian is no harder to learn and use than Ubuntu. Ububtu has some polish "out of the box" that Debian doesn't, but really they are not that different. I think any Ubuntu user could run Debian with about zero hours training

As to getting help from other users, I haven't really had any problems with contempt. When I have looked for help, I went to linuxquestions.org because I was used to going there on other distros.. so perhaps it is different where you looked for help.

Re:Modifying packages to conform to FHS = bad

[rekt]

i can't believe this is being moderated as Insightful. What are you mods thinking!?

i'm a huge fan of djb's work, and i use his software (and i use Debian), but quoting his theories about cross-platform compatibility as support for your argument is pretty weak. djb's strong suit is his technical and mathematical rigor, not his infamous interpersonal skills.

For those of us who maintain more than a handful of machines, cross-package similarity is a real and significant advantage:

• Just installed package foo, but don't really know quite how you might use it best? debian policy lets you confidently look in /usr/share/doc/foo and know that you'll find *something* that the package maintainer thought would be worth reading, even if it's only the changelog.
• package doesn't have a man page? thanks to policy, that's an actual bug, not just an inconvenience.
• need to understand exactly how service foo starts and stops? you can read /etc/init.d/foo
• where are the config files? you can find them in /etc/foo/
• and so on...

djb is right that cross-platform incompatibility is a significant hassle. But what's his solution to that? He invents a whole new filesystem standard (see "Filesystem layout" on this page)! I respect the man for his technical prowess. And i'll grant that his proposed scheme probably makes more technical sense than the FHS, when viewed in isolation.

But you don't achieve cross-platform compatibility through technical rigor. You achieve it through compromise, social and political consensus, transparency, legacy support, and published standards. The FHS currently represents all of those things, as does debian. In fact, that's why debian endorses, attempts to comply with, and contributes back to the FHS, because it is committed to cross-platform compatibility. djb's technical nit-picking, while usually a good thing, does him a disservice in this particular area, and debian gets it right.

Re:Modifying packages to conform to FHS = bad

[grosskur]

For those of us who maintain more than a handful of machines, cross-package similarity is a real and significant advantage

You're misunderstanding me. I'm not saying Debian shouldn't add man pages, or make the documentation for package foo available under the name /usr/share/doc/foo, or generally enhance the cross-package interface of their packages. All the power to them. What I'm saying is that if, by default, openssl installs its configuration files in /usr/local/ssl, and Debian wants to put them in /usr/lib/ssl, they should support the default location by symlinking it to the Debian-specific location. That way, people can still find them at the default location. Even if they refuse to touch /usr/local, they can at least symlink /usr/ssl to /usr/lib/ssl, so all the files are in their expected locations relative to the /usr prefix. But they flat out refuse to do that because the symlink would ``clutter up /usr and violate the FHS.'' That's what annoys me.

djb is right that cross-platform incompatibility is a significant hassle. But what's his solution to that? He invents a whole new filesystem standard

You're misunderstanding the purpose of /package: it's not a ``solution'' to cross-platform compatibility. In fact, DJB is strictly against modifying packages downstream to fit into /package. He proposed it as a format for upstream maintainers to adopt, if they choose. Furthermore, he's made it clear what he thinks of the FHS, but he still respects the decision of upstream maintainers who have chosen the FHS for their packages interfaces. He's not telling anyone to get rid of /usr/local/bin in favor of /command; on the contrary, he suggests you symlink everything in /command into /usr/local/bin for compatibility. Please read his pages again carefully. He's terse, but his reasoning is sound.

You couldn't be more wrong when you say Debian ``compromises'' to achieve cross-platform compatibility. In fact, they want everyone to conform to their world view; this is an uphill battle and it will never work. Different upstream authors do things differently with their packages, and they're not all going to suddenly change because Debian and the FHS are yelling at them that they're packages are ``broken.'' They choose layouts that reduce the total effort required by them to support all platforms.

But if you're an upstream maintainer, Debian will change your package's interface downstream as they see fit and make it incompatible with your upstream version. Now all the programs which depend on your upstream interface will break on Debian. So Debian will fix those programs, too, if they happen to package them. But if they don't, your users are in for headaches.

Don't get me wrong, Debian is a fantastic operating system. But there would be so many fewer headaches for users if they attempted to ``play nice'' with other systems, rather than saying ``It's the Debian way or the high way!''

Re:Modifying packages to conform to FHS = bad

[grosskur]

So they don't clutter up my /usr/local/ tree, a directory for things I've installed by hand, with automatically installed packages? Good for them. The Filesystem Hierarchy Standard says "The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated," and I'd hate to use a distribution that violated that safety.

How, pray tell, would one measly symlink

/usr/local/qt -> /usr/share/qt3

violate your ``safety''? Clutter up your precious /usr/local tree? Get a grip. If you want to install a ``local'' version of Qt later, just delete the symlink and go from there.

Why does the directory location of qt matter that much to you anyway? Fedora has it in /usr/lib/qt-3.3 and everything's working fine. In fact, I could put qt in /home/roystgnr/qt/ if I want, define QTDIR and my linker path accordingly, and unless your qt-using software is broken it should work.

The location of Qt matters to me because, if I write a program that depends on Qt, I can provide /usr/local/qt as the default location and it will Just Work for my users. I don't have to give them extra instructions on how to find out where Qt has been installed on their system and how futz around with environment variables. Do you realize how much distributions are diluting my support resources by refusing to make packages available at their default locations? Now multiply that by the number of people writing Qt applications, and you'll see why the location matters to me.

If you want to install Qt to a non-standard location like /home/roystgnr/qt, that's your problem to make it work. High-quality software would make the prefix of a Qt dependency easily configurable, anyways.