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."
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.
GNU C library
Tag this article gentoodiditfirst. I saw this in gentoo long ago.
So did Debian. Debian GNU/kFreeBSD as the port is poetically named has existed for a long time (see mailing list archives). This story is just about it being accepted as an official part of Debian. Who got there first? Who cares.
ZFS is nice, but thus far FreeBSD's port isn't.
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
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?