Slashdot Mirror
FreeBSD 4.6 Release Delayed
Dan writes "Bruce A. Mah from the FreeBSD Release Engineering team announced that due to some late-breaking issues, 4.6 will be released about a week later than originally planned."
← Back to Stories (view on slashdot.org)
Haven't you editors heard yet? BSD is dying! Get with the program and post another Linux 2.5 patch level increment announcement. Thank you!
Why bother.
Wouldn't it be nice if all software releases were *only* a week late?
I'm sure that having a stable DHCP installation is going to be important to all the cable modem users out there running FreeBSD, so this is clearly A Good Thing.
Well, there goes my weekend. Leave it to Slashdot to be the bearer of bad news.
...oh wait...no FreeBSD? I thought they said no free LSD.
Not exactly fair to claim this as embracing a free BSD base, as OSX is not free, portable, and open-source.
No, but Darwin, on which OSX is based, is free, portable and open-source. Oh, and it's based on a free BSD base (with a Mach microkernel).
More like claiming that Solaris is based on AT&T Unix, which it is.
Yes, MacOSX is based in part on BSDLite 4.4. Some libraries come from NetBSD, while most of he utilities stem from FreeBSD. BSD's contribution to MacOSX But MacOSX/Darwin is also based on Mach. Cheerfully adding to the confusion are various projects such as Fink, which aims to port a good deal of linux software to MacOSX. Occasionally, dumb flamewars will sprout up, with one side advocating FreeBSD style ports, etc., and the other advocating a more linux-like style. I guess it depends on what systems you've used before.
Well, right off the top of my head I can think of three that havn't been mentioned: Niksun NetVCR (a really sweet piece of kit), Juniper routers, and the Cybernet NetMAX. LOTS of people with embedded solutions that require a bit more oomph than your normal embedded OS can provide use FreeBSD. From a corporate point of view, the FreeBSD has a very favorable license and a conservative release schedule that helps insure a stable OS for your embedded project. Also, it doesn't hurt that the FreeBSD source tree is in CVS, and you can maintain a branch relativly painlessly without having your proprietary changes merged back in the main branch (although some companies merge their changes anyway, look at vinum).
I read the internet for the articles.
You might not see this if you don't actually look into it. Like, maybe start at that link I provided?
From this discussion of the history of Darwin we read:
andI guess seeing that much of Darwin is based on the 4.4BSD(-lite2) code, then this is "fair enough" for you.
From what I can tell, Mach is a very bare bones kernel here, not providing a process model or networking, etc.
The web page you refer to doesn't make it clear whether Darwin is actually based on BSD, or just an implementation of the BSD process model, filesystem, and other APIs. The GNU system is designed to follow BSD Unix - does that mean that Debian should start appearing in the BSD section of Slashdot?
:-P.
Well there is the mention of 'a customized version of 4.4 BSD-Lite2 kernel'. It's not immediately obvious how to transplant a monolithic kernel to run on top of Mach, but I guess we should take Apple's word for it that you really are running a BSD system: just one that happens to be hosted on Mach in some way. Maybe the objective test is: would a developer who is familiar with 4.4BSD, or FreeBSD or NetBSD, feel at home hacking the Darwin kernel?
Could anyone who knows more about this stuff clarify what is happening? I am assuming that JordanH is not _the_ Jordan H.
-- Ed Avis ed@membled.com
I used to work at VERITAS Software. They routinely delayed release dates on products if quality wasn't good enough.
There is a problem with this, though. Customers made business plans based upon planned release dates. When those release dates slipped, the customer's plans were upset. This could leave them in awkward situations because they couldn't do certain things without features present in newer versions of the software. As a consequence, we always dreaded a slipping of the release date because it would provoke great annoyance from the customers.
Customers want it right and on-time. If they have to pick between those two, they will select to have it right, but will not be happy about it!
Don't be daft. Actually read about the OS-X design before talking about it! The Mach microkernel is not a full kernel in the sense that Linux is. It provides a minimum of functionality. It requires external servers to provide much of the traditional functionality of a kernel. In OS-X (as in NeXT) the external server takes the form of a monolithic BSD system server. In other words, a standard BSD monolithic kernel is altered to run as a server on top of Mach. Unlike most microkernels, OS-X puts its system server in kernel space, which eliminates many benifets of the microkernel design (ie. better protection between kernel components). In OS X, the BSD system server is based on a customized 4.4BSD-lite2 kernel with many parts (like the whole networking infrastructure) thrown in from various BSD OSs, primarly FreeBSD 3.2. In OS-X 10.2, this kernel adopts a bunch of code from FreeBSD 4.4. To satisfy your curiousity, here's the dirt from Apple itself: http://developer.apple.com/darwin/history.html. Read the WHOLE thing. I'm not going to tell your where in the page it is, because reading is good for you.
A deep unwavering belief is a sure sign you're missing something...
I honestly don't see how the installation program is difficult to use. I have heard many people complain about it, but it's not hard to use at all. Of course I haven't used any recent Linux installers (last Linux I used was Slackware 7) with all the dumbed-down GUI luvin', but I still fail to see how a straightforward ANSI menu system is confusing and difficult?!
Well, don't take our word for it. Read here why Jordan Hubbard thinks it sucks - and he wrote it. (Section 2.2 describes sysinstall.) A select quote:
It also describes various reasons the ports system sucks, though "hard to use" isn't on my list. My major complaint with it is that the "base system" isn't packaged. With a RedHat system it is, and you can really take advantage of this. For example, when doing a security audit, boot from external media, check the GPG signatures in the package database, do a "rpm -Va", and make sure nothing extra is in suspicous places. ("rpm -qal" to get a list of what should be there, a "find" command to get what actually is.) You then know no binaries have been tampered with. With a BSD system, you pretty need to reinstall.
There are legitimate reasons to dislike these systems. It's all about weighing the choices - some new FreeBSD 5.0 features (KSEs in particular) sound interesting enough that I might switch a system or two back to BSD when it's released.
Oh sure, the ports system may be easy and all. Thing is, I have found a whole new level of respect for the Linux world of RPM's here. Normally a FreeBSD user, I went and slapped Suse 7.3 on a friend's laptop machine.
Suse's install is very sweet. Worked just like all those generic reviews out there said it would. Oh GOD, then I got the stupid notion in my head that I'd go in and update software! Nothing could have made me regret not going with FreeBSD more.
First off, pulled down the Mozilla RPM from Suse's site. Oh sure, it installs and all. After that, Mozilla comes up with a lovely blank screen!
The real beauty was trying to upgrade Gnome from Suse's RPM's. Can't install gnome-control without xscreensaver, which won't install without a couple of packages I've never heard of. Apparently gnome-core needs Sawfish installed... and of course Sawfish needs gnome-core. Weee!
I'm quite certain there's some kind of funky command line switch I'm going to need to extract from the overly verbose RPM man page. On FreeBSD I never have to deal with this crap. Every port and package has pretty much worked out all the dependency issues for me. Especially critical for something like Gnome which has dependencies that read like a Mormon's family tree (no, that is not a slam on Mormons. Geeesh).
Tell ya what though, for those folks who have been able to make use of RPM on a regular basis I have a new found respect. Anyone who can manage to get through "libobscure.so.12 not found" and still keep a system running is far smarter about this stuff than I am. This dumb FreeBSD user is humbled.
The line must be drawn here. This far. No further.
Not that this changes the argument about commercial contributions back to the OS, but to provide a non-rhetorical answer to what I presume was a rhetorical question:
The kernel support for USB is typically in sys/dev/usb in the source tree. (That's where it is on my FreeBSD 3.4 system; no, that's not a typo for "FreeBSD 4.3".) There may also be user-mode daemons or library routines there as well.
Here's a FreeBSD FireWire implementation under development; the most recent tarball came out 2002-05-30. I don't know what projects, if any, exist for NetBSD or OpenBSD.