Slashdot Mirror
FreeBSD 5.0 Developer Preview #1 Released
An Anonymous Coward writes: "The FreeBSD developers just announced the release of an official snapshot of the upcoming FreeBSD 5.0 which should be expected in November. Time to try out amazing new feature like background fsck, FFS snapshots, KSC, devfs, SMPng and many more. Check the Release Notes for detailed information." Read on for a list of ISO mirrors, too.
Thanks to AEtherSPOON, you can spare the main servers and use one of these FTP mirrors to grab the ISO:
The design of the BSD file system, when using "softwrites", is specifically engineered to handle this. It does require a rather sophisticated fsck (and one that is aware of how softwrites works). On the other hand, this also removes some of the complexity of the file system (which is not to say it isn't tricky code, but tricky in a different way from, say, a journaled filesystem)
"It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
You are right on Theo getting rooted. This sufficiently propelled the OpenBSD team into the security first approach that has made them so famous.
Thats not the real Theo. Its really spelled Theo de Raadt, not DeRaadt. Its just some troll who likes to think he acts like him.
Just because a kernel supports the Intel 80386 CPU doesn't mean that later x86 processors can't leverage their advances with the same kernel. It seems that you didn't fully register the last phrase in your blockquote. When a kernel supports advanced instructions, CPUs with lesser instruction sets must run tests to see which instructions are supported, and which they need to ignore. This significantly slows down the relatively underpowered 386 class CPUs, while post-Pentium grade CPUs hardly notice anything.
The trouble isn't that advanced instruction sets aren't utilized, but that there is no streamlined kernel for 386s that doesn't waste their precious time. Let me fictionalize a dramatization:
"Are you superscalar?"
"no"
"Do you grok MMX?"
"no"
"Have you heard of SSE?"
"huh?"
"Do you have the Pentium Floating point Bug?"
"The what?"
"Do you mind if I waste another 16,000,000 cycles asking you rhetorical questions?"
"no - at least not until I get my I386_CPU optimized kernel, so that I can make every kHz count!"
Support for i386 chips in the generic kernel should definitely be the default, even if it did mean that the advanced features in the latest CPUs couldn't be fully exploited. For one thing, you need to ship the lowest common denominator so that the lower boxes can even run in the first place. Not to mention that it is much more sensible to ask a Terahertz Sexium w/Frobnitz CPU to recompile a kernel than a piddling 16MHz 80386 with a whopping 8MiB RAM. By the time the poor thing grinds out a useable vanilla kernel, your latest generation system is starting its third bout of "make world".
It's called perspective... not everybody can track the latest revision of every hardware component. Some systems actually have uptimes higher than your IQ. (Hmm, was that last bit an insult? better think about it...)
-castlan
Except generic code that runs on any i386-i686 is going to be less optimizable and more verbose than code that runs only on i486-i686.
386 lacks certain instructions (e.g. cmpxchg); the compiler's not going to do a CPU check every time such an instruction will be useful, it'll just choose a solution that works everywhere, and you can be sure code that's good for a 16MHz 80386 that's just pulled the series out of 16bit hell is not going to be good for a 1600MHz Pentium 4 that doesn't even impliment the instruction set natively.
Besides which, anyone running i386 level hardware is hardly going to be interested in any of the new stuff in 5.0; they're probably still running 2.x, 3.x or maybe 4.x.
> Come back up immediately after an unclean shutdown, but have a background task sucking up IO bandwidth for an hour or three.
FFS fsck's quite fast, actually. As for sucking up IO; background fsck can be ran at a higher nice value.
IO operations for niced tasks are reduced in favour of other tasks competing for IO; so, you *could* have fsck running for hours if your system's doing a lot of IO and fsck is running at a nice of +20, but you're unlikely to notice it on anything but an accurate IO benchmark.
See Running "fsck" in the Background, section 7.
Sigh, at least get the name right, even if you have no id ea how the technology works.
-sirket