Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Apr 1998 20:33:05 -0700
From:      Don Wilde <dwilde1@ibm.net>
To:        Greg Lehey <grog@lemis.com>
Cc:        freebsd-advocacy@FreeBSD.ORG
Subject:   Re: Demo CDs (was: blessing)
Message-ID:  <3547F0F1.280A76EA@ibm.net>
References:  <17537.893491629@time.cdrom.com> <3541F04D.474FE994@ibm.net> <19980429145242.02565@papillon.lemis.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey wrote:

> > Second, the easy-demo-version disk is a real winner, especially a
> > you-*can't*-break-anything version that runs completely off the CD
> > and DRAM. _Please_ keep working on these, because I'm gonna be way
> > too busy to do more than kibitz.(Greg and Eivind?).
> 
> Is this me you're talking about?  I thought my role was to stand in
> the wings and encourage people.

Your role is whatever you want it to be, Greg. I'm not "General", I'm
only an enthusiastic advocate who saw an opportunity but was counseled
to take a safer course by others and agreed with their reasoning. I know
you have been thinking on these lines before, that's why I poked you
specifically.
 
> OK, so what do we need?  My thought is for two or three preinstalled
> versions:
> 
> 1.  A CD-ROM-based version which will boot from CD-ROM, Microsoft or
>     floppy, create an MFS file system for things that really need to
>     write to "disk", and other than that run from CD-ROM.  Create the
>     / file system on the mfs and symlinks to just about everything
>     except /tmp, /var/tmp and /home to the CD-ROM.  With any luck, we
>     should be able to get away with 4 MB MFS.

One danger I see is that just giving people a ram based "normal" system
is that they will say "okay, so what. What's it do?" I think we want to
can a bit more, for instance, by using Apache and Mozilla or the new
HTML3.2 Chimera which I see is on 2.2.6 to include the HTML-version
Handbook AND some canned info pages. For instance, use cron to schedule
some changes in the root window at different times, so they are
encouraged to leave BSD running in order to see them, and they can keep
playing with it while they wait. I think we should spoon-feed them as
much as we can by leaving a TOP window open in the background, for
instance, as well as an xterm to play with. We want to showcase FreeBSD
as a system which can do more things than they are used to, and I also
think it is a big mistake to use fvwm95 as the only window manager. If
we must use it, have it be one of a bunch which can be selected, much
like fvwm has 'restart X with twm, olvwm, etc'. The key to BSD is its
scripting and scheduling and multiple-job-ness. We need to highlight the
improvements, not the fact that it can be made to look like the abortion
we all despise. I'm leery of resolution changes beyond SVGA capability,
no card optimization or color depth. I would like to be able to read and
write from a floppy, either via mtools or native, so we can allow user
to createa and save, say, their own HTML files or graphics and then
reload them into the MFS RAMdisk.

This is what I think we should concentrate on. I want it to be
bulletproof and safe, but preprogrammed to be powerful. It's got to
impress people who are afraid to touch the keyboard, but be usable in
case they do actually get up the courage. This means being careful of
the commands we enable and the permissions on things, so that they can
play _while_ our demos are rolling in the background. This will really
wow them.

> 2.  PicoBSD for those who want it.  Copy to floppy and execute.

Haven't tried that yet, don't know much about it.
> 
> 3.  In the background, for those who are hooked, the regular
>     installable version of FreeBSD.

YES! Our goal, of course, and let me say that I like the improvements
I've seen so far in 2.2.6, although I'm dismayed at the number of
dangling ports-dependencies that  seem to be broken. This does not look
good.
> 
> Versions (1) and (2) would effectively be canned versions which
> couldn't easily be modified.  Run with "standard" peripherals,
> including Enternet and SVGA to 1024x768, but with a base resolution of
> 640x480 so that X will come up on just about any currently available
> board.  Include a functional fvwm95 window mangler so that what comes
> up looks pretty much like what Microsoft users are used to (can
> somebody come up with a daemon logo to fit where Microsoft puts its
> windows logo?).  Also a PPP configuration that could easily be
> modified to suit just about anything that the standard Windows 95% can
> do.

See anti-95 comments above. OS/2 tried to be more windows than windows,
and we saw what that got them. I also don't think ethernet would be
appropriate. This _is_ just a demo, remember, and it is of extremely
limited utility without access to a hard disk. Ditto ppp and printers,
too many variables. At least for the first pass, anyway. We want this to
be no-brainer demo material: it does what it does, and it does it
perfectly. No questions, no controversy, just demonstrated neat power
and LOTS of FreeBSD material for them to study while they are waiting
for that new O'Reilly book with CD's from WC to hit their doorstep :)))
640MB is a _lot_ of room for demos and scripts and HTML, since we need
no source or most of the programs.
> 
> This thing needs more flesh.  Any ideas?  What problems do you see?
> About the biggest one I see so far is how to find the mouse.  It would
> be nice to modify startx to check for the mouse if no valid pointer
> section is found in the XF86Config file ("no mouse found: please move
> your mouse around until I say \"stop\"").  Anybody know how to
> recognize a mouse?

How about the simpler "Move your mouse. When it moves, hit space bar"
"Hit left button" "Hit center button" "Is everything working?", maybe
add beeps.

I have an article I'm working on and a zillion non-FreeBSD things as
well, but I really want this to fly. I just got 'make' from O'Reilly to
study so I can understand how to build dependency trees, and I'm getting
2.2.6 pushed into shape on my home machine. Once I'm comfortably 'up'
again, I will start digging into this. It'll be fun!

Your knowledge is an asset, Greg. I can come up with lots of
"what-to's", you point me in the direction of "how-to".

Comments, everybody else? If I'm the only one doing stuff it ain't going
to happen fast, but if we each add to the framework and the how-to base,
it'll get done and we can start giving them out pretty quickly. I've
just begun to study how the kernel and the various filesystem types are
designed. I haven't gotten into the differences between the BOOTMFS and
regular kernels yet, although it appears that's an appropriate topic to
dig into.

	kernel with MFS filesystem loads
	script determines RAM size, mouse questions, X screen size
	programs needed fast loaded into MFS
	start apache httpd's
	basic X loads
	enable cron jobs of demos
	pop open browser on basic howtos of demo system, links to Handbook 	
pages on CD and FreeBSD purchase info, users groups, etc.
	user has choice of wm's, applets, etc., from menus
	tkman? xv? gimp? xpaint?
	what other applications?
	generic AdLib sound would be nice!

I guess the first thing I need to know is how to set up a spare piece of
my disk to play with this without repartitioning my main system. I have
a big disk (3.2G SCSI) which is just my /var. How would I go about
making a kernel program to "boot" from part of this, and how do I limit
its memory use to just part of my 64MB? I'd prefer to have my new kernel
operate as a task within my working system, so I can learn to use the
debugger on it, and then have it spawn its own processes, but if that's
not possible I can accept booting a kernel from the real root which then
changes root to my test filesystem. Worst case I still have 2 IDE spots
open, I can go find a 1G disk and make it bootable. I also have a
monochrome 486 lunchbox I can rejuvenate to be a test case, but it needs
a hard disk also. :\

If I can resolve this I can host the sample system. I have both IDE and
SCSI CD drives I can test, lots of bits and pieces.

--> Don



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-advocacy" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3547F0F1.280A76EA>