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.)
And now, we bring the RMS/Gnu thread to a close :-)
To kick a more relevant thread off, what was the "weirdest" Unix system you used & why? Could be an emulation like Eunice, could be the hardware e.g NULL was not zero, NUXI byte ordering etc.
Cheers, Warren
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
On Sun, Sep 3, 2017 at 11:08 AM, Warner Losh <imp(a)bsdimp.com> wrote:
>
>
> On Sat, Sep 2, 2017 at 8:54 PM, Dave Horsfall <dave(a)horsfall.org> wrote:
>
>> On Sat, 2 Sep 2017, Nemo wrote:
>>
>> Hhhmmm... This begs the historical question: When did LF replace CR/LF
>>> in UNIX?
>>>
>>
>> Unix has always used NL as the terminator :-)
>
>
> <CR><LF> was the line terminator in DEC operating systems that grew up
> around the same time as Unix. CP/M and MS-DOS inherited that from them
> since those systems were developed, in part, using cross compilers running
> on DEC gear with DEC OSes. Unix came from the Multics world where LF was
> used as the line terminator... Thankfully, neither CP/M nor MS-DOS picked
> up DEC's RMS...
>
> Warner
>
The fun story on that Warner is after years of dogged defense of RMS, when
C was written for VMS, Cutler had to add Stream I/O. The moment is was
released, much (?most?) of customer base (including a lot of internal folks
like the compiler runtime and DB folks) switched to using it. It was so
much easier. I never heard Dave back down, but it I used to smile when I
saw the statistics.
What is your favorite UNIX. Three possible categories, choose one or more:
1) Free
2) Forced to use a commercial platform. I guess that could include
macOS and z/OS with some vivid imagination, maybe even NT.
3) Historical
Me:
1) FreeBSD - I find it to generally be the least annoying desktop and
laptop experience with admittedly careful selection of hardware to
ensure compatibility. It's ideal to me for commercial appliances and
servers due to the license, tight coupling of kernel and base, and
features like ZFS, jails, and pluggable TCP stacks. Linux distros
lost their luster for me once systemd was integrated into Debian, and
that kind of culture seems to be prevailing up and down the stack in a
way that I'd prefer to be an outside observer of Linux and not
dependent on it for now.
2) AIX - I often see people disparage AIX but I like it. I learned a
lot in my teens about C, build systems, compilers, and lots of
libraries trying to port random software to it for auto-didactic
reasons. It definitely doesn't feel like any other UNIX. It probably
supports high core count and NUMA better than any other system except
Linux, it had advanced virtualization with LPARs and containers with
WPARs before most and hot patchable kernel, fully pagable kernel, lots
of rigorous kernel engineering there that didn't get a lot of fanfare.
SMIT is kind of cool as a TUI and spits out commands that you can
learn through repetition and use at the CLI or scripting. I think it
probably peaked in the early 2000s, but the memory management, volume
management, and file systems all seemed pretty forward thinking up
until then. I don't think SMP performance was a strong suite until it
was pretty much a relegated niche though.
3) IRIX - it just screams '90s cool like an acrylic sweater. Soft
real time, immense graphics support, pro audio and video features,
lots of interesting commercial software, NUMA, supercomputers. I
enjoy tinkering on this still, but a lot of that is due to the neat
hardware.
Regards,
Kevin
Warner Losh:
It's an abundance of caution thing. This code had security problems in the
past, we're not 100% sure that we've killed all the issues, though we
believe we have.
====
And if there isn't anyone who's actively interested in the
code, willing to dig in to clean it up and make security
issues less likely, deal with multiprocessing matters, and
so on, that's a perfectly reasonable stance.
I think it's an unfortunate result, and I wonder how much
of it comes from a cultural view that sysctl >> /proc.
(Recall how Ken and Dennis originally resisted Doug's push
for pipelines and filters, because--as Dennis once put it
in a talk--it just wasn't the way programs worked?)
But as someone who is sometimes credited with removing
more code than he wrote while working on the latter-day
Research kernel, it's hard for me to argue with the principle.
A lot of the code I tossed out was complicated stuff that
was barely used if used at all, and that nobody was willing
to step up to volunteer to maintain.
Norman Wilson
Toronto ON
What's your UNIX of choice to do normal "real" things these days?
Home file server (NAS), business stuff, develop code, whatever.
Mine is Solaris 11.3 at this point. Oracle has provided almost all the
"normal" utilities that are used by Linux folk, and it runs on Intel
hardware rather well. My main storage is a raidz2 of 24TB and I get
1.2GB/sec to a bunch of 3TB 512-byte-sector SAS drives.
It serves my vmware farm with iSCSI at 10gbe using COMSTAR, which also
houses a bunch of Solaris 11 guests that perform various chores. It also
houses some Linux and Windows guests for prototyping/testing. It's also
my Samba server, servicing a few Windows workstations.
This is all in my home office where I do all my personal/professional work.
What do you all use for day-to-day development and general playing
around with new stuff?
AAK
>> The Fedora system I have access to lacks /usr/share/doc/groff
> Fedora defaults to loading only the package
"groff-base" so that man pages can be displayed. To actually use
groff for any other purpose, the packages "groff", "groff-doc",
"groff-perl", and "groff-X11" have to be installed. Annoying, but
there it is.
That explains all. Thanks.
doug
On Thu, Sep 28, 2017 at 06:44:20PM +0100, Derek Fawcus wrote:
> On Thu, Sep 28, 2017 at 08:34:28AM -0400, Chet Ramey wrote:
> > Yes, that changed in 2007 based on bug reports you filed while working at Cisco.
>
> So fd 255 is my fault? :-)
Or not - given that macOS, using an older bash already used 255:
$ set|fgrep VERSION
BASH_VERSION='3.2.57(1)-release'
$ lsof -p $$|fgrep CHR
bash 6843 derek 0u CHR 16,10 0t554677 701 /dev/ttys010
bash 6843 derek 1u CHR 16,10 0t554677 701 /dev/ttys010
bash 6843 derek 2u CHR 16,10 0t554677 701 /dev/ttys010
bash 6843 derek 255u CHR 16,10 0t554677 701 /dev/ttys010
DF
>
> It's important to note, when talking about NFS, that there was Sun's NFS
> and everyone else's NFS. Sun ran their entire company on NFS. /usr/dist
> was where all the software that was not part of SunOS lived, it was an
> NFS mounted volume (that was replicated to each subnet). It was heavily
> used as were a lot of other things. The automounter at Sun just worked,
> wanted to see your buddies stuff? You just cd-ed to it and it worked.
>
> Much like mmap, NFS did not export well to other companies. When I went
> to SGI I actually had a principle engineer (like Suns distinguished
> engineer) tell me "nobody trusts NFS, use rcp if you care about your
> data". What. The. Fuck. At Sun, NFS just worked. All the time.
> The idea that it would not work was unthinkable and if it ever did
> not work it got fixed right away.
>
> Other companies, it was a checkbox thing, it sorta worked. That was
> an eye opener for me. mmap was the same way, Sun got it right and
> other companies sort of did.
>
I remember the days of NFS Connect-a-thons where all the different
vendors would get together and see if they all interoperated. It was
interesting to see who worked and who didn’t. And all the hacking to
fix your implementation to talk to vendor X while not breaking it working
with vendor Y.
Good times indeed.
David
> From: Theodore Ts'o
> when a file was truncated and then rewritten, and "truncate this file"
> packet got reordered and got received after the "here's the new 4k of
> contents of the file", Hilar[i]ty Enused.
This sounds _exactly_ like a bad bug found in the RVD protocol (Remote Virtual
Disk - a simple block device emulator). Disks kept suffering bit rot (damage
to the inodes, IIRC). After much suffering, and pain trying to debug it (lots
of disk writes, how do you figure out the one that's the problem), it was
finally found (IIRC, it wasn't something thinking about it, they actually
caught it). Turned out (I'm pretty sure my memory of the bug is correct), if
you had two writes of the same block in quick sucession, and the second was
lost, if the first one's ack was delayed Just Enough...
They had an unused 'hint' (I think) field in the protocol, and so they
recycled that to be a sequence number, so they could tell ack's apart.
Noel
