Re: rewrite of sysinstall
p or the memory filesystem root.
So long as the module has a checksum in its file format, partial
fetches could be handled fairly easily, even with a minimal
webserver that doesn't send file sizes in the protocol headers
(in fact non-error headers could be merely tossed in the bitbucket
and MOVED errors should merely be reported rather than followed).
That would also allow for a far more complete HELP system in the
basic install. Only an HTTP1.0 plus file:/// would be needed,
so long as all links are relative once that BASE is set, because
multi-file fetches would seldom (if ever) be any enhancement. It
should send a Host: header, though, for HTTP. Perhaps a questonmark
on EACH option could offer context-sensitive help.
It would even be logical to register an application/vnd. MIME type
for these modules. With OpenSSL in the base distribution for 4.x
(${OSVERSION} >= 400014) and up, should the shell try for https://
before http:// ??
**
Color code the modules. The Royal Blue is pretty, but this can help
with remote voice support, and even E-Mail/Usenet support and FAQ
documentation.
**
Check for screen/terminal size with the GUI. If post-install
configuration is run (later) in an X-Term that's 80x60 - or even
160x80, why should it still be stuck at about 80x24, if there are
more options to display than fit in that size.
**
If system component addition is done from an X-Term, open another
one as a log view, comparable to the 2nd console in a basic system
install. (e.g. if DISPLAY is a non-null shell variable).
**
In post-install, allow for the TRADITIONAL distinct kernel hostname
from kernel domainname, whether or not NIS will be used. I know
that this is a "religious battle" but there are still some of us on
the other side of that argument from current presumptions. Sure
each active interface (other than lo0) should have a FQDN assigned,
ideally, but certainly there are a lot of status displays that
benefit from a shorter hostname. Sendmail defaults (last I
installed one) still allow for Dj set following $w set to
`hostname` appending .`domainname` internally.
Many other utils allow for this, as well, including Perl's host
determination. Very few are able to handle both a FQDN as
`hostname` and a non-null `domainname`. I know of quite a
bit of UUCP use still going on around the world, and although
UUCP on FreeBSD handles internet addressing ...
**
In disk partitioning, several preset presumptions could be selected
from, rather than a single default.
/ swap /usr- Personal use
with /var/ symlinked to /usr/var/
/ swap /var /usr - Plain server
/ swap /var /usr - Print, Fax or Mail server
/ swap /var /usr
and /home and/or /usr/local
/ swap /var /usr
and /var/cache or similar for proxy servers
/ swap /var /var/db /usr for database servers.
etc. Even if only half a dozen typical uses were used for
formulation it could cut down on the "I've run out of room on..."
posts in the mailing lists and newsgroup.
**
Would it be easier to just do the rewrite based on Tcl which
already has regexp's and socket support built in, along with
UTF-8 for internationalization, sub-interpreter for "safe"
zones, and the like. The XF86Setup utility is Tcl/Tk without
a "normal" Tcl/Tk install, already, for example. With the Tk
dynamic loading in the works, it could even make sysinstall
evolve into one which is OPTIONALLY an X application when
used post-install.
Bruce Gingery <[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Recommended addition to FAQ (Troubleshooting)
h has been put up on the FBI's NIPC site, and with much of the same reasoning you display about this RAM test software. That "signature checker" which is documented as tested on 3 versions of Solaris, and 2 RedHat distributions, but NOT able to handle a.out nor COFF binaries, is (perhaps) worse than nothing at all, because of the false sense of security it might convey. Of course, one additional thing against it is that it's a binary-only distribution that they say _must_be_run_as_root?! (apparently it does direct memory access to loaded code in addition to scanning stored binaries for a recognizable compiled signature?) Am I the only one seeing something windowsey about that? Who gets to make the recurring profits this time for band-aid solutions to a spurting artery. http://www.fbi.gov/nipc/trinoo.htm So I'll leave it up to you. There should be info at least in a FAQ somewhere that indicates that bad RAM is not something that can be ruled out until tested adequately, and perhaps a checklist of symptoms that (virtually) ALWAYS indicate bad RAM, or at least should make it suspect. Bruce Gingery <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Recommended addition to FAQ (Troubleshooting)
I recently installed FreeBSD on my daughter's machine, remotely. She'd been on Windows3 since growing up and moving away from my NeXT, so "UNIX" wasn't a scary word to her, and she was getting tired of "Windows95 or better" on anything she was interested in, and certainly wanted "better" if she was going to change anyways. Well, just for a quickie, so she could play with it long enough to be familiar with it before moving on to FreeBSD, we tried to install Windows95, first. The install bombed three times, and we thought it was a scratched CD-ROM. VMM32 something-or-other failed to be installed each time, or so the bluescreen said AFTER what was supposedly a complete (minimal) install. So, boom, take the 3.2-STABLE diskettes I'd prepared ... boot up fine ... mfs mount CRASHRe-installed Windows3 (95 had thoroughly messed the drive) ... got back on line, got 3.4-RELEASE diskette images and fdimage.exe ... just to be sure, wrote the diskettes three times each from the .flp files. Again, good boot UNTIL the mfs mount. CRASH... So, Win3.1 was still installed on the hard drive, this time, downloaded 2.2.8 boot.flp in hopes that the smaller footprint would install (this is a K6-300 64Mx9-bit system with NO BIOS errors showing, and fast-boot turned off!). It did. Had slight problems getting PPP logged in (the username required a provider prefix). Started the install. Got to about slice 15 or so of the first distribution and BOOM... Kernel fault AGAIN! I can't praise highly enough, two software packages: http://reality.sgi.com/cbrady_denver/memtest86/ and http://www.qcc.sk.ca/~charlesc/software/memtester/ The former is a bootable image memory tester, built from some pieces of LiLo, Linux Kernel, and some good algorithms that sweep flat memory. The latter is a user-space utility that has different algorithms, and built for FreeBSD pretty easily (I've submitted my modifications to the author for a 2.2.8 build -- I don't have any hosts - yet - running 3.x). BOTH of these quickly identified flakey RAM that a supposedly full BIOS sweep of RAM totally missed, and that had caused "normal crashes" with her old Win3.1 installed. I'd really like to recommend that memtest86 be placed in tools/ from now on, including a pre-compiled .flp image. Anybody who's built a kern.flp and mfsroot.flp, or a boot.flp, will have NO problem creating a stand-alone i386 and up, memory tester from the "memtest.bin" file in the ZIP distribution, or the "precomp.bin" in the source .tar.gz Both are .flp images with a custom bootstrap loader. Similarly, I'd like to recommend that the user-space memtester be at LEAST added to the ports, although it wouldn't hurt to have it as a GPL'd part of the base distribution. For people who reboot rarely, it probably wouldn't hurt to run that one just before multiuser startup on every reboot. With the slight tweak I sent the author, the creation of a port for this should be trivial - and might not even be needed with the later FreeBSD versions. The reason I'm sending this to the DOC list, is that at a bare minimum, this info needs to be added to the FAQ and/or manual. To the hackers list because everybody reads it :) and I'm recommending changes to the distribution. Bruce Gingery <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
