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?
Click here or here.
A lot of companies prefer *BSD to avoid a lot of complications of the GPL.
He summed it up well.
Good to see how the quality of the release takes precedence over any deadlines. That's the way it should be. I'd rather have FreeBSD 4.6 a month late than have a buggy one now.
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.
Uhm, there's some little company, I think its called... Apple? :)
loply.com
Not exactly fair to claim this as embracing a free BSD base, as OSX is not free, portable, and open-source. This is like claiming MS-DOS is based on Unix because it has files and directories.
Click here or here.
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.
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.
My question, again, is who?
Click here or here.
Or you could just install the portupgrade port (from /usr/ports/sysutils/portupgrade), and use "portinstall program" or "portupgrade program" as appropriate. Even easier. (And, yes, "portupgrade portupgrade" works. :-)
This is one of the many reasons why I prefer OpenBSD to FreeBSD. OpenBSD is ALWAYS due either December 1st or June 1st. Now, today would've been the official release date of OpenBSD 3.1, but it was officially released 2 weeks ago!! This is the only big project I can think of that does not delay its release. Linux 2.4 was late by a year, FreeBSD 4.5 was late by a couple of weeks, 4.6 will be late by at least one week, FreeBSD 5.0 was delayed by 14 months, etc. The thing with OpenBSD: they don't do revolutionnary released like Microsoft. Each new version contains many security and bug fuxes, new application, new hardwares code and a couple of new features (e.g: openssh, pf, pfauth). Maybe some other projects should take example, not only on OpenBSD's commitement for security, but also its commitement to respect release schedule.
Yeah, I read about that in the paper this morning (I had breakfast in Multnomah County, so it's sort of a local issue). I was quite surprised that it wasn't on Slashdot yet. Maybe I should submit it again, and see if they'll take mine?
Looks like the New York Times is blocking your redirect there. Here's The Oregonian's article.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
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!
OpenBSD has good commercial support, due to the support of the hardware crypto folks.
Of course, being security companies, they don't talk much about it.
I believe the Nokia/Checkpoint platform is BSD based...
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.
Compaq sells hardware to Yahoo, which is a
FreeBSD shop.
The Nokia Firewall-1 implementation is based on
a modified FreeBSD.
IBM's InterJet router-toaster is based on FreeBSD.
Ben "You have your mind on computers, it seems."
Was rated +4 for me... Then again, I set up slashdot to +2 upvotes but only -1 downvotes.
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.
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.)
Okay, exactly what BSD have you used? The initial install of FreeBSD is ALL packages. If you never go about upgrading from what is released, you never even have to install the ports tree!
Don't have a package? Make one! Every port can be built into a package to distribute to other machines in a binary form.
As to doing a security audit, there's probably many better ways to do it, but the first thing that comes to mind are the portupgrade utilities, which comes with a pkgdb script. This runs through what is in the ports tree, what things depend on, and compares to what is actually installed.
Lastly, to address your issue with the "base system" not being packaged, that too is dead wrong. There are regular binary package snapshots created of the STABLE tree. It's just one heck of a lot easier, and more up to date, to cvsup the latest tree and compile.
You then know no binaries have been tampered with. With a BSD system, you pretty need to reinstall.
This is either FUD or ignorance. If you're dead serious about knowing whether or not files have been tampered with you wouldn't even consider RPM as your first line of defense. You'd be scripting your own MD5 summaries, or running something like TripWire.
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.
OpenBSD a long time ago, FreeBSD fairly recently. (Upgraded until about 4.4.)
The initial install of FreeBSD is ALL packages. [...] Lastly, to address your issue with the "base system" not being packaged, that too is dead wrong. There are regular binary package snapshots created of the STABLE tree.
This does not match my experience. A "pkg_info -a" would not show the base system. On RedHat, it certainly does - divided up into many different RPMs as appropriate.
I particularly noticed that it's divided up into many different RPMs because this is important. For example, I really don't like sendmail. It's nice to completely remove it from the system with a simple "rpm -e sendmail". (As to why I don't like it, look through my older postings here.)
Let me give another reason package management is useful. If you use the RedHat Network (or similar things), you will get an email notification whenever a security advisory applies to your system. No false alarms and you always get the notification, if the relevant stuff is an official RedHat package. (So you just need to watch anything you don't get from RedHat, and there's surprisingly little in that category.) Another of the many reasons why it is useful to have an accurate inventory of your system.
Don't have a package? Make one! Every port can be built into a package to distribute to other machines in a binary form.
True, I've never had a problem getting a package from a port. And I think it's not hard to make a port from plain source, either. I never said otherwise. I've done analogous things with .src.rpms on RedHat.
This is either FUD or ignorance. If you're dead serious about knowing whether or not files have been tampered with you wouldn't even consider RPM as your first line of defense. You'd be scripting your own MD5 summaries, or running something like TripWire.
You are very dismissive, yet give no reasons for believing these methods are superior. RPMs are signed with GPG signatures and come with MD5 signatures for each file (as well as much other metainformation). It is updated whenever you update the packages. TripWire, IIRC, just makes comparisons against arbitrary points in time, with no knowledge if the changes are authorized.
Also, your use of the phrase "first line of defense" is completely inappropriate. Prevention is the first line of defense. Checking if your system has been compromised is not. If it is, you are doing something horribly, horribly wrong.
So really, if, for some inexplicable reason, you don't like ports and want to use RPMs with FreeBSD, you can do that :)
And how is this database maintained? A simple script that makes checksums nightly and compares them to the current files? (As stock FreeBSD does for setuid binaries.) Then if someone is determined, (s)he could just change the checksum as well. It sounds like you are depending on security through obscurity - no one knows your checksum system is there, so no one would do that.
In contrast, the RPM way includes a GPG signature with every package. The checksums are signed. If you make your own RPMs, you can do so on your testing system, with a private key not stored on the machine you are checking. Then you know the database is trustworthy.
Why would your way be superior? I've shown one way it might not even be as good. Even if you've avoided that pitfall (sending the checksums somewhere else, perhaps), there's the problem of knowing if the changes are authorized or not - with a RPM, updating the package and the checksum always happens at once. With something like TripWire, you have to remember and/or tell other admins you changed this package. There are surely other pitfalls I can't think of now.
Any lack pf super high-level automation is not a disadvantage, it's traditional systems administration.
It is indeed traditional systems administration. However, I find it to be a disadvantage compared to RPM. Rejecting things because they are not traditional is dumb. Please explain to me why your way is better, if you can.
Yes, it is really tiring that EVERY BSD article is flamed by the exact same stupid responses. Yes Linux does have a larger support group, and it was more user friendly at an earlier stage, but that doesn't mean it is worth less as an OS. No matter what anyone thinks of any operating system, I am going to use whatever I think works best and most efficiently for ME on my machine. Currently that is FreeBSD. If a major OS release comes out on the x86 platform, I usually give it a go. Ignorance will never help, it might only stop me from finding something I find valuable.
Saying your OS is the best because more people use it is like saying MacDonalds make the best food
By "ports" do you mean "stuff in the {Free,Net,Open}BSD ports collections"? If so, have you surveyed, for example, all ~7000 FreeBSD ports to see what licenses they have, and determined that most of them are not GPLed (much less that most of them use the BSDL)?
If by "fBSD" you mean "FreeBSD", it doesn't have its own C compiler - or linker, or assembler; it uses GCC, GLD, and GAS. Take a look at /usr/src/gnu.
The following is by !me:
There once was a troll found on slashdot
Whose posts made him seem like a crackpot
Something's wrong with his head
Screaming BSD's dead
Thanks to Darwin it's just hit the jackpot
Computer Science is no more about computers than astronomy is about telescopes. --E. W. Dijkstra
If by that assertion you mean that the changes to the ported applications are BSD-licensed, then, even if true, it's not a very interesting assertion - the applications in question are still GPLed.
On BSD, cc is gcc:
Two names, same program.
So? That's make, not the compiler.
Which, as noted, is the GNU C Compiler, even if the command name used to invoke it is cc, not gcc.
I'm quite aware that there are plenty of BSDLed projects; I'm just noting that the C compiler that comes with BSD isn't one of them.
But if you weren't busy on Slashdot being yet another worthless stupid brainless monkey, and actually had a brain to use and bothered using it, you could have figured that out.
Correct. Just because BSD happens to have cc as one of the names for the GNU C Compiler doesn't mean that it's some compiler other than GCC. As you will discover if you actually bother looking at the source that generates the C compiler on BSD, it is GCC.
You are incorrect in your mistaken belief that I've been making some assumption that the C compiler on a system is called gcc; my makefiles use $(CC).