Debian Gets FreeBSD Kernel Support 425
mu22le writes "Today Debian gets one step closer to really becoming 'the universal operating system' by adding two architectures based on the FreeBSD kernel to the unstable archive.
This does not mean that the Debian project is ditching the Linux kernel; Debian users will be able to choose which kernel they want to install (at least on on the i386 and amd64 architectures) and get more or less the same Debian operating system they are used to.
This makes Debian the first distribution, and probably the first large OS, to support two completely different kernels at the same time."
Gentoo was there first (Score:4, Informative)
Gentoo has supported the FreeBSD kernel for a while now, afaik
Late to the party, Slashdot. (Score:3, Informative)
Debian has had an unofficial kfreebsd-i386 port for years. It is still an unofficial port.
Re:So it it Debian GNU/Linux/FreeBSD (Score:5, Informative)
Some more info (Score:5, Informative)
Is available at http://www.debian.org/ports/kfreebsd-gnu/ [debian.org]
There isn't much, but a little bit in the install notes.
Unofficial ports (Score:1, Informative)
As someone else has mentioned, the kFreeBSD port has existed unofficially for some time...
You can also run Debian with a HURD kernel. I did that years ago. It was kind of unstable, but an interesting thing to try out for fun. And it largely worked. :-)
Re:So it it Debian GNU/Linux/FreeBSD (Score:5, Informative)
GNU C library
Re:UbuntuBSD? (Score:5, Informative)
https://edge.launchpad.net/ubuntu/jaunty/hppa [launchpad.net]
http://cdimage.ubuntu.com/ports/daily/current/ [ubuntu.com]
(these are the links for the in-development release Jaunty, but HPPA has been a part of Debian since Breezy).
Re:Switching kernels for one install or? (Score:3, Informative)
It's probably an either/or proposition*, since the system calls and basic libraries aren't the same across the platforms.
*FreeBSD has a kernel level Linux binary compatibility layer, so I guess with enough pain and suffering you could make things switchable, at least with userland stuff.
Re:Late to the party, Slashdot. (Score:5, Informative)
It just became an official port. That is what is news.
Re:Gentoo Did This Years Ago (Score:5, Informative)
Tag this article gentoodiditfirst. I saw this in gentoo long ago.
Re:Gentoo was there first (Score:5, Informative)
Actually Gentoo has for quite a while had the option of installing all binary packages from a standard LiveCD.
Re:Gentoo Did This Years Ago (Score:5, Informative)
So did Debian. Debian GNU/kFreeBSD as the port is poetically named has existed for a long time (see mailing list archives [debian.org]). This story is just about it being accepted as an official part of Debian. Who got there first? Who cares.
Re:/usr/bin/pride, /usr/bin/ego, /etc (Score:5, Informative)
Compiler and toolchain, and all the 'standard' UNIX tools: the shell, the text utils like cat, grep, awk, etc.
Basically, back in the 80s, the FSF, reimplemented what was at that time nearly the entirety of what was called UNIX except the kernel (which was what the HURD project was/is). It was to be the GNU OS. While the kernel was in development, the userspace tools were developed and ported to other UNIX systems like sunos as a replacement for the often deficient historical versions supported by the UNIX vendors.
So when Linus came along and wrote a UNIX-like kernel using gcc, he could load all those programs on and have a mostly functioning UNIX environment. This was the reason RMS objected to calling it just Linux, at that time the majority of the code running on the system was GNU. It was probably a legitimate point at the time. And even if there were a different compiler, without a set of userspace tools that people could freely get and use it is unlikely Linux would have been able to take off.
Now, of course, a huge part of the user experience is provided by X11, the desktop environments, and various graphical appliations. GNOME is part of the GNU project but X.org, KDE, and most of the applications are not. So it isn't really true that GNU software is still the majority of the OS. Of course, the kernel is even less important in terms of the user environment, and despite all the other software around it, GNU utilities are what makes it (not) UNIX.
Re:I run Debian, and I run FreeBSD. (Score:1, Informative)
Now you've Seen Seen On Slash [seenonslash.com] On Slash.
Re:Switching kernels for one install or? (Score:3, Informative)
Pain and suffering? You mean editing the linker config so that the compat libraries are loaded first?
Re:I run Debian, and I run FreeBSD. (Score:5, Informative)
ZFS is nice, but thus far FreeBSD's port [freebsd.org] isn't.
Re:This is new? (Score:2, Informative)
Yes, but what does it really mean? (Score:4, Informative)
There are at least two things that need consideration here, in a sort-of general aspect:
There's little documentation about the Debian project but it doesn't say which route they've chosen, and what about possible issues with it (mostly: admin utilities).
And besides, a very large number of BSD users will agree that its userland is what's most important - the consistency of development and behaviour, the ease of administration. The kernel features are just icing on the cake :)
Re:ZFS support (Score:5, Informative)
I just don't see the requirement to have a shitty GNU userland on the FreeBSD system.
What do you mean? Every GNU tool I've used is far better than its BSD counterpart (if it exists). Some manpages do suck, but I've never failed to find the information I need for any command that is remotely complicated.
In any case, if the Debian maintainers shared your opinion of the BSD userland, they would try to get that into their standard Linux-based distribution, rather than wait to have the FreeBSD kernel to do that there.
Hurd too.. (Score:5, Informative)
http://www.debian.org/ports/hurd/ [debian.org]
Going the other way... (Score:1, Informative)
For a number of years now I've been going the other way. I have a Linux kernel but a large portion of my userland is from the BSDs.
For the most part, BSD tools build quite well on Linux (or more precisely, with glibc). I've had to create a small portability library to bring in functions that glibc lacks, but for the most part I've just been able to pull stuff from FreeBSD's libc with little modification.
I have replaced GNU coreutils almost completely with BSD versions (I wrote my own du and df because the BSD versions are too chummy with its kernel, and I've brought over heirloom sort because it doesn't have the size limitations of the BSDs'). I've got BSD gzip, tar, yacc, among others. I even have (Net)BSD's /sbin/init and related tools, and it works great.
I have some local patches to various programs that assume a GNU environment, but for the most part, the BSD tools work as drop-in replacements. What's more, they have man pages that do more than say "see info", which is fantastic.
Some things have to stay GNU for now, but I keep replacing as I can. I hope one day to replace glibc with a BSD-based version, but that's wishful thinking for the time being: while a lot of stuff could directly be used, a lot would have to be written expressly for Linux, and I haven't had the time to deal with that. I'm crossing my fingers about clang, so that I can replace gcc with another compiler some day.
Re:Switching kernels for one install or? (Score:5, Informative)
Disclaimer: I'm a FreeBSD fanboy.
FreeBSD has no problem running Linux binaries, linux binary compatibility has been there for years, I used it to run linux binaries that hadn't yet been ported to FBSD yet in 97, I still run several Linux binaries on my FBSD servers.
For things that don't directly interact with the kernel, FreeBSD will run Linux binaries fine, full syscall emulation is built in with practically 0 cost in most cases. You need the proper Linux libraries available for it all to work, but it will also run ibcs2 binaries so you can throw in SCO and such if you got a license for those libraries!
All it does is emulate the syscall interface to the kernel. FreeBSD and Linux are almost spot on in the way these interfaces work so it can accomplish the task with very little overhead, in many cases its just as efficient as using the native FBSD syscalls. In other cases some structure and memory mangling goes on so it slows down a bit.
FreeBSD is actually capable of running some Linux apps faster than the Linux kernel can. Of course thats simply because those apps happen to agree with the way FreeBSD does things under the hood a little better and not an indication of superior OS, as there are just as many apps that perform worse. As a general rule however, performance is practically identical as running it on a native Linux kernel.
With all that in mind, theres no reason you couldn't switch at boot time if your entire userland was made for the Linux kernel. There would need to be certain parts left as native code such as initd and the like, but you're really just talking about holding duplicate copies of what FBSD stores in /sbin and /bin. Probably just a simple matter of modifing the FBSD kernel and /bin /sbin apps to expect to work from /freebsd/boot,/freebsd/bin,/freebsd/sbin.
Doesn't Linux have this sort of thing? I haven't used Linux in years, I just kind of assumed it did something like this as well. Maybe not for FBSD so much, but I'd expect some ibsc2 support at least.
Finally, doesn't seem like theres much of a point really. FreeBSD is typically considered 'more secure' and has the fastest IP stack on the planet out of the box, but security is mostly a property of userland, kernel level exploits are rather rare now days, its usually a dumb app running with elevated privs that causes the problem so if you're using a Linux userland you aren't gaining that bit (real or imaginary). Linux isn't exactly slow when it comes to networking so unless you're trying to squeeze every last drop out of some hardware that doesn't seem to make it worth the while, might as well stick with what you know and what you know works for you. Just seems silly.
Re:APT? (Score:3, Informative)
Yes, it's a joke but it has an answer too. It might depend on how you define a "package manager" but all BSDs can do:
And this is not new - it's been there more than 13 years [freebsd.org]!
Re:ZFS support (Score:3, Informative)
Really? Hmmm...
http://evilviper.nstemp.com/BASH-SUCKS.png [nstemp.com]
Thank god for the OpenBSD version of ksh. With mksh it was made portable and can be installed on practically any Unix system. It features practically every BASH feature human beings could ever use, while being a tiny fraction of the size.
And how about FreeBSD's tar? No -z -Z -j crap... use any of the flags, and whatever compression method used will be detected and handled.
How about "ps -ax" bitching at you not to type the dash (which every other Unix system requires), or "bc" printing a dozen lines of the GPL every time you start it up?
Or how about just the fact that nearly every GPL binary is 4X the size of any of the BSD equivalents?
There's thousands more examples, I just haven't written them all up, and just listed a handful off the top of my head. Why don't you start trying to list a few ways YOU'VE find GNU utilities to be any better than their BSD counterparts?
Debian had netbsd and hurd kernels for 7&10 ye (Score:2, Informative)
Debian added:
Hurd kernel port in ? 1999 ? (may have been earlier, wasn't later)
Netbsd kernel port in 2002
And there was an unofficial port of the Open Solaris kernel to Debian a couple years back.
http://www.debian.org/ports/ [debian.org]
Re:ZFS support (Score:5, Informative)
Why don't you start trying to list a few ways YOU'VE find GNU utilities to be any better than their BSD counterparts?
I'm not the parent, but here you go:
- The BSD -h (--help) is a joke for almost every command. It gives you something like "usage: cat [-benstuv] [file ...]" with zero explanation what each of the switches do. Or "usage: ls [-ABCFGHILPRSTUWZabcdfghiklmnopqrstuwx1] [file ...]". Very helpful.
- GNU userland supports the things one might want to do. The BSD tools just don't have the features. Like, last time I wanted to teach my students to use apropos to find system calls, I told them to use apropos -s 2. Well, turned out some of them decided to use the BSD machines here, and apparently there's no such thing on the BSD apropos. Not only that but it doesn't have a --help or a -h at all. Missing features like this are truly pervasive in the BSD land. I hit them nearly every time I want to do something more exotic on a BSD.
Small things like
- BSD tar lacks the jz switches. Seriously. I want them.
- And for that matter, bash is the best shell I've seen. Yes, I've tried ksh.
The BSD kernel I can take (although I don't see the advantage compared to Linux), but I do want the GNU userland to consider the system even half-usable.
Apple mkLinux Microkernel (Score:2, Informative)
Apple's mkLinux [mklinux.org] (Wikipedia [wikipedia.org]) was based on the Mach 3.0 microkernel [wikipedia.org]. There was a howto to make it work with the standard monolithic kernel. It doesn't really count as "shipping with 2 kernels" but it did run on top of two kernels. It's been pretty much dead since 2002.
OS/2 [wikipedia.org] from IBM also shipped in both monolithic and microkernel flavors [wikipedia.org]. The ill-fated but technically shipped PowerPC version was microkernel-based, but not in the same installable package as a monolithic kernel based OS. This was in about 1996.
I wouldn't be surprised if back in the day, some experimental OSes shipped with both 32-bit and 16-bit kernels.
Re:ports-- (Score:4, Informative)
http://www.freebsd.org/doc/en/books/handbook/packages-using.html
Re:ZFS support (Score:5, Informative)
Thank god for the OpenBSD version of ksh. With mksh it was made portable and can be installed on practically any Unix system. It features practically every BASH feature human beings could ever use, while being a tiny fraction of the size.
Bash and ksh are quite on par feature-wise, so pick whichever one you prefer since both are available on GNU and BSD systems. However this misses the GNU-vs-BSD point, as do you -- if anything, you should be comparing bash against tcsh which is the default shell in FreeBSD. Is there such a thing as a BSD shell anyway?
And how about FreeBSD's tar? No -z -Z -j crap... use any of the flags, and whatever compression method used will be detected and handled.
From the GNU tar manpage (which, it may surprise you, is actually useful):
-a, --auto-compress
with --create, selects compression algorithm basing on the suffix of
the archive file name
So it's there, as an option. And IMO it makes better sense as an option than as default behaviour.
How about "ps -ax" bitching at you not to type the dash (which every other Unix system requires),
Again from a GNU manpage:
Note that "ps -aux" is distinct from "ps aux". The POSIX and UNIX standards require that "ps -aux" print all processes owned by a user named "x", as well as printing all processes that would be selected by the -a option. If the user named "x" does not exist, this ps may interpret the command as "ps aux" instead and print a warning.
That is, BSD ps has a given syntax ('ps aux') and "conveniently" ignores any dash preceding the options ('ps -aux'=='ps aux'). This clashes with POSIX standards. GNU ps not only supports its own POSIXly correct syntax and the strict BSD syntax, but it also correctly catches things like 'ps -aux', issues a warning and runs the command you intended to run. And you complain?
"bc" printing a dozen lines of the GPL every time you start it up?
If a dozen is three, then yes. It doesn't do that when you pipe into it, which is all that matters in practice.
Or how about just the fact that nearly every GPL binary is 4X the size of any of the BSD equivalents?
I don't see how that's to do with anything other than how the binaries were compiled?
Why don't you start trying to list a few ways YOU'VE find GNU utilities to be any better than their BSD counterparts?
GNU make is a great example, because it's obviously immensely superior to all other implementations of make.
Other than little personal annoyances, you've listed nothing much. Try comparing manpages side by side and let me know when you find a single *feature* in a BSD tool that is not in a GNU tool. Starting by the ones you mentioned above.
Re:Debian Solaris? (Score:1, Informative)
http://www.nexenta.org/
Re:I run Debian, and I run FreeBSD. (Score:5, Informative)
It all depends on what you do with it, and how much time you put into it. If you are willing to put in the effort up front, to plan out how the pool is created, to tune the OS and ZFS, and to test things ... then you can get a very performant, very stable system.
We have a pair of storage boxes running FreeBSD 7.1-RELEASE with / and /usr on CompactFlash on one and USB sticks on the other (2x 2GB mirrored using geom_mirror), with /var, /tmp, /usr/local, /usr/src, /usr/obj, /usr/ports, /usr/ports/distfiles, and /storage/backup as ZFS filesystems. Some have compression enabled (gzip-9 or lzjb), some have atime enabled, some have snapshots created daily.
They're 5U rackmounts with 2x dual-core Opterons, 8 GB of ECC SDRAM, a 3Ware 9550SXU PCI-X RAID controller, a 3Ware 96650SE PCIe RAID controller, a 1350-watt 4-way redundant power supply, 4-port Intel gigabit NIC, as 24x 500 GB SATA harddrives.
The zpool is configured using 3x 8-drive raidz2 vdevs, giving a total usable space of just over 10 TB.
The primary server does an rsync-based backup of 90 FreeBSD and Linux servers every night. Takes just under 5 hours. According to MRTG, which polls the 32-bit storage counters every 60 seconds, it sustains 80 MBytes/sec for the bulk of the 5 hours. We can't get the 64-bit storage counters to work, so it's possible the counters are looping. We're also limited by the remote site bandwidth, as most sites are ADSL with ~768 Kbps uploads.
Other than some problems with the initial configuration of the server (don't use more than 9 drives in a raidz2 vdev), and with the initial "trial and error" for the kmem, ARC, and network tuning, it's been running very smoothly. We have daily backups going back four months, and only used 2 TB so far.
At this rate, we'll be able to keep a full year of daily backups without running out of space. And if we start to get low on space, we just swap out the drives in one of the raidz2 vdevs for larger ones, and continue one with the extra space.
We're really looking forward to the changes that FreeBSD 8.0 will bring, as it includes ZFS v13, removes the 2 GB kmem barrier, and a bunch of other unrelated performance enhancements.
Just because some people have run into some problems with ZFS, doesn't mean it's crap for everyone. You just need to run the 64-bit version, with lots of RAM, or be willing to test and tune to find the right settings for your 32-bit setup.
Once you've used a pooled storage system, or any filesystem with inline snapshots, you won't be able to use LVM anymore. LVM is okay, and has it's uses, but the snapshots system for LVM is crap, more crap, and worse crap.
Re:ZFS support (Score:5, Informative)
- BSD tar lacks the jz switches. Seriously. I want them.
http://www.freebsd.org/cgi/man.cgi?query=tar&apropos=0&sektion=0&manpath=FreeBSD+7.1-RELEASE+and+Ports&format=html [freebsd.org]
Do you see the -jz switches, cause I sure do. Maybe you could get a clue before you're put in a position of "teaching". Another sad mark reflecting the lack of rigor in our educational standards. Talk about the blind leading the blind.
Also on bsd utilities, -h(if it exists) assumes you have some basic knowledge of the command. Otherwise that is what man(1) is for.
In response to you syscall bs, you can reference this file: /usr/src/sys/kern/syscalls.master or this one for linux syscalls: /usr/src/sys/i386/linux/syscalls.master. Wow even easier than apropos returning jumbled garbage. Imagine that. I'm also going to share a really special trick, you can even use grep(or other utils) on those files to return specific info you're targeting.
Horatio, one of us here doesn't know what the fuck we're talking about and I'm betting it's not me.
Re:I run Debian, and I run FreeBSD. (Score:3, Informative)
It's Xen, and you can run FreeBSD in an HVM just fine, no hoop-jumping required. Works for 32-bit and 64-bit guests, all the way back to 6.2 (earliest version I used in my testing).
It's true that PV support for FreeBSD guests is lacking, but that's not to say you can't run FreeBSD on Xen.
Re:I run Debian, and I run FreeBSD. (Score:3, Informative)
Not LVM: Btrfs.
http://en.wikipedia.org/wiki/Btrfs [wikipedia.org]
Incorect Bragging Right Bring Only Shame (Score:1, Informative)
"This makes Debian the first distribution, and probably the first large OS, to support two completely different kernels at the same time."
First? Nope: Gentoo Linux has supported Linux on a BSD kernel for a number of years now.
Also, when you say "at the same time," I'm sure you meant that Debian users can chose either kernel during install, not that users can choose which to boot either BSD kernel or Linux kernel each time they boot... please write more clearly.
Re:Gentoo Did This Years Ago (Score:2, Informative)
Re:What's the point? (Score:3, Informative)
Because if you want to run anything besides sendmail you are stuck with the ports that occasionally have the quality control of "if it compiles ship it", especially if you head of the beaten tracks and try obscure ports like php and samba.
Debian has its short comings, but if you like FreeBSD because it is integrated, you should find that Debian is even more integrated.
FreeBSD tends to have the source readily available and builds without any black magic to hold together a billion dependencies, so it is a more fun system to hack on, and figuring out where a problem is much easier, if you have training in the Computer arts.
In Debian, simply enabling apt-src does not get you a fully populated /src tree, and getting the source to start looking at to see if you can make a patch is a pain.
Just a few thoughts from someone that uses Debian and FreeBSD as my two most common operating systems.
Re:Switching kernels for one install or? (Score:3, Informative)
> Does this actually work 100%? How?
No. The only reason I run Debian on my desktop instead of FreeBSD is because I need to use VMWare, which hasn't run under the Linux compat stuff since VMWare Workstation 3, but given that it *did* work once is a bit of a tribute to its completeness.
I spent several years running an extremely busy yet stable Counter-Strike server under Linux compat, which performed significantly better (lower latency, less CPU load) than when running Linux natively on the same hardware. Good times...
> what does FBSD do when I open("/proc/*") and start parsing stuff?
If you've got linprocfs in your kernel and mounted, it should work in most cases.
In general, linux compat stuff works surprisingly well unless you need a high level of kernel interaction such as modern VMWare releases. In 99% of cases It Just Works.
Re:I run Debian, and I run FreeBSD. (Score:3, Informative)
"I still can't wrap my head around how the two kernels yield to each other in respect to the PC architecture"
User Mode Linux manages it... imagine a UML running in kernel mode, loadable as a module... you lose the protection of running it in user mode, but you gain speed of running it within the kernel.
Comment removed (Score:2, Informative)