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:

• ftp://ftp2.FreeBSD.org/pub/FreeBSD/
• ftp://ftp5.FreeBSD.org/pub/FreeBSD/
• ftp://ftp.au.freebsd.org/pub/FreeBSD/
• ftp://ftp.uk.FreeBSD.org/pub/FreeBSD/
• ftp://ftp.dk.FreeBSD.org/pub/FreeBSD/

Comments

Freebsd 5.0 DP1

[Jeff Probst]

Do any of the linux distros have a beta release program as excellent as FreeBSD's?

Re:Freebsd 5.0 DP1

[BRTB]

Well, at any time you want you can download a snapshot of Slackware's current tree, which is the development happening in realtime... probably can't get any faster beta releases then that ;)

background fsck

[mjed]

Sounds interesting, but fsck isn't something you should run in the background. I mean, do you really want to be writing to the disk at the same time you're checking for errors? Maybe it's just my parinoia. If the developers pull this off safely and with no or barely any noticable slowdown, my hat is off to them.

Re:background fsck

[ChadN]

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)

Re:background fsck

[Aniquel]

To quote: "fsck(8) now has support for foreground (-F) and background (-B) checks. Traditionally, fsck(8) is invoked before the filesystems are mounted and all checks are done to completion at that time. If background checking is available, fsck(8) is invoked twice. It is first invoked at the traditional time, before the filesystems are mounted, with the -F flag to do checking on all the filesystems that cannot do background checking. It is then invoked a second time, after the system has completed going multiuser, with the -B flag to do checking on all the filesystems that can do background checking. Unlike the foreground checking, the background checking is started asynchronously so that other system activity can proceed even on the filesystems that are being checked. Boot-time enabling of this feature is controlled by the background_fsck option in rc.conf(5)."

Re:background fsck

[mosch]

Sounds to me like you don't understand how the BSD filesystem works. While Linux has started implementing journaling filesystems in order to get better recoverability, BSD used a different technique. It shifts the filesystem from valid state to valid state, in a manner where the only error that can occur due to a crash is a harmless wasted inode, wasting a little disk space. This can be cleaned up with a fsck.

Because the only error that can exist on a UFS filesystem with SoftUpdates enabled is this wasted space, there's no problem running the fsck as a background process.

Re:background fsck

[Fweeky]

> 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.

Dropping 80386 from default kernel: Good Idea

[finite_automaton]

I would say that it is about time that both *BSD and Linux look at dropping support for 80386 chips from the default kernel.

From the FreeBSB-5.0/DP1 release notes:

Support for the 80386 processor has been removed from the GENERIC kernel, as this code seriously pessimizes performance on other IA32 processors. The I386_CPU kernel option to support the 80386 processor is now mutually exclusive with support for other IA32 processors; this should slightly improve performance on the 80386 due to the elimination of runtime processor type checks.

Supporting 386 chips is a good idea, but it should not be the default. I would like to be certain that the kernel that I build is taking advatage of the new features that my processor offers.

Re:Dropping 80386 from default kernel: Good Idea

[castlan]

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

Re:Dropping 80386 from default kernel: Good Idea

[Fweeky]

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.

Re:Dropping 80386 from default kernel: Good Idea

[realdpk]

Almost nobody should be using the GENERIC kernel by default anyways. The only reason to do that is if you don't understand the kernel config file (which is, admittedly, not an easy thing to grasp for newbies).

The GENERIC kernel ought to boot just about everything, IMO, simply because it is "generic".

Re:This is shamelssly offtopic, but....

[questionlp]

Actually... the tension is between NetBSD and OpenBSD. Theo deRaadt "forked" the NetBSD code and created OpenBSD. I used to have a link that discusses the reasons for the split as well as some comments made by Theo.

As far as I know of... there isn't any noticeable tension between OpenBSD and FreeBSD... but of course, I don't pay attention to the politics; I just use what is best for each situation.

Re:This is shamelssly offtopic, but....

[jeffy124]

the story told to my OS class was that Theo for whatever reason split from either Free or NetBSD to OpenBSD. For a while, the two were pretty much the same. Then someone r00t3d Theo's machine. Thus OpenBSD took on the task of being the most secure OS out there, and I think they've done a pretty good job, particularly in their development practices that encourage finding bugs and getting things right the first time.

