Re:NetBSD is faster and more scalable then OpenBSD
on
NetBSD 2.0 RC5 Tagged
·
· Score: 1
You'd know all of this if you didn't live under a rock. Almost all of Slashdot's OS zealots/trolls know about Felix' (very flawed but still popular, making Felix himself a great candidate for government, ) scalability benchmarks which compare apples and oranges and then slander perfectly good systems.
Nevertheless, NetBSD went from being second worst to second best in two weeks of work, all of which continues to work stably and all. This is a proud achievement that the other BSDs could learn from, and apparently have (but nobody has put new figures up yet so it's not 'public').
NetBSD has three important things going for it: Cleanliness (code and system), stability, and portability. It also has security (but is not as active in this as OpenBSD, yet still very active..) and amazing performance in 2.0 (but most of the time performance is still left up to Linux). It has a very good place in computing, but could be doing much better if NVidia got up off their asses and made drivers for it, at the very least.
And yes, there are newer architectures that it doesn't support, ppc64 and ia64. Strange but true. Nevertheless when they do support it, they'll support it with "solutions, not hacks".
I don't have that kind of power, nor would I do it if I could. You can install a 2.0RC5 system with a couple of floppies and FTP, or failing that, an unofficial ISO. You can then track (via cvs) netbsd-2-0 past its release and on to -stable. This will work very well for you and not require an official release, which, at this stage, could mean a flaky system for some other users (since there are still issues holding it back).
A lot happened to make 2.0, and given it's edging NetBSD out of 'old slow deprecated system' into 'holy sh*t-fast modern system', getting the first release Right is well worth the wait. The functional difference is about as much as FreeBSD 4 into FreeBSD 5 (sans some things like Project Evil), but with a performance gain instead of performance loss. You really have to try it to believe it.
Beautiful. The first 100% troll post I've seen in ages. Usually trolls have had at least one thing that was partially true, but not this one. Pure shit:)
A work of art, even. Thankyou sir, you give us something to mark other stupidities by.
Well log-structuring is said to be the 'more complete journalling' so I didn't figure the distinction would matter as much. Thanks for the extensive description though, that really depicts the differences. Even the online documentation on NetBSD's site didn't go into that much detail.
We need more people like you and less like great grandparent (fellow talking about Linux being the only one with journalling file systems and hence being so bloated, etc).
It does not support more architectures in-tree. You need external patches for a great many of them. A person with a clue would know this. NetBSD supports them all in-tree and with mutual inclusion.
LFS is a journalling file system, which NetBSD has. A person with a clue would know this. If you looked at my self-reply post, I pointed out that the difference the Linux file systems makes is roughly "jack shit".
There are also few drivers Linux has the BSDs don't. These are mostly only the 'evil' new cards made by NVidia and co, for which you often need external Linux drivers anyway. What's your point? None of them take up 15 meg bzip2'd anyway.
More scalable doesn't require larger code, if done right. If you knew ANYTHING about programming you'd understand this. You're coming off as a clueless troll and I can only conclude this is in fact what you are. Go read a book before you try to write one.
...and then email the diff to Linus who'll happilly include it. Seems that's how the coding is done, anyway.
Face it man, getting bigger doesn't mean getting better. It still suffers from very significant issues in stability, networking capability, security, and root@life knows how dirty it is in every way, even dmesg. That's what you get when you hand a tosspot around to thousands of developers.
Exactly, see? Good systems don't need code bloat. OpenBSD is yet another system which does what it does very well and obviously efficiently.
Linux doesn't have security, in 2.6 it doesn't even have stability, and performance seems limited to synthetic cases. Why it gets all the attention is beyond me.
Actually, before some clueless newbie posts saying it's all file systems, take a look at this:
thor linux # pwd/usr/src/linux
thor linux # tar -c fs | bzip2 -9 > fs.tar.bz2
thor linux # du -h fs.tar.bz2
2.8M fs.tar.bz2
Not to mention NetBSD supports a few file systems Linux doesn't in-tree (LFS, portalfs, nullfs...), and that many (NFSv3, UFS [NetBSD supports more of it anyway], ext2fs, SMBFS,...) they have in common. Sorry folks, file systems doesn't answer for it.
It's more than just base software choices actually. The BSDs have huge amounts of useful base system software, and depending on your needs you can get an amazing lot done without touching a single out-of-tree package. This includes relatively comfortable software development thanks to nvi, gcc/g++/etc, gdb, BSD make, and so on.
The difference comes in when you look at how bloated the software itself is. All the BSDs have libcs that are tiny (a couple of minutes to compile on even my slowest machines) and do everything a C library should, including full networking and everything. The GNU libc, which you'll find on every Linux system by default (there's a diet libc out there, but it isn't recognized), is a HUGE package that takes a very long time to compile and results in a hefty binary in the end. What does all this bloat go towards? Most say it's all because of its attempt at being completely internationalized, but this is hardly enough to warrant about a 10x size increase.
The same idea applies to all other software that wasn't imported from GNU. If you can do the same things smaller and more efficiently, do it that way. There's no point in having 90% of your source appeal to minor features few people will ever use. There's also a strict adherence to tradition where possible - nvi is kept instead of some stripped-down vim-alike (which would have more convenient features, for instance) because people coming from a BSD system a decade ago won't get culture shock. But all the same modern software is a 'make install' away on any of the BSDs.
The bloat difference in the Linux kernel and BSD kernels isn't even worth discussing. It's just not funny any more. Linux has inflated a LOT in recent times. I remember back when some 2.4 was about 25 megs tar.bz2, now look at it - 2.6.9 weighs in at 35 meg. Is it really 40% more functional? Nowhere near. If anything it should be getting smaller, since they insist they're refining to simpler algorithms that should work faster and take less code.
The NetBSD 2.0RC5 src/sys source compresses (bzip2 -9) to 20M, smaller than Linux 2.4 was. Compared to 2.6, it includes most of the same drivers, the same functionality (plus good security), the ability to run Linux binaries natively (and FreeBSD, SVR4, and some others I forgot), a network stack known to be better than Linux', and oh so much more. This source INCLUDES the ports of NetBSD for which Linux needs EXTERNAL patch sets to run on, meaning that this source tree is even more portable. We all know it's more stable, too. Where is the gargantuan (~175%) size of Linux going? It's all pure bloat. And I challenge even one person to come up with something Linux does that NetBSD can't do, and that takes up 15 meg when bzip2-9'd.
Well that's just depressing. Okay, on the other hand, if you strip away all the unstable functionality, any software can be at least practically 'stable'... but I wouldn't be surprised if they left in something terrible.
I still say, firmware or at most simple microkernels for embedded devices. Complexity leads to mistakes, and in embedded devices this is much more annoying and harder to fix. Even my Ti83+ is a buggy PoS (~40% of the ones I have ever seen in my life are, in fact, and in random ways) and that has its own dedicated 'operating system', but Ti somehow managed to get it wrong even after dozens of revisions.
For my servers I was attracted by the lightness of the base NetBSD install, and the general simplicity of things like tcp/ip configuration
What about the cleanliness, second-to-OpenBSD security, performance, and most of all stability? Linux hasn't ever been secure without third-party patch sets which rarely get merged back, and even they themselves aren't anywhere near any of the free (OSX not counted) BSDs which actually care about security. NetBSD has had 9 security advisories in this entire year, and (I think, check) 7 of these were in userland components imported from other projects. Linux has had a few brown-paper-bag-worthy security holes and lots of other little exploits like the ones this release fixes. This from the media-hyped "free secure operating system"? Almost as bad as Windows XP being called "secure".
To grandparent: Yes, run a BSD. Forking Linux won't help, it's a hack job from the ground up, and anything Linux does can be ported to a BSD cleanly, and it will be done securely and most of all reliably. If corporations that write Linux drivers and so on were made aware of other operating systems and the potential profits from supporting them, the BSDs would have a much better standing.
Actually, most 'projects' that people run Linux for (let's say ReiserFS) are actually only there to make up for Linux deficiencies in the first place. Our friend ReiserFS exists to plug the 'reliable file system' hole in Linux. Even it makes a huge mistake, which is forgetting that data actually gets written to hard disk. If you'll look closely at how it's laid out, there is NO superblock backup. One byte wrong in the superblock can mangle a whole partition in ways no fsck tool can easily fix, and there's your "reliable file system" gone. It hides behind journalling, and to this end it also devotes a very big chunk of your system resources. The BSDs all have the solid FFS/UFS which has been reliable for decades without journalling, with superblock backups, and with very good real-world performance. Tack SoftUpdates on if you want journalling-like reliability and performance enhancements. Not good enough? Run LFS, a (let's call it) half-way between UFS and ReiserFS that is now stable (in NetBSD 2).
-Huge funding and sponsorship doesn't make something good
-Media hype doesn't make something good
-More developers is often worse, not better. Linux has countless developers with highly different and unstandardized ideas of how to code, how to test, how to format error/boot messages, and so on. If you look at the code, you start to wonder how gcc doesn't just reject it as a crime against development. We should talk to the GNU GCC team on adding such a feature.
-Security damn well matters. How Linux developers manage to completely overlook this is just amazing.
-A solution in a week is better than a hack in one day. Linux has had lots of "it'll be good enough for now" hacks that have stayed as core features for years, and may have been replaced by something closer resembling a solution by some clever coder a few years later. Or not.
-If you're going to change something big (SCSI interface, anyone?), wait for a new major version to do it, especially if the old system works fine. The very least you can do is release the new system as an alternate patch/branch and see if people accept it. Never should a big change be 'slipped in' to a mainline branch with no real warning or option to use the old system. Basing this on "I don't like it" is even worse.
-If you're going to port or add significant features, make them fit in the mainline kernel all at once. People say "Linux is portable". This is not true. People have just managed to make patches that replace functionality and make a certain Linux version - with the patches - boot on some architecture. Big deal. Real portability fits in the system with mutual inclusion, and it's in the mainline, gaining the benefits of the main project as well as any contributions. This is why NetBSD, though historically run on less archs/machines overall, is truly Portable. You see this when you use it too - it actually fits on every system like the system was built for it, not like some parents'-basement hacker made a kernel boot.
But FreeBSD DOES have a few components of GPL code (ext2fs, the *good* floating emulator) in the kernel, they're just usually omitted in release builds. It will still warn you that your kernel is 'tainted' when you compile it in.
But being anti-GPL in kernels is a Good Thing. Let's face it, kernels are where a lot of good useful tech resides, and they're what go into embedded systems. GPL makes it too messy to borrow code (you have to open-source the host program, and if you derive a significant portion from GPL'd code, the host program has to be GPL too) and don't even think about embedding cleanly. This means that companies which need good code but can't afford to go open are stuck writing their own sh*t.
Thankfully the BSDs are there. Although there are some technical advantages in Linux (not many though) the BSD code bases are notably cleaner (which is very important) and can be incorporated into anything with little legal difficulty. The very least any BSD-includer has to do is retain credit to the developer of the code.
If Linux was under a BSD license a lot of other systems would be much more powerful today (including the BSDs themselves), and if Linux had a BSD development model it would actually be clean and have a high functionality-to-code ratio. We wouldn't have problems like the one I've been having, where a segfaulted server can't re-bind its socket for up to a minute because Linux (2.6.9) didn't clear out the file descriptor tables (all the BSDs do it immediately after program termination in *any* way).
Even scarier is the two separate Alan Cox instances, both kernel developers. If root@life loves object-oriented programming He should be more careful with duplication.
You're behind there. pkgsrc is already on at least one known Linux distro internally, and it can be installed on any other, and many do this (if you read the mailing lists).
It doesn't help though. pkgsrc is like the rest of NetBSD it seems, conservative. Although I am amazed to find that it has Ruby 1.6, I never noticed that. It had the new firefox RC's within hours of their introduction to the internet, which is about as fast as Gentoo Portage, but with many less developers and an admittedly much harder to work with (PLIST) mechanism. Not bad at all. If they had a larger range (at least most of what FreeBSD Ports has, which includes everything I've ever needed..) with this same attention to quality it'd be awesome....and a tool to update properly. (I did an update, and it rebuilt all of Firefox. Fair enough. Then it rebuilt zlib, and then everything that depended on it - which is PRETTY MUCH EVERYTHING - including Firefox which it JUST rebuilt. It removes them as soon as it updates the 'core' thing, zlib in this case, but it doesn't reinstall them until the build completes, which may not even happen - mine failed).
If Gentoo Portage was more ubiqitious and less Linux-ism'd, we could run it on the BSDs properly and they'd be much easier to install software for. There are projects to do this now, but they seem to be hack jobs more than actual re-writes of basic Portage design. At the very least the ability to have patches be conditional based on platform and the ability to 'inject' and never need to update the portage equivalents of everything said BSD has in its base - but this should be automatic!
Yeah, I did actually mean what I said, but I suppose it was in the wrong way. Meh, I've seen worse.
As for FreeBSD 5, I'm very seriously considering running it again just because it did have everything and it had it easily, even if it did mean the tree right now wouldn't milk every last drop of performance. "Crap" was entirely the wrong word, "poky but still useful" may be more on track. May as well fetch that ISO then.
Sorry for anyone I may have offended or otherwise ticked off during my pseudo-trolling rage.
That's pretty bad taste... the concorde tragedies shouldn't be laughed about. They came about entirely because of breakdowns in communication (cheap workers from one country, documentation from another...) and could have easily been avoided.
Yeah. Hey FreeBSD is still the most usable free OS I've ever known, and probably THE most functional... it would suck to see it go down on a technicality. I hope they make everything good again. Or, on the other side of the coin, NVidia write drivers for NetBSD:) (and somebody ports/writes equivalents of FreeBSD's devfs and watch(1)+snp(4))
Anyway, DragonFly BSD will still be a refuge, because anything FreeBSD 5 whips up seems to be easy enough to port back to DFly, and this is what they have done for most of what they think is worthy. And the new VFS work will allow journalling file systems, which FreeBSD hasn't had for years, since they diked out LFS (which NetBSD kept and stabilized). DFly is definitely going right up into the greats of systems.
That's actually a pretty good idea. Double-whammie - help them and get a 'free' (for you) copy of a great system.
Personally if I like what I see of OpenBSD when I try it, I'll buy it anyway, my money or not. It's the kind of thing that is so great you feel good having the real set of, as opposed to Windows where you feel even having a 'free' (cough) CD provided by Dell or whoever is a waste of money manufacturing. Not that I'm bashing Windows per se, it has its uses, but the license of one key per 'owner' (which nobody abides by anyway it seems) is ridiculous. With OpenBSD it's unencumbered - you buy the CD and that's it, do whatever (except clone it and resell, you have to make your own ISOs for that). Install it on every machine in a 1k box network, then give it to your friend to install on his box too.
But yeah, something like this does sound like a kernel task as much as user. But if Linux users now endorse udev, anything can happen. Personally I think it's a terrible idea but that's just me. Thank root Linux devs don't engineer security.
OpenBSD always seem to work out the Right Way for these things, they haven't failed at a project yet. Don't anybody bring up those flawed scalability benches, who really cares? If you want scalability, you know where to find it. OpenBSD brings practically flawless security and quality where they step, and they have pioneered a lot of development in security that has made modern unices what they are renowned for.
PCs with free software are worlds of freedom. Embedded or otherwise 'specialty' hardware usually has less freedom and costs a ton more. Personally I don't want a router even though they're cheap and effective, because I like having complete control over my gateway (and being able to use it as an emergency internet client:))
But I think you're exaggerating the 'danger' of CISCO kits. Are they really going to tell you to go f*ck yourself if you ask for part replacement or something? I'm curious because I don't know their policies, but it still sounds like something nobody would buy if it was that bad.
That's the BSD Way, as far as I have seen. To do one thing and do it very well, and only add more functionality if people really want/need it.
Look at the BSD tools versus GNU tools. They do fundamentally the same things, but GNU tools are usually tens of times larger because they do lots of things only one or two people alive would want. This means those one or two people find GNU tools more convenient, while the rest of us like being able to compile the whole *BSD world in 1 hour on a slow machine, where a GNU-based system takes an hour to compile JUST glibc on the same hardware.
In the running system, GNU tools are handier, since they have more modern defaults, more convenient shortcuts to doing things (default of . for find(1), default output of stdout instead of the tape device for tar, and so on), etc. but the BSD tools are usually a load easier to know the full functionality of. Look at BSD indent versus GNU indent (which is a fork of BSD indent). The latter has every feature under the sun, many of which never will be used. The former hasn't changed much in years and still does what it always did well, nobody complains. The latter can be more convenient, but at the cost of code size, sometimes even cleanliness... no thanks.
But yeah, that's my point. The BSDs focus on the functionality something is meant for, and do it as cleanly as possible. The 'other' software doesn't have this focus. Which you consider 'better' is all about your priorities I suppose.
That's absolutely right ("hopefully"). The more secure and trustworthy (read: OpenBSD:P) code Microsoft and whoever else import, the safer the internet will be. I think security and quality should come before political agendas regarding defeating corporations. Microsoft is not going to go away any time soon, so it may as well gets its act together and release at least one secure product.
As Theo himself said, their security is our security, since every compromised machine on the net is yet another drone to add to brute force networks or yet another gateway sniffing our packets. Security doesn't end at your network, it continues everywhere you can possibly connect.
Why do things have to be GPL? Just because it makes it impossible for corporations to borrow from them, and makes embedded work messier? I respect RMS' ideas and all, but the GPL is just as encumbered as proprietary licenses, certainly as long and complicated. It just happens to demand that the product have source included with binaries, and that further generations of the software must also be GPL. They call it the "GNU Public Software Virus" in some camps, since it ends up 'infecting' a lot of otherwise unencumbered software.
I bet I could save ~10 meg all up if every instance of the GPL in software on my disk (that measurement includes bzip2's effects) was relicensed to BSD or even free domain.
Slashdot Mirror
You'd know all of this if you didn't live under a rock. Almost all of Slashdot's OS zealots/trolls know about Felix' (very flawed but still popular, making Felix himself a great candidate for government, ) scalability benchmarks which compare apples and oranges and then slander perfectly good systems.
Nevertheless, NetBSD went from being second worst to second best in two weeks of work, all of which continues to work stably and all. This is a proud achievement that the other BSDs could learn from, and apparently have (but nobody has put new figures up yet so it's not 'public').
NetBSD has three important things going for it: Cleanliness (code and system), stability, and portability. It also has security (but is not as active in this as OpenBSD, yet still very active..) and amazing performance in 2.0 (but most of the time performance is still left up to Linux). It has a very good place in computing, but could be doing much better if NVidia got up off their asses and made drivers for it, at the very least.
And yes, there are newer architectures that it doesn't support, ppc64 and ia64. Strange but true. Nevertheless when they do support it, they'll support it with "solutions, not hacks".
I don't have that kind of power, nor would I do it if I could. You can install a 2.0RC5 system with a couple of floppies and FTP, or failing that, an unofficial ISO. You can then track (via cvs) netbsd-2-0 past its release and on to -stable. This will work very well for you and not require an official release, which, at this stage, could mean a flaky system for some other users (since there are still issues holding it back).
A lot happened to make 2.0, and given it's edging NetBSD out of 'old slow deprecated system' into 'holy sh*t-fast modern system', getting the first release Right is well worth the wait. The functional difference is about as much as FreeBSD 4 into FreeBSD 5 (sans some things like Project Evil), but with a performance gain instead of performance loss. You really have to try it to believe it.
Beautiful. The first 100% troll post I've seen in ages. Usually trolls have had at least one thing that was partially true, but not this one. Pure shit :)
A work of art, even. Thankyou sir, you give us something to mark other stupidities by.
Well log-structuring is said to be the 'more complete journalling' so I didn't figure the distinction would matter as much. Thanks for the extensive description though, that really depicts the differences. Even the online documentation on NetBSD's site didn't go into that much detail.
We need more people like you and less like great grandparent (fellow talking about Linux being the only one with journalling file systems and hence being so bloated, etc).
It does not support more architectures in-tree. You need external patches for a great many of them. A person with a clue would know this. NetBSD supports them all in-tree and with mutual inclusion.
LFS is a journalling file system, which NetBSD has. A person with a clue would know this. If you looked at my self-reply post, I pointed out that the difference the Linux file systems makes is roughly "jack shit".
There are also few drivers Linux has the BSDs don't. These are mostly only the 'evil' new cards made by NVidia and co, for which you often need external Linux drivers anyway. What's your point? None of them take up 15 meg bzip2'd anyway.
More scalable doesn't require larger code, if done right. If you knew ANYTHING about programming you'd understand this. You're coming off as a clueless troll and I can only conclude this is in fact what you are. Go read a book before you try to write one.
You're right. I should join in and help make Linux a bigger, more 'forward' project.
/usr/src/linux
...and then email the diff to Linus who'll happilly include it. Seems that's how the coding is done, anyway.
cd
dd if=/dev/urandom of=l33t-new-functionality.c bs=1k count=10k
Face it man, getting bigger doesn't mean getting better. It still suffers from very significant issues in stability, networking capability, security, and root@life knows how dirty it is in every way, even dmesg. That's what you get when you hand a tosspot around to thousands of developers.
Exactly, see? Good systems don't need code bloat. OpenBSD is yet another system which does what it does very well and obviously efficiently.
Linux doesn't have security, in 2.6 it doesn't even have stability, and performance seems limited to synthetic cases. Why it gets all the attention is beyond me.
BSD: The cathedral versus the bizarre.
Actually, before some clueless newbie posts saying it's all file systems, take a look at this:
/usr/src/linux
thor linux # tar -c fs | bzip2 -9 > fs.tar.bz2
thor linux # du -h fs.tar.bz2
2.8M fs.tar.bz2
...) they have in common. Sorry folks, file systems doesn't answer for it.
thor linux # pwd
Not to mention NetBSD supports a few file systems Linux doesn't in-tree (LFS, portalfs, nullfs...), and that many (NFSv3, UFS [NetBSD supports more of it anyway], ext2fs, SMBFS,
It's more than just base software choices actually. The BSDs have huge amounts of useful base system software, and depending on your needs you can get an amazing lot done without touching a single out-of-tree package. This includes relatively comfortable software development thanks to nvi, gcc/g++/etc, gdb, BSD make, and so on.
The difference comes in when you look at how bloated the software itself is. All the BSDs have libcs that are tiny (a couple of minutes to compile on even my slowest machines) and do everything a C library should, including full networking and everything. The GNU libc, which you'll find on every Linux system by default (there's a diet libc out there, but it isn't recognized), is a HUGE package that takes a very long time to compile and results in a hefty binary in the end. What does all this bloat go towards? Most say it's all because of its attempt at being completely internationalized, but this is hardly enough to warrant about a 10x size increase.
The same idea applies to all other software that wasn't imported from GNU. If you can do the same things smaller and more efficiently, do it that way. There's no point in having 90% of your source appeal to minor features few people will ever use. There's also a strict adherence to tradition where possible - nvi is kept instead of some stripped-down vim-alike (which would have more convenient features, for instance) because people coming from a BSD system a decade ago won't get culture shock. But all the same modern software is a 'make install' away on any of the BSDs.
The bloat difference in the Linux kernel and BSD kernels isn't even worth discussing. It's just not funny any more. Linux has inflated a LOT in recent times. I remember back when some 2.4 was about 25 megs tar.bz2, now look at it - 2.6.9 weighs in at 35 meg. Is it really 40% more functional? Nowhere near. If anything it should be getting smaller, since they insist they're refining to simpler algorithms that should work faster and take less code.
The NetBSD 2.0RC5 src/sys source compresses (bzip2 -9) to 20M, smaller than Linux 2.4 was. Compared to 2.6, it includes most of the same drivers, the same functionality (plus good security), the ability to run Linux binaries natively (and FreeBSD, SVR4, and some others I forgot), a network stack known to be better than Linux', and oh so much more. This source INCLUDES the ports of NetBSD for which Linux needs EXTERNAL patch sets to run on, meaning that this source tree is even more portable. We all know it's more stable, too. Where is the gargantuan (~175%) size of Linux going? It's all pure bloat. And I challenge even one person to come up with something Linux does that NetBSD can't do, and that takes up 15 meg when bzip2-9'd.
Well that's just depressing. Okay, on the other hand, if you strip away all the unstable functionality, any software can be at least practically 'stable'... but I wouldn't be surprised if they left in something terrible.
I still say, firmware or at most simple microkernels for embedded devices. Complexity leads to mistakes, and in embedded devices this is much more annoying and harder to fix. Even my Ti83+ is a buggy PoS (~40% of the ones I have ever seen in my life are, in fact, and in random ways) and that has its own dedicated 'operating system', but Ti somehow managed to get it wrong even after dozens of revisions.
What about the cleanliness, second-to-OpenBSD security, performance, and most of all stability? Linux hasn't ever been secure without third-party patch sets which rarely get merged back, and even they themselves aren't anywhere near any of the free (OSX not counted) BSDs which actually care about security. NetBSD has had 9 security advisories in this entire year, and (I think, check) 7 of these were in userland components imported from other projects. Linux has had a few brown-paper-bag-worthy security holes and lots of other little exploits like the ones this release fixes. This from the media-hyped "free secure operating system"? Almost as bad as Windows XP being called "secure".
To grandparent: Yes, run a BSD. Forking Linux won't help, it's a hack job from the ground up, and anything Linux does can be ported to a BSD cleanly, and it will be done securely and most of all reliably. If corporations that write Linux drivers and so on were made aware of other operating systems and the potential profits from supporting them, the BSDs would have a much better standing.
Actually, most 'projects' that people run Linux for (let's say ReiserFS) are actually only there to make up for Linux deficiencies in the first place. Our friend ReiserFS exists to plug the 'reliable file system' hole in Linux. Even it makes a huge mistake, which is forgetting that data actually gets written to hard disk. If you'll look closely at how it's laid out, there is NO superblock backup. One byte wrong in the superblock can mangle a whole partition in ways no fsck tool can easily fix, and there's your "reliable file system" gone. It hides behind journalling, and to this end it also devotes a very big chunk of your system resources. The BSDs all have the solid FFS/UFS which has been reliable for decades without journalling, with superblock backups, and with very good real-world performance. Tack SoftUpdates on if you want journalling-like reliability and performance enhancements. Not good enough? Run LFS, a (let's call it) half-way between UFS and ReiserFS that is now stable (in NetBSD 2).
-Huge funding and sponsorship doesn't make something good
-Media hype doesn't make something good
-More developers is often worse, not better. Linux has countless developers with highly different and unstandardized ideas of how to code, how to test, how to format error/boot messages, and so on. If you look at the code, you start to wonder how gcc doesn't just reject it as a crime against development. We should talk to the GNU GCC team on adding such a feature.
-Security damn well matters. How Linux developers manage to completely overlook this is just amazing.
-A solution in a week is better than a hack in one day. Linux has had lots of "it'll be good enough for now" hacks that have stayed as core features for years, and may have been replaced by something closer resembling a solution by some clever coder a few years later. Or not.
-If you're going to change something big (SCSI interface, anyone?), wait for a new major version to do it, especially if the old system works fine. The very least you can do is release the new system as an alternate patch/branch and see if people accept it. Never should a big change be 'slipped in' to a mainline branch with no real warning or option to use the old system. Basing this on "I don't like it" is even worse.
-If you're going to port or add significant features, make them fit in the mainline kernel all at once. People say "Linux is portable". This is not true. People have just managed to make patches that replace functionality and make a certain Linux version - with the patches - boot on some architecture. Big deal. Real portability fits in the system with mutual inclusion, and it's in the mainline, gaining the benefits of the main project as well as any contributions. This is why NetBSD, though historically run on less archs/machines overall, is truly Portable. You see this when you use it too - it actually fits on every system like the system was built for it, not like some parents'-basement hacker made a kernel boot.
Absolutely. That's why I don't run Linux on production machines to begin with :)
2.4 is more reliable than 2.6, but that's not saying much. It's like WinXP is more reliable than WinME. You still wouldn't stake your life on it.
But FreeBSD DOES have a few components of GPL code (ext2fs, the *good* floating emulator) in the kernel, they're just usually omitted in release builds. It will still warn you that your kernel is 'tainted' when you compile it in.
But being anti-GPL in kernels is a Good Thing. Let's face it, kernels are where a lot of good useful tech resides, and they're what go into embedded systems. GPL makes it too messy to borrow code (you have to open-source the host program, and if you derive a significant portion from GPL'd code, the host program has to be GPL too) and don't even think about embedding cleanly. This means that companies which need good code but can't afford to go open are stuck writing their own sh*t.
Thankfully the BSDs are there. Although there are some technical advantages in Linux (not many though) the BSD code bases are notably cleaner (which is very important) and can be incorporated into anything with little legal difficulty. The very least any BSD-includer has to do is retain credit to the developer of the code.
If Linux was under a BSD license a lot of other systems would be much more powerful today (including the BSDs themselves), and if Linux had a BSD development model it would actually be clean and have a high functionality-to-code ratio. We wouldn't have problems like the one I've been having, where a segfaulted server can't re-bind its socket for up to a minute because Linux (2.6.9) didn't clear out the file descriptor tables (all the BSDs do it immediately after program termination in *any* way).
Haha well that's just embarassing on my part :)
Even scarier is the two separate Alan Cox instances, both kernel developers. If root@life loves object-oriented programming He should be more careful with duplication.
You're behind there. pkgsrc is already on at least one known Linux distro internally, and it can be installed on any other, and many do this (if you read the mailing lists).
...and a tool to update properly. (I did an update, and it rebuilt all of Firefox. Fair enough. Then it rebuilt zlib, and then everything that depended on it - which is PRETTY MUCH EVERYTHING - including Firefox which it JUST rebuilt. It removes them as soon as it updates the 'core' thing, zlib in this case, but it doesn't reinstall them until the build completes, which may not even happen - mine failed).
It doesn't help though. pkgsrc is like the rest of NetBSD it seems, conservative. Although I am amazed to find that it has Ruby 1.6, I never noticed that. It had the new firefox RC's within hours of their introduction to the internet, which is about as fast as Gentoo Portage, but with many less developers and an admittedly much harder to work with (PLIST) mechanism. Not bad at all. If they had a larger range (at least most of what FreeBSD Ports has, which includes everything I've ever needed..) with this same attention to quality it'd be awesome.
If Gentoo Portage was more ubiqitious and less Linux-ism'd, we could run it on the BSDs properly and they'd be much easier to install software for. There are projects to do this now, but they seem to be hack jobs more than actual re-writes of basic Portage design. At the very least the ability to have patches be conditional based on platform and the ability to 'inject' and never need to update the portage equivalents of everything said BSD has in its base - but this should be automatic!
Yeah, I did actually mean what I said, but I suppose it was in the wrong way. Meh, I've seen worse.
As for FreeBSD 5, I'm very seriously considering running it again just because it did have everything and it had it easily, even if it did mean the tree right now wouldn't milk every last drop of performance. "Crap" was entirely the wrong word, "poky but still useful" may be more on track. May as well fetch that ISO then.
Sorry for anyone I may have offended or otherwise ticked off during my pseudo-trolling rage.
Okay, that's pretty fscking bad. I just assumed they had some decency. Imagine my surprise :)
That's pretty bad taste... the concorde tragedies shouldn't be laughed about. They came about entirely because of breakdowns in communication (cheap workers from one country, documentation from another...) and could have easily been avoided.
Yeah. Hey FreeBSD is still the most usable free OS I've ever known, and probably THE most functional... it would suck to see it go down on a technicality. I hope they make everything good again. Or, on the other side of the coin, NVidia write drivers for NetBSD :) (and somebody ports/writes equivalents of FreeBSD's devfs and watch(1)+snp(4))
Anyway, DragonFly BSD will still be a refuge, because anything FreeBSD 5 whips up seems to be easy enough to port back to DFly, and this is what they have done for most of what they think is worthy. And the new VFS work will allow journalling file systems, which FreeBSD hasn't had for years, since they diked out LFS (which NetBSD kept and stabilized). DFly is definitely going right up into the greats of systems.
That's actually a pretty good idea. Double-whammie - help them and get a 'free' (for you) copy of a great system.
Personally if I like what I see of OpenBSD when I try it, I'll buy it anyway, my money or not. It's the kind of thing that is so great you feel good having the real set of, as opposed to Windows where you feel even having a 'free' (cough) CD provided by Dell or whoever is a waste of money manufacturing. Not that I'm bashing Windows per se, it has its uses, but the license of one key per 'owner' (which nobody abides by anyway it seems) is ridiculous. With OpenBSD it's unencumbered - you buy the CD and that's it, do whatever (except clone it and resell, you have to make your own ISOs for that). Install it on every machine in a 1k box network, then give it to your friend to install on his box too.
henning = phk? Good work on devfs!
:)
But yeah, something like this does sound like a kernel task as much as user. But if Linux users now endorse udev, anything can happen. Personally I think it's a terrible idea but that's just me. Thank root Linux devs don't engineer security.
OpenBSD always seem to work out the Right Way for these things, they haven't failed at a project yet. Don't anybody bring up those flawed scalability benches, who really cares? If you want scalability, you know where to find it. OpenBSD brings practically flawless security and quality where they step, and they have pioneered a lot of development in security that has made modern unices what they are renowned for.
And yet, I've never run OpenBSD
Hey easy there, we get the idea :)
:))
PCs with free software are worlds of freedom. Embedded or otherwise 'specialty' hardware usually has less freedom and costs a ton more. Personally I don't want a router even though they're cheap and effective, because I like having complete control over my gateway (and being able to use it as an emergency internet client
But I think you're exaggerating the 'danger' of CISCO kits. Are they really going to tell you to go f*ck yourself if you ask for part replacement or something? I'm curious because I don't know their policies, but it still sounds like something nobody would buy if it was that bad.
That's the BSD Way, as far as I have seen. To do one thing and do it very well, and only add more functionality if people really want/need it.
Look at the BSD tools versus GNU tools. They do fundamentally the same things, but GNU tools are usually tens of times larger because they do lots of things only one or two people alive would want. This means those one or two people find GNU tools more convenient, while the rest of us like being able to compile the whole *BSD world in 1 hour on a slow machine, where a GNU-based system takes an hour to compile JUST glibc on the same hardware.
In the running system, GNU tools are handier, since they have more modern defaults, more convenient shortcuts to doing things (default of . for find(1), default output of stdout instead of the tape device for tar, and so on), etc. but the BSD tools are usually a load easier to know the full functionality of. Look at BSD indent versus GNU indent (which is a fork of BSD indent). The latter has every feature under the sun, many of which never will be used. The former hasn't changed much in years and still does what it always did well, nobody complains. The latter can be more convenient, but at the cost of code size, sometimes even cleanliness... no thanks.
But yeah, that's my point. The BSDs focus on the functionality something is meant for, and do it as cleanly as possible. The 'other' software doesn't have this focus. Which you consider 'better' is all about your priorities I suppose.
That's absolutely right ("hopefully"). The more secure and trustworthy (read: OpenBSD :P) code Microsoft and whoever else import, the safer the internet will be. I think security and quality should come before political agendas regarding defeating corporations. Microsoft is not going to go away any time soon, so it may as well gets its act together and release at least one secure product.
As Theo himself said, their security is our security, since every compromised machine on the net is yet another drone to add to brute force networks or yet another gateway sniffing our packets. Security doesn't end at your network, it continues everywhere you can possibly connect.
Why do things have to be GPL? Just because it makes it impossible for corporations to borrow from them, and makes embedded work messier? I respect RMS' ideas and all, but the GPL is just as encumbered as proprietary licenses, certainly as long and complicated. It just happens to demand that the product have source included with binaries, and that further generations of the software must also be GPL. They call it the "GNU Public Software Virus" in some camps, since it ends up 'infecting' a lot of otherwise unencumbered software.
I bet I could save ~10 meg all up if every instance of the GPL in software on my disk (that measurement includes bzip2's effects) was relicensed to BSD or even free domain.