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.)
Back when it was all UUCP, a friend setup his own system, bang.
He then used his initials as his login, bam.
So when asked for his email address he answered
bang bang bang bam
Bret was a funny guy.
David
Gerard Holzmann took the true and false commands as
the jumping-off point for "Code Inflation", an
installment of his "Reliable Code" blog and column
in IEE Software. An informative, but depressing, read:
http://spinroot.com/gerard/pdf/Code_Inflation.pdf
Doug
Random832:
The existence of cd as a real command is a bit silly (Ubuntu doesn't
seem to bother with it), but it is technically required by the standard.
===
Just for the record, Fedora 21 supplies /bin/cd, as part
of package bash-4.3.42-1. Interestingly, it is a shell
script:
lu$ cat /bin/cd
#!/bin/sh
builtin cd "$@"
lu$
As has been said here, it's hard to see the functional point.
Others have remarked on the continued life of /bin/true and
/bin/false. There are some who use those as shells in /etc/passwd
for logins that should never actually be allowed to do anything
directly. I have no strong personal feeling about that, I'm just
reporting.
And to be fair (as has also already been displayed here), the
copyright notice inserted in the once-empty /bin/true was hundreds
of bytes long, not thousands. Let us call out silliness, but let
us not make it out as any sillier than it actually is.
Norman Wilson
Toronto ON
UNIX old fart and amateur pedant
Hi all, I'm working on a Unix-related project, and I thought I'd ask if
anybody here might help.
There's a pared-down Unix-like system, xv6, which is inspired by 6th Edition
Unix and the Lions Commentary. Its purpose is to teach OS principles.
The website and book are here:
https://pdos.csail.mit.edu/6.828/2014/xv6.htmlhttps://pdos.csail.mit.edu/6.828/2014/xv6/book-rev8.pdf
Unfortunately, while the kernel is nice, they don't provide much of
a run-time environment, so it feels too much of a toy to use. I had the
idea of porting a small set of libraries and commands over to get it to
the point where it feels a bit like 7th Edition.
I've made a start by using the Minix 2.0 libraries and commands, see
https://github.com/DoctorWkt/xv6-minix2 and the NOTES file. I now realise
that bringing up a libc plus associated commands will involve a fair bit of
work.
So, if anybody is interested in helping, let me know.
Thanks in advance, Warren
> Date: Sat, 30 Jul 2016 15:30:36 +0000
> From: Michael Kjörling <michael(a)kjorling.se>
> To: tuhs(a)tuhs.org
> Subject: Re: [TUHS] History repeating itself
> Message-ID: <20160730153036.GI3375(a)yeono.kjorling.se>
> Content-Type: text/plain; charset=utf-8
>
> On 30 Jul 2016 10:15 -0400, from cowan(a)mercury.ccil.org (John Cowan):
>>> Who needs FedEx?
>>
>> Well, latency counts for something too, as does radius: if I want to
>> send bulk data from New York to London (a very normal thing to do),
>> your station wagon isn't going to count for much.
>
> You could, however, get an economy class flight ticket and load up
> your suitcase with either HDDs or SDXCs (I suspect SDXCs would be
> better per amount of data from the perspective of both volume and
> weight, and would take better to handling). Given FedEx's prices,
> _once you have the infrastructure set up_ (which you'll need whether
> you have someone travel with the media, by air or by stationwagon, or
> FedEx it), that _might_ even compare favorably in terms of bytes
> transferred per second per dollar. (Now that's a measurement of
> throughput I don't think I've seen before; B/s/$.) Of course, you'd
> need someone who can babysit the suitcase, which potentially adds to
> the cost, but the stationwagon traditionally hasn't been self-driving
> either, and most of a transatlantic flight isn't active time on part
> of the person travelling with the suitcase so you could go with an
> overnight flight and allow the person to sleep.
>
> If you want to reduce the risk of the bag getting handled roughly or
> lost in handling, reduce the above to carry-on luggage; it will still
> provide a quite respectable throughput.
>
> ... ...
>
> It might not be the absolute cheapest approach, but it seems rather
> hard to beat in terms of throughput per dollar for bulk data transfer,
> especially if you already have someone who would travel anyway and can
> be convinced to take a company-approved suitcase in return for having
> their ticket paid for.
>
> --
> Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
> “People who think they know everything really annoy
> those of us who know we don’t.” (Bjarne Stroustrup)
>
To setup the 'infrastructure might be the tricky part. Many years ago
I flew from Montreal to Amsterdam and had two stacks of 5-1/4"
diskettes with me. No papers, confiscated in Amsterdam.
Cheers,
Rudi
Hi folks,
My root partition for Unix v6 is almost full and /dev/rk0 only has 83 blocks.
The trouble is I wanted to compile bc.y and I think it needs around
300 blocks of temporary space. I was wondering if there was a way to
set up Unix v6 so that it could use one of the other drives for tmp
space. I tried to set up a link using ln but it seems I can't link
across filesystems.
The exact error is "26: Intermediate file error".
I managed to rearrange things so that /dev/rk0 had over 300 blocks of
free space and it fixed the problem, but I'm curious if there was
another solution.
Mark
Clem Cole:
Also to be fair, Dennis did symlinks before 4.2. They were part of the V8
I believe.
=======
I'm pretty sure they came from Berkeley nevertheless. I don't know
the exact order of events, but the 8th Edition kernel was essentially
that from one of the later 4.1x BSDs, hacked in 1127 to remove sockets
and FFS (were they even there yet), then to add Dennis's stream I/O
system, Tom Killian's original /proc, and Peter Weinberger's neta
network-file-system client. Perhaps a few other hooks as well.
Symlinks were already there, and although we made some limited careful
use of them, made nobody very happy because they made such a big
irregular lump in so many things: file system no longer a tree,
difference between stat and lstat, and so on.
One thing 8/e did differently from Berkeley was that ls by default
hid symlinks rather than trotting them out proudly. If f was a
symlink, ls -l f showed the state of the target file, not that of
the link; one had to do ls -lL f to see the symlink itself.
That reflected a general feeling that symlinks should be neither
seen nor heard unless necessary.
Norman Wilson
Toronto ON
William Pechter:
Only thing I can think of is add another drive or partition and mount it
as /tmp.
=====
You say that as if it's a bad thing.
Norman Wilson
Toronto ON
mount >> ln -s
Just to be clear: I don't pine at all for UUCP.
I do still think it's a mistake that e-mail addresses and
domain names run backwards from the way directories and
filenames run. That's what I miss about !norman vs
norman@.
But it's all a Beta-vs-VHS matter these days, like a lot
of unfortunate design decisions that have become standard
over the years. Like git winning out over hg, which is
sort of like the VAX/VMS command language winning out over
the Bourne shell. (To toss another pebble into the pond
to see what the ripples look like, rather in the manner
of Rob and Dave.)
Norman Wilson
Toronto ON
