Slashdot Mirror
NetBSD 2.0 RC5 Tagged
ulib writes "NetBSD 2.0_RC5 has now been tagged. Changes since RC4 include fixes to various COMPAT_ emulations, IP Filter backward compatibility fixes, XFree86, pax(1), rsh(1), hp300 boot blocks, pthread fixes for amd64 and i386, documentation updates. Binary snapshots of NetBSD 2.0_RC5 are available in the daily builds directory on the main FTP site."
Posting works. It's morning EST; the nerds slumber. I for one am pumped about 2.0. I'm a recent convert from Linux and I like NetBSD's installer as well as its bloat and crap-free default software arsenal.
With Fluxbox, the GNU coreutils, and bash, my P133 makes a reasonable desktop workstation. Though Linux would work, the low hard-drive footprint of a NetBSD install is what makes the installation trouble-free. Comparable modern Linux distros seem to me to take time to whittle down to a sub-300MB install. With NetBSD, the core system with XFree uses only 290.
Does NetBSD have any plans to migrate? Or do they have a good reason for sticking with XFree86?
Licensing aside, most of the development seems to be happening at X.Org and that is a good reason to migrate.
- If you need top of the line security, use OpenBSD.
- If you need a small footprint, use NetBSD.
- If you need to run on an odd architecture, use NetBSD.
- If you need a great BSD operating system, and know that everything you'll use is in NetBSD's package system, use NetBSD.
- If none of the above meet your criteria, use FreeBSD.
Also, FreeBSD has better hardware support than the other BSDs as far as number of supported devices. FreeBSD works well, and ports is pretty good, but the cost of that is bloat (although it pales in comparison to what Linux users regard as bloat. A bloated FreeBSD is comparable to a modestly slimmed down Linux installation, although if you really bite down hard, Linux can be made a little smaller than FreeBSD, while still not being able to compare to NetBSD). Basically, if one of the other BSDs will work for you, use it instead of FreeBSDLastly, in time, DragonFlyBSD will edge out FreeBSD. Dfly is going to have far better SMP and clustering, and it's being done so well that performance on a UP machine isn't suffering.
Just curious (as I've never installed or maintained any *BSD system): Suppose you have a FreeBSD and lets say a Mandrake workstation setup, complete with XOrg, GNOME, KDE, OpenOffice, etc. Are we talking a substantial bloat increase with the Mandrake setup just because it's "Linux"? Is it more libraries, bigger binaries, more software package dependancies...? Or are you talking a default install of *BSD versus a typical default install of a modern Linux distro?
I'm sure "SlashdotMedia" will improve on all the wonders that Dice Holdings blessed us all with
Mandrake
I would recommend FreeBSD over Mandrake, if you're just looking for a non-Windows OS. FreeBSD's configuration takes place via direct manipulation of the text files that control the OS. It's generally not hard to find information on what to twiddle and how, and you end up learning more in the process. Mandrake (and Redhat, the last time I used it) uses GUI frontends to change these text files, and often uses its own nonstandard text files, so that anything you learn won't carry over to another Linux distribution. Furthermore, the last time I used Redhat, I had choices of several different GUI frontends to many different text files, some of which were changed in different ways for different purposes. Without X, I couldn't configure my system.
Is it more libraries, bigger binaries, more software package dependancies...? Or are you talking a default install of *BSD versus a typical default install of a modern Linux distro?
It's typical distribution size. Almost every Linux distribution has a large sprawl involved with what it's including these days. A default Linux From Scratch install contains expect and Perl, for example. The BSDs are built with a focus on taking away everything that isn't necessary. Linux distributions for the most part don't even try.
As for the system binaries, it depends on how they're built. You could build in the library routines they use, or compile them so that they need dynamic libraries, or you could use something like busybox to decrease the size dramatically. It's not a cut and dry situation, but most Linux distributions manage to be larger than the BSDs anyway.
As always, it comes down to what you personally need and what matches your skill level. For Linux, you're better off using Slackware or Debian or Gentoo because they're less likely to damage your ability to learn Linux deeply than something like Mandrake. Today, even though I have no trouble managing FreeBSD or Linux From Scratch, I'd probably have trouble managing a Redhat or Mandrake installation, but I could probably pick up Gentoo or Debian's way of doing things in a few days.
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.
Sam ty sig.
Well I am a big fan of Open and Free BSD's. As soon as I get my iBook back in from warantee I will be dualbooting OSx with netbsd. I tried Openbsd and it simply never had the support. Understand the BSD goals. Openbsd tries to be the most secure/stable OS. FreeBSD likes to be rich with features. NetBSD tries to get on as many architechtures as possible. It's all about flavors, just like various flavors of linux. There, I hope that helps you :)
OpenBSD broke from the NetBSD base over 9 years ago, that is nine years of code divergence in small ways even in the most similar of parts of the codebases.
NetBSD has a great deal of platforms that are supported, including architectures untouched by most other operating systems. OpenBSD supports only 14 platforms, with several discontinued ones as well. NetBSD's supported platforms however are not up to the same standard as OpenBSD's; OpenBSD requires that the port be compilable on it's given platform and many of NetBSD's cannot. This makes the overall codebase of NetBSD more portable and stable at the price of properly supporting it's platforms.
OpenBSD has in the past audited the codebase for it's entire system in order to remove as many programming errors as possible, this has lead to increased security as well as stability.
OpenBSD has in the past removed system tools and ports that it deems to be too insecure or bug ridden. NetBSD does not have this policy. Such as rlogin.
OpenBSD has in the past fought over licenses which they do not believe in having within their system; trying to relicense or replace code which does not conform with their level liberal code. NetBSD does not find this to be a priority. Such things include SSH/OpenSSH, IPF/PF, XFree86/X.org and GnuTAR/TAR.
OpenBSD integrates security minded protection into it's system whenever possible. NetBSD does not. Stack protection; stackghost on Sparc and propolice on I386 as well as taking them to other platforms in the future.
I honestly see no major pros to using NetBSD over OpenBSD on any of the overlapping platforms, but NetBSD is on more platforms.
I'm sick of following my dreams - I'm just going to ask them where they're going and hook up with them later.
as one point of comparison, in the time NetBSD 2.0 has been in beta, OpenBSD has managed to ship two releases out the door.
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.
Sam ty sig.
Oh, and LFS isn't a journalling filesystem. It's a log structured filesystem. The idea of LFS is that nothing is deleted (until you run out of space). When you save a file, it writes the changes at the end of the disk. This means that nothing you do will corrupt the disk in the event of a power failure (as with journalling, the only thing you'll lose is the last update), and that you can easily undo changes to a file (since the original is never overwritten). Additionally, the write performance of LFS is close to the theoretical maximum of the disk (since the head never has to seek for a write). The disadvantages are that it requires a lot more disk space, and disk reads of frequently modified files are slow. Additionally, when the disk becomes nearly full it is necessary to compact the log (i.e. erase bytes that have been overwritten). Log structured filesystems were a hot research area about a decade ago, but the disk space requirements were such that they were not considered feasible for general use. That will probably change in the near future due to larger disk sizes (except for Linux users, who won't be happy unless they have 500 text editors installed...). Tanenbaum proposed an interesting variant of a log structured filesystem that was implemented in Amoeba. In this version, there was no modify operation. Files were created and written to, then became read-only. Modifying a file was a matter of reading the entire file, modifying it in-core, and then writing the new version. This gave similar write-performance to a log structured FS, but also gave very good read performance (since files were always contiguous). While this design is not feasible for everything (very large files, frequently updated files), it would be ideal for many things.
I am TheRaven on Soylent News
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.
Sam ty sig.