I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Seventh Edition:
http://www.cita.utoronto.ca/~norman/old-unix/old-fs.html
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
> There where several ports: Sun3, Sun4 / SPARC, DECstation, SPUR, Sequent
> Symmetry at least. Even mixed architecture clusters where supported. See
> http://www.cs.berkeley.edu/projects/sprite/retrospective.html
Wasn't the Symmetry a 386 based system? Could Sprite be "revived" for the
modern PC? Just wondering ...
Arnold
I think you're confused. The DECstation was made by DEC, but used a MIPS
processor, not a VAX. SIMH won't be able to do anything with it, although
there are likely other MIPS simulators out there to be found.
Arnold
> From: "Gregg C Levine" <hansolofalcon(a)worldnet.att.net>
> To: <tuhs(a)minnie.tuhs.org>
> Subject: RE: [TUHS] Sprite
> Date: Sun, 30 May 2004 18:16:33 -0400
>
> Hello from Gregg C Levine
> Okay, now this begs the question: Can the VAX Station boot code which
> is targeted to that specific system, be rewritten to accommodate the
> VAX processor that SIMH emulates? I am not a good C programmer, just a
> whatever comes before that. I can only offer these suggestions, and
> ask these questions.
>
> For that matter, do any of us have any of the SUN hardware that I do
> know Sprite ran on? Or that VAX Station? For me, its no to all three.
> -------------------
> Gregg C Levine hansolofalcon(a)worldnet.att.net
> Date: Wed, 26 May 2004 07:19:19 -0500
> From: Cornelius Keck <cornelius(a)mail.keck.cx>
> To: Randy Belk <rbelk(a)onlybsd.com>
> Subject: Re: [TUHS] Sprite
> Cc: tuhs(a)minnie.tuhs.org
>
> I looked at the Berkeley repository last night, and did not
> see some files required to run Sprite directly from disk --
> for instance, the Sparc bootimage (sun4.bt or so) seems to
> be missing, or I'm overlooking it, in my coffein-deprived
> state of mind.
>
> Come to think of it.. I do have a few Sparc 2 machines, with
> a few improvements (like 128MB RAM, Weitek PowerUp), and would
> like to give Sprite a spin. I'm all for adding the Sprite ISO
> to the archive!
>
> - Cornelius
Jose' R Valverde wrote:
> > >
> > > I had the (small) pleasure to run it on a small number of
> > > DECstations back in 1994-1995 out of the freshly published
> > > WalnuCreek CD and I still long for some of it features.
Let me be confused, and note that a DECstation is not a SPARCstation.
carl
--
carl lowenstein marine physical lab u.c. san diego
clowenst(a)ucsd.edu
Jose,
TNX for parking Sprite on ftp.es.embnet.org!
I just ran into a little problem.. looks as if
the node is either down, or not reachable (at
least from here (== Plano, Texas):
$ ping ftp.es.embnet.org
PING bakalao.cnb.uam.es (150.244.80.6): 56 data bytes
^C
--- bakalao.cnb.uam.es ping statistics ---
9 packets transmitted, 0 packets received, 100% packet loss
$ ftp ftp.es.embnet.org
[2 minutes later]
^C$
> generated an ISO from the raw CD and am copying now the CD
> contents to disk, which are being made available as
>
> ftp://ftp.es.embnet.org/pub/misc/TUHS/sprite
> and
> ftp://ftp.es.embnet.org/pub/misc/TUHS/sprite.iso
>
> as the copying is done. Beware, it is ~530MB.
This goes for both my machine at home, and here at work.
Now, www.es.embnet.org responds fairly fast, so I don't
think that it's the wire across the big pond. Any
ideas?
TNX!
Regards,
Cornelius
Would it make sense to add Sprite to the Unix Archives? To me, yes, it was
enough UNIX like although it wasn't ATT or BSD derived and it had many
advanced features.
I had the (small) pleasure to run it on a small number of DECstations back in
1994-1995 out of the freshly published WalnuCreek CD and I still long for some
of it features.
The distribution is still available at
http://www.cs.berkeley.edu/projects/sprite/
j
--
These opinions are mine and only mine. Hey man, I saw them first!
José R. Valverde
De nada sirve la Inteligencia Artificial cuando falta la Natural
> From: Albert Cahalan <albert(a)users.sf.net>
> Subject: Re: [TUHS] cvsweb for BSD
> > One of the big problems is that they move files all over the place as BSD
> > developed and CVS doen't work too elegantly with those kind of changes.
>
> Bitkeeper handles this well. I suspect that Larry McVoy would
> at least be mildly interested in giving advice for such
> a project. Bitkeeper is SCCS-based.
Yes, I'd be interested. Other than the renames I think we can automate
most of this.
> Bitkeeper also has a superior web interface. You can't beat
> standard unified diff format with a tiny bit of color added.
Thanks. One day we'll get around to adding sub line highlighting - that
would be an improvement.
> From: "M. Warner Losh" <imp(a)bsdimp.com>
> Subject: Re: [TUHS] cvsweb for BSD
>
> If you are going to use a proprietary system, you might as well use
> perforce, which has better branching and file movement support than
> bitkeeper. But I guess I'm a little biased because I like p4 better
> than bk.
Both biased and incorrect. There are over 10,000 branches of the linux
kernel floating around in BitKeeper (we know, we counted them) and we
handle file movement much more nicely than perforce does (we have our
own concept of an inode, a pathname is a attribute of an inode just
like contents are an attribute of the inode - so you can move A to B,
I modify A, you pull from me and the changes apply to B in your tree.)
You can be as biased as you want, I don't want to turn this into a
SCM discussion, but try and be accurate. About the only thing that
p4 does that we don't do is centralized locking; we don't need to
do that in a distributed/replicated system but people sometimes want it.
--
---
Larry McVoy lm at bitmover.comhttp://www.bitkeeper.com
Maybe everyone here already knows about this, but I haven't seen
anything, so I'm posting it.
http://www.groklaw.net/article.php?story=20040524130757328
"We hope with this Grokline project to be able to identify any
conceivable legal issues that those wishing to block, slow, hobble or
tax GNU/Linux may try to use in future legal assaults on the community.
If there are litigation risks, even just from nuisance lawsuits,
particularly with respect to patents, we want to find those risks,
hopefully before they do, and mitigate or resolve them now. I am
personally convinced, as you no doubt are too, that the next wave of
attacks on GNU/Linux and the GPL will involve patents."
--
http://chris.nodewarrior.org/
>
>Incidentally, the Unisoft m68k port of SVR2 at the core of A/UX was also
>ported to the Perq-5 in 1986/1987, to create the Crosfield Studio 9500.
>
>Perq had just folded, but a core group of ex-Perq employees worked with a
>team from the UK company Crosfield Electronics to take the machine (which at
>that time existed only as a wire-wrap prototype) through to production.
>
>I was a member of that team and I have fond memories of sitting in a
>basement office in Pittsburgh surrounded by kernel listings (with a very
>puzzled look on my face).
>
>Just a small footnote in Unix history...
>
>--
>Roger
That's strange, I have those very same memories. In fact I was looking
for someone who would appreciate this:
#ifdef PYTHON
Cheers,
Eric
