Re: The 6.3. FreeBSD Install sucks a lot



Begin <fpejn3$or3$1@xxxxxxxxxxxxxxxxxxxxxxxx>
On Tue, 19 Feb 2008 12:57:07 +0000 (UTC),
Michel Talon <talon@xxxxxxxxxxxxxxxx> wrote:
jpd <read_the_sig@xxxxxxxxxxxxxxxxxxxxxx> wrote:
The installer, in that respect, does what an installer is expected
to do, even if inefficiently in extreme cases. It allows me choices
even if some choices aren't good ideas and/or could stand improvement.
Personally, I've had to use worse, much worse.

The standard now seems to be a cdrom booting to a live system, and then
an installer benefiting from all the goodies coming with a full system.

This is a relatively recent thing, if you can think of, say, half a
decade as recent. I'd like to note that it was made possible by having
sufficient memory to ``waste'' a large chunk on memory fses.

To put that into perspective, compare the tricks involving moving root
around (temporary root in swap, and so on) for severely memory limited
systems.

Now, there is a point in having the memory and so why not use it, but
such is mighty inconvenient if the memory is not available and it is
needed. Such gives rise to the same sort of problems as the OP was
ranting about, except coming from an entirely different angle.

If the livecd thing is to be added, then doing it in such a way as to
not do away with the previous solution that works even under severe
constraints would be desirable. Even mandatory, perhaps, to placate
the old gard. If that paints me as old guard, so be it.


[snip!]
Very weak points of the FreeBSD installer are all the stuff about
fdisk and disklabel, which are quite unusable, and worse buggy.

For some reason I've never run into that, so I can't relate much. That
while I started in the middle of the emergence of lba and what have you.
There was a time I could convert various chs formats to suit the present
situation. Now, I've thankfully forgotten all that, except that I had
learned the trick from reading the installation notes of the various
*BSDs.

The main thing I remember is that you have to be careful just what you
ask for, as the prompts can be finnicky and somewhat opaque. Other than
that, ie I usually know what I'm doing, it doesn't give me trouble.


[more snip]
More generally sysinstall is unable to cope with all the modern
features of FreeBSD, geom mirrors, ZFS, etc.

This is definately a point, yes.


However modifications are certainly needed since at present port
developers need to add notes in UPDATING as a band aid to solve some
complex cases which cannot be solved automatically.

I'd like to note that I vastly prefer a system that usually works and
comes with band-aids that explain how to fix the oversights, over
supposedly all-encompassing systems that fail in corner cases and can't
be fixed without recompiling, or even major rewrites. Did I mention that
makefiles are really easy to edit in comparison?

You're right that it might look a bit shoddy and the hoops to be jumped
through might verge on the ridiculous and the jumps could be ungraceful.
But, the important point is that a couple notes in UPDATING is a quick
and easy quick fix that more often does work than the general usage, or
rather, normal failure mode, of some of the other packaging systems I
could mention.

I would say that for its intended audience (ports builders (Hi Kris! if
you're still reading) and anyone else wanting to use the same mechanism)
it works reasonably well given the number of odd cases it has to deal
with. At least IME; maybe Kris has other things to say about it.


Another consideration is the general slowness of this system which is
incompatible with the present situations where you may have currently
1000 ports installed (notably with the new Xorg modularisation).

The new XOrg packages setup arguably strains the system a lot, yes. I
don't know whether the ports framework itself could be meaningfully sped
up, as the bulk of the resources are spent on compiling, not on running
make for the framework.


good upgrade mechanism for the ports system, correctly dealing with
dependencies, gives a building block for a ports installing system in
the installer.

You're confusing correctly with efficiently here. Besides, if you
are installing a new system, there is no point in worrying about
dependencies of already installed packages.

Yes, there is if you want to correctly dispatch the packages on cdroms
and to correctly use the cdroms without constantly exchanging them.

That will be packages you just installed, so you already know the
dependencies on them. What portupgrade has to deal with is with
already installed packages with old dependencies to be replaced by new
dependencies needed for new versions of what was already installed.

If you can't make package distributions (for use on freshly installed
machines) without stale dependencies you might as well give up now.


I note that I have moved to wanting to come up with a running system
and only then worry about installing packages on other systems as well,

Same for me. We all end up doing network installation of ports because
it works really better.

Didn't say I only use network installations. Just that I didn't use
sysinstall for installing packages on a system that I don't know will
boot yet. First I roll out base (and man and a kernel, usually), then I
boot, and only once that succeeds I go wonder what else I might want.


If you cater to the needs of *present* users you may very well deter a
lot of potential *future* users of trying your system.

I can't really bring up the will to care about possible future
uncertainties at the cost of a reasonable status quo. So, if you want to
come up with an improvement, it will have to do everything the current
users like in the current system before trying to attract new ones.

Otherwise, you might as well pack in, or, well, fork a new project and
see if you can't attract those new users. DragonflyBSD, DesktopBSD and
PC-BSD did. I have no insight in how successful they are, but I would
like to note that efforts are probably better spent there than to try
and turn people's heads around here. Unless and until those systems do
come up with a better system that can be adapted and do everything the
users here want in the system, at which time it'll get stolen^Wadapted
for this system.


I think that if someone comes with an obviously better system (not an
easy task), this will convince the first circle of FreeBSD developers
(who are quite critical about the status quo) and the sheep will
follow.

Sure, but those developers also know that if they fsck up it will cost
them lots of sheep. You for one already moved away, if for reasons with
a slightly different background.


--
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.
.



Relevant Pages

  • Re: greetings from FreeBSD DLL Hell!
    ... Packages are built to work with the particular release specified. ... ports are unfrozen, right before release, they start changing again, ... > with cvsup and then installed yet some more stuff, ... end up installing some packages and building others, ...
    (freebsd-questions)
  • Re: greetings from FreeBSD DLL Hell!
    ... Packages are built to work with the particular release specified. ... ports are unfrozen, right before release, they start changing again, ... > with cvsup and then installed yet some more stuff, ... end up installing some packages and building others, ...
    (freebsd-questions)
  • Re: Upgrading to 7.0 - stupid requirements
    ... box down for a whole day while I upgrade ports. ... For example using a chroot so it ... I used the opportunity to clean up my installed packages, ... I chose to compile from ports instead of installing ...
    (freebsd-stable)
  • Re: New
    ... or would CVSup be able to update the userland ports, ... 3rd party software -- ports: ... However, installing pre-compiled ... called 'packages' will often be quicker. ...
    (freebsd-questions)
  • More Fun with Unmet Dependencies
    ... Boots, and loads KDE, and I login. ... It tells me it's "Installing Packages." ... The following packages have unmet dependencies ...
    (Ubuntu)