Debian NetBSD

bXTr writes "Interesting project over at SourceForge. Quoting from the website, 'Debian NetBSD is a port of the Debian Operating System to the NetBSD kernel. It is currently in an early stage of development and cannot currently be installed from scratch. Instead, a tarball of the current envionment is available and can be extracted into a handy directory on a NetBSD system.' Check out the reasons why they're doing it and some interesting commentary at DailyDaemonNews on this."

Comments

Re:They're not cooperating...

[Carlos Laviola]

Their motivation is quite clear to me: have another choice of a kernel that is already robust and better than the Linux kernel in certain areas, and have the nice, organized and easily upgradable Debian on top of it. Come on, building *everything* from source is so much more trouble than apt-get dist-upgrade. Think XFree86, Mozilla, etc.

I don't like it

[znu]

The thing I've always really liked about the BSDs is that they're complete and separate systems that include everything from the kernel to the userland tools, all integrated by one team. Compare with the Linux world, where you have a bunch of different distros that many people pretend are all the same OS (in spite of the fact that file systems are arranged differently, boot sequences are different, configuration is different, package management is different, userland tools are often different, etc.) because they happen to use the same kernel. The BSD way has always seemed a lot cleaner to me. The idea of seeing a myriad of distros based on the BSD kernels really isn't one that I like. I believe it's a step in exactly the wrong direction. Open source Unix needs more standardization, not more fragmentation.

Transition

[tiny69]

Not too long ago, someone made the comment on slashdot about the general progression of Linux users. As a users becomes more experienced with Linux, they tend to shift from:

Mandrake/RedHat -> Debian/Slackware -> *BSD

It seems that Debian is going to make that last transition a little easier.

ports

[lightfoot jim]

What exactly is the ports system?

More like, what are rpm users missing out on? With rpm -i package.rpm the user may or may not be able to install the intended software. There could be real dependency problems, as in kde2 needs qt2. There could also be bogus dependency problems since you may have compiled qt2 from source but rpm wouldn't know about it.

Enter FreeBSD and ports. A typical FreeBSD install creates a directory called /usr/ports which is a whole tree of makefiles. So to install something, you just cd /usr/ports/category/WhateverYouWantToInstall/ && make && make install. All dependencies are taken care of automagically. The makefiles in these directories are smart enough to download whatever you need and then compile the source on your machine. So installing a new package doesn't take several hours of trolling newsgroups and searching for rpms.

But you don't have to take my word for it. Check this out.

My experience is limited to Mandrake, Slackware, FreeBSD and OpenBSD. They each have their strengths and weaknesses, but when I need to get sh*t done, BSD, espescially FreeBSD is my first choice just because the ports tree contains nearly any software I'd want to run, eliminating the bottleneck that software installation sometimes turns into and letting me get to the task at hand.

As an aside, it seems like everything that Mandrake tries to be to "joe sixpack" who is just getting into trying linux on the desktop, BSD is to the sysadmin or programmer who needs to get a *nix platform up and running for a certain task. Compiling a custom kernel, installing software, modifying the init process, etc are at least as easy for the sysadmin on BSD as adjusting the screen fonts and changing the wallpaper are for a newbie in Mandrake.

Re:ports

[scrytch]

> How is this any more convenient than apt-get which is also available for RPM based systems?

Because ports does not require packages. Example, if I want to install a KDE app, it does not require that I have the qt package installed. It searches for libqt.so. If it's a gtk package, it runs gtk-config, if it's apache, it runs apxs, and so forth. Now debian's a little better than RPM, which ends up making you force-install just about everything (defeating dependency checking) because you installed something from source, but you still have to intervene when a dependent package isn't present. Ports assumes you know what you're doing, and if the lib is there, it's there, it doesn't need a package manifest to tell you. It does check for the package first, and ports does build a package, so you get a package-based system that degrades gracefully when you don't religiously use the package system.

THAT is why I use ports. Because no sysadmin I know of takes the builds out of the box, they keep their source trees around to tweak and recompile as needed. Oh, and ports lets me do that doo, I just "make get" the port, cd work/packagename, and there's the source tree as if I'd untarred it myself. I can configure && make install it from there, or cd ../..; make install from there and it builds as a package.