FFS Snapshots?

[adolf]

Anyone know how the snapshot feature is supposed to work, or have any experiences with it that they'd like to relay?

It sounds similar, if not identical, to what an ISP of mine used around 1994-1995 (and perhaps still do). They had a NetApps filer for their users' home directories, which provided a few .snapshot directories.

Inside of .snapshot were the ghosts of ~ past. Which was -very- nice when you changed or deleted something and then change your mind about it hours, days, or weeks later. One could go back in time, and retrieve any of several periodic revisions of anything which had been modified.

Incidentally, the aforementioned shell box was also running FreeBSD, although a much earlier incarnation than that being discussed here.

Re:This is shamelssly offtopic, but....

[Tuzanor]

Theo was the maintainter of NetBSDs SPARC port. For whatever reason, (it really depends who you ask. NetBSD guys says Theo was a dick, the people who sided with Theo say that one guy had a problem with him and blew everything way out of proportion) Theo was kicked out. Later Theo grabbed what he could of NetBSD and forked it into OpenBSD.

You are right on Theo getting rooted. This sufficiently propelled the OpenBSD team into the security first approach that has made them so famous.

Re:Almost there, buddy

[Tuzanor]

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.

Re:This is shamelssly offtopic, but....

[Tuzanor]

OpenBSD doesn't support SMP for security reasons and for reasons of simple practicality. Most users of OpenBSD use it for firewalling and such. No need for SMP there. If you really need to crunch seti@home that badly, then by all means use free or linux.

Re:This is shamelssly offtopic, but....

[castlan]

Right, it wasn't Tara, but IPF. OpenBSD didn't end up killing Tara...er, IPF, but disowning it. But that was mostly IPFs fault. So then IPFs twin sister PF showed up claiming to be the rightful heiress to the OpenBSD fortunes, and now IPF is forced to hang around the FreeBSD family much more then ever, which is making their local firewall jealous.

Then in a big suprise, IPF comes back from her romping aroung NetBSD, FreeBSD and the red-light district of commercial Unix to deliver a bastard child... er, fork, of OpenBSD 3.0, and the Twin Suns of OpenBSD are silently duking it out through their invisible firewalls with divergent syntax. FreeBSD slips SMP into NetBSDs drink, and then, stay tuned for next weeks episode of "As Make World Tunes"...

I think this post clearly indicates that it is my bedtime. Theo vs. NetBSD's remainder is old dead news. IPF wasn't as "Free (libre)" as the BSD community had assumed, and when Mr. IPF held this over Theo deGUUYs's head, deGUUY had a schitzoid reaction and hacked it out of OBSD. The remainder of the BSD community has more important things to worry about, OBSD embraced and extended a Free IPF alternative in time for the 3.0 release, and again OpenBSD has taken the high road.

Theo is an unfairly maligned jerk who maintains a Free OS with uncompromizing values, where NetBSD and FreeBSD don't mind "bending the(ir) rules" now and then. He is most definitely not a software visionary, who rather believes that a 30 year old security model is the best choice for today's global internetwork of secure systems - because that way there are no surprises. The FreeBSD guys are hardworking arbitrary freeware oligarcho-capitalist volunteers just trying to keep thier releases regular.

Darren Reed helped OpenBSD become what it is today, just as Theo de Raadt helped NetBSD become what it was, but both groups parted ways. IPF feels like a second class citizen without OpenBSD, so Mr Reed forked his own openbsd30.ipfilter.org, but IPF plays nice with most Unices. PF is now the OBSD Chosen One. Soap Operas should be criminalized. Support FreeBSD; but pay for OpenBSD, for when the shit hits the fan. Better safe than sorry, better secure than friendly. Computers don't need hugs. Oh, and Soap Operas need to be outlawed. Not to mention criminalized. Save Tara - she's a hottie.

Re:gcc 3.x

[Fweeky]

> so FreeBSD 5.0 won't be using gcc3?

It will. It's just in it's own branch at the moment while everything's adapted to gcc3's new warnings stuff, IA-64 and the other new architectures gcc3 is needed for (IA-64, etc).

Threads

[teambpsi]

"The kernel is now aware of the concept that there are smaller units of scheduling than a process (but only one thread per process is allowed at this time)."

