Slashdot Mirror
FreeBSD 4.8-RELEASE Status Update
Dan writes "FreeBSD Release Engineering Team's Bruce Mah provides the latest status of what's holding up the official release of FreeBSD 4.8. We fully support FreeBSD RE's approach to fixing necessary problems before officially releasing the product."
I kinda like this. Basically, the release is held up because the needed files don't fit on a floppy.
Rather than just reformat the floppy as a 1.722MB, they'd rather just get everything fitting onto a 1.44MB. Kudos to you, FreeBSD team!
There is no reasonable defense against an idiot with an agenda
:wq
FreeBSD Release Engineering Team's Bruce Mah provides the latest status of what's holding up the official release of FreeBSD 4.8. Our take: we fully support FreeBSD RE's approach to fixing necessary problems before officially releasing the product. Thanks mezz, our forums moderator for the newstip.
[Read full announcement]
Date: Wed, 2 Apr 2003 16:23:25 -0800
From: "Bruce A. Mah"
To: freebsd-stable@freebsd.org
Subject: 4.8-RELEASE status
Hi--
A number of you have been (rightfully) wondering what's up with
the i386 4.8-RELEASE. Here's the current state:
The files that are as of this moment tagged as RELENG_4_8_0_RELEASE
can't be used to build a release because the MFSROOT kernel (that goes
on the kern.flp) overflows a the size of a 1440K floppy disk.
This bug was masked by another problem that happened to be present on
the machines used by the RE team to build releases...namely, that they
didn't have the cvsroot-all collection in their local repositories.
To make a long story short, the $FreeBSD$ tags didn't get expanded in
the source files, thus (I am not making this up) causing the MFSROOT
kernel to be just a *little* bit smaller so that it could fit on a
floppy. I think this was the world's April Fool's joke to the RE
team.
We're currently trying to fix this by finding some other driver we can
move to a module on the mfsroot.flp image (or maybe just eliminate).
After we finish some tests, we'll need to commit whatever change is
required, re-tag the affected files, and then rebuild the base system.
I'm not in a position to comment on a timeline for these happenings.
Thanks for your continued patience!
Bruce.
PS. This may sound rude, for which I apologize in advance: The less
time that the RE team has to spend replying to various emails
(particularly those that are not relevant to the immediate goal of
shipping 4.8-RELEASE), the faster the release is probably going to be
finished.
hmm
It is also reported that in some situations, Linux binaries perform better on FreeBSD than they do under Linux.
Why yes, it does. =)
It also depends if you have a cd burner... since I have one I download the smallest cd iso for freebsd and do a very basic install and then add to that...
Only 'flamers' flame!
Although floppies are antiquated, but there are still machines that will not boot off of bootable CDs and require a boot floppy (I have several Toshiba laptops that just will not boot from CD no matter what setting is used or how the ISO is burned)... but it's also useful to get a machine booted to either do a re-install or install from an FTP or an NFS server.
Anyway, most bootable CDs use floppy images (be it 1.44MB or 2.88MB) as the boot section of the CD... primarily for legacy/compatibility purposes. With that, you still have to deal with the size limitation of either 1.44MB or 2.88MB.
This is good slashdot fodder, but the issue has been resolved. The awi driver (wireless prism card) is being removed from the floppy and the space problem is solved. Move along nothing to see here...
Also, most manufacturers systems with their own BIOS (alas Toshiba etc) don't follow the El Torito standard (I think only Award and AMI does infact!), so they can't actually boot from a CD where the first image file isn't 1.44Mb; despite the FACT that the El Torito standard CLEARLY STATES that it MUST support 2.88Mb images also.
So, for people to be able to boot from CD's on non-Award and AMI BIOS motherboards, the floppy image must fit in 1.44Mb.
This is why I will never buy a fricking PC again, I'm sticking with Mac's and Sun UltraSPARC machines from now.
The various CD's you buy are generally identical to the ISOs you download. If you want to support the project, it is recommended you buy from one of the vendors who supports the project. I have subscriptions with both FreeBSD Mall and BSD Mall (Part of Daemonnews).
Other options are listed in the Handbook.
I definatly recommend downloading rather then buying from people like cheapbytes.
-- Brooks
-- Any statement of the form "X is the one, true Y" is FALSE.
Or even more importantly:
Does it run VMware 3.x or the about-to-be-released 4.x?
I didn't think so. Sorry, I'll stick with Linux even though I feel many things in FreeBSD are coded better.
Seriously, now that the nVidia drivers are ported (sorta; not up to date though) the only reason I don't use FreeBSD is because of VMware. And yes, I know 2.x works, but that version is missing too many things that I need.
In other words, 5.0 is not production-ready, although it is a complete release. It's still being actively debugged and stabilized in preperation for 5.1, which will probably be the first in the series that I'd put on a production server. The 4.x line is incredibly stable and still being actively maintained in the mean time.
Dewey, what part of this looks like authorities should be involved?
bzip may make smaller files, but takes more cpu power and more memory than gzip. That is why they don't change.
ah my dreams are foiled.. pf in a bsd distro that people "support"
Soon maybe
Oh, they're definitely principles worth sticking to.
I don't put CD-ROMs in the servers I build. It's stupid, why would they need CD-ROMs? I just install a floppy drive, because it needs one of those regardless (hardware bios updates, emergency recovery, etc.).
I boot off the install floppies and install via FTP (takes LESS time than via CD when doing so on a T3).
The floppies are extremely important. Many shops rely on them.
Andy
Here's a good way to screw with your brain.
/etc/inetd.conf using that binary
/etc/inetd.conf rather than the actual file. The worst part is that editing /etc/services DID change the real (system-level) file, so mangling stuff in there would make inetd stop listening, while changing the inetd.conf didn't.
1. Install FreeBSD with Linux compatibility layer
2. Bring over a Linux binary of your favorite editor
3. Edit
4. Whack inetd with a HUP
5. Wonder why the ports are still open
It took me a good while to figure out that the damned thing was opening some compatibility version of the