I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
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.)
Hi all, I received an e-mail looking for the ksh-88 source code. A quick
search for it on-line doesn't reveal it. Does anybody have a copy?
I recently built a PiDP11 and have been enjoying going back in time
to 2.11BSD.. I was at UC Davis in the the early 1980's and we had
a few PDP-11/70's running 2.8/2.9 BSD. Back then we reached out to
David Korn and he sent us the source for KSH -- this would have been
in 1985ish if I remember, and we compiled it for 2.9 & 4.1BSD, Xenix,
and some other variants that used K&R C. It may have been what was
later called ksh88. I wish I still had the files from then..
I was wondering if you might know if there's an older version like this
or one that's been ported for 2.11BSD?
Is it okay for me to ask a question about Linux that's from '91~'92?
Does anyone happen to have copies of H.J. Lu's Bootable Root and the
associated Linux Base System disk images from the early '90s?
I've managed to find a copy of 0.98.pl5-31 bootable root disk. But I
can't find any base disks to go along with it.
The files used to be on tsx-11.mit.edu:/pub/linux/GCC in rootdisk and
Unfortunately all of the mirrors I'm finding of tsx-11 are newer, have
the basedisk directories, but no image files there in.
Grant. . . .
unix || die
What's the current status of net/2?
I ask because I have a FreeBSD 126.96.36.199 CVS repo that I'd like to make
available. Some of the files in it are encumbered, though, and the
University of California has communicated that fact. But what does that
actually mean now that V7 has been released and that's what the files were
based on? Are they no longer encumbered?
For sure, I've seen at least two interesting changes:
- market forces have pushed fast iteration and fast prototyping into the
mainstream in the form of Silicon valley "fail fast" culture and the
"agile" culture. This, over the disastrous "waterfall" style, has led to a
momentous improvement in overall productivity improvements.
- As coders get pulled away from the machine and performance is less and
less in coders hands, engineers aren't sucked into (premature) optimization
On Sat, Jan 30, 2021 at 6:10 AM M Douglas McIlroy <
> Have you spotted an evolutionary trend toward better, more productive
> programmers? Or has programmer productivity risen across the board due to
> better tools? Arguably what's happened is that principle has been
> self-obsoleting, for we have cut back on the demand for unskilled (i.e.
> less capable) programmers. A broad moral principle may be in play:
> programmers should work to put themselves out of business, i.e. it is wrong
> to be doing the same kind of work (or working in the same way) tomorrowas
> On Tue, Jan 26, 2021 at 5:23 AM Tyler Adams <coppero1237(a)gmail.com> wrote:
>> Looking at the 1978 list, the last one really stands out:
>> "Use tools in preference to unskilled help to lighten a programming task"
>> -- The concept of unskilled help for a programming task...doesn't really
>> exist in 2020. The only special case is doing unskilled labor yourself.
>> What unskilled tasks did people used to do back in the day?
>> On Tue, Jan 26, 2021 at 4:07 AM M Douglas McIlroy <
>> m.douglas.mcilroy(a)dartmouth.edu> wrote:
>>> It might be interesting to compare your final list with the two lists in
>>> the 1978 special issue of the BSTJ--one in the Foreword, the other in the
>>> revised version of the Ritchi/Thompson article from the CACM. How have
>>> perceptions or values changed over time?
>>> On Mon, Jan 25, 2021 at 7:32 AM Steve Nickolas <usotsuki(a)buric.co>
>>>> On Mon, 25 Jan 2021, Tyler Adams wrote:
>>>> > I'm writing about my 5 favorite unix design principles on my blog this
>>>> > week, and it got me wondering what others' favorite unix design
>>>> > are? For reference, mine are:
>>>> > - Rule of Separation (from TAOUP <
>>>> > )
>>>> > - Let the Machine Do the Dirty Work (from Elements of Programming
>>>> > - Rule of Silence (from TAOUP <
>>>> > - Data Dominates (Rob Pike #5)
>>>> > - The SPOT (Single Point of Truth) Rule (from TAOUP
>>>> > <http://catb.org/~esr/writings/taoup/html/>)
>>>> > Tyler
>>>> 1. Pipes
>>>> 2. Text as the preferred format for input and output
>>>> 3. 'Most everything as a file
>>>> 4. The idea of simple tools that are optimized for a single task
>>>> 5. A powerful scripting language built into the system that, combined
>>>> 1-4, makes writing new tools heaps easier.
> - separation of code and data using read-only and read/write file systems
I'll bite. How do you install code in a read-only file system? And
where does a.out go?
My guess is that /bin is in a file system of its own. Executables from
/letc and /lib are probably there too. On the other hand, I guess
users' personal code is still read/write.
I agree that such an arrangement is prudent. I don't see a way,
though, to update bin without disrupting most running programs.
I was introduced to Unix in the mid 1990's through my wife's VMS account
at UT Arlington, where they had a portal to the WWW. I was able to
download Slackware with the 0.9 kernel on 11 floppies including X11. I
installed this on my system at the time - either a DEC Rainbow 100B? or
a handme down generic PC. A few years later at Western Illinois
University - they had some Sun Workstations there and I loved working
with them. It would be several years later, though, that I would
actually use unix in a work setting - 1998. I don't even remember what
brand of unix, but I think it was again, sun, though no gui, so not as
much love. Still, I was able to use rcs and and when my Windows bound
buddies lost a week's work because of some snafu with their backups, I
didn't lose anything - jackflash was the name of the server - good
memories :). However, after this it was all DOS and Windows until, 2005.
I'd been eyeing Macs for some time. I like the visual aesthetics and
obvious design considerations. But, in 2005, I finally had a bonus big
enough to actually buy one. I bought a G5 24" iMac and fell in love with
Mac. Next, it was a 15" G4 Powerbook. I loved those Macs until Intel
came around and then it was game over, no more PC's in my life (not
really, but emotionally, this was how I felt). With Mac going intel, I
could dual boot into Windows, Triple boot into Linux, and Quadruple boot
into FreeBSD, and I could ditch Fink and finally manage my unix tools
properly (arguable, I know) with Homebrew or MacPorts (lately, I've gone
back to MacPorts due to Homebrew's lack of support for older OS
versions, and for MacPorts seeming rationality).
Anyhow, I have thoroughly enjoyed the Mac ride, but with Catalina, the
ride got really bumpy (too much phone home, no more 32 bit programs and
since Adobe Acrobat X, which I own, outright, isn't 64 bit, among other
apps, this just in not an option for me), and with Big Sur, it's gotten
worse, potholes, sinkholes, and suchlike, and the interface is downright
patronizing (remember Microsoft Bob?). So, here I am, Mr.
Run-Any-Cutting-Edge-OS anytime guy, hanging on tooth and nail to Mac OS
Mojave where I still have a modicum of control over my environment.
My thought for the day and question for the group is... It seems that
the options for a free operating system (free as in freedom) are
becoming ever more limited - Microsoft, this week, announced that their
Edge update will remove Edge Legacy and IE while doing the update -
nuts; Mac's desktop is turning into IOS - ew, ick; and Linux is wild
west meets dictatorship and major corporations are moving in to set
their direction (Microsoft, Oracle, IBM, etc.). FreeBSD we've beat to
death over the last couple of weeks, so I'll leave it out of the mix for
now. What in our unix past speaks to the current circumstance and what
do those of you who lived those events see as possibilities for the next
revolution - and, will unix be part of it?
And a bonus question, why, oh why, can't we have a contained kernel that
provides minimal functionality (dare I say microkernel), that is
securable, and layers above it that other stuff (everything else) can
run on with auditing and suchlike for traceability?
As I find myself starting yet another project that that wants to use
ANSI control sequences for colorization of text, I find myself -- yet
again -- wondering if there is a better way to generate the output from
the code in a way that respects TERMinal capabilites.
Is there a better / different control sequence that I can ~> should use
for colorizing / stylizing output that will account for the differences
in capabilities between a VT100 and XTerm?
Can I wrap things that I output so that I don't send color control
sequences to a TERMinal that doesn't support them?
Grant. . . .
unix || die