The one feature I've been waiting for the most isn't quite there -- kernel-land threads.

Still though, I'd rather have it right than 'ready'.

besides, I'm relieved that I can continue to listen to my euro trance shoutcast stream uninterrupted by ISO image downloads ;)

Re:Threads

[shlong]

The one feature I've been waiting for the most isn't quite there -- kernel-land threads.

I'm not sure what you mean here. Threads that exist entirely in the kernel have existed for some time now. If you're talking about kernel-scheduled userland threads, then yes, they are not quite there yet. Note that this is different than linux threads, which are just forked processes that happen to share the same address space. FreeBSD can do that too, and in fact has a 'linux-threads' package.

Re:Threads

[Anonymous Coward]

What he means is: kernel-land threads as opposed to user-land threads. Kernel threads are independently schedulable (the scheduler deals with threads not processes), user threads run in one process and take turns executing within that process's cpu allocation (timeslice) using a library to switch stacks and do partial context switches. User threads are not seen by the kernel and are not independently schedulable by the kernel. I.e. if one user-land thread blocks, none of the user-land threads in that process will run since the kernel only schedules the process, even if these threads are capable of running. Also, within a single process, user-land threads cannot execute in parallel on SMP machines while kernel-land threads can.

Threads that exists in the kernel are probably currently implemented in a way similar to linux's clone and FreeBSD's rfork(): they are probably really processes sharing the kernel address space.

Re:Trollbot?

[fm6]

Hey, I've already died twice. No biggie.

SoftUpdates, Not softwrites

[sirket]

Sigh, at least get the name right, even if you have no id ea how the technology works.

-sirket

Tara and Offtopic

[fm6]

It's pointless to tell Amber Benson to emulate Sarah Geller. They're very different people on many levels. Not the least of which is the difference in body types. Sarah has that underfed look that Hollywood considers mandatory for sex symbols. Amber does not. Not fair, but that's the way it is.

I don't follow your anti-Offtopic argument at all. If you're going to have descriptive upmods and downmods (not an idea I'm in love with, but Rob seems attached to it). then "offtopic" is the most widely applicable one. Even if we didn't have spam, crapfloods, and trolls, "offtopic" would still describe a lot of posts. Every online discussion is subject to topic drift. Our current conversation is a prime example! If a moderator notices this post, it will probably get downmodded as "Offtopic". I have absolutely no problem with that.

Perhaps your dislike of "Offtopic" has to do with the usual concern with "unfair" downmods and consequent loss of Karma. Now, a lot of bad downmods bother me, but I think too many Slashdotters are pathologically obsessed with this issue. Having a clever post be slightly less visible is unfair, but it's not the end of the world. And if you're a reasonably good Slashdot citizen, you have a enough karma to spare for a few downmods now and then.

I can't help but observe that the people who are most vehement and obsessive about "unfair" downmods are the ones with the least to say. They have a few thoughts that they themselves are in love with, and can't understand why most other users are unappreciative. Such folks need to do a little growing up.

Re:What about background defragmentation?

[bmah]

FFS (the filesystem used by the BSDs) is designed not to require defragmenting, not in the sense of Microsoft FAT-type filesystems. (FFS uses different algorithms for laying the data out on disk, which I unfortunately can't explain well enough to be of use.) So it's kind of a non-issue here.

RAM fragmentation: "Fragmentation" is a vastly over-used word in the computer world. As applied to filesystems, it means a suboptimal layout of disk blocks on the disk, therefore requiring lots of seeks to read/write the data blocks. RAM disks are random access, and it generally takes the same amount of time to grab a disk block from a RAM disk no matter where it is. The word "fragmentation" can be applied to memory but in a different context that what you cited.

And it came to pass...

[fm6]

I have this friend. She's extremely attractive, and she has a webcam. She's also a very interesting person. So of course, she gets a ton of email from total strangers.

Funny thing is, she actually reads a lot of it. But she gets very impatient if she gets a long message whose basic point is not terribly obvious. I think she's sort of offended at the assumption that she has an infinite amount of spare time, or at least an amount of spare time equal to that of each of her correspondents multiplied by the total correspondent count.

Her word for lengthy email is "biblical". Rather appropriate.

All of which is my way of saying -- could you boil that down a bit?