Re: The case for FreeBSD

I'd like to make some contrary remarks to what you've claimed here:

On 2/8/2005, "supraexpress_at_globaleyes.net"
<supraexpress_at_globaleyes.net> wrote:

>One of the main "stumbling blocks" to using FreeBSD is the installation
>process. I have had "lots of fun" (not!) with NetBSD's line-mode/shell-script
>"installer" and confusing companion installation instructions, in the past; I
>only tried OpenBSD once and don't remember anything about its installation
>process, but I seem to recall that it was similar to NetBSD's; FreeBSD's
>'DOS-like menu' system is a travisty and IS PROBABLY THE ONE THING THAT TURNS
>OFF MORE PROSPECTIVE FBSD USERS THAN ANYTHING ELSE - I know - I have heard!
>

The CURSES installer is actually very good IMHO. It is not resource
intensive, it is interactive, and it makes no device assumptions, save a
keyboard and a terminal. This makes the installer very portable and
accessible, while presenting the user with a menu-driven interface.

>Besides, it is REALLY EASY to get lost in the FBSD installer "menu system",
>and not that hard to get caught in a "control loop"; this is not to say that
>the current FBSD installer is a piece of junk - I give kudos to its
>developers, but IT IS TIME TO MOVE ON, and this is the ONE thing that gets
>compared to with Linux "installers" as well as Winchoke, probably more than
>anything else, so if FreeBSD is going to be more appealing to "the masses",
>it needs a completely new installation process (note: I don't really care
>for Solaris' "wizard process" - though it is not TOO bad, and I am not
>trying to advocate a "wizard process" that mirrors others).
>

FreeBSD is not Linux, and I take offense to the idea that BSD needs to be
"Linux-ized" by overhauling bikesheds like a CURSES installer simply
to gain appeal in the passenger-seat unix crowd. The installer can be
better, yes; but the direction you are taking your argument is something
that I as a user and hopeful future committer do not want to see - the
transformation of FreeBSD into "that Linux distro that isnt' really
Linux".

>I offer the following suggestions for cogitation and realize that some
>of MY choices may not be "the best", but here goes anyhow:
>
>a) redesign the "installer" as a graphical menu system with pull-down
>   options, organized as a linear heirarchy where there is NO possibility
>   of getting lost or of winding up in a "control loop", and the progression
>   is clearly visible; real graphical images of major processes/steps and
>   "systems/major applications" should be provided; THIS installer should
>   begin with THREE, and only THREE options: "user workstation",
>   "server", or "(expert) choice of workstation/server setups"
>

I like the idea of showing the progression the user is in, so they have
an idea of where they are in their particular menu topography. However,
I cannot stress enough that dependance on a GUI system is a shot in the
foot waiting to happen. What if the mouse daemon doesn't init for some
reason? What if the graphics mode isn't supported by the user's
display hardware? What if the user is installing remotely over a tty?

...


>There are "circular menus" (ala one Firebird extension), layered pie-chart
>diagrams of the filesystem with size information (such as KDE's "filelight")
>where mousing over one of the concentric circles pops up an "info box", while
>clicking on one of them traverses down the filesystem path and creates a new
>set of concentric circles of lower level directories, and the exhilarating
>3D-Desktop as examples of unique, "futuristic", artistic, free flowing
>graphical "systems" that could lead to interesting ideas for the above
>mentioned "graphical installation system".
>

I would also like to see more advanced filesystem tools, not necessarily
just for graphical effects. If we're using a GUI, for instance, it
would be nice to have a disk widget that shows the partition layout and
allows for the addition and resizing of partitions with the pointer, ala
some old versions of Tru64/VMS. It would also be nice to have a more
robust disk tool that could resize live partitions and slices. That's
something I myself would really like to get my hands on, when I have the
ability.

>Granted, there are MANY, MANY issues to be worked out, and some of these
>suggestions will have to be modified - of course. There might even need to
>be a two-tiered system where the first tier could be a basic graphical
>system that doesn't need special graphics cards to perform, and the second
>tier that could install X, or something close enough, and then provide the
>full blown "graphical installation" system. If there are enough drivers
>available to the "installation system" to determine enough about a system
>"monitor", then hopefully this could be an automated facility (eg; install
>a minimal X-system with just enough to do the necessary graphics, and later
>install the entire X-system where needed).
>
>OK - let the "flame wars" begin. Whatever comes out of this, the FreeBSD
>"installer" badly needs a facelift.

First off, there must always be a fallback. Second, I think this post is
flamebait and offers more complaints that FreeBSD isn't like Linux than
creative and constructive comments. I tried in my reply to keep my own
comments as constructive as possible, but I must let that be said. And
Last, I'm frankly pretty glad that some people that see the installer
and notice it isn't like Linux or Windows get scared and run off. The
FreeBSD user base is different than that of Windows and Linux, and that
is _okay_. IMHO, of course. If FreeBSD were the same thing as Linux,
then how could it stand out as something special?