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.)
----- Forwarded message from meljmel-unix(a)yahoo.com -----
Warren,
Thanks for your help. To my amazement in one day I received
8 requests for the documents you posted on the TUHS mailing
list for me. If you think it's appropriate you can post that
everything has been claimed. I will be mailing the Unix TMs
and other papers to Robert Swierczek <rmswierczek(a)gmail.com>
who said he will scan any one-of-a-kind items and make them
available to you and TUHS. The manuals/books will be going
to someone else who very much wanted them.
Mel
----- End forwarded message -----
Hi all, I've just heard that the Usenix board of directors do not want
to explicitly celebrate the 50th anniversary of Unix.
It's been suggested that we, the TUHS members, both lobby the board and
also offer our assistance to help organisation such a celebration.
Who, on the list, would put their hands up to help organising something
that coincided with the 2019 Usenix ATC in July 2019?
I'd like to get the bare bones of an organising team, then approach the
Usenix board, offer our help and ask them to support us.
What do you think? 11 months to go.
Thanks, Warren
P.S. Nokia Bell Labs are also going to organise something, possibly a month
earlier but I have no solid details yet.
On Wed, Aug 29, 2018 at 1:07 AM Greg 'groggy' Lehey <grog(a)lemis.com> wrote:
> On Tuesday, 28 August 2018 at 23:23:10 -0400, Theodore Y. Ts'o wrote:
> > On Wed, Aug 29, 2018 at 11:06:05AM +1000, Dave Horsfall wrote:
> ....
>
>
> Creeping featurism!
>
No, I think its really is that many programmers that touch different
applications felt the need to pee on the code to feel that they left their
scent. 😘
Seriously, IMO the problem is you can never know what someone else really
values, so be careful at what you change. Pike's 'cat -v' dissertation
b*tched at UCB for the some of the same issues. Somewhere there is a
proper middle ground ( I think of as having good taste elegance). BSD nor
Linux was no more 'perfect' that 6th or 7th edition. Truth is a much as I
pine for the elegance, I don't want to run either of the later as my
day-2-day system in today's world and I >>loved<< running them when they
were what I had.
Rob has a real point and many of the changes really *are gratuitous* and
there *are better ways of doing* many things than adding a switch to old
command and reusing it because you can. I also think the complaint of just
adding 'crap' because you could started with BSD but the cause wasn't that
people were bad -- there was address space relief over the PDP-11 and often
added a new switch/new functionality was easy to do, instead of creating a
whole new solution just deidcated to that problen only. FWIW: sendmail is
my best example (useful tool that it was - there were/are much more elegant
solutions - sendmail should have been 'headerwriter' and smtpd should have
been a seperate program).
Dueling switches and functionality (dec vs -f bs -F) I fear is sometimes
ignorance of the past. I fear there is some sort of belief we need to shed
the past because someone feeld the it gets in the way of the future (I'll
pick on my on son here - who things 2-3 years is 'old' and its time to
throw things away). Truth is sometimes it might. But I would rather
inject a stronger strain into the mix and let the users decide and for good
or bad, BSD did that to the original (v6/v7) and now Linux is doing/has
done it to much of BSD.
The compaint is the 'throwing the baby out with the bath water' behavior
that seems to often follow (see systemd issues on other mailing lists);
*i.e*. did you really gain something for this huge disruption. To me when
something really new/a great innovation comes that should be celebrated.
BSD gave us VM and a number of 'useful' new utilities, and eventually an
networking API (al biet not everyone liked it, sockets was good enough,
solved the problems and became a standard that allowed us to move on).
Mach (while Larry may not like the VM implementation), moved the bar for
the kernel's handling of memory a huge amount and almost won the uK war
(which IMO was a too bad). BTW: other kernels would do nice VM's too, but
Mach was generally available (open source if you will and really was the
system the moived it forward).
That said, I give the Linux folks great credit for the addition of modules
was huge and it took BSD and the other UNIX systems a few years really pick
up that idea in the same way (yes Solaris, Tru64 and eventually HPUX etc..
had something too but again - my comment about being generally available
applies).
So here is the issue, how to do move the ball forward? BSD, then Linux,
became the 'stronger strain' and pushed out the old version. The problem
is the ROMs in my fingers (like Dave) never got reprogrammed so some of the
'new' becomes annoying. Will I learned to like systemd? We shall see...
Clem
On 08/29/2018 07:46 AM, William Pechter wrote:
> Also... If you run on the internet remember documented security exploits
> are decades old. I recommend no open ports except for ssh if it will
> build and maybe UUCP.
I'm working on a Retro Computing Networking project with a few other
people and I think it would be a benefit for things like running 4.3 BSD
and other old OSs in a relatively safe environment.
I'm bringing this up on TUSH for two reasons:
1) I think THUS members could benefit from RetroNet
2) I (we) would very much appreciate any suggestions or desires that
the THUS community would like to see in such a network.
The idea behind RetroNet is two fold:
1) Create a network of interconnected VPNs between interested parties.
2) Provide ISP like services over said interconnections.
Our hopes are for RetroNet to be able to provide a sandbox / small pool
/ isolated network where members can interconnect with each other (if
they want to) similar to the Internet, but with much less exposure. (We
are planing on RetroNet not having direct Internet connectivity.) We
are also hoping and planing to be able to carry any Ethernet based
traffic between sites, routed or not.
I (we) would be very interested in any input that THUS members might be
able to provide. Particularly what you might like to see in such a network.
--
Grant. . . .
unix || die
> From: Warner Losh
> The trouble, as I was given to understand when I worked at Solbourne,
> was that ... There were a number of third party bits and pieces in there
> that could not be relicensed ... if there are other IP issues, not
> limited ... It's that quagmire that efforts like this will run up
> against.
Oh, we'll just ask Oracle for a license 'for all parts of SunOS for which they
have the ability to grant a licence'.
There's no way I'd want them to have to chase down all the corner cases,
that's just a way to guarantee it will never happen. I'd want to ask for the
bare minimum of time/effort on their part.
Anything above that, probably the SCCS stuff would be next on the priority
list, sounds like.
Noel
After the past several years of focusing on 3B2 preservation and emulation, I've begun to wonder whether 3B2 hardware was used very much inside of Bell Labs. Has anyone ever heard whether Research UNIX was ever ported to the WE32100? I've certainly never seen anything that would suggest it was, but I'd love to be proven wrong.
-Seth
--
Seth Morabito
Poulsbo, WA
web(a)loomcom.com
Hello,
against my plan to stay under my rock and learn from your messages I now
have to speak up, because I stumbled over this:
https://bsd.network/@sehnsucht/100635118831337239
which speaks of
gopher://ftp.icm.edu.pl/1/vol/rzm2/
(after some puzzled searching for a client I found out that lynx still
supports gopher)
This site has the following list in its root directory:
4.4BSD-Lite FreeBSD LSI NetBSD OpenBSD UnixArchive ancient-unix
desktopbsd dragonflybsd ghostbsd kde kde-applicationdata kś linux-alsa
linux-archlinux linux-atm linux-bipv6 linux-blackarch linux-bluehawk
linux-cbq.init linux-cryptoapi linux-documentation linux-dret
linux-e2compr linux-fido linux-gentoo linux-gentoo-portage linux-inner
linux-iproute linux-linos linux-net-tools linux-norlug linux-nvidia
linux-nvidia.old linux-nvidia.old2 linux-openvz linux-packware
linux-pcmcia linux-radvd linux-raspbian linux-reiserfs linux-rtlinux
linux-sgi linux-silo linux-slackware linux-sparc linux-superrescue
linux-tsx-11 linux-uk linux-usagi linux-uw-linux linux-vectorlinux
linuxberg nexenta openindiana opensolaris pcbsd solaris-10
solaris-cd-fsn solaris-cd-pm solaris_i86pc solaris_sparc sun-fixes
sun-patches www.tazenda.demon.co.uk
I descended into the OpenBSD directory, where things look quite
authentic, at a first glance.
Please keep the stories coming, Marcus
> From: Clem Cole
> The problem is finding some at Oracle that would care
Well, I've got a nephew who's been at Oracle for like 20+ years; he can
probably point us at the right person.
> and finding a proper distribution tape to officially release.
Why do we need that? Can't they say 'any and all versions of SunOS', and that
term ('SunOS') is sufficiently well defined in real-world documents (e.g. Sun
licenses) that that should be 'good enough'.
It sounds like the _actual code_ is reasonably available, we wouldn't need
Oracle to go looking around for it, would we?
Noel
Hi!
If I wanted to run 4.3BSD on an x86 box (VirtualBox? QEMM? other emu?)...
anybody has suggestions? Where can I find media for 4.3BSD (if any are
legitimately accessible)?
Or on a Raspberry Pi? :)
Thanks!
Gilles
--
*Gilles Gravier* - Gilles(a)Gravier.org
GSM : +33618347147 and +41794728437
Skype : ggravier | PGP Key : 0x8DE6D026
<http://pgp.mit.edu:11371/pks/lookup?search=0x8DE6D026&op=index>
