Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 22 Feb 95 10:46:03 MST
From:      terry@cs.weber.edu (Terry Lambert)
To:        ugen@netvision.net.il (Ugen J.S.Antsilevich)
Cc:        hackers@FreeBSD.org, jkh@violet.berkeley.edu
Subject:   Re: FYI..
Message-ID:  <9502221746.AA24312@cs.weber.edu>
In-Reply-To: <Chameleon.950222130314.ugen@ugen.NetManage.co.il> from "Ugen J.S.Antsilevich" at Feb 22, 95 12:58:44 pm

next in thread | previous in thread | raw e-mail | index | archive | help
> Hmm..again completely sick NetBSD "release"..
> Tell me, is there *ANY* such release of NetBSD which supports
> without any exclusion or stuff at least 70% of hardware for some
> architecture? That funny OS just comes out anytime with messages like the
> one you sent: SUPPORT FOR <abc>
> And then: except [ethernet|discs|video(no X,never!!!)|serial|processors|etc..]
> Actually i think this is even too small to be called "FYI"..:)
> *IMHO*

By this argument most "releases" on the net are really Beta
distributions anyway.  I wouldn't necessarily disagree with this
from a commercial viewpoint, but this list is not a list for a
commercial product.

I'm actually very interested in this port, since a 160 MHz Alpha
motherboard is available from DEC Direct for $1170 retail (you
should never pay retail!), about the same price as a good P90
motherboard.

Admittedly, the $1170 board is PCI based, and so won't work without
some effort given the current state of the port.

But the port has other value in providing information on 64 bit
architectural changes needed in both NetBSD and FreeBSD, as well as
providing some cleaned up tools ported to a 64 bit aware kernel.

Finally, the comments on ecoff files and getting the symbols makes
it clear (to me anyway) that utilities that depend on things like
symbols instead of things like procfs are dated and should die a
horrible death; the user space utilities other than the developement
tools should not be dependent on the object file format used.  They
can, however, depend on published cross-platform interfaces like
procfs.

This implies certain file system constructs are mandatory, ie: the
mounting of procfs can not be left up to the user, it must be
implied by the kernel.


I was also interested (but not pleased) by the way they solved the
inter-OS file system mounting problem.  That the problem exists
points out the inadequacies of not isolating the disk subsystem
dependencies from the device abstraction, and from not making the
per system physical layout of logical partitioning information a
seperately interposable layer.

The need to move removable media from one machine to another (such
as Syquest and magneto-optical cartridges) clearly argues for the
ability to interpose the layering on a per device rather than on a
per architecture basis.


All in all, I think the announcement (which the NetBSD people did
*not* make to the FreeBSD lists -- it was echoed by Jordan as an
item of general interest) did a lot to make me think about problems
for which I did not already have concrete soloutions.


					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9502221746.AA24312>