Slashdot Mirror
Interview with Ian Jackson
Figuring you can never get too much Ian Jackson, Trevelyan writes: "Debian Planet has an
interview with the long time Debian maintainer, and a former DPL, a current member of the
technical committee and the author of
dpkg.
Also
announced Debian GNU/Linux 2.2r7 released. In case some of you thought Debian won't be releasing anything this year =)"
I would be interested for slashdot to host and interview with Ian. As a user of gentoo linux I have experienced much of the power of a ports based system with its portage package management system, which has close ties to Debian's very own apt-get and dpkg. Debian seems very focused on a stable kernel, even more so than any other distribution I know of. Would it not serve Debian to focus more on the Server side of things and leave the desktop to the propeller heads, Gentoo that is. :)
Go Illini!!!
Debian is always out of date so why dont they add a bsd like ports system.
Just for the record... Last time I tried FreeBSD, I found the ports tree not to be all that stable. Trying to install gdm I found something like 4 or 5 broken dependencies.
You can't get quality in a hurry. (Not that FreeBSD isn't great and stable -- I'm just saying Debian is absolutely more polished)
Anyway -- Debian will have something similar to the ports tree (but better) in Woody+1. (apt-src)
Besides that, Debian has been innovating since ever, and has great features:
- APT (now in Conectiva too)
- update-alternatives (now in Red Hat)
- First to adhere closely to FHS
- Bug reporting tools are the best I've ever seen (try reportbug -- the latest version even warns you about the "usual non-bugs in this package") - Kernel compiling tools are quite sophisticated - Debian has been incorporating more Java packages than any other distribution I know of
- Runs on *lots* of architectures. First to use the Hurd. Will soon work wirh BSD kernels (Free, Net & Open)
- Recently created apt-src program will let you create source trees much better than the BSD ports tree.
That's why it takes time to release a new version of Debian.
Well 'outdated' is not a major problem when you want a RELIABLE server.
And I think this is the point of Debian Stable. Tell me exactly what you would need for a home or semi-pro server that's not in Debian Stable?
If you want recent software, 'testing' and unstable shall make you happy.
I think it's a very good thing that a distro keeps a branch that is very unlikely to cause security problems
Ever heard of testing? Replace 'stable', 'slink', or (when it's released) 'woody' with 'testing' in /etc/apt/sources.list and update. Then everything's fairly up-to-date, but since it's already gone through 2 weeks of testing by people who run unstable (like me), it's also fairly stable. It's not as stable as 'stable', of course, but it's not horribly outdated, either.
The only way the typical /.er can pick up a chick is with a forklift. -- AC
-- Terry
My Blog. Sela Ward can sell me long distanc
Grins. That was not exactly my experience. I used to work with him whilst he was doing a summer job before he went to Cambridge. He didn't actually get fired or have to resign; but let's just say that at the time he was rather more interested in security than the system administrators would wish perhaps...
Anyway he matured loads at Cambridge; must have done, cos he's still alive ;-)
Bloody smart guy.
-WolfWithoutAClause
"Gravity is only a theory, not a fact!"I'm running kernel 2.4.18 with ext3. It really just depends on how much work you want to put into your system after Debian finishes installing. Switching from ext2 to ext3 literally took me less than 10 minutes.
Karma: Positive. Mostly effected by cowbell.
Sorry but Debian isn't out of date. If you like, you can use testing or unstable versin of package and you are more updated that with other distro. But if you want a very stable system maybe it's ok to wait the stable. The difference are in security. Now I run 3 servers, two with RedHat and one with Debian, and difference are important.
I can wait for Debian developer to release the new version with it's ok in quality and security features. If you like more "updates" and more insecure system use Redhat like distro.
I shouldn't feed the various trolls, but I guess I will. For one, someone mentioned OpenBSD's no remote hole in 5 years... Well that has changed now. Debian can compete with OpenBSD directly in the realm of security, because Debian backports EVERYTHING. They audit their code. No, they don't tout this fact like Theo does, but Debian is defintely covering their bases. And, you can be sure they will release a advisory AND a patch in a timely manner. Debian maintainers are some of the most talented guys out there, and highly motivated.
Someone said that Debian was dying because it hasn't made a stable release.. Well, clueless troll you are! Run Unstable. It is _cutting edge_.
I have ran Debian since 1.3, and for most of those years, I have used the unstable branch exclusively. I have been burned by it maybe 3 times. 3 bugs bad enough to affect my life. And every bug was fixed within a day. Let's see m$ or anyone else have that level of dedication.
Debian is very much alive and well, thank you very much, and I will continue to use for years to come, and should they stop maintaining, I will be happy to contribute, just to keep it going. Security, current packages, and reliability. Not bad for free software.
'sup with that session-id? Shouldn't you strip it from the link...
What tends to happen is the ports directory lags behind software releases, especially the ports directory that gets installed from cd, and the particular .tar.gz source file that the makefile is trying to fetch isn't hosted on the web anymore.
It's really easy to get cvsup to continually update your ports directory. Just run it once in a while (like once a month or so) to update your ports directory to take into account newer versions of software packages and such. Once you do this, all issues with getting things built will probably never show up.
Are rpms still such a pain in the ass to create? With dpkg, all you need is a "make clean" and "make install" target, and 2 minutes with dpkg-make and you've got a deb of your own software.
/usr/lib/rpm/find-requires and find-provides.
You can manually add Requires or Provides to the specfile, like Provides: smtpdaemon.
/etc/apt/sources.list on a new workstation, apt-get update, and apt-get install ourworkstationload and it downloads the latest version of everything and installs.
In essence, Yes.
You make a specfile which mostly consists of macros; like %configure, %make, %makeinstall. Of course you have to specify other Metadata, like License, Source, Patch1, Patch2, Url. You can make a filelist yourself, where you choose which files end up in the package.
And if you're packaging something that uses libaries, dpkg-buildpackage will automatically figure out what libraries you're using, what packages provided those libraries, and then automatically add them to the package's dependency list.
Yup, rpm uses on mandrake the scripts
A difference is that rpm uses mostly files from libraries as dependencies, while dpkg uses packages. In the end that should just work the same.
Combine that with the ability to easily make your own sources for apt, and making many workstations is as easy as creating one deb file that depends on all the packages you want to have on a workstation. Just add your local source to
Well, if you use apt together with rpm, you can just do the same I suppose.
If you use urpmi with rpm, you can use genhdlist which makes a hdlist.cz file with the rpm-headers. You can then use "urpmi.addmedia name ftp://ftp.bla.org/RPMS with hdlist.cz" and install packages from that repository.
And for the fake package, you can make a specfile without a real tar.gz and filelist, but with your own defined dependencies.
apt and dpkg rock compared to rpm.
There you go again.
You can compare dpkg and rpm.
And you can compare apt+dpkg and apt+rpm or urpmi+rpm.
You cannot compare apt to rpm, in the same sense that you cannot compare apt and dpkg.
Well, don't worry about that. We can get you back before you leave. (Dr. Who)
Security fixes are back-ported to the old versions, where necessary. 'stable' can be kept secure by adding security.debian.org to apt's sources and doing a regular apt-get update; apt-get upgrade.
Q: Are rpms still such a pain in the ass to create?
A: In essence, Yes.
Duh, I meant No. And Yes, they are rather easy to build.
I never built deb packages though, so I can't really compare them.
Well, don't worry about that. We can get you back before you leave. (Dr. Who)
apt does appear to be easier to use than rpm. Not sure about urpmi.
The problem is with dependency resolution. rpm doesn't handle this, though, e.g., up2date attempts to handle it. Whether the reason is the care with which the pieces are built, or for some other reason rpms seem to break via dependency problems more often. (Of course, apt-get assumes an internet connection, etc.)
OTOH, as of Friday, Debian was having problems with validity checking (or possibly with packages?). To be specific, the fileutils module has been refusing to update itself due to validity check violations. Now this may well be because I don't really understand the system. I don't know. And I don't know how to find out.
OTOH, I've had this kind of problem before with rpms, though usually not with anything that seems to be a essential part of the system.
Still, with apt-get I was able to switch from Progeny to Debian testing to Debian stable and back to Debian testing. I was never able to do anything equivalent with rpms.
To my mind both systems have advantages. I haven't decided which I prefer. But there are a lot more packages that are available as rpms. And sometimes those are the ones I need. Compiling will usually work, but if there are unsatisfied dependencies, that conflict with other things that are installed... OUCH!
What I'm really hoping for is that the apt-get for rpms becomes more standardized. (And just why is alien being removed from the next version of Red Hat?)
I think we've pushed this "anyone can grow up to be president" thing too far.
My Blog. Sela Ward can sell me long distanc
Debian Stable is perfect for servers because it is stable. By definition, a 2.2 kernel is more stable than a 2.4 kernel, and arguably a 2.0.39 kernel would be best if you want to minimize uncertainties and surprises. That would explain the continuing development into 2.0.40 and the 2.2.x tree.
Althogh I know of people running idle "servers" that have money to burn for bragging rights, most serious server administrators actually have a budget. Hobby or professional, that means that 1000bT and RAID aren't usually purchased until the previous component is actually a bottleneck. Does SAN really exist outside of the enterprise? How many home servers are on SMP capable motherboards (including the infamously unstable BP6)?
Perhaps your 120GB of data really is crap, which could explain why instead of being properly partitioned, it is existing on a filesystem almost certainly an order of magnitude larger than it should be (according to any Unix administration rule of thumb). If this is the case, then maybe you won't care about your files falling corrupt when your journalling FS sacrifices them for the sake of metadata cohesion. I'm certain that a home server has no feasible means of backup for such a filesystem, so if the data weren't crap, the filesystem should be at least as stable as ext2 with asynch writes disabled.
Again, the point of Debian Stable, in case you didn't catch it, is that it is stable. Many servers are values more for their robustness, which is a typical byproduct of maintained stability. Flaws are addressed by backporting fixes without new features exposing new flaws. The latest featured advances in Linux based systems are definitely useful, but contradictory to the goal of stability. Rather than mad haphazard patching, Debian suggests tracking their Stable tree, which maintains well tested patches that don't add features. If this is a public system, then security takes a justifiable front seat to stability, and so follow that tree as well.
As for your parting shots, Debian Stable is indeed suitable for large systems, especially when it is hard for physical RAM to reach "large" in personal class servers. RAM too large to autodetect in less-than-recent kernels is easily accessible by passing the value to the kernel during boot.
Multiprocessor systems are definitely useable, the latest advances in 2.5 don't negate the previously available SMP functionality of 2.2. If you are maxxing out your SMP hardware, maybe less stability would be a valuable tradeoff for improved SMP utilization. Is your home server stressing the locking schemes? Remeber, Seti@home won't benefit from improved SMP - you still have to run multiple instances of the client.
If you use "PC" in the Intel-x86 sense, then you couldn't be further from the mark. Debian Stable supports a wider range of platforms than any competing GNU distribution's latest release. Higher Debian releases support even more architectures. I don't think SGI or IBM servers could really fall within the scope of semi-pro or personal without aiming half a decade into the past.
As for attached storage, propose a home or semi-pro serving situation where there will be heavy writing activity which may benefit from a journaling FS so that I know where you are coming from. Most serving implies reading, not writing of files, and serving from a read-only filesystem might even be prudent. (Notice my previous comment about partitions.)
As for your pissant serving tasks, wouldn't stability still be top priority? To promote further discussion, please point out which distros handle routing and firewalling better then Debian, and just how so. Which features are better than stability?
Honestly, I don't think any distro yet available will stop you from shooting yourself in the foot if you insist on running a "server" without following standard administrative guidelines... what does your fstab look like? Does your primary serving task involve MPEG2 rips of LotR, Shindlers List and Dances with Wolves? Please, choose between personal, semi-pro, or enterprise class serving. (SAN? give me a break.)
"Sure, Linux 2.2 is old, but it's heavily tested, and stable as hell". Fair enough, when when you start upgrading to a later brank of the kernel, you aren't running that "heavily tested stable as hell" kernel any more.... same level of testing and abuse...
stable but 3 years out of date.... yada yada.
If your hardware is brand new and only supported by unstable Linux, then it isn't considered stable hardware. If your Linux is brand new and only supported by unstable GNU then it isn't considered a stable kernel. If your server had more than one client, then you sould have been foolish to do all the hard of of upgrading, patching, etc etc yourself to the latest unstable Stable Linux. Much better to track a distribution's less volatile path towards your desired featureset even if it isn't "up to date." Most distributions of GNU have proven over time their priorities regarding stability versus featuritis. Choose one that reflects your comfort level.
The point of Debian is that you don't have to do the hard work of upgrading and patching yourself. When pointing at an appropriate APT repository, you type "apt-get update; apt-get dist-upgrade". While Debian Potato isn't considered Stable (offically sanctioned by the Debian Project) with Linux 2.4, that doesn't mean that it isn't stable. As for the hard work of DIY, Google for "Debian Potato 2.4" and feel the pain of typing "apt-get dist-upgrade".