Fwd: FreeBSD 7.1 Content

[Ian Smith]

On Sun, 7 Sep 2008, Ken Smith wrote:
 > On Sat, 2008-09-06 at 14:51 +1000, Ian Smith wrote:
 > > I just booted off the 7.0 disc1 to check, and /usr/local/bin/links is 
 > > still the default browser in Options, available during installation from 
 > > another vty.  So I was a bit surprised, on rebooting into my so far not
 > > much configured 7.0, to find that it hadn't actually been installed.
 > > 
 > > It's a pretty small package, useful enough to at least read local docs, 
 > > and would be handy installed from disc1 .. and maybe even by bootonly?
 > 
 > I'm actually planning to go in the opposite direction so to speak as far
 > as sysinstall is concerned.  There are a couple projects in the works to
 > replace sysinstall, along with the other nifty projects that roll
 > FreeBSD into "another distro" in Linux-speak.

[Please in FreeBSD-speak, to avoid getting called that?  'derivative'? 
(deriv for short? :)  Anything but what world plus dog will inevitably 
equate to a linux 'distro'.  Sorry, bikeshed topic but it tweaked me ..]

Yes derivative releases (Freesbie, PC-BSD, Desktop BSD) are Good Things, 
and your New Direction below sounds like it should faciliate more such.

 > Basically this is something where one thing can't cater to everyones'
 > needs/tastes/bikeshed-color.  All you need to do is tolerate this thread
 > long enough to reach this message to see that...  :-)

Hope you can handle just one more :)

 > I'm with Scott in that I like the "other distros" being around.  I don't
 > think that necessarily means we shouldn't try harder.  But IMHO trying
 > harder needs to be reflected in a new installer.  Lets face it,
 > sysinstall s*cks...  For the type of folks who want the installer to do
 > more than sysinstall does now sysinstall simply isn't the right tool (no
 > offense intended).

% man sysinstall | tail says it all.  However sysinstall has enough bits 
(modules, really) that don't suck to make its presence still worthy.

The wrappers around fdisk and bsdlabel alone are worth a lot, despite a 
notion that 'real men' figure out cylinder and slice offsets themselves.  
If even those sections were broken out to separate tools, I'd rarely 
need to fire up sysinstall to, for example, partition a new disk/slice.

And sysinstall's frontend to pkg_add is pretty handy, especially for 
noobs, though by the time you're doing an FTP install you have to wade 
through all x,000 packages .. a bit more on this aspect later ..

 > That said I think "I" (as RE) am stuck with sysinstall being around for
 > the forseeable future, even after we get a new installer, because some
 > people are so accustomed to it and it fits their needs (again witness
 > this thread...).  So I do have some plans for sysinstall but as I said
 > above it'll be more towards a different direction than mentioned above.
 > 
 > The path I'm planning is based on these observations:
 > 
 > 	- Many people believe you should just use sysinstall to install
 > 	  the baseline system, and any packages/ports installs should
 > 	  be done post-install.  Its hard to say that point of view is
 > 	  wrong.

Indeed, perhaps it should be enforced by some sort of 'yes we have a 
functioning basic install aboard' flag before allowing postinstall stuff 
at all?  The only times I've ever had problems with sysinstall were when 
trying to do too much - like selecting lots of assorted packages before 
having committing the base install, which can be tempting as it is.

 > 	- The baseline system and the ports are fundamentally different.
 > 	  People should be aware of that from the beginning.

Yes, though any other installer than sysinstall, unless part of the base 
system - and therefore not relying on other languages like ruby, python, 
whatever - might need to install some bits to run?  That is, such a 
separation may sometimes need to be less than religiously enforced?

 > 	- At least some of the packages on the ISOs are stale within a
 > 	  week of release at times; a bit longer than a week in most
 > 	  cases but ...

This is really a separate issue.  While many well-connected folks with 
fast machines tend to advocate updating the ports tree and installing 
all from source, quite validly, at the other end of the spectrum - those 
with older, slower and/or smaller kit and/or those still stuck with 
dialup connections (still very common in other-than-urban Australia, let 
alone 'developing' countries) it should still be possible to do what I 
did over 10 years ago; install from CDs, spend some weeks learning and 
configuring the system and tools before even first putting it online.

 > 	- My plans for DVD sized media (still uncertain how that will
 > 	  factor into 6.4/7.1) are to provide CDROM sized ISOs that have
 > 	  no packages on them at all (giving people who don't have DVD
 > 	  drives something they can still install from) and one DVD
 > 	  sized ISO that has packages.

Downloading even 2 CDs at 56k dialup is thinkable, over a couple of 
days.  A 4GB DVD, probably not.  Even on my ADSL plan it's heavy.

