Slashdot Mirror
NetBSD 5.0 Released
kl76 writes "The NetBSD Project have announced the release of NetBSD 5.0 after two years of development. Highlights of the seven million new lines of code in 5.0 include a new threads implementation, kernel preemption, a new scheduler, POSIX real-time scheduling, message queues and asynchronous I/O, WAPBL metadata journaling for FFS filesystems, improved ACPI support, UDF write support, X.Org instead of XFree86 (on some platforms — at last!) and lots of driver updates. Binary distributions for 53 different platforms are provided."
That's $28 million/month in total!!!!!!
Colorless green Cthulhu waits dreaming furiously.
NETCRAFT:
Bring out your dead!
[clang]
Bring out your dead!
CUSTOMER:
Here's one.
NETCRAFT:
Ninepence.
NETBSD:
I'm not dead!
NETCRAFT:
What?
CUSTOMER:
Nothing. Here's your ninepence.
NETBSD:
I'm not dead!
NETCRAFT:
'Ere. He says he's not dead!
CUSTOMER:
Yes, he is.
NETBSD: Bring out your dead!
[clang]
Bring out your dead!
[clang]
Bring out your dead!
[clang]
I'm not!
NETCRAFT:
He isn't?
CUSTOMER:
Well, he will be soon. He's very ill.
NETBSD:
I'm getting better!
CUSTOMER:
No, you're not. You'll be stone dead in a moment.
NETCRAFT:
Oh, I can't take him like that. It's against regulations.
NETBSD:
I don't want to go on the cart!
CUSTOMER:
Oh, don't be such a baby.
NETCRAFT:
I can't take him.
NETBSD:
I feel fine!
CUSTOMER:
Well, do us a favour.
NETCRAFT:
I can't.
CUSTOMER:
Well, can you hang around a couple of minutes? He won't be long.
NETCRAFT:
No, I've got to go to FreeBSD. They've lost nine today.
CUSTOMER:
Well, when's your next round?
NETCRAFT:
Thursday.
NETBSD:
I think I'll go for a walk.
CUSTOMER:
You're not fooling anyone, you know. Look. Isn't there something you can do?
NETBSD: [singing]
I feel happy. I feel happy.
[whop]
CUSTOMER:
Ah, thanks very much.
NETCRAFT:
Not at all. See you on Thursday.
CUSTOMER:
Right. All right.
[howl]
[clop clop clop]
Who's that, then?
NETCRAFT:
I dunno. Must be Tux.
CUSTOMER:
Why?
NETCRAFT:
He hasn't got shit all over him.
Learning HOW to think is more important than learning WHAT to think.
Of course it will. Toasting multiple toasts simultaneously is now supported, as well as suspending and resuming the toasting process. If toasting fails, the toasts will now be rolled back into the original raw state.
Ezekiel 23:20
It is interesting, but is it relevant to this thread?
I tried to find a methodology of their statistics. If I recall, netcraft used to perform fancy packet inspection to determine what a site was running and if or when a site rebooted. Today, any site of substance is really a cluster of servers fronted by load balancers. You really have no idea when a server behind it reboots.
This is a boring sig
Would that be called the undough or redough function?
Every mans' island needs an ocean; choose your ocean carefully.
BSD is one of those things that I've been interested in doing, especially early on. It is arguably more secure than Linux, is definitely older and potentially more secure.
OpenBSD is - not BSD in general.
2) Although they had similar backgrounds and technologies, the differences were enough that it was almost a complete re-learn. RPM didn't work. Init was totally different. Commands such as ps, at, etc. had different options.
You name three things that one would expect to be different, even without installing OpenBSD:
I guess I don't see why your experience surprised you so much. If you're going to switch Unices, particularly from a (mostly) SysV-based system like Linux to a near-purely BSD-based system like OpenBSD, you should expect that some things are going to be different. It's one thing to say "hey, I tried OpenBSD, found that security is indeed the inverse of convenience, and decided I liked Linux better because it was more familiar to me". But saying that you were surprised to find that RPM didn't work leaves you vulnerable to "well, duh" comments. Like this one ;-)
Advice: on VPS providers
Why do some Operating Systems never show uptimes above 497 days ?
The method that Netcraft uses to determine the uptime of a server is bounded by an upper limit of 497 days for some Operating Systems (see above). It is therefore not possible to see uptimes for these systems that go beyond this upper limit. Although we could in theory attempt to compute the true uptime for OS's with this upper limit by monitoring for restarts at the expected time, we prefer not to do this as it can be inaccurate and error prone.
Why does my uptime go back to 0 after 198 days ?
The Linux TCP stack uses the low 32 bits from the system uptime timer, and this timer, in recent kernel releases, runs at 250Hz. This means that the timer value wraps around to 0 after roughly 198 days. Although we could in theory attempt to compute the true uptime for OS's with this upper limit by monitoring for restarts at the expected time, we prefer not to do this as it can be error prone.
Why do you not report uptimes for Linux 2.6 or FreeBSD 6 ?
We only report uptimes for systems where the operating system's timer runs at 100Hz or less. Because the TCP code only uses the low 32 bits of the timer, if the timer runs at say 1000Hz, the value wraps around every 49.7 days (whereas at 100Hz it wraps after 497 days). As there are large numbers of systems which have a higher uptime than this, it is not possible to report accurate uptimes for these systems.
The Linux kernel switched to a higher internal timer rate at kernel version 2.5.26. Linux 2.4 used a rate of 100Hz. Linux 2.6 used a timer at 1000Hz (some architectures were using 1000Hz before this), until the default was changed back to 250Hz in May 2006. (An explanation of the HZ setting in Linux.)
FreeBSD versions 4 and 5 used a 100Hz timer, but FreeBSD 6 has moved to a customisable timer with a default setting of 1000Hz.
So unfortunately this means that we cannot give reliable uptime figures for many Linux and FreeBSD servers.
meh...
Anyone know of any major projects where NetBSD has been deployed and has been known to provide benefits far and beyond what can be gained from using more "traditional" operating systems?
I believe NetBSD 5.0 is a major turn of tide. Compared to 4.0, this is definitely a new chapter. In a way Mr. Hannum did a favour in his infamous rant: practically all aspects he identified have been addressed.
We here at $DAYJOB have made extensive evaluation of the NetBSD 5.0 pre-releases and it is looking very good indeed. Our internal benchmarks show that for our typical workload, performance of NetBSD is now comparable to that of Linux and FreeBSD. (Numbers and methodology may not be representative nor even correct, but we have to base our decisions to something.) It is very likely that we will be rolling the next big-iron production line solely with NetBSD again. The recent happenings with Sun and the uncertainty surrounding Solaris have warmed also the management section upstairs.
Besides performance and SMP, other things that account high in our book:
Some drawbacks:
At $HOME perhaps the most exciting feature is the new power management framework. This has taken huge leap forward in NetBSD 5.0. While there is still much work to be done, the direction is right. I believe that like SMP on the other end, power management will be one of the dominant factors in consumer-grade computing at the other end of the spectrum.
Other things that I like generally in NetBSD:
BSD is one of those things that I've been interested in doing, especially early on. It is arguably more secure than Linux, is definitely older and potentially more secure.
In general, BSDs do have a longer lineage than Linux, and they seem to have better security as well. However OpenBSD is the only one the is exceptionally notable in the security standpoint.
1) At the time, getting stuff installed was more of a chore.
I don't know, I've not used NetBSD. Install from packages on FreeBSD is fairly trivial. As long as you don't go crazy with your make.conf, install from source is pretty reliable and trivial as well.
2) Although they had similar backgrounds and technologies, the differences were enough that it was almost a complete re-learn. RPM didn't work. Init was totally different. Commands such as ps, at, etc. had different options.
Their backgrounds aren't really similar. I wouldn't expect RPM to work any more on *BSD than I would expect it to work on Windows or Mac. Well, maybe a bit more than on Windows. It doesn't even work across all Linux distros (and in my experience, I had better luck with apt on RH, than RPM. The exception being for the Linux Compatibility Layer, I would expect RPM to properly install stuff there (and it does!)
As for init, yes, it is rather different, but there are several different init systems out there for *nix and *nix-like operating systems. You can get two or three of them on Linux.
3) Didn't have support for multi-core systems. (at the time, I believe that's long under the bridge now)
I've had SMP on FreeBSD for a long time, I expect OpenBSD was the same way. However, prior to FBSD7, you had to change some kernel options to get SMP. I'm guessing OpenBSD was the same way.
Bottom line? I'd started to build a business that continues to this day using Linux as my architecture. In order to move over, I'd have to port over all my administration scripts, and much of my software to an environment that was just different enough to make me *think* I knew the answer when I didn't. Porting would have been somewhat expensive, and the case to make for the switch was marginal.
True, but no one is asking you to switch. Keep with Linux, if it works for you, stick with it.
In my experience, I spend less time in a year doing administrative tasks on a FreeBSD box, than I do in a month on a Linux box. But it's a mindset thing. FreeBSD is better designed for my mindset. There are people for whom the Linux mindset is better, or the Windows, or the Mac. It's good we have options so more people can have computers they can use.
Long live BSD!
And Linux, Windows, MacOS as well. May BeOS and Amiga be raised from the dead in the process.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).