Slashdot Log In
Debian Gets FreeBSD Kernel Support
Posted by
timothy
on Sun Apr 05, 2009 05:39 PM
from the types-like-this-kept-me-out-of-good-schools dept.
from the types-like-this-kept-me-out-of-good-schools dept.
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."
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
I run Debian, and I run FreeBSD. (Score:5, Funny)
I think I need to lie down now.
Re:I run Debian, and I run FreeBSD. (Score:5, Interesting)
Parent
Re:I run Debian, and I run FreeBSD. (Score:5, Funny)
now all they (Debian) need to do is replace the userland with a BSD one (preferably Net) and we'll have a proper OS.
*zing*
Parent
Re:I run Debian, and I run FreeBSD. (Score:5, Funny)
Two kernels? At the same time? I'll be in my bunk.
Parent
Re:I run Debian, and I run FreeBSD. (Score:5, Funny)
You know what I'd do with a million bucks?
Two kernels at the same time.
Parent
Re:I run Debian, and I run FreeBSD. (Score:5, Funny)
You know what I'd do with a million bucks?
Two kernels at the same time.
Just 2??? For a million bucks? You're aiming to low. Imagine a beowulf cluster of them!
Parent
Re:I run Debian, and I run FreeBSD. (Score:5, Interesting)
Two kernels? At the same time? I'll be in my bunk.
That's essentially what cooperative Linux does, runs a Linux kernel and the NT kernel at the same time, often with a special X emulator to get full-blown Linux apps running in Windows userspace with better support than with Cygwin. I still can't wrap my head around how the two kernels yield to each other in respect to the PC architecture, but it's an interesting project - guaranteed to keep you in your bunk for a while ;)
Parent
So in other words... (Score:4, Funny)
Debian is dead. Netcraft confirms it.
Parent
Re:I run Debian, and I run FreeBSD. (Score:5, Interesting)
FreeBSD
*is more secure (apparently, i don't know enough to be sure but they're development model and security results do tend to suggest this)
*has zfs,
*etc
while linux has other advantages,
*hardware support for many newer devices,
*faster boot (i think),
*lvm (imho when snapshot merging merges, i think it can compete with zfs)
*etc
So while I think the biggest difference though is the licensing, there are some pretty big differences that affect users.
Parent
Re:I run Debian, and I run FreeBSD. (Score:5, Informative)
ZFS is nice, but thus far FreeBSD's port [freebsd.org] isn't.
Parent
Re:I run Debian, and I run FreeBSD. (Score:4, Interesting)
Apple's port too :) http://zfs.macosforge.org/trac/wiki/ [macosforge.org]
I mean they do a great work but it is basically not ready for prime time. For OS X, Prime Time means at least time machine support, data write/read (including all metadata, even Finder flags) support, Disk Utility GUI support and at last, boot support. Of course, don't forget no kernel crashes should happen and it should handle massive abuse, uptime and even sleep without any glitches. If a Mac doesn't sleep when no programs running, it is generally taken to service by end user.
Things go really complex when your potential ZFS loving users are professionals doing things with Resource (metadata) enabled files (e.g. Photoshop) and expect exact (not 99.9) feature compatibility with HFS+. If ZFS really rolled out in Leopard (10.5) release, there were even people asking for commercial, high end disk utility (like Disk Warrior) support.
What ZFS needs is a very practical use and the proof of how modern it is. Time Machine of OS X is the best thing to prove it to end users. Adding new disks easily when space runs out, snapshots etc. If there is one company which can make ordinary users say "Wow, I really need it" for such a high end filesystem, it is Apple.
I was actually expecting ZFS on XServe/RAID/OS X Server but I forgot the files stored on them are generally Apple Client files too.
Parent
Re:I run Debian, and I run FreeBSD. (Score:5, Interesting)
As someone who's run FreeBSD for their dedicated desktop for close to 5 years now, my only gripes are this:
I love FreeBSD, though. There have many times when I downloaded and and burned a new Linux distro CD with the intent of moving back to Linux (5 years prior to my jump to FreeBSD, I ran Redhat or Fedora on my desktop). However, when I tried the live CD, I just couldn't bring myself to go back, even with the few shortcomings I highlight above.
While the mating of Debian and FreeBSD is cool for its own sake, I really don't see how someone from either camp would be happy with the result. If you like the cutting edge hardware support, virtualization, filesystems, and software support of Linux, you'll miss them in FreeBSD. If you enjoy the Zen-like simplicity of the base FreeBSD OS (including its rock solid nature) and the "ports" system, you'll be left wanting with even the best Linux solution (which, in my opinion, would probably be Debian). I applaud the effort, but I doubt it will have much adoption in the long run.
Parent
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.
Parent
Re:I run Debian, and I run FreeBSD. (Score:5, Insightful)
*faster boot (i think)
As an honest question (from someone who, not that it matters, runs both slackware at home and xp at work), what's with the obsession with boot time? Can anyone explain why the free software community is so obsessed with this metric? I understand that embedded devices are better when they boot immediately - nobody wants to have to wait to make toast - but to boot a computer? Don't most people just sleep or hibernate their computer these days anyway? I think that before yesterday, the last time I rebooted this machine was a couple months ago. I don't mean this as a slight - it's an honest question.
Parent
Re:I run Debian, and I run FreeBSD. (Score:4, Insightful)
Parent
Re:I run Debian, and I run FreeBSD. (Score:5, Interesting)
Energy saving.
I turn off my computer every night, when it isn't downloading something. It's about 6 hours of near-zero power consumption every day. If everyone did that it would make a difference in energy use. I could just suspend, but if it isn't going to do anything anyway, let's save a couple more joules, shall we?
And when I boot it in the morning, I don't want to have to wait two minutes just to see xkcd.
Especially since Arjan demonstrated it was so easy to optimise the process.
I think if the boot was quick to begin with, people wouldn't have got this bad habit of leaving the computer on 24/7. Just because Linux can run months straight doesn't mean that it should.
Parent
Re:I run Debian, and I run FreeBSD. (Score:5, Insightful)
As an honest question (from someone who, not that it matters, runs both slackware at home and xp at work), what's with the obsession with boot time? Can anyone explain why the free software community is so obsessed with this metric? I understand that embedded devices are better when they boot immediately - nobody wants to have to wait to make toast - but to boot a computer?
Boot time is the only time the computer is on when you can't switch to a browser while waiting for it to do something you want done, but aren't interested in the process. You can do that with copying, torrenting, uncompressing, compiling, encrypting, etc, but not boot.
Also, because you shouldn't have to wait [lwn.net].
Don't most people just sleep or hibernate their computer these days anyway?
I dual boot Gentoo and Vista. And ditching either one is not an option.
Parent
Once a decade? (Score:5, Funny)
Whippersnappers. I haven't rebooted my Multics machine since the 60s!
Parent
Re:I run Debian, and I run FreeBSD. (Score:5, Insightful)
A couple reasons for quicker boot:
kernel or driver updates that cannot be dynamically unloaded and reloaded require a reboot. If you want to keep your system patched up to fix bugs and insecurities you will need to reboot at some point. Might sound like a trivial scenario but a long boot process can deter you from doing the necessary update.
Laptops and other mobile devices should boot quickly. Granted, suspend and hybernate are good options but these systems do need to be rebooted on occasion and nothing sucks more than a 5 minute reboot when your battery is low and you are on an airplane. believe it or not, sometimes X crashes and the system cant shake the leftovers because of an nvidia driver quirk.
virtual machine environments where bringing up more computing resources in a hurry is necessary and a fast booting VM image is necessary.
and lastly, the drive to make things work faster is what keeps the gears of progress spinning. If we get content to have slow bootup then we will always have slow bootup.
Parent
Servers (Score:5, Insightful)
but that's what, once a month, once a year, once a decade if your server is in good health?
You seem to make the assumption that people keep their computers on 24x7.
I imagine *many* consumers want their computer to turn on instantly during a cold boot. That's obviously unrealistic for now. But even more certainly, *more* people would prefer it.
Now, I know you may not care much -- but if given the chance -- wouldn't you want faster boot times if possible? Why not? So if yes, why not try?
Parent
Gentoo Did This Years Ago (Score:5, Insightful)
Re:Gentoo Did This Years Ago (Score:4, Funny)
Perhaps, but I'm not sure if it's done compiling yet to test.
Parent
Re:Gentoo Did This Years Ago (Score:5, Interesting)
Parent
Re:Gentoo Did This Years Ago (Score:5, Informative)
Tag this article gentoodiditfirst. I saw this in gentoo long ago.
Parent
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.
Parent
Gentoo was there first (Score:4, Informative)
Gentoo has supported the FreeBSD kernel for a while now, afaik
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.
Parent
God, I never thought I'd see the day (Score:5, Funny)
I love what that symbolizes! (Score:5, Funny)
FreeBSD fans created that image, but...
1. It shows that FreeBSD is gay.
2. It leaves no doubt why FreeBSD is represented by Satan.
Clearly, this is why we must stay away from FreeBSD.
Parent
This is just really cool (Score:4, Interesting)
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.
Switching kernels for one install or? (Score:5, Interesting)
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.
Parent
Boring... (Score:5, Funny)
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 :)
Hurd too.. (Score:5, Informative)
http://www.debian.org/ports/hurd/ [debian.org]
What's the point? (Score:4, Insightful)
Why not just run FreeBSD with a real BSD userland and ports system? I'm just curious why you would use a BSD kernel but keep a Debian userland when it would probably be more reliable to just use FreeBSD's userland too.
Re:So it it Debian GNU/Linux/FreeBSD (Score:5, Informative)
Parent
Re:So it it Debian GNU/Linux/FreeBSD (Score:5, Informative)
GNU C library
Parent
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.
Parent
Re:/usr/bin/pride, /usr/bin/ego, /etc (Score:5, Insightful)
I don't understand the "ego" criticism of calling the system GNU/Linux. No one's demanding that anyone call the system "Stalmanux" are they? It's about ethics/ideology, not about ego. The concern is that "Linux" as the name for the system encourages people to adopt the apathy the Linus and a lot of kernel developers share about issues concerning software freedom. If you care about software freedom and you think people should be able to do whatever they want with the software they use that is on *their* own machines, then call it GNU/Linux. If you opt for this pseudopragmatism instead, just call it whatever you want.
Ultimately, the name isn't the most important thing, is it?
Parent
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).
Parent
Re:APT? (Score:5, Insightful)
Is it essentially just FreeBSD with APT and gnu userland instead of ports and bsd userland?
It's FreeBSD with the entire Debian userland. AND it's Debian with a FreeBSD kernel. Pretty much like a centaur is a man with a horse's body AND a horse with a human head.
The best description depends on what part you focus on. To me it's Debian with a FreeBSD kernel.
Parent
Re:APT? (Score:5, Funny)
So they went from being the Linux with the best package manager to being the BSD with the worst package manager?
Parent
Re:Late to the party, Slashdot. (Score:5, Informative)
It just became an official port. That is what is news.
Parent
Re:ports-- (Score:5, Funny)
Even getting a decent lamp server fully setup is a chore under freebsd. Hopefully debian/apt can breath more life into it!
I couldn't imagine why...
Parent
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.
Parent
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.
Parent
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.
Parent
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.
Parent