This seems a bit close to forcing the abandonment of pre-DVD kit, in the 
less well-endowed circumstances I'm advocating for here.  FreeBSD's 
always been able to be installed and setup from multi-CD sets, but I can 
well see needing to rethink just how these CDs are used .. more below ..

 > The path will be to finish what I started a while ago when I removed the
 > X11 options in the "installation distributions" section of sysinstall by
 > removing the last couple of tidbits that touch packages before you get
 > to the "Would you like to view the list of available packages?" section
 > of sysinstall (e.g. the offer to install Linux compatibility on i386).
 > This will provide us with a clean separation of the baseline system from
 > the packages.  After doing a baseline install you can choose to:
 > 
 > 	- reboot and install ports/packages when it comes back up

Which means rebooting into, or at least clearly offering some way to 
'return' to sysinstall (ono) for the genuine noob, I guess?  I know how 
hard it is to remember just what those genuinely new to BSD know and may 
not know, but Jordan did do a pretty good job then of making it easy for 
those knowing very little to get FreeBSD up and running, without needing 
to hook into the mailing lists and such first.

And despite what someone offered, browsing the handbook as a text file 
is really only for the masochist .. yet the handbook is really essential 
before you have much of a clue - even with regards installing.  It's not 
even fair to assume that people have ready access to another machine ..

 > 	- switch install media to be an FTP server and get a larger
 > 	  selection of packages to choose from

So much larger that it's almost a problem finding stuff you _know_ you 
want.  I did one bootonly-CD install of 6.1-R just to check it out on a 
blank-slate laptop - and modulo a bit of hunting for packages amongst 
various incomplete mirrors, for installing packages it was just great, 
but mostly because I already knew what I wanted.  It's a bit too 'flat' 
when faced with the whole of, say, packages/sysutils, compared to the 
nice sparse sets on the CDs or even, I imagine, on a single DVD.

I wonder would it be possible to use, say, the INDEX off the DVD as a 
subset to use when viewing the whole banana of an FTP packages install?  
If so, various people could create various subset INDEXes for different 
sets of packages, maybe?

 > 	- use the available packages if you're installing from DVD

As I see it, the problem with packages on multiple CDs has been both the 
ongoing bloat in package sizes and virtually indeterminate dependencies 
mandating very nearly intolerable disc swapping in some instances.

Everything solid is in packages/All/* the rest are links in directories.  

Back on 2.2.6 and for 4.x boxes I just copied the CDs to disk images, so 
I could merrily mount and browse these and pkg_add at will, mostly when
logged in remotely, and usually got away with it.

One multi-CDs to DVD script I saw handled the problem by updating the 
INDEX file to change the CD number all to disc 1, as I recall.  Perhaps 
another option instead of DVD is using a USB stick, with same issues. An 
easy process to put the DVD image onto a stick would be something I 
could use on this pre-DVD laptop, for instance, despite onlu USB 1.0 ..

Another useful way might be a process that sucks up as many CDs that 
have /packages/* as you care to feed it, copying the package files to 
their default home in /usr/ports/packages, which I think pkg_add looks 
in as well - certainly portupgrade/install does.  Or to some temporary 
space you specify, whatever.  Copying say 2-6 CDs to a new /usr isn't 
going to bother anyone, and you can always rm /usr/ports/packages/*

This would get away from that mindless disc-swapping scenario, while 
still letting people download (or otherwise obtain) CD images for say, 
Xorg plus KDE | Gnome | xfce, which are probably the main things people 
with smaller/older gear would rather not have to build from source, and 
for those without net access for FTP at install time.

 > No matter which approach you use, you're clearly seeing a separation
 > between the baseline system and the packages/ports.  If you want lynx or
 > links or Gnome or KDE you're aware that they are packages/ports and
 > simply select them.  If you didn't want them then you don't wind up with
 > them sitting on your disk.  Basically I'm saying any of the things that
 > may have been in the "Distributions" section of sysinstall before (X11
 > stuff used to be in the Distributions) are now in the packages section
 > along with all the other things that are packages.  And with the
 > packages only being available on the DVD sized media we stop needing to
 > deal with deciding what precious little amount of stuff is worthy of
 > being on disc1 versus disc2/disc3/etc. and all the disc swapping that
 > comes with CDROM sized media.

So if we got away from CDs being anything other than pieces that go to 
make up the DVD, or to be copied to .../packages on the HD, we wouldn't 
have to worry about all that trying to fit stuff sensibly much if at 
all?  I guess another option would be for people who care about this 
(like me :) figuring out how to make sensible subset CDs that people 
could use, as above.  The actual copy-CD-to-HD script doesn't sound too 
challenging, so could the 'install from image/s on disk' section be 
easily hacked/configured to accommodate accessing something like that?

 > And for at least some arch's we *might* be able to move the livefs
 > support back onto disc1 if there are no packages there for CDROM sized
 > media - I haven't had a chance to check if that's still feasible.

Sounds worthy.  Modulo not wanting to lose CDs, and advocating a useful 
developing-world install process, it all sounds like improvement to me.

Thanks for letting us know what's happening with all this, Ken; hope you 
can excuse my perhaps too long unspoken concerns this late in the piece.

cheers, Ian