Debian Elevates KFreeBSD Port to First-Class Status 376
Reader tail.man points out this press release from Debian which says that the port of the Debian system to the FreeBSD kernel will be given equal footing alongside Debian's several other release ports, starting with the release of Squeeze. Excerpting from this release:
"The kFreeBSD architectures for the AMD64/Intel EM64T and i386 processor architectures are now release architectures. Severe bugs on these architectures will be considered release critical the same way as bugs on other architectures like armel or i386 are. If a particular package does not build or work properly on such an architecture this problem is considered release-critical. Debian's main motivation for the inclusion of the FreeBSD kernel into the official release process is the opportunity to offer to its users a broader choice of kernels and also include a kernel that provides features such as jails, the OpenBSD Packet Filter and support for NDIS drivers in the mainline kernel with full support."
Re:OK (Score:3, Informative)
But, does it run Linux?
No, it's GNU/FreeBSD. It can, however, emulate Linux system calls and therefore natively run binaries compiled for Linux.
Re:I still dont see the point (Score:3, Informative)
So just take stock freebsd, rename pkg_add to apt-get and you are done :)
Ok, im joking of course but you see the point im sure.
Re:Linux vs. FreeBSD (Score:4, Informative)
Re:Awesome! But... (Score:1, Informative)
and that's the problem with the terminology of calling Linux Linux and not Gnu/linux and the like. While being pedantic, it separates the fact that what people are familiar with in dealing with linux, has little to do with the kernel and mostly to do with the utilities and apps that run on top of it. With debian, you dont change the utilities and apps , so it's the same OS no matter what kernel you're using. The kernel just makes subtle changes in what those apps can do (and possibly let you run different apps that aren't compatible between kernels). Start thinking of "Linux" in the same light as we think "Unix". It's not an OS, but it's a superset of OS's. Distributions aren't simply repackaging an OS, they are different OS's. Some limited to just one kernel, some limited by the gui even. We need to stop visualizing them as all revisions of the same pseudo OS.
So no, For the most part, i dont think linux users who use Debian Linux will find themselves in an alien environment with Debian kFreeBSD. And i dont think it would be a stepping stone to using FreeBSD. I think it just gives Debian users (which should be considered it's own OS) a different backend that may do certain things better than the more familiar Linux backend.
With Debian crossing the kernel boundaries, i think the idea that the OS is the kernel will be even more obviously misguided. It's the Debian OS. It really can't be described as anything else. Debian refuses your limitations. Unless it has a non-free license.
Re:Linux vs. FreeBSD (Score:5, Informative)
In my opinion, the biggest advantage of FreeBSD is how coherent the system is. Everything, from documentation to userspace utilities to the kernel, was developed and tested and released as a single project.
This allows for neat features that require cooperation between several system components, which would be more difficult to implement in the Linux world. For instance, in FreeBSD you can press ^T while cp is copying some huge file, and this will send SIGINFO to cp, causing it to print a progress report to STDERR. Handy.
So it seems to me that this Debian project defeats the most attractive feature of the FreeBSD operating system (by separating its kernel from its tightly integrated BSD userspace), while simultaneously casting aside Linux's advantages over FreeBSD (more drivers, more supported architectures, somewhat better performance, and--this may be controversial--in my experience, better stability). On the other hand, maybe Debian really can improve on the FreeBSD experience; apt rocks, and the Debian project does perhaps a better job than anyone of combining the disparate parts of the GNU/Linux ecosystem into a coherent operating system. So kneejerk reactions aside, I guess I shouldn't judge this until I have the chance to try it... still, I don't see myself trading in my Debian GNU/Linux anytime soon.
Re:Linux vs. FreeBSD (Score:2, Informative)
As a UNIX/Linux veteran, I have to admit that I've almost no experience with FreeBSD. Could someone summarize why one might prefer it over Linux?
FreeBSD is unix-like http://en.wikipedia.org/wiki/FreeBSD [wikipedia.org].
You might prefer it over Linuxes for some of the same reasons you might prefer Apple's Mac OS X http://en.wikipedia.org/wiki/OS_X#History [wikipedia.org].
Other than that, perhaps rock-solid stability, ZFS, or it's package management system (admittedly I don't use much Linux, but the pkg_add utility and the ports tree in fbsd are excellent). Oh and did I mention Linux binary compatibility?
Re:Linux vs. FreeBSD (Score:4, Informative)
For instance, in FreeBSD you can press ^T while cp is copying some huge file, and this will send SIGINFO to cp, causing it to print a progress report to STDERR. Handy.
Isn't this an internal feature of their cp implementation? I don't see what this has to do with the kernel, or indeed any program besides cp, at all.
Re:Cool (Score:5, Informative)
If your custom apps required you to install a package, it'll already be listed as manually installed, so it'll never be automatically uninstalled.
The idea is that $app depends on $foo and $bar. But because $foo also depends on $bar, someone was able to goof up and only document that $app depends on $foo. So when $foo gets updated and drops its dependency on $bar, $bar goes away (due to being automatically installed) and $app stops working.
Re:Linux vs. FreeBSD (Score:5, Informative)
A lot of wireless hardware still doesn't have drivers (at least, not working ones) on Linux (or FreeBSD). For obvious reasons, NT drivers do exist. FreeBSD's kernel supports directly loading those NT drivers. Linux has ndiswrapper, a project to allow the same thing (ndiswrapper itself is a Linux kernel module that attempts to load the NT driver binary) but the FreeBSD NDIS support is a feature of the kernel itself, and supported as such.
For TL;DR folks: if you've ever had trouble making WiFi work in Linux, this might help.
Re:Cool (Score:5, Informative)
Not if the required package was already installed because a third package that required it and correctly specified it was installed. Uninstall that package, which seems to be utterly unrelated to your custom app, and BOOM, custom app breaks.
Re:OK (Score:2, Informative)
Re:Cool (Score:3, Informative)
That's a case for having apt on the test server, not the production server.
Come to think of it, you'd have apt on the production server solely because you don't want it to look different from the test server, but you'd still never use it, instead simply copying the package changes from the test server.
Re:Cool (Score:3, Informative)
Which is a good reason to either use apt-get which defaults to the sane behaviour of tracking packages it thinks are unused but not removing them until it's explicitly told to or reconfiguring aptitude to do the sane thing.
Re:Linux vs. FreeBSD (Score:5, Informative)
The grandparent was trying to make a point, but failed. Similar behavior exists throughout the FreeBSD userland--you can send SIGINFO with ctrl-t to many userland processes to get information on what they're doing. The point is that FreeBSD's kernel and userland were designed as a system, and little touches like this show that off.
Re:Awesome! But... (Score:3, Informative)
One thing about so called "rc" bugs in debian is that they divide into a few categories.
* Those that while technically qualifying for severity serious aren't actually bad enough for the release team to take any action.
* Those in packages that the release team considers unimportant enough to kick out.
* The real rc bugs, those that can't be allowed in the release but aren't in packages that can reasonably be kicked out either. These are a small minority of the so-called "rc" bugs but they are the ones that really hold up releases.
Re:Linux vs. FreeBSD (Score:5, Informative)
For instance, in FreeBSD you can press ^T while cp is copying some huge file, and this will send SIGINFO to cp, causing it to print a progress report to STDERR. Handy.
Isn't this an internal feature of their cp implementation?
No. The fact that ^T sends SIGINFO, just as ^C sends SIGINT, is a feature of the "tty driver" (standard tty line discipline). The fact that a particular program catches SIGINFO and prints a progress report is a feature of the program.
I don't see what this has to do with the kernel...
The standard tty line discipline referred to above is in the kernel.
Re:What's Next ? (Score:2, Informative)
Nexenta [nexenta.org]
Re:Linux vs. FreeBSD (Score:5, Informative)
I would say mod parent up, but you're already at +5. This was what made me switch from Linux around 2002: Sound Works. I had a cheapy AC97 CODEC in my computer at the time. It didn't do hardware mixing. I installed Linux. There were two drivers, an OSS one and an ALSA one. Neither one let the majority of my programs play sound at the same time. For example, I couldn't have xmms playing music while I played BZFlag. Both KDE and GNOME came with their own sound daemon, which meant that either KDE programs could make sounds or GNOME programs could make sounds. Oh, and I think if I used the ALSA drivers then two programs that had had their sound output rewritten to use ALSA could play sounds at once... sometimes. Then I tried FreeBSD.
In FreeBSD, there was one driver for the sound device. This was back in the 4.x days, so sound devices needed a little bit of extra configuration. I had to set the number of virtual channels and then tell each device to talk to a different one. I set up 4, one for GNOME, one for KDE, one for xmms and left the default one for whatever apps just wrote to /dev/dsp. I could have music playing, BZFlag sound effects in the game, and notification beeps when I got an email or IM. Then came FreeBSD 5 and all of that manual configuration went away. To play sound, a program opens /dev/dsp and writes audio data to it. That's it. No libraries to link against; it's all done via standard UNIX system calls (open(), read(), write(), and ioctl()). It's trivial to program for and it just works. With FreeBSD 8, you now get per-channel volume controls and a rewritten high-performance mixing algorithm, as well as support for all of the new OSS 4 APIs (backwards - binary - compatible with the old OSS 3 ones) if care about those things (i.e. if you are a programmer).
A few other things that I like about FreeBSD:
There are probably some things I've forgotten. I was going to say that the only thing I miss on FreeBSD was valgrind, but it turns out that Valgrind 3.5 has been in ports for a little while now and I just wasn't paying attention (so, obviously, I don't miss it that much).
Re:Cool (Score:2, Informative)
Sweet, I didn't know they added raid5/6 support to btrfs!
ZFS also has triple parity ("RAID 7"?), as well as the ability to shim in SSDs transparently. There's also 'zfs send/recv'.
How long, and how many petabytes of data has been in production on Btrfs?
Re:Start the RMS timer... (Score:4, Informative)
Re:Cool (Score:3, Informative)
You might want to read up on ZFS. It's not just a simple filesystem; it also includes LVM and RAID features, all in one. I'm not a professional sysadm, but my understanding is that, unlike Linux where changing a RAID5 array to have more disks or more space requires messing with the logical volumes using LVM, then messing with the RAID arrays with mdadm, then redoing the filesystems with the e[34]fstools, whereas doing this in ZFS just involves a few quick commands without having to unmount the filesystem.
In fact, a quick Google search shows that resizing an ext3 partition is a bit of a pain, involving converting it to ext2 (removing the journal), running resize2fs, and converting it back. Obviously that's not good if the power cuts out while you're doing this. With ZFS, you should be able to resize arrays, add disks, etc., without even interrupting service.
If btrfs can do this too, then it sounds great to me. I wish they'd pick a better name though.
This is not how a sane admin uses apt. (Score:4, Informative)
Any sane admin has their own local apt repository, that they point all production and testing servers at. That repository has both "stable" and "testing" branches, like any apt server. All of the production servers grab off of the "stable", and all of the testing off of "testing".
The trick is, this repository SHOULD NOT be a mirror of the actual debian repository. Rather, the "testing" of your internal server should be a mirror of the "stable" debian tree. Then, weekly or daily or whenever new debian "stable" packages come out, you update your testing boxes, and TEST the packages against your local software. If something breaks, no harm no foul - you wait till the next update.
Once everything is tested OK, you sync those packages over to YOUR "stable" branch, and then that night all of your production servers will automatically get those updates. No fuss, no muss.
Re:Cool (Score:3, Informative)
There are more and less correct ways to go about running "non-stable" packages. Just jamming in a foreign binary deb and it's deps is generally the wrong way to do it. The right way to do it is to basically do what backports.org does....and check if backports has it first. If you're not running a Debian derivative then research the equivalent for your distro or BSD flavor:
1. add an apt-src line from the "non-stable" distro. I've even done this when Ubuntu had the latest SpamAssassin and I wanted a late model debianized SpamAssassin. Note well I said "apt-src" and NOT an "apt" line. apt-get update, yadda yadda
2. mkdir package-of-interest; cd package-of-interest; apt-get build-dep package-of-interest. If you're lucky this pulls in everything needed to build the package. If not you'll have to recurse with apt-get build-dep package-of-interest-newer-dependency; apt-get source package-of-interest-newer-dependency and come back to step 2 until you have everything you need to build your "non-stable" package.
3. apt-get source package-of-interest (or -newer-dependency)
4. cd package-of-interest-version; fakeroot dpkg-buildpackage -b. If all goes well a backport of the newer software that is built against your nice stable distro's libraries will be built one directory level up.
5. If you had to build a newer library your package needs install it then go back to #2. rinse and repeat until you have your newer software. Myself, I'll build one or two before giving it up as a bad job. Generally I succeed at this. Bread and butter stuff like Clamav and SpamAssassin that is well behaved tends to work well with this procedure.
The point of this is to avoid having to replace heeby jeeby inducing things like glibc, libstdc++, or even Perl since half your system scripts depend on such things. You avoid replacing packages that are contributing to the stability of the rest of the system and that are still getting critical bug and security updates. It keeps the "foreign" footprint to a middle and gives you a "foreign" package that is more or less compliant with the rest of the system.
Re:Cool (Score:2, Informative)
Having one system that provides the same interface and same capabilities across many sets of hardware is very handy.
In action, ZFS is something to behold.
Re:Cool (Score:3, Informative)
This kind of thing does happen. I've reported a package that did so... we had a fix on the official repositories within days.
Why this is considered a bad thing is beyond me. Debian on my server, other shinier toys on my desktop.
Re:Cool (Score:4, Informative)
You know about Debian-Volatile [debian.org] right? What's even better, is this is part of -stable and has been included in your default repository config since Lenny released.
This is meant specifically for moving targets like ClamAV.
Re:Cool (Score:3, Informative)
You might want to read up on ZFS. It's not just a simple filesystem; it also includes LVM and RAID features, all in one. I'm not a professional sysadm, but my understanding is that, unlike Linux where changing a RAID5 array to have more disks or more space requires messing with the logical volumes using LVM, then messing with the RAID arrays with mdadm, then redoing the filesystems with the e[34]fstools, whereas doing this in ZFS just involves a few quick commands without having to unmount the filesystem.
ZFS can't resize arrays at all, so comparing it to the process in Linux isn't really relevant.
ZFS's "volume management" is certainly easier than in any other OS, but it's real killer feature IMHO is the block checksumming.
In fact, a quick Google search shows that resizing an ext3 partition is a bit of a pain, involving converting it to ext2 (removing the journal), running resize2fs, and converting it back. Obviously that's not good if the power cuts out while you're doing this. With ZFS, you should be able to resize arrays, add disks, etc., without even interrupting service.
Whatever article you found is wrong. The process for growing a FS in Linux (with LVM and ext3) is (can be done online):
Increase size of LV (lvresize)
Increase size of FS (resize2fs)
To shrink (needs to be done offline):
Unmount FS, run e2fsck
Shrink filesystem (eesize2fs)
Shrink LV (lvresize)
The process is straightforward and not difficult, though it *is* easier with ZFS.
Re:Cool (Score:3, Informative)
I use ext2online [squarebox.co.uk] to resize my LVM based ext3 filesystem. To clarify, when I have added a new disk to the LVM [tldp.org] group, I use ext2online to extend the filesystem to cover the new disk. Also, I have never used lvresize. It's the same procedure as either lvreduce or lvextend. Here is my mini howto for adding a new disk to an LVM volume.
Re:Cool (Score:3, Informative)
Re:Cool (Score:3, Informative)
I'm no expert on this, but it sounds like you need to just start over: instead of adding new disks to your existing volume, just create an all-new volume and move everything from the old one to the new one, so you don't inherit any weird problems.
Re:Not as insane as it sounds (Score:3, Informative)
Ummm. WHAT?
Why are you installing all your software from the latest CVS snapshot of FreeBSD ports?
You're supposed to use the RELEASE-tagged ports tree for your version of the OS (the tar.gz file on every FTP mirror server, everywhere). Then, install portaudit, and only when portaudit complains about security issues in a specific version of a specific port, should you CVS-UP that single port, and build the latest and greatest.
Even if the package in question is dependant on 20 other packages, and 20 packages in-turn depend on it, it will work just fine.
So I'll ask again, why do you think you need to CVS-UP the entire ports tree, and build all these new, presumably incompatible and/or buggy newer version of all the software you use?