Slashdot Mirror
Debian Gets FreeBSD Kernel Support
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 managed to get this kind of setup working years ago, didn't they?
when this image was actually an on-topic response to a Slashdot story.
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
GNU/FreeBSD. FreeBSD kernel (and libc?) + GNU userland (instead of the BSD userland). There's no linux involved (except perhaps the linux syscall emulation)
Do you even lift?
These aren't the 'roids you're looking for.
Is available at http://www.debian.org/ports/kfreebsd-gnu/
There isn't much, but a little bit in the install notes.
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.
IranAir Flight 655 never forget!
GNU C library
"This makes Debian the first distribution, and probably the first large OS, to support two completely different kernels at the same time."
Two kernels? At the same time? I'll be in my bunk.
You know what I'd do with a million bucks?
Two kernels at the same time.
... and that's when the C.H.U.D.'s came at me.
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.
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...
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!
These posts express my own personal views, not those of my employer
ZFS is nice, but thus far FreeBSD's port isn't.
*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.
If I had a nickel for every time I had a nickel, I'd be richcursive!
http://www.debian.org/ports/hurd/
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
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.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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 ;)
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.
entropy happens
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.
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.
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.
The state you are in while your HEAD is detached... - wait, what?
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?