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."
But with FreeBSD doing Linux apps, and Debian able to run the FreeBSD kernel, things are getting kinda weird in UNIX-land.
I think I need to lie down now.
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
Gentoo managed to get this kind of setup working years ago, didn't they?
Gentoo has supported the FreeBSD kernel for a while now, afaik
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.
It's one thing to sit and think about a beautiful system. To daydream wistfully about interfaces so well-thought that you can swap kernels and userland implementations without the world coming to an end. It's another thing entirely to see it happen with a full featured OS like Debian! Congrats are in order for the Debian team for tackling this and (apparently) going all the way.
Too much repetition my too much repetition!
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.
So can I install just one system and choose between the two kernels at boot time? Or do you have to make a completely different install with executables build separately for each kernel?
Do you care about the security of your wireless mouse?
GNU C library
Actually Ubuntu has supported PA-RISC/HPPA for ages:
https://edge.launchpad.net/ubuntu/jaunty/hppa
http://cdimage.ubuntu.com/ports/daily/current/
(these are the links for the in-development release Jaunty, but HPPA has been a part of Debian since Breezy).
This signature was left intentionally blank.
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.
The state you are in while your HEAD is detached... - wait, what?
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.
It just became an official port. That is what is news.
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
I'm waiting for Windows kernel support to be added. I prefer blue screens over seg faults. :P
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...
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.
Is it essentially just FreeBSD with APT and gnu userland instead of ports and bsd userland?
So they went from being the Linux with the best package manager to being the BSD with the worst package manager?
sic transit gloria mundi
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.
The state you are in while your HEAD is detached... - wait, what?
http://www.debian.org/ports/hurd/
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
Whippersnappers. I haven't rebooted my Multics machine since the 60s!
Tsunami -- You can't bring a good wave down!
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.
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?
- 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
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.
brandelf -t FreeBSD
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?
Fact: Everything I say is fiction.
FreeBSD supports Linux binary compatibility as a kernel compile time option (and now available as a module I think).
This could mean in theory you would "only" need to have a base package with the FreeBSD kernel and have it load FreeBSD specific kernel modules and that could be a base install from which existing Debian packages could be installed. Although, in practice I can image it would really mean updating other packages as well as the installer, e.g. like those for bootloaders, to ensure they were aware that using a FreeBSD kernel was an option.
As a point of interest, Solaris 10 is also compatible with Linux binaries, if you have the appropriate compatibility package installed. In theory (license permitting) the same thing could be done with Sol 10.
Bit off topic:
Solaris could REALLY do with better package management - Sun's own patches are inconsistent and some of the defaults are terrible (such as being insecure by default) and of course it lacks both the sophistication and convince of apt+dpkg on Debian. Often Sun packages don't even check for pre-requisites properly, I find them very sloppy and haphazard - this is frustrating especially as without some essential packages software may still run, but behave unexpectedly.
I raised this with Sun at an open event in London, while they were launching the Sun Fire x86 range (which are really excellent servers) which Andy Bechtolsheim gave a presentation on. They asked for general open questions and made a polite enquiry regarding package management. They seemed to have no idea their existing solution was so poor (compared to package management on Debian, Red Had and even FreeBSD) and were _very_ dismissive of the polite inquiry. They looked at each other for a moment, a bit confused and responded "Most of our vendors run hundreds or thousands of systems" they sniffed, "and have no trouble managing their packages".
Of course having seem hundreds of Solaris boxes over the years I know most major Sun customers they only /think/ they have no problem keeping their systems patched and up to date. The reality is they slap them behind private networks, are usually not patched after installed and are almost never patched thereafter (despite having a a number of essential bug fixes in their patches). This accounts for not only security holes but also a great deal of bugs.