Benchmarks of Debian GNU/kFreeBSD vs. GNU/Linux 143
An anonymous reader writes "The Debian Squeeze release is going to be accompanied by a first-rate kFreeBSD port and now early benchmarks of this port have started coming out using daily install images. The Debian GNU/kFreeBSD project is marrying the FreeBSD kernel with a GNU userland and glibc while making most of the Debian repository packages available for kfreebsd-i386 and kfreebsd-amd64. The first Debian GNU/kFreeBSD benchmarks compare the performance of it to Debian GNU/Linux with the 2.6.30 kernel while the rest of the packages are the same. Results are shown for both i386 and x86_64 flavors. Debian GNU/kFreeBSD may be running well, but it has a lot of catching up to do in terms of speed against Linux."
Holy moley ! (Score:1)
From the Linux only perspective, I am still running everything (servers, desktop, laptop) on Linux 32 bits even on 64 bits machine because I figured that running 64 bits wasn't really worth yet.
Now, I am really surprised to see that Debian Linux 32 bits is actually faster than Debian Linux 64 bits in many tests !
Re: (Score:2)
32-bit was faster in a few tests, but it seems like overall the 64-bit still came ahead in more tests than it fell behind in.
Re: (Score:2)
Before seeing this benchmark I took for granted that 64 bits would be faster or at least come to par in all tests. How do you explain that 32 bits is faster in some tests ?
The only way I can explain it is that some piece of code is not optimized yet to run on 64 bits. This kind of prove my impression right; I can still wait for a while before upgrading to 64 bits OSes. The overall performance
gain might or might not be there depending on your use cases.
Of course, I will upgrade to 64 bits some day. Stability
Re:Holy moley ! (Score:4, Insightful)
Re:Holy moley ! (Score:4, Interesting)
Re: (Score:2)
For example, if you have a pipeline of 8 instructions, the first four instructions might be using R1, and the second set of four instructions might be using R1 too - but for different _independent_ reasons. Now you can't store the same R1 values to two different locations since the second four instructions would generate a different "R1" value.
Re: (Score:2)
If that's the case, it shouldn't give x64 a performance hit...
Why so ?!? (Score:4, Informative)
No, not necessary.
It's not because your CPU is running a 64bits OS that suddenly every data format has to be replaced with one using 64bit integers.
It's not because your CPU is running a 32bits OS that you aren't allowed to manipulate anything bigger 32bits.
The OS bittage has almost no impact on what data format can be used. Only how fast those format will be processed, and how many memory can easily be addressed in a straight-forward way.
A 256 x 256 bitmap, RGBA, with 8bits per channel, will always take the same amount of memory wherever the OS is running 32bits or 64bits code. Only with a 64bits OS it will be much more easy to store more than 3GiB worth of textures.
And even a 32bits OS can manipulate 1024bit data structures like crypto key (only a little bit slower, because the CPU internally won't be able to do 64bit operations).
Also most OSes are LLP64 or LP64, meaning that the default "int" still is 32bits. Thus code recompiled in 64bits will tend to approximately use the same amount of data as original code in 32bits.
Re: (Score:2)
It's not because your CPU is running a 32bits OS that you aren't allowed to manipulate anything bigger 32bits.
I can't speak for other OS's, but in the case of Linux, a 32-bit OS does mean there is a 32-bit limit on general registers (EAX, EBX, ECX, EDX, ESP, EBP, EIP, ESI, EDI). During a task switch, only the lower 32 bits of the general registers will be saved into the process state, even on a 64-bit CPU. When the kernel switches back to the process, only the lower 32 bits will be restored.
Not a big difference (Score:2)
in the case of Linux, a 32-bit OS does mean there is a 32-bit limit on general registers (EAX, EBX, ECX, EDX, ESP, EBP, EIP, ESI, EDI).
Well that's still 8regs * 4bytes = 32bytes per task, vs. 16regs * 8bytes = 128bytes per task.
You'll need quite a lot of task switching in order to fill the cache.
And even then, switching tasks is a rather rare event on the scale of other computations (Linux can switch task at 1000Hz when the low-latency desktop option is compiled into the kernel), so it is less dramatic if the switch does force a reload from RAM.
Data vs. Code (Score:2)
The parent poster mentioned problems with *data* structures, not with code.
And the code it self is less likely to increase. First there isn't a big different in length between x86_64 and stock x86 op codes. The whole x86 family has been using opcodes of varying length since day 1.
There's nothing as dramatic as the differences between ARM native 32bits and Thumb 16bit modes.
Second, in 64bits the number of available registers increases dramatically, as said elsewhere in this thread.
As such, the net result is
Re:I've heard this...Unlikley. (Score:4, Insightful)
> Because every 64-Bit CPU I've ever used always had more than twice as much L2 cache as 32-bit Systems.
I am glad I am using 64 bits CPUs to run my 32 bits OSes then ;-)
Well unless somehow, the "twice as much" doesn't get used with 32 bits OSes running...
What do you think ?
Re: (Score:2)
If you're talking about x64, the primary 64-bit consumer desktop / laptop CPU architecture, has it occurred to you that code running in the CPU's 32-bit mode also benefits from the doubled cache? It's not like the 32-bit code only uses half the cache, with 64-bit code using the full cache.
Re: (Score:2)
the tricky part is to NOT use half the caches when running 32 bit apps :-p
Re: (Score:2)
64bit code uses more memory, which can in some cases result in decreased performance..
Also, i believe on some intel cpus some performance features are not available in 64bit mode (i forget the exact details)...
Re:Holy moley ! (Score:5, Informative)
As others have said, 64-bit programs take more memory to run. There's nothing inherently faster about 64-bit registers and operations unless you're dealing with integers that get that big (which in most everyday programs, they don't). What makes 64-bit faster isn't just "more bits", but optimizations. 32-bit code is typically compiled for the lowest common denominator: i386. However, x86-64 CPU's are guaranteed to be at least i686 compatible (you're also guaranteed up to a certain level of SSE compatibility and such). In that regard, it's the code optimization that we can rely on and not "more bits" (which due to extra memory usage, will typically make things SLOWER, not faster) to make things faster.
However, not every app or test really benefits that much from i686 optimizations. For those that don't, and don't deal in larger numbers (AND that don't use so much memory that a 64-bit chip is needed to address it), 32-bit processors will typically be faster.
As to stability, x86-64 is well past the "new" stage. The specification is 10 years old and processors based on it 7 years old - Linux support was almost immediate. Just how long does it take for you to consider it not bleeding edge anymore? :)
Re:Holy moley ! (Score:5, Informative)
You missed out on the fact that there are more registers on 64 bit than the famously register starved 32 bit x86. More places to put things can't hurt even if your not dealing in 64 bit values.
The problem with 64 bit is that a lot of code is still hand tuned to the maximum possible performance on 32 bit arches and in at least a couple of the cases listed in the benchmarks I wouldn't be shocked if there was some hand done assembler involved. I have also noticed GCC has some performance tweaks that work around the lack of registers on 32 bit that also tend to get enabled in 64 bit..
Re:Holy moley ! (Score:5, Insightful)
On most architectures, 64-bit code is slower. Pointers are bigger, which means you need more memory bandwidth to load them and you use more cache holding them. On x86-64, the situation is confused by the fact that 64-bit means 'using Long mode,' as well as 'using 64-bit pointers'.
Long mode gives you 64-bit registers (so you can store 64-bit values in a single register, rather than spread across two, doubling the number of 64-bit values you can store in registers), more registers, and a few other benefits like removing the 'must use EAX as the target' restriction on a lot of instructions (reducing the number of register-register moves, and decreasing instruction cache usage as a side effect). 64-bit pointers use more memory bandwidth and data cache.
For best performance on x86-64, you want pointers to remain 32 bits, but still run in Long mode. The OS should make sure that everything is mapped below the 4GB line for the process. As far as I am aware, no operating systems actually support this mode of operation. Without that, for any process using less than 4GB of address space, you have some advantages and some disadvantages when running in 64-bit mode. Whether the advantages outweigh the disadvantages, or vice versa, depends on the code.
Re: (Score:2)
> Whether the advantages outweigh the disadvantages, or vice versa, depends on the code.
That is exactly what I had figured out by intuition I guess ;-))
I have learned (or got refreshed on?) some logical explanations to this fact here today, thanks to you and some others.
I have to admit that I don't remember taking the time to evaluate 32 bits vs 64 bits advantages, just postponing that analysis and an eventual upgrade to later. I though I was past due on that matter but with what I have read today, I wil
Re: (Score:2)
Re: (Score:3, Funny)
> so the only advantage of a 128-bit architecture would be for
supporting the full length of a message on /. ?? ;-))
Thanks for your reply anyway,
Cheers,
Re: (Score:3, Interesting)
Whoa, wait jus
Re: (Score:2)
The architecture doesn't have to support it. It is a chastity vow from the program, that while it may use 64bit, it simply opts to only use 32bit while still running in 64bit mode. Sounds confusing but is really simple.
The register is still 64bit (because CPU is in 64bit mode).
The memory slot used to store pointers is 32bit (because no more is needed).
The 64bit instruction set still has "load 32bit from memory" which may be used to load 32bit pointers into 64bit registers.
Now: The reason no one is doing it
Re: (Score:3, Informative)
The reason no one is doing it is becaue the C api states that the pointers should be 64bit when in 64bit mode. If you use a trick like this, your application will no longer be following standards, making it unable to use standard libraries.
Correction: The C ABI says that, and the C ABI is defined on a per-platform basis (for example, FreeBSD and Linux use slightly different calling conventions on IA32). It's up to the operating system to define the ABI or ABIs that it supports. Solaris, IRIX, and most other commercial UNIX variants have been happily supporting 32-bit and 64-bit ABIs on 64-bit platforms for a couple of decades.
Re: (Score:2)
Re: (Score:3, Interesting)
Before seeing this benchmark I took for granted that 64 bits would be faster or at least come to par in all tests. How do you explain that 32 bits is faster in some tests?
For most, its generally considered a wash. Larger data structures require more cache and more memory and more memory to be accessed. On the other hand, you also get more registers in 64-bit mode. As a result, some things run slower and some things run faster, depending on the nature of the application. On average its likely to be a wash.
The big exception are those that use the PAE 32-bit extensions. Generally speaking, 64-bit is going to be a lot faster. Even still, there are some odd exceptions which will
Re: (Score:2)
Because Postgres is really a Unix-type program and not an NT-type program, you mean; NT has cheap thread creation and expensive process creation, while Unix generally features the reverse situation. If Postgres were NT-ized and used multiple threads instead of multiple processes... perhaps things would be different. The bit-width of the system makes no difference to the amount of RAM used for file caches; are you talking about how fast you can shovel data with a 64-bit processor? Data shoveling is the only
Re: (Score:2)
Unix-type program and not an NT-type program
Yes, process model vs threaded model. For NT, a threaded application would be limited to its maximum addressable space per process, of one process, for all back-ends. Since PostgreSQL is a process model, that means each back-end is limited to the maximum addressable process space. Thus on a Windows 64-bit box, you can load it up with memory and EACH back-end can manipulate up to its 2GB-4GB of address space, depending on configuration.
The bit-width of the system makes no difference to the amount of RAM used for file caches
Absolutely it does. I have no idea why you would believe otherwise. Cache
Re: (Score:2)
Absolutely it does. I have no idea why you would believe otherwise.
It only makes a difference, as you say, over 4GB. Or on castrated platforms, 3GB. But since you can't actually use more than 4GB without ugly, performance-killing hacks, anyone using more than 4GB is going to need to use 64 bit just to use all their memory. But that's not just the file cache, that's everything.
Re: (Score:2)
I think somewhere I lost you and I'm not really sure how since the conclusion is extremely obvious. You're even making exceptions which were already clearly spelled out or flat out obvious.
Which is faster? 1GB of DB files cached? 10GB of DB files cached? The later is only possible on a 64Bit OS. Thusly, even 32bit applications can benefit in this environment, despite the fact they are 32bit and are not directly accessing all of that data within its own 32bit address space. That's entirely the point of every
Re: (Score:2)
> I have been using SuSE Linux 64 since 2005 with no problems.
Patrick Volkerding has just released the first version of Slackware 64 bits about 5 months ago and it doesn't seem to have had any impacts on the perception Slackware users have ;-))
Granted, there was unofficial ports before that ;-))
Thanks for letting me know it is stable on your side although ;-)
Re: (Score:3, Insightful)
Where many is ~20% of them.
And why would that be surprising? 64 bit lets you address more memory and they did the tests in a machine with memory that 32 bits could address all of. 64 bit pointers are obviously larger too, so the 32 bit version has effectively more memory and better cache usage.
Some programs aren't going to take advantage of 64 bit registers and so on, but are going to suffer from worse cache performance.
Stick 8 or 12 GB of RAM in and things might be different
Re: (Score:2)
> 64 bit pointers are obviously larger too, so the 32 bit version has effectively more memory and better cache usage.
Very good point ;-))
Re: (Score:2)
I'm sorry, what?!
What are "many tests" you speak of?
32-bit Debian Linux was notably better only on compilation (which isto be expected) and POVRay. A couple of tests have shown very small advantage towards 32-bit system, but 64-bit has won MOST of 27 test hands down.
Re: (Score:3, Informative)
Now, I am really surprised to see that Debian Linux 32 bits is actually faster than Debian Linux 64 bits in many tests !
I'm not so surprised to see that somebody didn't read the graphs very well. 32 bit was faster in only 4 out of 25 tests (16%). Further, 2 of those were only marginally faster to the point where they barely count as a clear lead. Conversely in the majority of cases, 64 bit was not only faster but significantly faster. To the point where I wonder if there were other configuration differences -- for example I don't understand why you'd see a much higher hard drive TPS rate under 64 bit (something like 4x)
Re: (Score:2)
Hehe, sorry, my fault. I used "many" to mean "more than one" and that was a mistake. After reviewing the English dictionary, it seems that in English, "more than one" is expressed by "several". I used to think that they were almost synonyms but "many" means more "a lot" than "several".
My God, how many times must I have sounded like bullshitting before ;-))
Again, my mistake, I even learned the real signification of the word "many" today !! ;-)) /. teaches me all kind of stuff, including getting better in Eng
Re: (Score:2)
After reviewing the English dictionary, it seems that in English, "more than one" is expressed by "several".
Nope. "More than one" means "more than one", and it is a common figure of speech. "Several" means "enough to be worth mentioning."
Re: (Score:2)
> Nope. "More than one" means "more than one", and it is a common figure of speech. "Several" means "enough to be worth mentioning."
OK, about "a few" then instead of "more than one" ? ;-))
Re: (Score:2)
Yes, a "few" would probably work. It often is used to mean three, however; a "couple" being two. After that it gets hazy, but "handful" is probably next :)
Re: (Score:2)
That said - I still wish they'd just give us the numbers in a usable format instead of spreading it across 10 pages with three charts each.
PS: and it's just like you furriners, claiming the language is too hard iffn yer not unnerstood! Why can't yous just talk good English like us reglar folk! ;)
Re: (Score:2)
> PS: and it's just like you furriners
Hey I am not a furriners ! ;-)
My ancestors were in North America probably long before yours or at least before the ones of most Americans were! ;-)
Granted, English ain't my first language although. This doesn't constitute a valid excuse although and I don't try to use that fact as an excuse ;-))
I was merely admitting that I still do mistakes that seem obvious to the rest of the /. community and I actually enjoy being corrected ;-))
Thanks a lot or many thanks or sever
Re: (Score:2)
Glad to hear you're improving your English. Keep up the effort.
"many" implies a significant percentage of the whole. That's obviously not the case here.
"several" would be close, but I wouldn't use it for this situation. It indicates a moderate amount. My instinct is that this is a tad greater than what you want to describe.
I would use "few". It represents more than one, but also signifies a minority.
Ironically, the phrase "quite a few" actually means a large amount, and would be synonymous with "many".
Re: (Score:2)
Thanks ;-)
Bad time for a holy war (Score:3, Funny)
We can't start a holy war now! My armor is at the cleaners.
Cue nerd rage
Sheldon
Mod Article Flamebait (Score:5, Insightful)
Re:Mod Article Flamebait (Score:4, Informative)
Linux 2.6.30 is from Jun 9 2009. The latest patchset 2.6.30.10 though is from December 3rd.
Re: (Score:2)
And we’re already at 2.6.33. What’s the point?
Re:Mod Article Flamebait (Score:4, Insightful)
Re: (Score:2)
> # Sometimes Linux is faster, # Sometimes FreeBSD is faster. # Usually the difference between the two is smaller than the difference between IA32 and x86-64..,
That's what I would expect! A big difference would be something weird.
> The tests were mostly either CPU- or I/O-bound, so there are lots of factors beyond the kernel that would affect the results.
The benchmarks must be CPU or I/O bound... why should they benchmark sleeping apps?
>Debian kFreeBSD uses an old FreeBSD kernel, not sure how old
Re:Mod Article Flamebait (Score:4, Insightful)
The benchmarks must be CPU or I/O bound... why should they benchmark sleeping apps?
If they're I/O bound, userspace and kernelspace are both waiting for the drive. The layout of the files on disk will have more of an impact than the kernel. You are right that things should be CPU-bound, I should clarify that I meant userspace CPU bound. You want to benchmark things that are systemcall-heavy, like concurrent apps that use lots of synchronisation primitives.
I really don't hope the last minute changes to the kernel, to do a big improve the system performance.
FreeBSD development follows three branches. -CURRENT is where all of the latest stuff is. -STABLE is where stuff that has been tested a bit in -CURRENT goes. -RELEASE branches are where only bug fixes (no new features) go. The 8.x series began development as 8-CURRENT shortly after 7.0 was released (about two years ago). Some features were then back-ported to the 7-STABLE branch, but only those that could be moved without invasive changes that might affect system stability.
8-RELEASE is the latest stable release and has had two years worth of new features on top of the one shipped with Debian, including, among other things:
It's not a matter of last minute changes, it's a matter of not getting the last two years of improvements. I know that Debian likes the stable-and-tested versions of things, but they don't seem to apply that policy to the Linux kernel.
Re: (Score:2)
> If they're I/O bound, userspace and kernelspace are both waiting for the drive
Filesystem strategies can impact severely the time the CPU is waiting for data. This is very important to people who runs databases.
> You want to benchmark things that are systemcall-heavy, like concurrent apps that use lots of synchronisation primitives.
Well, yes, for a pure kernel bench, and I accept it that seems to be the main purpose of TFA; but for me it's more interesting and useful a test of the system as a whole.
Re: (Score:2, Flamebait)
Nobody cares about what OS itself does.
All people want from an OS is that their application run and run best.
The statement is valid for e.g. MS-DOS. But it never was valid for OSs supporting virtual memory and I/O abstraction: the way kernel does things impact application performance quite noticeably. I/O optimization (read-ahead, delayed write back) and virtual memory management (application memory allocation, stack, context switching) all have direct influence on user space performance. And that is w
Phoronix (Score:4, Interesting)
While they're really the only group that does a lot of linux benchmarking, I'd put a *large* grain of salt in their results.
They have no problem blindly accepting something like this [phoronix.com] without investigating why it is so much faster and seeing if there's a problem with their testing.
Re: (Score:2)
Wait a minute... glibc? (Score:1)
I just wanted to see if ... (Score:3, Funny)
I don't use BSD, I just wanted to see if the "BSD is dying" troll still posted. It has been years, eh?
It does also seem to me that the FreeBSDk thing is meant to make certain features available to developers, maybe be more reliable, and "faster, faster" isn't being sold as part of the bill of goods. Yet, the talk returns to speed, speed, speed.
But what do I know... I work as a nurse. Although... I DO love a fast computer.
Re: (Score:1)
Please educate me a bit. (Score:4, Interesting)
Re: (Score:2)
Well, why not? I don't feel I'm going to use it, but it's nice to have a choice.
Re: (Score:3, Informative)
'Because we can' is the answer you are looking for I think.
Considering what they've done (most of it anyway) can be accomplished with a few flags to make.conf anyway, its not exactly impressive. Tell the system to use glibc instead of its native libc, then rebuild world (to rebuild the built in GNU tools with glibc) and build the ports for other GNU tools you want and you've got what they made.
You could probably write a fairly trivial sh script to do this on a generic FBSD install.
This is just a typical 'W
Re: (Score:2)
Re: (Score:2)
FreeBSD has some cool features in the kernel, like ZFS support, Jails, and a 10Gb optimised network stack. I've found that the FreeBSD kernel responds better when the system is under heavy load. That's a godsend when you're trying to fix an issue. It's a high quality kernel, and is extremely stable.
Software management in Debian is much nicer than FreeBSD. The configuration files are more consistent, and keeping your system clean and tidy is an easy process. Doing updates, and even major upgrades, is of
Re: (Score:2)
As someone who is just now stepping into FreeBSD and who has managed Debian/Ubuntu systems for quite some time, i do find the front end tools for package management on Debian to be a bit nicer than pkg_add/pkg_delete on FreeBSD, but i know there are many other tools on FreeBSD for this purpose that i haven't found yet :)
Re:Please educate me a bit. (Score:5, Informative)
but other than a gui I see no outstanding advantage over the FBSD package system
As a gauge of relative activity level in each package system:
The weekly list of UPDATED (and possibly NEW) BSD packages at
http://www.freshports.org/ports-new.php?interval=week [freshports.org]
is roughly equal in size to the weekly list of NEW Debian packages at
http://packages.debian.org/unstable/main/newpkg [debian.org]
So, each week, there is about as much new stuff added to Debian as there is updated preexisting stuff in BSD.
FreeBSD ports can't be relied upon (Score:2)
The other day, I was installing an old FreeBSD system for compatibility with some stuff I had. I figure it's like installing an old Linux, right?
Wrong. When I install an old Linux, I can install all the old software. The *.rpm or *.deb files exist. FreeBSD doesn't work like that. It has ports. If your system is old, you're screwed. The ports system is only 100% available for the latest release. For older releases, there is a sort of weak idea that maybe it kind of sort of ought to be maintained when somebod
Re: (Score:3, Informative)
Re: (Score:3, Insightful)
In theory, perhaps.
On that web page I see this: "The ports and doc trees use tags whose names begin with RELEASE tags." Excuse me, WTF? You're only going to tell me how the name begins and leave me to guess the end?
Can I go back 15 years? Can I do this for versions 1, 2, or 3?
What about all the stuff it drags in? Is the old source code actually there, or just the build system?
I sure hope that a CVS checkout isn't going to drag a bunch of old history with it. Gigabytes would be unfriendly.
I can go to Red Hat
Re: (Score:3, Funny)
I wish Alter Relationship would stop replying to himself.
He's almost as bad as that other troll, Friend of a Friend.
Re: (Score:3, Insightful)
Yes, your slackware from 1994 is full of security holes. The FAIL here is you trying to install an unsupported version of the OS and then complaining about it when it doesn't work.
Never did I suggest that I was running a random server exposed to the Internet. The box could be running some lab equipment that costs millions of dollars to replace, using a proprietary control program that won't run on a more modern OS. The box could be running a legacy app, with a modern system controlling things over a serial line. Shit happens.
The fact that an unsupported OS suffers bit rot is disgusting. The bits should just sit there forever, as they do for every Linux distribution except Gentoo.
I wi
Re: (Score:3, Interesting)
The FreeBSD kernel can be faster the Linux, but there are a lot of poorly written apps that think they absolutely must run on Linux or were written expecting GNUisms. Now you can do that.
FreeBSD is generally the more generic and performance driven of the BSD's with a larger developer base then the othe BSD's. The odds for very good performance and good hardware support are in FreeBSD's favor over Open or Net.
Porting apps to different platforms
Re: (Score:2)
Re:Please educate me a bit. (Score:5, Informative)
Why use freebsd with GNU apps, when you can just run freebsd? And why freebsd and not lets say, openbsd or netbsd?
They actually have a NetBSD port [debian.org] as well as a Hurd port [debian.org]. They also have a nifty why NetBSD [debian.org] section. There doesn't seem to be a similar page for kFreeBSD, but I assume the reasons are similar.
Re: (Score:2)
Re: (Score:2)
When George Mallory, the guy who attempted to climb Mount Everest several times (and almost succeeded, though the most successful attempt was also fatal in the end), was asked why exactly would he try to climb it, as it was extremely dangerous and he wasn't even a scientist or a cartographer, he said one simple thing.
"Because it's there."
Sure, there probably are some practical purposes for a version of Debian running the FreeBSD kernel, but whatever those might be, I think it's not a matter of "what for" bu
Re: (Score:2)
With such a large challenge, overcoming the hurdles on the way produces benefits that often can't be quantified beforehand. And
Re: (Score:2)
I think that sums up for me why I'd be interested in the project. I'm not interested in running Linux with a BSD kernel for work because I like things that are reliable and well tested and documented by a large userbase. I'm not running it personally because I don't want to spend the time on something without a strong obvious benefit, but I appreciate that someone is.
The goal of doing something like this isn't to produce a product that is better than anything else, it is to see what you can do and see what
Re:Please educate me a bit. (Score:4, Informative)
Why use freebsd with GNU apps, when you can just run freebsd?
Then you'd be stuck with freebsd apps instead of GNU apps.
If you have a mighty herd of servers, desktops, and kiosks, all sharing various automation scripts, supporting both freebsd and GNU command line apps could be a pain, due to subtle differences in command line options, etc. Its possible to create a blizzard of "if then" to work around, but why bother.
But I am missing the improvement for Debian here.
Overall, none really. The way ports work on Debian, is if enough people volunteer to maintain a port, and they are successful, then we have a new port. Heck, that is the way everything works in the Debian project, if something meets a certain standard of excellence, its in, no matter if its a package, docs, artwork, shared VCS, human language translation, a network service, a mirror, or in this case, a port. Debian is thankfully not a deletionist stronghold like that dumpy embarrassment known as wikipedia.
This link provides a one page summary of each attempted Debian port, successful and ... not so successful :
http://www.debian.org/ports/ [debian.org]
Re: (Score:2)
This link provides a one page summary of each attempted Debian port...
Don't forget the unofficial Debian ports; one really interesting one is Debian Interix [debian-interix.net], which is a Debian userland on top of Microsoft's Unix layer for Windows. It hasn't had a lot of activity recently because it's mainly run by one guy, and Interix doesn't get a lot of bugfix love from Microsoft (surprise surprise), but compared to the abomination that is Cygwin it's already light-years ahead. All it needs is a decent community...
Re:Please educate me a bit. (Score:4, Informative)
The FreeBSD kernel gives you a few nice things. ZFS, DTrace, and a high-performance in-kernel sound system that eliminates the need to mess about with things like PulseAudio just to get half a dozen applications going 'bing' at the same time while another one plays music (although this got a lot of improvements in the FreeBSD 8 kernel, which isn't in Debian yet, as did ZFS). It also gives you the ULE scheduler, which has had several years of testing and refinement (unlike Linux's scheduler-of-the-week) and performs very well (was outperforming Linux by a large margin on 8+ cores, now they're pretty similar). It includes Jails, which are like chroot but with a complete environment inside so you can have a different IP, different users, and so on in a jail (and you can create them with a complete clone of a skeleton system almost instantly with ZFS clones).
As to why you'd use Debian rather than FreeBSD, the big difference is glibc rather than BSD libc. When people talk about Linuxisms in code, they most often really mean GNUisms and the code depends on something weird in glibc, rather than on anything specific to the kernel. It will therefore work with glibc on kFreeBSD just as it would with glibc on Linux. You may also prefer the GNU userland utilities. Some people install these on FreeBSD anyway, but with Debian they are the default ones. This means that a few other common GNUisms (e.g. assuming that /bin/sh is bash and that POSIX utilities accept GNU arguments in shell scripts) will work.
This means that it's easier to port crappy code (and there is a lot of it about) from GNU/Linux to GNU/kFreeBSD than to FreeBSD. I've written a bit about which bits are GNU and which bits are Linux [informit.com] before: most of what the user or developer interacts with is GNU.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The BSD userland works and is tested with the BSD kernel. The GNU userland isn't, really.
The debian package manager is not really any better in real world use, so that leaves the GNU userland as being the only reason for its existence.
2c, but IMHO Debian/BSD is wasted effort that would be better spent on either Debian/Linux or FreeBSD proper...
Though, i guess if you're set on running a Debian system with a
Re: (Score:2)
Only reason i have RHEL at the moment here is due to it being an officially supported platform for our ERP solution.
Comparison with original FreeBSD? (Score:2, Insightful)
What about a performance comparison with original FreeBSD?
Re: (Score:2)
What about a performance comparison with original FreeBSD?
The "original"? Just for laughs, get the results for version 1.0 from 1993 along with 8.0-RELEASE and 9.0-CURRENT
http://en.wikipedia.org/wiki/FreeBSD#Version_history [wikipedia.org]
Flash? (Score:3, Interesting)
glibc (Score:2)
glibc is a much more complex libc than the one FreeBSD uses. FreeBSD doesn't use libc as the "glue layer" nearly as much as Linux, so the extra overhead of glibc is wasted.
This is a good thing (Score:3, Insightful)
I can see a really good usage case for this.
You're a sysadmin, and you're running Debian almost exclusively. You have a large number of automation scripts that you use to do your job (security updates, auditing, provisioning, general maintenance, etc). All of them are expecting to run on Debian, because all you run is Debian. So you, as a sysadmin, decide you want to use ZFS somewhere.
You have a few options:
1) Run Solaris
2) Run some derivative of BSD (FreeBSD, OpenBSD, NetBSD, etc)
3) Run Debian w/ ZFS in Fuse
4) Run Debian kFreeBSD
Options 1 and 2 will most likely require you to tweak or rewrite a lot of your scripts. I shouldn't need to explain why option 3 is a bad idea. Since you're working with Debian userland, going with option 4 seems like it would be the path of least resistance. Seems pretty useful.
Other Interesting Benchmarks (Score:3, Interesting)
It would also be interesting to see benchmarks of functionality actually provided by the respective kernels. E.g. performance of fork, fork+exec, socket, accept, reads and writes on IPC, multiprocessor/multicore/hyperthreading performance, etc. Past benchmarks have shown that there can be dramatic differences between operating systems especially when large numbers of something (processes, filehandles, CPUs, etc.) are being used simultaneously.
Also, I am missing a description of exactly how they measured. Did they recompile the benchmark suite from scratch on each platform? Which compiler was used, and with which settings? Are they running the same binaries on both? How exactly did they arrive at the presented values? Is each bar the result of a single run, or did they run each benchmark multiple times and account for any variation in observed scores somehow?
As others have already mentioned, it would also be interesting to see how a regular FreeBSD system would fare.
All in all, interesting benchmarks. My conclusion: there isn't that much of a difference between the tested versions of Linux and kFreeBSD in there benchmarks. The difference between 32-bit and 64-bit is usually more pronounced. If you need the highest performance for your application, you'll still have to run your own tests.
Re: (Score:3, Insightful)
Yep, because we ALL KNOW speed is EVERYTHING when running a computer.
Of course it's not everything - but it IS a major part. Cost is another. We're at a tie there.
So what's left? User friendliness? These systems use the same apps - tie there too.
We're basically left with security and stability. If you want to write and article on those feel free - I'm sure Linux won't fare too bad there, but I'd like to see the results.
Still though, to dismiss speed as a criteria is just being naive.
Re:sigh (Score:4, Insightful)
Re: (Score:2)
It's not noticeable for most people...but for those of us in situations where it is noticeable that sort of difference is interesting. For example, my office has a debian box that runs at a continuous load average of around 5. Shave 10% off that & we'd notice.
Re: (Score:2)
Whether raw throughput or responsiveness is important depends on your application.
Re: (Score:3, Insightful)
Re: (Score:2)
Re: (Score:3, Interesting)
``Why even swap the kernel out?''
It's good to have choices. Even if Linux is the best choice for you today, you can never know that it will be the best choice for you forever. Providing Debian GNU/kFreeBSD not only offers Debian users the option of using the FreeBSD kernel instead of Linux, but also offers FreeBSD users a way to use the GNU userland instead of FreeBSD's.
Moreover, in making different kernels and userlands work together, areas where this is problematic are identified and improved, so that oth
Re: (Score:3, Insightful)
I'm a Linux fan, but there's a first. A linux user complaining that he needs to tweak the OS to get the most out of it!
Here's a tip, ALL OS's require tweaking to get the most out of them.