Submitted by “In conclusion, let me say that Martin’s book is not an easy read, but then few things worth doing are easy to do. You will be challenged by Martin’s book, unless you are a wizard like Martin. But after you have toiled through the intellectually taxing tasks of examining, weighing, lifting, turning and tweaking the multitudinous creatures that inhabit the Debian forest, you will come out with a far, far greater appreciation for the beauty of the Debian System.”
A strange word to use with debian. it certainly is not on my list of words to use with debian.
A strange word to use with debian. it certainly is not on my list of words to use with debian.
Beauty is not always indicative of the outside of something. Debian has an inner beauty that shows itself to those that take the time to learn it.
Damn, I’m feeling awful zen-ish today!
A strange word to use with debian. it certainly is not on my list of words to use with debian.
Beauty is not always indicative of the outside of something. Debian has an inner beauty that shows itself to those that take the time to learn it.
Damn, I’m feeling awful zen-ish today!
A strange word to use with debian. it certainly is not on my list of words to use with debian.
Beauty is not always indicative of the outside of something. Debian has an inner beauty that shows itself to those that take the time to learn it.
Damn, I’m feeling awful zen-ish today!
debian is the best. the package management system works better (and is easier and notably faster, less strenuous on the user) than pkgtools, rpm, etc.
apt and the near-equivalent yum are great. pretty much everything else sucks and is outdated in comparison.
apt is not anything like rpm. Thats comparing apples and oranges.
apt vs yum vs yast vs urpmi vs smart vs swup vs smart. That is a fair comparison.
dpkg vs rpm, yes!
Anyways, if apt is all you like or think is a strong selling point, then wake up. apt has been ported to support rpm for ages.
As far as the packaging systme “just works” it could not be further from the truth. Many debian servers have had the unfortunate pleasure of looking after have been plagued with constent issues.
debian != best, it is so far removed from the best its a joke.
Though I agree that Debian is among the best, and the dpkg/apt package system is great, I think what really makes the difference is not the package system but the quality of the packages themselves.
The author has generously begun offering free copies of his book to encourage people to participate in Debian bugsquashing. See http://blog.madduck.net/debian/2005.11.24-book-bsp.html for the announcement. In fact the closing date for this particular batch of giveaways was the 14th of December, but people should keep their eyes peeled on his blog for a second round of the competition. Great way to motivate people to fix bugs… 🙂
Debian can improve by simply making their update policy less idiotic.
Instead of “security fixes only” policy, it should be “100% backward-compatible bugfixes only” policy.
EXAMPLE OF DEBIAN’S POLICY IMPACT:
Today, jfsutils-1.1.7 is in Debian Stable which has serios bugs fixed in 1.1.8, 1.1.9 and 1.1.10? Debian’s “security fix only” policy for stable is keeping these fixes out of Debian Stable’s jfsutils (partial list):
* Ensure that data gets flushed to disk
* Fix stack buffer overflow in Is_Device_Mounted
* Fix bug in replaying journal that corrupted inodes
I’m obviously not proposing that we update Stable with ALL/MOST upstream bugfixes. I’m saying valuable non-security related fixes related to preventing crashes, data loss, etc. should be included as long as they are 100% backward compatible.
Given this, is Debian’s system really beautiful? Not really but it is still better than most other distros and I’ll continue using it until FreeBSD 6.6 or Ubuntu-Server 7.04/7.10 or similar OS provides sufficient reasons to switch.
“I’m obviously not proposing that we update Stable with ALL/MOST upstream bugfixes. I’m saying valuable non-security related fixes related to preventing crashes, data loss, etc. should be included as long as they are 100% backward compatible.”
FWIW, this is *already* current practice. See e.g. bug #318463, where the e2fsprogs maintainer mailed debian-release requesting permission to upload an updated package to stable-proposed-updates with the following changelog:
* Fix e2fsck segfault if a disconnected inode contains extended attrbutes (Closes: #318463)
* Fix compile_et and com_err library so it is compatible with MIT Kerberos 1.4.x (otherwise it’s core dump city)
* Fix use-after-free bug in e2fsck
* Fix type-alias bug which can cause a reproducible SEGV on at least one ia64 configuration.
To which the stable release manager replied:
“Even though this doesn’t seem to be critical I’d accept it for the first stable update.”
Has the jfsutils maintainer emailed debian-release asking whether an upload to stable-proposed-updates to fix the bugs you mentioned would be accepted? If not, you might want to suggest to him that he do so… Perhaps, like you, he is under the mistaken impression that the criteria for acceptance are more stringent than is actually the case.
And the book must be interesting. There are some good on-line documentation about debian, specifically at http://www.debian.org/doc/ .
The Policy Manual is the one which more clearly explains how things are structured and done in the system, it’s a good read.
Debian Reference Manual also a very nice read, and good to keep close with you.
And of course, for those installing users, Installation Guide. But I advise you to print Debian Reference as well.
Who is writting the init scripts of the ubuntu/kubuntu project? are they comparable to debian scripts and do debian check for open files before tyring to umount the file systems at shutdown/reboot? kubuntu fails in this task quite often.
This book review makes a good point: In order to be able to appreciate the beauty of a large complex system like Debian you first need to understand its underlying principles. The reviewer is also right in suggesting that Martin Krafft’s book does an excellent job in helping its readers to understand how these fundamental working principles constitute Debian.
“The primary theme running throughout Martin’s book is that the code reflects the Debian policy and the Debian social contract.”
The Debian policy and the Debian social contract are always present on every level of the Debian system. These two grand principles help the developers to construct a large and complicated system of checks and balances that guarantee Debian’s high quality and technical excellence. Debian is not a product of one single brilliant mind or one exceptional individual. Instead, it’s the result of a community effort and the volunteer work of thosands of developers and, as such, Debian epitomizes perhaps better than any other project the success story of Free / Open Source Software movement.
The Debian policy manual is available here: http://www.debian.org/doc/debian-policy/
And here is the Debian social contract: http://www.debian.org/social_contract
Very nicely written
I would have to argue that Gentoo is comparably beautiful, if not moreso since it manages to customize and compile everything from source.
I think Debian (or Ubuntu atlest) has higher quality packages, sensible defaults, easy post install configuration if needed at all (mostly Just Works).
Gentoo on the other hand has much nicer tools for system administration. emerge (or the various wrappers) beats apt/aptitude/deborphan hands down.
A conary based Ubuntu would be the killer 😉
To nitpick, this is not all that different from Debian: Debian packages are created as ‘source packages’, uploaded to Debian servers, and subsequently they are automatically compiled into the binary packages (for each platform) end-users generally download and install.
Users, especially on slow machines, will appreciate it that the compilation has already been done for them.
Users who want to compile locally for some reason can simply “apt-get source –compile packagename”.
Granted, optimizing for the architecture the end-user happens to be running is easier on Gentoo, but the systems aren’t as different as they may seem.
I’ve been using debian for 2 years and learned a lot about it. And I must admit the only reason why I still use debian now on 1 computer is the quality and amount of packages. Nothing more.
I think the init files suck (and the symlinks). BSD init style scripts are way cleaner (like in arch linux, freebsd).
And arch linux’s pacman sure is better then apt-get+apt-cache+dpkg for me.
Debian is just not pretty at all underneath the hood either if you ask me. I wonder why there’s always this “debian way” .
The debian menu which I liked a lot is easily replaced with the terrific menumaker program.
Debian boots really slow even after tweaking almost everything. Slackware, FreeBSD, arch linux, … have no problem booting faster with default settings then a tweaked debian.
Even as server I think FreeBSD is better.
If only arch linux would have more packages (quality ones) and more ports to different architectures (i486 !) then it would be my first choice for any computer.
Debian is a nice community effort though and I have to thank everyone who contributes to it.
grtz,
gunnix
You don’t really want Freebsd or Arch. What you want is “apt-get install runit runit-run”.
http://smarden.org/runit/benefits.html
Menumaker sucks hard and deep, IMHO.
Thx for your suggestion. I just tried runit. It boots faster, great. There are other advantages I know, but I didn’t look at those yet. That’s what I gonna look into now
But when will it be the debian default init? (if ever)
The latest menumaker version is great by the way. I removed the debian menu because I like the generated menumaker menu better. Ofcourse I have to edit it for 1 minute to make the menu really good. And if some application isn’t added in the menu by menumaker you can just email the friendly author and he adds it right away.
How much hand tunig is required to get runit to work with a debian system?
Is it just apt-get and reboot, or do you have to create scripts for each service you install?
How much hand tunig is required?
It depends. Read the docs first, then install the app.
“I think the init files suck (and the symlinks). BSD init style scripts are way cleaner (like in arch linux, freebsd). ”
what’s not so clean for you in the init files? They are just simple symlinks which you can quick enable or disable by editing x file attribute.
“And arch linux’s pacman sure is better then apt-get+apt-cache+dpkg for me”
arch’s pacman is way slower than dpkg+apt. The functionality of both appz are nearly the same. You still have to learn both to use them with ease.
“Debian is just not pretty at all underneath the hood either if you ask me.”
Your conception of GNU/Linux beauty must be indeed very strange. Debian is one of the cleanest and most rationally
structured distros out there.
“Debian boots really slow even after tweaking almost everything. Slackware, FreeBSD, arch linux, … have no problem booting faster with default settings then a tweaked debian. ”
Just disable discover and I can assure you your Debian GNU/Linux system will boot as fast as Arch Linux.
Arch is nice, i agree, but the quantity and quality of packages are something they need to improve.
You’ll have to do some hand tuning but it’s not that much. (15-30 minutes should be more then enough time) Just be sure to follow the docs precisely.
Browser: Links (2.1pre19; Linux 2.4.27-2-586tsc i586; x)