Hi, I have one question about 386BSD & NetBSD 0.8... If I'm right the reason that they were 'pulled' was because of infringing AT&T code. However didn't you need a 32v license to get access to 4.X BSD? So in that case since 32v is now public wouldn't that allow these early self hosting BSD's to be 'free' again???
Just wondering...
Jason
Folks,
I am interested in the use of multiple system call sets in Unix systems.
I recollect that Pyramid Technology machines in the 80's allowed users
and/or processes to select whether to use BSD or SYSV system call
semantics. Also, FreeBSD supports Linux system calls and SYSV in
emulation.
Does anyone know a good location (book, article, website) that discusses
this.
thanks
dayton
Dayton Clark
CIS Department dayton(a)brooklyn.cuny.edu
Brooklyn College/CUNY 718.951.4811
Brooklyn, New York 11210 718.951.4842 (fax)
> 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
> 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/
