> Hallo Wolfram,
I got cc'd on this somehow, I'm not sure how, but what the heck - I'll
respond anyway. ;-)
I'm also going to respond in english since to do so in German would
take me about 3 times as long (at least) so I hope you don't mind my
replying in a language different than that of the original article.
> ein Kollege hat sich neulich FreeBSD von der TU via ftp gezogen und war
> ziemlich sauer, da das Zeug nicht lauffaehig ist. Im Gegensatz zu Linux
> (CD rein und schon geht's los) scheint FreeBSD (und wahrscheinlich auch
Well, I'm not sure if that's an entirely fair comparison for several
1. If you try and build a Linux release on CDROM you will also
find it interesting going, especially if you're going for
one of the newer platforms like Linux/ALPHA, for which it's
impossible to even rebuild a working kernel with the sources
supplied - the RedHat people do NOT distribute the same bits on CD
that they use to build their own releases, using rather special
magic versions of various include files and such to actually do it.
I know this because I've tried making my own release and I've asked
the Red Hat people about it directly (who admit to this lack of
sync) and I even got Patrick Volkerding (the creator of Slackware
Linux) to try and do it on my box, in case it takes some special
expertise' which I lack, and he failed too. So please don't hold
Linux up as any kind of good example because it is, in fact, a very
BAD example of software engineering. :-)
2. If you had tried one of the FreeBSD CDROMs which I produce for
Walnut Creek CDROM, I am sure that it would have also been a
simple "rein und schon geht's los" affair. I understand the
specific aspects of FreeBSD CDROM release building and I've taken
special steps to make it a more seamless installation than it would
be if you just copied the FTP archive onto it. The Linux folk do
exactly the same thing, and it's not surprising when you consider
how different a CD installation vs a suck-the-bits-down-over-a-slow-link
is; you need to make different trade-offs so that the user is only
xferring the bits they want in the latter case.
Furthermore, the tools/ directory (which is freely available at
ftp.freebsd.org) is not included as part of the release because we
don't like to have binaries checked into our source tree, preferring
instead to build them from the sources themselves, and in the case of
the DOS utilities (like fdimage.exe) we obviously have no way of doing
that, at least not until gcc -dos works under FreeBSD ;-). Therefore,
they're simply collected together at the FTP site and I copy them by
hand onto every CDROM. It's not ideal, no, but then neither would
having lots of uuencoded DOS binaries in our source tree.
> NetBSD/OpenBSD) kein Interesse an einer grossen User-Gemeinde zu haben,
> denn ansonsten wuerde man sich da wohl mehr Muehe geben:
> sitzt) und brannte alles auf eine CD in ein Unterverzeichnis
> "FreeBSD-2.2.1" und nahm diese CD mit nach Hause.
Second mistake - you need to put everything at the top level,
including a cdrom.inf file. In my own defense here, I must say that
this much is indeed automated by the release process, and if your
friend had done a "proper" release he would have gotten a directory
called <builddir>/R/cdrom at the end, containing the two
subdirectories "disc1" and "disc2" (for the two FreeBSD CDs)
and with everything properly organized.
An operating system is a complex instrument, like an automobile, and
you can no more expect to throw a subdirectory on a CD and have it
just work than you can expect to toss a couple of bicycle tires onto a
bedframe, along with a lawnmower engine, and take the results out on
the Autobahn. :-)
> script mit dieser Antwort nicht einverstanden, denn es gehauptete
> steif und fest, auf der CD waere kein FreeBSD. (Doppel-Grumpf @#^&@^*)
> Auch dieser Versuch scheiterte: Angeblich kam FreeBSD nicht auf die
> zweite Partition seiner Platte. (Quadrupel-Grumpf @#^&@^*)
Why not? Can you be a little bit more detailed? That should have
worked well enough - I do it here all the time.
> Partition. Und siehe da: Endlich liess sich FreeBSD installieren.
> (Heureka!) Ist es nicht schade, dass man sich aber erst seine Platte
> in zerpartitionieren muss, um FreeBSD zu installieren?
It's normally not even necessary - I have test machines here with 2
and 3 drives, and I've installed FreeBSD in many odd locations on all
of them. I'd like to know a little more about how this failed for
your friend - perhaps he had the 2nd partition somewhere after cyl
1024? Neither FreeBSD nor Linux or anything else for that matter can
cope with that situation since it's PC hardware braindamage in the way
there. There are some limitations imposed by the PC itself and you
have to respect them if you want to get a successful install out of
any OS on it.
> ketzerisch gefragt: Will die BSD-Gemeinde sich mit solchen Torturen
> die nicht-Unix-Freaks vom Leibe halten? Ich muss zumindest meinem
> Kollegen Recht geben: Mit solch einer Installation schreckt man (fast)
> jeden Nutzer ab!
Well, you seem to have had an expecially bad experience, about 75% of
which your fault for trying to do things the wrong way (and asking for
installation from more carefully prepared, "official" installation
media is hardly too much to ask - you tried to do it yourself and you
did it wrong, no big deal but still unfair to blame us for it :-) and
perhaps 25% our fault for whatever issue kept you from being able to
install from your DOS partition to the 2nd partition, assuming that it
was indeed entirely below cylinder 1024 (or you at least were careful
to allocate the root fs in that portion of it which started and ended
below 1024). As I said, I'd like to know more details.
We take the installation very seriously in FreeBSD and we are not at
all interested in producing something which is hard for new users to
come to grips with. We know that our current installation is far from
perfect in that respect, and work on an entirely new one with a better
fundamental design is now underway, but we've still had pretty good
luck with a *lot* of installations and most new users have good things
to say about it, so your experience is fortunately not all that
And a P.S. to your P.S.
> *BSD nieder macht. Es sollte also - wie es in jeder Software-
> Firma ueblich ist - vor einem Release eine "Abnahme" durch eine
> Qualitaetssicherungs-Gruppe erfolgen, die das Produkt in jeder
> moeglichen Variante auf jungfraeulichen Rechnern installiert und
> testet. Nur so kann man eine gleichbleibende Qualitaet sichern
> und die genannten Probleme verhindern.
That's the ideal, yes, and something it's not hard to do in a true
Software company with a budget for buying hardware, hiring testers
(and testing is a lot of hard, thankless work so paying people to do
it really helps), putting people on the phone to take customer bug
reports and follow them up with the testing dept, etc.
We're not a real software company and we have no budget, however, so
this has to happen with entirely volunteer labor and sometimes that
labor doesn't do a very good job. In the case of 2.2.1 in particular,
there was a ALPHA-BETA-GAMMA period of over ** 4 months **, during
which everyone was strongly urged to test the product and report bugs,
and indeed some folks did (and I cannot thank them enough). However,
do you want to know when I got my greatest number of bug reports? A
week after 2.2.1 was out. Yep. Most people just don't want to run
anything except for the *release* and they wouldn't test a pre-release
if I sent them a CDROM with a $5 bill wrapped around it. They just
can't be bothered and so this whole "Qualitaetssicherungs-Gruppe"
concept is really not much more than a fond dream for us. It would
be nice, but...
Received on Fri 04 Apr 1997 - 19:46:18 CEST