Subject: Lots of new users
To: None <netbsd-advocacy@netbsd.org>
From: Miles Nordin <carton@Ivy.NET>
List: netbsd-advocacy
Date: 02/22/2002 21:25:50
All this talk about logos and poweron-defaults is making me twitch
nervously.  I'm having horrific flashes of gigantic monkeyteams
mobilized to rewrite trampoline.s around 3D boot logos rendered in
MMX-optimized assembler code.

As I read, I started thinking about arguments for doing one thing or
another, but then I realized why everyone is suddenly so focused on
NetBSD's first-bootup appearance: because a bunch of people have just
started using NetBSD for the first time!  This is a GOOD thing!, and
is only natural.  so, at the risk of sounding cultish or embarassingly
elitist: WELCOME!


The installer is a topic that comes up a lot.  I've written some
rather rude words on the subject before that probably don't need
repeating.  However, when I read Perry Metzger's post about patch
management, I thought he referred to the features in vendor Unixes
like Solaris and HPUX which support fixing security advisories and
other bugs between formal releases.  And not the Strategic Global
Gooification Project.  Right?

When NetBSD security advisories come out, the suggested fix is
something like, ``Upgrade to 1.5.4 when it comes out a few months from
now, or get foofrobinator.c 1.13 or later from WebCVS and rebuild your
/usr/libexec/food.  If you have i386 only, you can download food.gz
from here.''

I like this system.  It's robust and very easy for developers, so
fixes that theoretically work for absolutely everyone come out very
quickly.  However, it is shabby compared to vendor support contracts.
Downloading individual source files, or replacing /usr/libexec/food by
hand, has problems.  There's no automatic audit tool of which holes
are fixed and since when, and which still aren't fixed.  There's no
way to roll back fixes if something breaks, which is something the
vendors offer.

Fine-grained tracking of built base-system components is a part of
fixing this shabbiness.  Since sysinst installs the base system, large
pieces of sysinst may not survive the fix.

However, that doesn't mean we need to fork sysinst into a text version
and a QT/Embedded version, or rewrite it in Ruby, or turn it into
novice sysadmin wallpaper like Linuxconf/sam/smit/AdminTool/netinfo
with a ``Services'' control panel, or make sysinst install things from
pkgsrc.  Some (not me) may find those features desireable, but they
aren't implied by packaging the base system or auditing SA patches.

If you want my two cents, sysinst is what you use when your toolbox is
deficient.  You have no other NetBSD box on which to mount and prepare
the disk, otherwise you would install by hand with pax and some
hypothetical host/target-aware 'installboot' tool.  Additionally,
sysinst should not be an upgrade tool or a customization tool---those
tools should run on the booted target, not off an ``Install'' CD.
sysinst should be a bootstrap tool and a rescue shell ONLY.

I question even the wisdom of sysinst allowing X11 or compilers to be
installed or omitted.  Maybe it should install a uniform system, and
focus on _working_, rather than adding feechers that will make it more
likely to fail and dump you into a nonworking system where you're
expected to recover with a substandard set of tools.

I have _NEVER_ used a bootstrap-and-configure tool that doesn't suck.
cygwin, redhat, solaris, debian, whatever---they all get muffed up
downloading something and force you to re-enter the same data over and
over BY HAND.  And you're always left with obnoxious redundancy---now
that you've completed the ``Install Phase,'' how do you configure your
system?  If you're a Linux sysadmin, you shut down the system and go
get your ``Install CD.''  That's ridiculous!  On this list, we're
discussing a Unix that can boot off magtape, not flickering
nightlights for thumbsucking bed-wetters.

It's bad enough that this Installer-vs-Running-system redundancy is
unavoidable with the partitioning tools, bootcode installers, and FTP
clients built into sysinst, but there are some plausible arguments for
that.  The install tool should just partition the disk, bring up
minimal networking, make the system boot multiuser, and then GO AWAY.
That way, whatever you need to do next---install more stuff, flip
daemons on and off, get X working on a Hindu Shamshi 4000 AGPro video
card---you only need to learn ONE way of doing it.

After booting, it's not easy enough?  Fine.  Think about making it
easier.  Assume your users are literate, and write some documentation.
Buy a book about sysadmining Unix.  Don't use Unix at all.  But, don't
build an AdminTool crutch into the installer like some kind of
Configuration Wizard!

One of my better NetBSD experiences: I was installing over a cable
modem, which uses DHCP ``client IDs.''  Because sysinst is a
crunchided version of standard tools, I was able to exit to a shell,
make a 'dhclient.conf' file with identical syntax to my working NetBSD
laptop, start dhclient by hand, and continue with the install.  Almost
miraculously, sysinst did not clobber the already-brought-up network
as it proceeded through its linear Wizard-script.  sysinst understood
its role of substituting for my sorely-missed toolbox.  sysinst
minimized the redundancy between Installer and Working System so that
I could use the same dhclient.conf.  Try that with a QT/Embedded
install tool with some oddball DHCP client written in ActivePerl.
(never mind that I did it all over a serial console.)  Sure, no matter
what I say I did, you can say ``we can make our GUI program work in
that one case, too,'' but there will always be bugs, missing features,
and strange cases.  The better system has a better architecture, not
more lines of code to plaster over the hubris of a failed attempt with
yet more condescention.


I'm familiar with the dread that some new user will abandon The
Offering because first-poweron is somehow unimpressive, but I've
gotten so used to this concern that, these days, the most a stranger's
contempt can hope to wring from me is a wry smile.

Are you worried The NetBSD Desktop is ugly?  Take a look at Mac OS X,
and give up.  You will never impress anyone this way.  Ab! Nob! Woah!
put your screenshots back in your pants.  You won't.  You do not have
translucent throbbing genie-bottle antialiased MPEG4 icons, and you
know it.  Even if you had it, I don't think we want it.

Are you worried about boot logos?  Flip on a modern game console.  The
good 'ole s3m/``demo-scene'' is alive and well in game console
firmware, and you don't stand a chance pissing your name in the snow
next to professionals of this magnitude.

I think NetBSD will win more friends in its first hour of use by not
annoying users than by impressing them.  I am so sick of dterms,
hpterms, trashcans and recycle bins, designer color schemes, and giant
hovering spacedocks crowding my screen.  I do not WANT my box booting
into someone else's favorite desktop---that's just a bunch of nonsense
I have to rototill out before I can get down to planting my garden the
way I like it.

Because, let's face it.  Us sysadmins are in no position to dazzle and
condescend.  This is real Unix.  This is not Desperate Desktop
Replacement #9, to which you come after short stints with DoubleDOS,
DesQview X, HP OpenView, OS/2 Warp, Win98, WinNT, NeXT OpenStep, BeOS.
We do not want to join this legacy of pathetic failure, even if the
price means finally admitting that mere lowly sysadmins like me have
to start on the bottom rung.

Look at it this way: NetBSD is supposed to look ugly to fools, so you
can be proud of yourself for discovering its goodness.

``blah blah Elitist blah blah blah.''  Well, yeah.  If I didn't think
it was better, I would use something else.


BTW, CSH, the top web page is a parody of The Battle of Iwo Jima?
``No Japanese survivors?''  Great.  juuuust great.  Yeah, to be
honest, I actually liked that drawing a lot, too.  But I didn't know
where it was from.  so... let's ask if we can borrow the logo from
THESE GUYS

 http://www.badvogato.org/

and use it instead, so as to be more tactful.

-- 
``President Macapagal seems to have forgotten that not so long ago,
her staunch ally was mistaking our Aeta brothers and sisters for wild
boar and shooting at them.''
		-- Aurora Parong