A letter by Don Norman, from the days before he became an Apple
Macintosh enthusiast, and GUIs became a widespread thing.
No idea if he is still an Apple enthusiast, or what he thinks about
Apple so proudly touting that its current flagship OS is officially
?Unix??.
----
The truth about Unix: The user interface is horrid
Donald A. Norman
Department of Psychology and Program in Cognitive Science
Center for Human Information Processing
University of California, San Diego
La Jolla, California 92093
(to appear in Datamation)
Norman, D. A. The truth about UNIX. Datamation 27, 12 (1981).
<snip>
A letter by Don Norman, from the days before he became an Apple
Macintosh enthusiast, and GUIs became a widespread thing.
No idea if he is still an Apple enthusiast, or what he thinks about
Apple so proudly touting that its current flagship OS is officially
?Unix??.
A letter by Don Norman, from the days before he became an Apple
Macintosh enthusiast, and GUIs became a widespread thing.
The charge that Unix developers' approach to UI/UX matters is
blinkered and informed almost entirely by their own preconceptions,
in particular, is still broadly applicable to UI/UX across the whole freenix/FOSS ecosystem to this day.
Waaaaah waaaaaah UNIX is tooooooo hard to leeearrrrrrrn.You're comparing a real, full OS to a home-system toy.
Even back then it was better than fscking DOS.
The DEC systems were much more user friendly and the commands were consistant. DELETE. COPY. RENAME. APPEND. TOPS-20's TYPE command will
stop at the end of your terminal. VMS has TYPE /PAGE to
stop. Directories aren't normally deletable in VMS. If you want to
delete multiple files, you must place commas in between them. Both
systems keep multiple versions/generations for you by default. Do you
need to search a file for a string? Get this - it's called SEARCH.
The DEC systems were much more user friendly and the commands were consistant.
Directories aren't normally deletable in VMS.
On 2026-01-28, jayjwa <jayjwa@atr2.ath.cx.invalid> wrote:
The DEC systems were much more user friendly and the commands were
consistant. DELETE. COPY. RENAME. APPEND. TOPS-20's TYPE command will
stop at the end of your terminal. VMS has TYPE /PAGE to
stop. Directories aren't normally deletable in VMS. If you want to
delete multiple files, you must place commas in between them. Both
systems keep multiple versions/generations for you by default. Do you
need to search a file for a string? Get this - it's called SEARCH.
I do find the name of the TYPE command a bit counterintuitive, though.
Not that "more", or worse, "cat" or "less", is any better.
If you do, Linux is light years ahead of windows in console
usability, but in terms strictly of GUI usage I'd rate the two
systems about equal.
Lawrence D?Oliveiro wrote this post by blinking in Morse code:
A letter by Don Norman, from the days before he became an Apple
Macintosh enthusiast, and GUIs became a widespread thing.
No idea if he is still an Apple enthusiast, or what he thinks about
Apple so proudly touting that its current flagship OS is officially
?Unix??.
----
The truth about Unix: The user interface is horrid
Donald A. Norman
Department of Psychology and Program in Cognitive Science
Center for Human Information Processing
University of California, San Diego
La Jolla, California 92093
(to appear in Datamation)
Norman, D. A. The truth about UNIX. Datamation 27, 12 (1981).
<snip>
Waaaaah waaaaaah UNIX is tooooooo hard to leeearrrrrrrn.
Even back then it was better than fscking DOS.
It does appear to be an empty, petty criticism doesn't it? I mean he
wrote that long winded analysis while teenaged college students were
eargerly learning unix by the droves without much issue and plenty
finesse. Makes him seem half-rate through that lense.
Chris Ahlstrom <OFeem1987@teleworm.us> writes:
Waaaaah waaaaaah UNIX is tooooooo hard to leeearrrrrrrn.You're comparing a real, full OS to a home-system toy.
Even back then it was better than fscking DOS.
The DEC systems were much more user friendly and the commands were consistant. DELETE. COPY. RENAME. APPEND. TOPS-20's TYPE command will
stop at the end of your terminal. VMS has TYPE /PAGE to
stop. Directories aren't normally deletable in VMS. If you want to
delete multiple files, you must place commas in between them. Both
systems keep multiple versions/generations for you by default. Do you
need to search a file for a string? Get this - it's called SEARCH.
On all systems, you figure it out and then you get familiar with
it.
Nowadays I use "man -k" or I goo-goo for the info.
On Tue, 27 Jan 2026 21:32:13 -0800, Daniel wrote:
It does appear to be an empty, petty criticism doesn't it? I mean he
wrote that long winded analysis while teenaged college students were
eargerly learning unix by the droves without much issue and plenty
finesse. Makes him seem half-rate through that lense.
I do find it odd that he was taught to use ?cat? to look at files --
surely the ?more? command was already available at the time, and
provided the screenful-at-a-time display that he clearly felt was
lacking.
As for dealing with files with strange characters in their names --
the ?dsw? command he mentioned is not needed any more, and I don?t
think anything like it even exists on current *nix systems. The usual file-manipulation commands, running under current POSIX-compatible
shells, are quite able to do the job.
And of course GUIs are commonplace now, so ordinary users can happily
avoid the command line for all the ordinary-user stuff. At least on
Linux and other *nix systems. That probably answers the bulk of his criticisms, I think he would agree.
Oh, and that weird ?ed? editor is still available as part of the GNU
tools, for those who really want to use it. Thankfully it is far from
the only choice available -- and I?ve certainly never felt the need to
come close enough to touch it with a ten-foot pole.
Niklas Karlsson <nikke.karlsson@gmail.com> wrote or quoted:
I do find the name of the TYPE command a bit counterintuitive, though.
Not that "more", or worse, "cat" or "less", is any better.
This is probably a textbook case of bikeshedding. For people
who aren't into this stuff, the first thing that clicks for
them are the command names, so that's what they end up talking
about. Doesn't mean it's wrong to talk about command names.
Still, you could say that a name like "rm" instead of "remove"
is quicker to type and helps avoid the mistake of thinking you
can just use the command word like the regular English verb.
On Tue, 27 Jan 2026 21:41:59 -0700, Peter Flass wrote:
If you do, Linux is light years ahead of windows in console
usability, but in terms strictly of GUI usage I'd rate the two
systems about equal.
Worth noting that Linux is the only system in common use which gives
you a choice of GUIs.
Chris Ahlstrom <OFeem1987@teleworm.us> writes:
Lawrence D?Oliveiro wrote this post by blinking in Morse code:
A letter by Don Norman, from the days before he became an Apple
Macintosh enthusiast, and GUIs became a widespread thing.
No idea if he is still an Apple enthusiast, or what he thinks about
Apple so proudly touting that its current flagship OS is officially
?Unix??.
----
The truth about Unix: The user interface is horrid
Donald A. Norman
Department of Psychology and Program in Cognitive Science
Center for Human Information Processing
University of California, San Diego
La Jolla, California 92093
(to appear in Datamation)
Norman, D. A. The truth about UNIX. Datamation 27, 12 (1981).
<snip>
Waaaaah waaaaaah UNIX is tooooooo hard to leeearrrrrrrn.
Even back then it was better than fscking DOS.
It does appear to be an empty, petty criticism doesn't it? I mean he
wrote that long winded analysis while teenaged college students
were eargerly learning unix by the droves without much issue and plenty finesse. Makes him seem half-rate through that lense.
I never been a unix guy despite my past. Went from DOS > Windows 98 >
Linux. I use windows only for work, as it's mandated. It's fine I
guess. Im in Teams meetings all the time and anything I do, workwise, is inside a putty screen or doing diagrams.
Niklas Karlsson <nikke.karlsson@gmail.com> wrote or quoted:
I do find the name of the TYPE command a bit counterintuitive, though.
Not that "more", or worse, "cat" or "less", is any better.
This is probably a textbook case of bikeshedding. For people
who aren't into this stuff, the first thing that clicks for
them are the command names, so that's what they end up talking
about. Doesn't mean it's wrong to talk about command names.
Still, you could say that a name like "rm" instead of "remove"
is quicker to type and helps avoid the mistake of thinking you
can just use the command word like the regular English verb.
the Multics equivalent of `cat` is similyarly `print` (not to be
confused with printing to a line printer).
Chris Ahlstrom <OFeem1987@teleworm.us> writes:
Waaaaah waaaaaah UNIX is tooooooo hard to leeearrrrrrrn.You're comparing a real, full OS to a home-system toy.
Even back then it was better than fscking DOS.
The DEC systems were much more user friendly and the commands were >consistant. DELETE. COPY. RENAME. APPEND.
In article <unix-20260128130650@ram.dialup.fu-berlin.de>,
Stefan Ram <ram@zedat.fu-berlin.de> wrote:
Niklas Karlsson <nikke.karlsson@gmail.com> wrote or quoted:
I do find the name of the TYPE command a bit counterintuitive, though. >>>Not that "more", or worse, "cat" or "less", is any better.
This is probably a textbook case of bikeshedding. For people
who aren't into this stuff, the first thing that clicks for
them are the command names, so that's what they end up talking
about. Doesn't mean it's wrong to talk about command names.
Still, you could say that a name like "rm" instead of "remove"
is quicker to type and helps avoid the mistake of thinking you
can just use the command word like the regular English verb.
And that was the original motivation, of course.
Multics had a concept of an official name for a command, and
then a short version. So to list the contents of the current
working directory, one might run the `list` command:
DEC's VMS supported abbreviating commands
to the shortest unique first characters of the command name.
I do find it odd that he was taught to use ?cat? to look at files --And what of "pg"? Everyone is taught "cat" but no one mentions "pg". It
surely the ?more? command was already available at the time, and
provided the screenful-at-a-time display that he clearly felt was
lacking.
As for dealing with files with strange characters in their names --It probably stood for "delete stupid words", or possibly, the initials
the ?dsw? command he mentioned is not needed any more, and I don?t
think anything like it even exists on current *nix systems.
Oh, and that weird ?ed? editor is still available as part of the GNU.sos ed.txt
tools, for those who really want to use it. Thankfully it is far from
the only choice available -- and I?ve certainly never felt the need to
come close enough to touch it with a ten-foot pole.
On 2026-01-28, Scott Lurndal <scott@slp53.sl.home> wrote:
DEC's VMS supported abbreviating commands
to the shortest unique first characters of the command name.
And appears to have been an inspiration for the Cisco IOS CLI, where you
can do the same thing. Also you'll go "show X" much the same as you
would in VMS to get the status for something.
*nix shells eventually evolved completion, which is at least a coarse approximation of the abbreviation ability, at least for the part of the command that is an actual executable... though you can program it to do
more if you put enough effort in.
Niklas
On 1/28/26 05:07, Stefan Ram wrote:
Niklas Karlsson <nikke.karlsson@gmail.com> wrote or quoted:
I do find the name of the TYPE command a bit counterintuitive, though.
Not that "more", or worse, "cat" or "less", is any better.
This is probably a textbook case of bikeshedding. For people
who aren't into this stuff, the first thing that clicks for
them are the command names, so that's what they end up talking
about. Doesn't mean it's wrong to talk about command names.
Still, you could say that a name like "rm" instead of "remove"
is quicker to type and helps avoid the mistake of thinking you
can just use the command word like the regular English verb.
If you were really concerned, I guess you could set up aliases for
commands. Several times I've been tempted to alias "del" to "rm".
On 1/27/26 22:32, Daniel wrote:
Chris Ahlstrom <OFeem1987@teleworm.us> writes:
I never been a unix guy despite my past. Went from DOS > Windows 98 >
Linux. I use windows only for work, as it's mandated. It's fine I
guess. Im in Teams meetings all the time and anything I do, workwise, is
inside a putty screen or doing diagrams.
I went from DOS > OS/2 > Linux, with a short diversion thru Minix. Wife
runs windows, so I've had to play with that a little, but never was an actual windows user. I was a mainframe sysprog, and my job didn't
involve PCs, so I managed to stick with OS/2 at work until I left.
the ?dsw? command he mentioned is not needed any more, and I don?tIt probably stood for "delete stupid words", or possibly, the initials
think anything like it even exists on current *nix systems.
of the programmer's name.
Could Multics `print` also concatenate files, which is after all where
the name `cat` comes from?
Lawrence D?Oliveiro <ldo@nz.invalid> writes:
I do find it odd that he was taught to use ?cat? to look at files --And what of "pg"? Everyone is taught "cat" but no one mentions "pg". It
surely the ?more? command was already available at the time, and
provided the screenful-at-a-time display that he clearly felt was
lacking.
had to have been around back then. My Linux verson is util-linux, but my >Sun/illumos one has a man page dated 1996.
Peter Flass wrote this post by blinking in Morse code:
On 1/27/26 22:32, Daniel wrote:
Chris Ahlstrom <OFeem1987@teleworm.us> writes:
I never been a unix guy despite my past. Went from DOS > Windows 98 >
Linux. I use windows only for work, as it's mandated. It's fine I
guess. Im in Teams meetings all the time and anything I do, workwise, is >>> inside a putty screen or doing diagrams.
I went from DOS > OS/2 > Linux, with a short diversion thru Minix. Wife
runs windows, so I've had to play with that a little, but never was an
actual windows user. I was a mainframe sysprog, and my job didn't
involve PCs, so I managed to stick with OS/2 at work until I left.
My history from the very beginning:
- PDP-8/e "EduSystem" in high-school, starting with
hollerith cards marked with a number 2 pencil, then on to
the teletype with paper tape. BASIC.
- In early college, some unknown time-sharing system,
learning Algol.
Later a DEC system and a DECwriter.
- First job:
On 2026-01-28, Scott Lurndal <scott@slp53.sl.home> wrote:
DEC's VMS supported abbreviating commands
to the shortest unique first characters of the command name.
And appears to have been an inspiration for the Cisco IOS CLI, where you
can do the same thing. Also you'll go "show X" much the same as you
would in VMS to get the status for something.
*nix shells eventually evolved completion, which is at least a coarse approximation of the abbreviation ability, at least for the part of the command that is an actual executable... though you can program it to do
more if you put enough effort in.
And what of "pg"? Everyone is taught "cat" but no one mentions "pg". It
had to have been around back then. My Linux verson is util-linux, but my Sun/illumos one has a man page dated 1996.
On 1/28/26 13:19, Scott Lurndal wrote:
What used to drive me nuts, and still does occasionally, is that I want
to use "type" instead of "cat" to display a file on my terminal.
more(1) appeared in west coast unix. It appears that it was written
at Berkeley in 1978.
I continue to lament that more people involved in wrecking Linux
haven't read the old Labs unix papers and books.
Still, you could say that a name like "rm" instead of "remove" is
quicker to type ...
The truth about Unix: The user interface is horrid
Donald A. Norman
Waaaaah waaaaaah UNIX is tooooooo hard to leeearrrrrrrn.
*nix shells eventually evolved completion, which is at least a
coarse approximation of the abbreviation ability ...
Lawrence D?Oliveiro <ldo@nz.invalid> writes:
I do find it odd that he was taught to use ?cat? to look at files --And what of "pg"? Everyone is taught "cat" but no one mentions "pg". It
surely the ?more? command was already available at the time, and
provided the screenful-at-a-time display that he clearly felt was
lacking.
had to have been around back then. My Linux verson is util-linux, but my Sun/illumos one has a man page dated 1996.
jayjwa <jayjwa@atr2.ath.cx.invalid> writes:
the ?dsw? command he mentioned is not needed any more, and I don?tIt probably stood for "delete stupid words", or possibly, the initials
think anything like it even exists on current *nix systems.
of the programmer's name.
dsw is "delete from switches". The original PDP-7 version used the
console switches for confirmation rather than the terminal:
https://github.com/DoctorWkt/pdp7-unix/blob/master/src/cmd/dsw.s
("oas" is "OR accumulator with switches".)
And what of "pg"? Everyone is taught "cat" but no one mentions "pg". It
had to have been around back then. My Linux verson is util-linux, but my Sun/illumos one has a man page dated 1996.
more(1) appeared in west coast unix. It appears that it was written at Berkeley in 1978.
pg(1) appeared in east coast unix. It is first documented in Research
v8, best I can tell. It's now been removed from the POSIX spec, and at
least some Linux distros have quit building it in the util-linux
package.
My general read of the unix world is that the BSD universe attracted
more mindshare than the Bell universe.
I continue to lament that more people involved in wrecking Linux haven't
read the old Labs unix papers and books.
<snip>
Hated Visual Studio and the microsoft development environment
with a passion.
Could Multics `print` also concatenate files, which is after all
where the name `cat` comes from?
On 1/27/26 21:45, Lawrence D?Oliveiro wrote:
On Tue, 27 Jan 2026 21:41:59 -0700, Peter Flass wrote:
If you do, Linux is light years ahead of windows in console
usability, but in terms strictly of GUI usage I'd rate the two
systems about equal.
Worth noting that Linux is the only system in common use which
gives you a choice of GUIs.
As someone who uses an alternative GUI (Mate), I think this is
great, but in general it's confusing to would-be new users.
And before we get too far into the GUI wars, let's consider what has
happened to web design. <shudder>
I agree that we should try to come up with a better interface than
what currently exists. But "Ohhhh, shiny" should not be one of the
criteria. I think most people would - in the long run - appreciate a
system which simply does what you want and then gets out of the way.
(As opposed to modern design, which is based on three words: In Your
Face.)
tryThe charge that Unix developers' approach to UI/UX matters is
blinkered and informed almost entirely by their own preconceptions,
in particular, is still broadly applicable to UI/UX across the whole freenix/FOSS ecosystem to this day.
People can, and do, come up with alternatives to those traditional idiosyncratic Unix commands. Just because you haven?t bothered to
them out, doesn?t mean they don?t exist.
The DEC systems were much more user friendly and the commands were consistant. DELETE. COPY. RENAME. APPEND.
.R PIP
User friendly?
On Wed, 28 Jan 2026 01:52:19 -0000 (UTC)
Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
The charge that Unix developers' approach to UI/UX matters is
blinkered and informed almost entirely by their own
preconceptions, in particular, is still broadly applicable to
UI/UX across the whole freenix/FOSS ecosystem to this day.
People can, and do, come up with alternatives to those traditional
idiosyncratic Unix commands. Just because you haven?t bothered to
try them out, doesn?t mean they don?t exist.
They sure do - unfortunately, they're usually done by people with
the same essential mindset, who merely happen to have a different
set of personal preconceptions and idiosyncracies.
According to Chris Ahlstrom <OFeem1987@teleworm.us>:
The truth about Unix: The user interface is horrid
Donald A. Norman
Waaaaah waaaaaah UNIX is tooooooo hard to leeearrrrrrrn.
Mike Lesk wrote a rather testy reply in which he pointed out that
the "more natural" commands Norman preferred were the ones on the
PDP-10 he was accustomed to.
Someone wrote a paper I can no longer find in which they tried some experiments with different commands do see how usable a bunch of naive
users found them. Unsurprisingly, they found it was about the same
either way.
On 28 Jan 2026 15:21:20 GMT, Niklas Karlsson wrote:
Could Multics `print` also concatenate files, which is after all
where the name `cat` comes from?
Some descriptions of early Unix mention that there was also a ?dog?
command in addition to ?cat?. Though what it did was never described,
and nothing remotely resembling that name seems to exist on current
*nix systems.
Presumably it was some kind of file-concatenation utility somewhat
like cat, perhaps with additional features, but who knows ...
What used to drive me nuts, and still does occasionally, is that I want
to use "type" instead of "cat" to display a file on my terminal.
jayjwa <jayjwa@atr2.ath.cx.invalid> writes:
Lawrence D?Oliveiro <ldo@nz.invalid> writes:
I do find it odd that he was taught to use ?cat? to look at files --
surely the ?more? command was already available at the time, and
provided the screenful-at-a-time display that he clearly felt was
lacking.
And what of "pg"? Everyone is taught "cat" but no one mentions "pg". It
had to have been around back then. My Linux verson is util-linux, but my
Sun/illumos one has a man page dated 1996.
The pg(1) utility appears to have first been included in Unix V10 (1989)
and was included in SVR4 and successor USL distributions (e.g. unixware).
Lawrence D?Oliveiro wrote this post by blinking in Morse code:
Oh, and that weird ?ed? editor is still available as part of the GNU
tools, for those who really want to use it. Thankfully it is far from
the only choice available -- and I?ve certainly never felt the need to
come close enough to touch it with a ten-foot pole.
How about TECO? :-)
I had a job writing assembler code for DOS machines for a
classified ad system. The editor of choice was... EDLIN.
Very painful to page to where you wanted to go in a 1Mb file.
I showed them PC vi, but though faster to use, it took awhile to
load a 1Mb file (obviously building an index into the file), so
was categorically rejected.
My boss (from a different company) cued me onto VEDIT, which was
nicer but had a tendency to reverse all the character in its buffer.
:-D
On Wed, 28 Jan 2026 15:51:22 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
The DEC systems were much more user friendly and the commands were
consistant. DELETE. COPY. RENAME. APPEND.
.R PIP
User friendly?
Yeah, that's a statement that deserves some qualification XD
Not sure what drives the apple cult, to be honest.
It bothers me that recent Linux versions of more have changed their
behaviour so that you have to type magic keystrokes to move to the
next file in a wildcard group, or to get out of it at all.
On Wed, 28 Jan 2026 14:38:32 -0500, Chris Ahlstrom wrote:
- PDP-8/e "EduSystem" in high-school, starting with
hollerith cards marked with a number 2 pencil,
There was some sort of optical reader? That sounds like even a bigger pain
in the butt than keypunches. I suppose you could erase the pencil marks though. Hard to glue the confetti back in place.
A letter by Don Norman, from the days before he became an Apple[...]
Macintosh enthusiast, and GUIs became a widespread thing.
No idea if he is still an Apple enthusiast, or what he thinks about
Apple so proudly touting that its current flagship OS is officially
?Unix??.
----
The bad news is that Berkeley Unix is jury-rigged on top of regular[...]
Unix, so it can only patch up the faults: it can't remedy them. Grep
Lawrence D?Oliveiro wrote this post by blinking in Morse code:
A letter by Don Norman, from the days before he became an Apple
Macintosh enthusiast, and GUIs became a widespread thing.
No idea if he is still an Apple enthusiast, or what he thinks about
Apple so proudly touting that its current flagship OS is officially
?Unix??.
----
The truth about Unix: The user interface is horrid
Donald A. Norman
Department of Psychology and Program in Cognitive Science
Center for Human Information Processing
University of California, San Diego
La Jolla, California 92093
(to appear in Datamation)
Norman, D. A. The truth about UNIX. Datamation 27, 12 (1981).
<snip>
Waaaaah waaaaaah UNIX is tooooooo hard to leeearrrrrrrn.
Even back then it was better than fscking DOS.
On 28 Jan 2026 18:31:45 GMT, Niklas Karlsson wrote:
*nix shells eventually evolved completion, which is at least a
coarse approximation of the abbreviation ability ...
And also applies to other things, like file names.
In fact, command-name expansion only works because it matches an
existing file name.
On 2026-01-28, Daniel <me@sc1f1dan.com> wrote:
Not sure what drives the apple cult, to be honest.
And that's what it is, innit? See my .sig.
Lawrence D?Oliveiro <ldo@nz.invalid> writes:
I do find it odd that he was taught to use ?cat? to look at files --
surely the ?more? command was already available at the time, and
provided the screenful-at-a-time display that he clearly felt was
lacking.
And what of "pg"? Everyone is taught "cat" but no one mentions "pg". It
had to have been around back then. My Linux verson is util-linux, but my >Sun/illumos one has a man page dated 1996.
As for dealing with files with strange characters in their names --
the ?dsw? command he mentioned is not needed any more, and I don?t
think anything like it even exists on current *nix systems.
It probably stood for "delete stupid words", or possibly, the initials
of the programmer's name. TOPS-10 has DELFIL, which was so kindly
pointed out to me, to delete directories out of [1,1] which are normally
not killable via "del".
Oh, and that weird ?ed? editor is still available as part of the GNU.sos ed.txt
tools, for those who really want to use it. Thankfully it is far from
the only choice available -- and I?ve certainly never felt the need to
come close enough to touch it with a ten-foot pole.
Creating ED.TXT
00100 /bin/ed is a bit like TOPS-10's "sos" or maybe TOPS-20's "edit"
00200 but ever so slightly less user-friendly. I recall DOS had a
00300 scrolly editor so that you didn't have to use "edline" but
00400 I've since forgotten its name. Maybe it was just "edit". This
00500 was around the time Turbo Pascal and Quick BASIC were out.
00600 $
*e
[DSKB:ED.TXT]
And what of "pg"? Everyone is taught "cat" but no one mentions "pg". It
had to have been around back then. My Linux verson is util-linux, but my Sun/illumos one has a man page dated 1996.
more(1) appeared in west coast unix. It appears that it was written at >Berkeley in 1978.
pg(1) appeared in east coast unix. It is first documented in Research
v8, best I can tell. It's now been removed from the POSIX spec, and at
least some Linux distros have quit building it in the util-linux
package.
My general read of the unix world is that the BSD universe attracted
more mindshare than the Bell universe.
I continue to lament that more people involved in wrecking Linux haven't
read the old Labs unix papers and books.
On Wed, 28 Jan 2026 01:52:19 -0000 (UTC)
Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
The charge that Unix developers' approach to UI/UX matters is
blinkered and informed almost entirely by their own preconceptions,
in particular, is still broadly applicable to UI/UX across the whole
freenix/FOSS ecosystem to this day.
People can, and do, come up with alternatives to those traditional
idiosyncratic Unix commands. Just because you haven?t bothered to try
them out, doesn?t mean they don?t exist.
They sure do - unfortunately, they're usually done by people with the
same essential mindset, who merely happen to have a different set of
personal preconceptions and idiosyncracies.
In article <unix-20260128130650@ram.dialup.fu-berlin.de>,<snip description of list vs. ls on Multics>
Stefan Ram <ram@zedat.fu-berlin.de> wrote:
Niklas Karlsson <nikke.karlsson@gmail.com> wrote or quoted:
I do find the name of the TYPE command a bit counterintuitive, though. >>>>Not that "more", or worse, "cat" or "less", is any better.
This is probably a textbook case of bikeshedding. For people
who aren't into this stuff, the first thing that clicks for
them are the command names, so that's what they end up talking
about. Doesn't mean it's wrong to talk about command names.
Still, you could say that a name like "rm" instead of "remove"
is quicker to type and helps avoid the mistake of thinking you
can just use the command word like the regular English verb.
And that was the original motivation, of course.
Multics had a concept of an official name for a command, and
then a short version. So to list the contents of the current
working directory, one might run the `list` command:
DEC's VMS supported abbreviating commands
to the shortest unique first characters of the command name.
On 2026-01-28, Scott Lurndal <scott@slp53.sl.home> wrote:
DEC's VMS supported abbreviating commands
to the shortest unique first characters of the command name.
And appears to have been an inspiration for the Cisco IOS CLI, where you
can do the same thing. Also you'll go "show X" much the same as you
would in VMS to get the status for something.
*nix shells eventually evolved completion, which is at least a coarse >approximation of the abbreviation ability, at least for the part of the >command that is an actual executable... though you can program it to do
more if you put enough effort in.
Chris Ahlstrom <OFeem1987@teleworm.us> writes:
Waaaaah waaaaaah UNIX is tooooooo hard to leeearrrrrrrn.You're comparing a real, full OS to a home-system toy.
Even back then it was better than fscking DOS.
The DEC systems were much more user friendly and the commands were >>consistant. DELETE. COPY. RENAME. APPEND.
.R PIP
User friendly?
On 29/01/2026 00:36, rbowman wrote:
On Wed, 28 Jan 2026 14:38:32 -0500, Chris Ahlstrom wrote:
- PDP-8/e "EduSystem" in high-school, starting with
hollerith cards marked with a number 2 pencil,
There was some sort of optical reader? That sounds like even a bigger pain >> in the butt than keypunches. I suppose you could erase the pencil marks
though. Hard to glue the confetti back in place.
No need to glue. The confetti usually sayed in place for at least a
couple of runs when pressed back into the card....
In article <FjqeR.3$%sT8.2@fx23.iad>, Scott Lurndal <slp53@pacbell.net> wrote: >>cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <unix-20260128130650@ram.dialup.fu-berlin.de>,<snip description of list vs. ls on Multics>
Stefan Ram <ram@zedat.fu-berlin.de> wrote:
Niklas Karlsson <nikke.karlsson@gmail.com> wrote or quoted:
I do find the name of the TYPE command a bit counterintuitive, though. >>>>>Not that "more", or worse, "cat" or "less", is any better.
This is probably a textbook case of bikeshedding. For people
who aren't into this stuff, the first thing that clicks for
them are the command names, so that's what they end up talking
about. Doesn't mean it's wrong to talk about command names.
Still, you could say that a name like "rm" instead of "remove"
is quicker to type and helps avoid the mistake of thinking you
can just use the command word like the regular English verb.
And that was the original motivation, of course.
Multics had a concept of an official name for a command, and
then a short version. So to list the contents of the current
working directory, one might run the `list` command:
DEC's VMS supported abbreviating commands
to the shortest unique first characters of the command name.
Yeah, that was kind of nifty. TOPS-20/TENEX does it, as well.
On 1/28/26 16:45, Lawrence D?Oliveiro wrote:
On 28 Jan 2026 15:21:20 GMT, Niklas Karlsson wrote:
Could Multics `print` also concatenate files, which is after all
where the name `cat` comes from?
Some descriptions of early Unix mention that there was also a ?dog?
command in addition to ?cat?. Though what it did was never described,
and nothing remotely resembling that name seems to exist on current
*nix systems.
Presumably it was some kind of file-concatenation utility somewhat
like cat, perhaps with additional features, but who knows ...
Maybe it just barked. Burroughs 5500 MCP has a SPO (console) command EI,
and all it did was reply EIO.
David Wade <g4ugm@dave.invalid> writes:
On 29/01/2026 00:36, rbowman wrote:
On Wed, 28 Jan 2026 14:38:32 -0500, Chris Ahlstrom wrote:
- PDP-8/e "EduSystem" in high-school, starting with
hollerith cards marked with a number 2 pencil,
There was some sort of optical reader? That sounds like even a bigger pain >>> in the butt than keypunches. I suppose you could erase the pencil marks
though. Hard to glue the confetti back in place.
No need to glue. The confetti usually sayed in place for at least a
couple of runs when pressed back into the card....
Technical term for that 'confetti' was 'chad'. (See 2000 US election).
We once balanced a box of chad atop a partially opened door
in a colleagues office as a prank.
On 2026-01-28, Chris Ahlstrom <OFeem1987@teleworm.us> wrote:
Lawrence D?Oliveiro wrote this post by blinking in Morse code:
Oh, and that weird ?ed? editor is still available as part of the GNU
tools, for those who really want to use it. Thankfully it is far from
the only choice available -- and I?ve certainly never felt the need to
come close enough to touch it with a ten-foot pole.
My only connection with ed is that I use :x in vim to save and quit.
How about TECO? :-)
I had a job writing assembler code for DOS machines for a
classified ad system. The editor of choice was... EDLIN.
Very painful to page to where you wanted to go in a 1Mb file.
I found that edlin was just enough like CP/M's ed to feel familiar,
and just enough different to bite you.
I showed them PC vi, but though faster to use, it took awhile to
load a 1Mb file (obviously building an index into the file), so
was categorically rejected.
My boss (from a different company) cued me onto VEDIT, which was
nicer but had a tendency to reverse all the character in its buffer.
:-D
My editor of choice in my MS-DOS days was KEDIT.
On Thu, 29 Jan 2026 06:30:38 GMT, Charlie Gibbs wrote:
It bothers me that recent Linux versions of more have changed their
behaviour so that you have to type magic keystrokes to move to the
next file in a wildcard group, or to get out of it at all.
It?s always been ?:n? for next file, ?:p? for previous file, ?q? to
quit, for both more and less, for as long as I can remember.
In article <_fqeR.2$%sT8.0@fx23.iad>, Scott Lurndal <slp53@pacbell.net> wrote:
jayjwa <jayjwa@atr2.ath.cx.invalid> writes:
Chris Ahlstrom <OFeem1987@teleworm.us> writes:
Waaaaah waaaaaah UNIX is tooooooo hard to leeearrrrrrrn.
Even back then it was better than fscking DOS.
You're comparing a real, full OS to a home-system toy.
The DEC systems were much more user friendly and the commands were
consistant. DELETE. COPY. RENAME. APPEND.
.R PIP
User friendly?
Peripheral Interchange Program. That's easy enough, right?
Right?
David Wade <g4ugm@dave.invalid> writes:
On 29/01/2026 00:36, rbowman wrote:
On Wed, 28 Jan 2026 14:38:32 -0500, Chris Ahlstrom wrote:
- PDP-8/e "EduSystem" in high-school, starting with
hollerith cards marked with a number 2 pencil,
There was some sort of optical reader? That sounds like even a bigger pain >>> in the butt than keypunches. I suppose you could erase the pencil marks
though. Hard to glue the confetti back in place.
No need to glue. The confetti usually sayed in place for at least a
couple of runs when pressed back into the card....
Technical term for that 'confetti' was 'chad'. (See 2000 US election).
We once balanced a box of chad atop a partially opened door
in a colleagues office as a prank.
Peter Flass <Peter@Iron-Spring.com> writes:
Maybe it just barked. Burroughs 5500 MCP has a SPO (console)
command EI, and all it did was reply EIO.
We had that on the B3500 systems as well. We also had the BO (Blackout) command for hardcopy terminals to 'black out' a password.
When you executed that command, it would print 8 'W' and overprint
with 8 'X' and 8 'M' characters.
On 2026-01-29, Charlie Gibbs wrote:
On 2026-01-28, Daniel <me@sc1f1dan.com> wrote:
Not sure what drives the apple cult, to be honest.
And that's what it is, innit? See my .sig.
But but UI consistency is bad! Hardware buttons are bad!
You're holding it wrong!
I can't help but think that his criticism isn't so much aboutI can't imagine anything worse. I may not love some of the commands, but renaming or extending would be a complete disaster!
Unix the operating system, but more about the shell, programming
libraries, and names of standard commands. But one of the
enduring strengths of Unix was that _all_ of those things could
be changed. Nothing has ever stopped a site from creating an
`/altunix/bin` directory full of differently named programs that
do whatever it is that Norman would want, including a different
shell with different behavior with respect to globbing and so
on.
On 2026-01-29, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
In article <_fqeR.2$%sT8.0@fx23.iad>, Scott Lurndal <slp53@pacbell.net> wrote:
jayjwa <jayjwa@atr2.ath.cx.invalid> writes:
Chris Ahlstrom <OFeem1987@teleworm.us> writes:
Waaaaah waaaaaah UNIX is tooooooo hard to leeearrrrrrrn.
Even back then it was better than fscking DOS.
You're comparing a real, full OS to a home-system toy.
The DEC systems were much more user friendly and the commands were
consistant. DELETE. COPY. RENAME. APPEND.
.R PIP
User friendly?
Peripheral Interchange Program. That's easy enough, right?
Right?
I always hated the name PIP. "Peripheral Interchange Program"
sounds like some sort of support system for device independence
and/or hardware reconfiguration, not a file copy utility.
MTS on the 2741 terminals would prepare the paper for a password
with overstruck W, M, B, and I. (We discovered this by manually
turning the form advance knob between each line.)
On 2026-01-29, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
On Thu, 29 Jan 2026 06:30:38 GMT, Charlie Gibbs wrote:
It bothers me that recent Linux versions of more have changed
their behaviour so that you have to type magic keystrokes to move
to the next file in a wildcard group, or to get out of it at all.
It?s always been ?:n? for next file, ?:p? for previous file, ?q? to
quit, for both more and less, for as long as I can remember.
Perhaps, but the version I had (which came standard with whatever
version of Debian I was using at the time) would let you scan
through multiple files with nothing more than the space bar.
Lawrence D?Oliveiro <ldo@nz.invalid> writes:
I do find it odd that he was taught to use ?cat? to look at files
-- surely the ?more? command was already available at the time, and
provided the screenful-at-a-time display that he clearly felt was
lacking.
And what of "pg"? Everyone is taught "cat" but no one mentions "pg".
It had to have been around back then. My Linux verson is util-linux,
but my Sun/illumos one has a man page dated 1996.
On Thu, 29 Jan 2026 19:32:16 GMT, Charlie Gibbs wrote:
I always hated the name PIP. "Peripheral Interchange Program" sounds
like some sort of support system for device independence and/or hardware
reconfiguration, not a file copy utility.
Pip Installs Packages.
I always hated the name PIP. "Peripheral Interchange Program" sounds
like some sort of support system for device independence and/or
hardware reconfiguration, not a file copy utility.
According to Chris Ahlstrom <OFeem1987@teleworm.us>:
The truth about Unix: The user interface is horrid
Donald A. Norman
Waaaaah waaaaaah UNIX is tooooooo hard to leeearrrrrrrn.
Mike Lesk wrote a rather testy reply in which he pointed out that
the "more natural" commands Norman preferred were the ones on the
PDP-10 he was accustomed to.
On Thu, 29 Jan 2026 19:32:16 GMT, Charlie Gibbs wrote:
On 2026-01-29, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
On Thu, 29 Jan 2026 06:30:38 GMT, Charlie Gibbs wrote:
It bothers me that recent Linux versions of more have changed
their behaviour so that you have to type magic keystrokes to move
to the next file in a wildcard group, or to get out of it at all.
It?s always been ?:n? for next file, ?:p? for previous file, ?q? to
quit, for both more and less, for as long as I can remember.
Perhaps, but the version I had (which came standard with whatever
version of Debian I was using at the time) would let you scan
through multiple files with nothing more than the space bar.
I just checked /usr/bin/more, and it still works that way.
Can?t find an option to have less do the same, but I don?t see that as
a big loss ...
On Thu, 29 Jan 2026 19:32:19 GMT, Charlie Gibbs wrote:
Don't laugh. The other day I was on the phone with our User from Hell -
I was having trouble getting him to double-click an icon. As far as I
can tell, he was either holding the mouse backwards so the buttons were
reversed, or (less likely) he had stumbled up on the setting that
reverses the buttons.
I'm left handed so the first thing I do is reverse the buttons. It's interesting watching someone try to use it. I sometimes forget that before logging into a Linux session the buttons are not reversed.
I do a mental switch too. I 'right click' to bring up menus although it's really a 'left click'.
Lawrence D?Oliveiro <ldo@nz.invalid> writes:
I do find it odd that he was taught to use ?cat? to look at files --And what of "pg"? Everyone is taught "cat" but no one mentions "pg". It
surely the ?more? command was already available at the time, and
provided the screenful-at-a-time display that he clearly felt was
lacking.
had to have been around back then. My Linux verson is util-linux, but my Sun/illumos one has a man page dated 1996.
Oh, and that weird ?ed? editor is still available as part of the GNU
tools, for those who really want to use it. Thankfully it is far from
the only choice available -- and I?ve certainly never felt the need to
come close enough to touch it with a ten-foot pole.
.sos ed.txt
Creating ED.TXT
00100 /bin/ed is a bit like TOPS-10's "sos" or maybe TOPS-20's "edit"
00200 but ever so slightly less user-friendly. I recall DOS had a
00300 scrolly editor so that you didn't have to use "edline" but
00400 I've since forgotten its name. Maybe it was just "edit". This
00500 was around the time Turbo Pascal and Quick BASIC were out.
00600 $
*e
[DSKB:ED.TXT]
On 1/29/26 07:06, Dan Cross wrote:
I can't help but think that his criticism isn't so much about
Unix the operating system, but more about the shell, programming
libraries, and names of standard commands. But one of the
enduring strengths of Unix was that _all_ of those things could
be changed. Nothing has ever stopped a site from creating an
`/altunix/bin` directory full of differently named programs that
do whatever it is that Norman would want, including a different
shell with different behavior with respect to globbing and so
on.
I can't imagine anything worse. I may not love some of the commands, but >renaming or extending would be a complete disaster!
On Thu, 29 Jan 2026 19:32:16 GMT, Charlie Gibbs wrote:
I always hated the name PIP. "Peripheral Interchange Program" sounds
like some sort of support system for device independence and/or
hardware reconfiguration, not a file copy utility.
If it was called something like ?Peripheral Manager Program? or
?Peripheral Configuration Program?, I would agree you had a point. But
I think the word ?Interchange? is a hint that there?s something
involving actual I/O going on.
(No, the concept of ?interchange? of peripherals themselves is not
something that would have made sense back then.)
that was in your $PATH. And a shell was just aother program.
So if you _wanted_ to live in an alternative universe of
commands and interpreters, you could by simply adding the
directory where they lived earlier in your $PATH, but you did't
have to, nor did you have to change anything about the base
system to do it.
On 1/30/26 04:01, Dan Cross wrote:
that was in your $PATH. And a shell was just aother program.
So if you _wanted_ to live in an alternative universe of
commands and interpreters, you could by simply adding the
directory where they lived earlier in your $PATH, but you did't
have to, nor did you have to change anything about the base
system to do it.
The shell is a very powerful feature, which unix borrowed from Multics
and extended. Previous to this the command interpreter (like
command.com) was part of the OS and couldn't be changed much. To run a >program, you had to type "run <program>" and programs couldn't easily be >connected.
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
On 2026-01-28, Scott Lurndal <scott@slp53.sl.home> wrote:
jayjwa <jayjwa@atr2.ath.cx.invalid> writes:Oh yeah, pg. I forgot about that one. It's been a long time.
Lawrence D?Oliveiro <ldo@nz.invalid> writes:
I do find it odd that he was taught to use ?cat? to look at files -- >>>>> surely the ?more? command was already available at the time, and
provided the screenful-at-a-time display that he clearly felt was
lacking.
And what of "pg"? Everyone is taught "cat" but no one mentions "pg". It >>>> had to have been around back then. My Linux verson is util-linux, but my >>>> Sun/illumos one has a man page dated 1996.
The pg(1) utility appears to have first been included in Unix V10 (1989) >>> and was included in SVR4 and successor USL distributions (e.g. unixware). >>
It bothers me that recent Linux versions of more have changed their
behaviour so that you have to type magic keystrokes to move to the
next file in a wildcard group, or to get out of it at all.
Actually I had the opposite problem: a program starts 'more' in
a terminal window to show content of a file. Now, when the file
fits into a single screen 'more' immediately quits and the
termianal window vanishes. That works with 'less', but recent
Linux distributions seem to skip 'less', so only 'more' may
be available.
On 1/29/26 16:48, Lawrence D?Oliveiro wrote:
On Thu, 29 Jan 2026 19:32:16 GMT, Charlie Gibbs wrote:
I always hated the name PIP. "Peripheral Interchange Program" sounds
like some sort of support system for device independence and/or
hardware reconfiguration, not a file copy utility.
If it was called something like ?Peripheral Manager Program? or
?Peripheral Configuration Program?, I would agree you had a point. But
I think the word ?Interchange? is a hint that there?s something
involving actual I/O going on.
(No, the concept of ?interchange? of peripherals themselves is not
something that would have made sense back then.)
Interchange of data. Copy Paper Tape to DECTape or something,like that?
On 2026-01-28, Chris Ahlstrom <OFeem1987@teleworm.us> wrote:
Lawrence D?Oliveiro wrote this post by blinking in Morse code:
Oh, and that weird ?ed? editor is still available as part of the GNU
tools, for those who really want to use it. Thankfully it is far from
the only choice available -- and I?ve certainly never felt the need to
come close enough to touch it with a ten-foot pole.
My only connection with ed is that I use :x in vim to save and quit.
How about TECO? :-)
I had a job writing assembler code for DOS machines for a
classified ad system. The editor of choice was... EDLIN.
Very painful to page to where you wanted to go in a 1Mb file.
I found that edlin was just enough like CP/M's ed to feel familiar,
and just enough different to bite you.
I showed them PC vi, but though faster to use, it took awhile to
load a 1Mb file (obviously building an index into the file), so
was categorically rejected.
My boss (from a different company) cued me onto VEDIT, which was
nicer but had a tendency to reverse all the character in its buffer.
:-D
My editor of choice in my MS-DOS days was KEDIT.
If it was called something like ?Peripheral Manager Program? orIt moves data around. Many of the things it does can be done using the
?Peripheral Configuration Program?, I would agree you had a point. But
I think the word ?Interchange? is a hint that there?s something
involving actual I/O going on.
(No, the concept of ?interchange? of peripherals themselves is not
something that would have made sense back then.)
Could it be that in Charlie's system the distro somehow found it fitting
to alias more to less?
On 2026-01-28, John Levine wrote:
According to Chris Ahlstrom <OFeem1987@teleworm.us>:
The truth about Unix: The user interface is horrid
Donald A. Norman
Waaaaah waaaaaah UNIX is tooooooo hard to leeearrrrrrrn.
Mike Lesk wrote a rather testy reply in which he pointed out that
the "more natural" commands Norman preferred were the ones on the
PDP-10 he was accustomed to.
If this is true, that's a huge bias which really should be accounted for
when discussing user interface design, instead of letting it influence
the criticism. A bit amateurish, I'd say?
In general I do get a bit wary if the expressions "user friendly" and "intuitive" are used without clear objectiveness, and this kind of "preference" I'd put in the same drawer as "intuitive".
Peter Flass wrote this post by blinking in Morse code:
On 1/29/26 16:48, Lawrence D?Oliveiro wrote:
On Thu, 29 Jan 2026 19:32:16 GMT, Charlie Gibbs wrote:
I always hated the name PIP. "Peripheral Interchange Program" sounds
like some sort of support system for device independence and/or
hardware reconfiguration, not a file copy utility.
If it was called something like ?Peripheral Manager Program? or
?Peripheral Configuration Program?, I would agree you had a point.
But I think the word ?Interchange? is a hint that there?s something
involving actual I/O going on.
(No, the concept of ?interchange? of peripherals themselves is not
something that would have made sense back then.)
Interchange of data. Copy Paper Tape to DECTape or something,like that?
<https://en.wikipedia.org/wiki/Peripheral_Interchange_Program>
Fog Lamps, n.:
Excessively (often obnoxiously) bright lamps mounted on the fronts
of automobiles; used on dry, clear nights to indicate that the
driver's brain is in a fog. See also "Idiot Lights".
On Thu, 29 Jan 2026 06:30:38 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
It was more Jeff Gribbin's (John's brother) choice, but I used it and
My editor of choice in my MS-DOS days was KEDIT.
wrote a heap of macros (all lost now) in "ked" to customise the CMS type XEDIT port to more of a DOS 'Edit' thing, with a few extras like
box-drawing (that used 8? out of the 10 flags available).
I still resort to it occasionally for the "column delete" that just isn't there in a lot of modern WP type programs.
Fog Lamps, n.:
Excessively (often obnoxiously) bright lamps mounted on the
fronts of automobiles; used on dry, clear nights to indicate
that the driver's brain is in a fog. See also "Idiot
Lights".
Sadly, this statement is now out of date. Many standard headlights
are now excessively, obnoxiously, and dangerously bright. It started
in the late '80s with the new concept of daytime running lights being implemented on the high beam lamps, and has evolved into (sometimes deliberately) misadjusted HID and LED lamps. And automobile ads
glorify it.
On Fri, 30 Jan 2026 15:50:45 GMT, Scott Lurndal wrote:
Are you sure about that last statement? My experience has been the
opposite, where the distros (Fedora, Ubuntu) seem to prefer 'less' over
'more' (no pun intended).
$ more --version
more from util-linux 2.41
$ less --version
less 668 (GNU regular expressions)
Copyright (C) 1984-2024 Mark Nudelman
less comes with NO WARRANTY, to the extent permitted by law.
For information about the terms of redistribution,
see the file named README in the less distribution.
Home page: https://greenwoodsoftware.com/less
That's Ubunto 25.10. Fedora 43 is the same.
All uti-linux packages are not the same. Neither Ubuntu or Fedora has the >legacy 'pg' but Arch does.
https://en.wikipedia.org/wiki/Util-linux
From the Ubuntu man more
DESCRIPTION
more is a filter for paging through text one screenful at a time. This >version is especially primitive. Users should realize that less(1)
provides more(1) emulation plus extensive enhancements.
Not sure what drives the apple cult, to be honest.
And that's what it is, innit? See my .sig.
But but UI consistency is bad! Hardware buttons are bad! You're
holding it wrong!
Completion and abbreviation aren't exactly the same thing, and
completion in the TOPS-20 sense is much more evolved than anything
Unix has done.
It's a shame that the industry collectively is so fixated on Unix-y
systems and spends so little looking at other historical designs:
there are a lot of great lessons to be learned out there, if folks
would just take a look.
I don't know how many left handed people use the mouse left handed.
For me I have better fine control. However I play guitars, banjos,
flutes and shoot long guns in the normal right handed manner so it's
all what you learn.
fwiw, if I'm at a computer with a right handed mouse I use it right
handed. It's a little awkward but the buttons work out naturally.
The shell is a very powerful feature, which unix borrowed from
Multics and extended. Previous to this the command interpreter
(like command.com) was part of the OS and couldn't be changed much.
To run a program, you had to type "run <program>" and programs
couldn't easily be connected.
To be fair, real operating systems (the set of which doesn't include
either Windows or MS-DOS), had mechanisms to add custom commands to
the command interpreter. DCL on VMS, for example, allowed user-
defined commands.
They sure do - unfortunately, they're usually done by people with
the same essential mindset, who merely happen to have a different
set of personal preconceptions and idiosyncracies.
Feel free to show us how you would do better.
It's documented in AA-0998B-TB "User's Utilities Manual". Did I see
one on CP/M? Yes, I think so. But I never used CP/M much.
Actually I had the opposite problem: a program starts 'more' in a
terminal window to show content of a file. Now, when the file fits
into a single screen 'more' immediately quits and the termianal
window vanishes.
That works with 'less', but recent Linux distributions seem to skip
'less', so only 'more' may be available.
The shell is a very powerful feature, which unix borrowed from
Multics and extended.
I still resort to it occasionally for the "column delete" that just isn't there in a lot of modern WP type programs.
On Thu, 29 Jan 2026 00:28:49 -0000 (UTC)
Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
They sure do - unfortunately, they're usually done by people with
the same essential mindset, who merely happen to have a different
set of personal preconceptions and idiosyncracies.
Feel free to show us how you would do better.
If and when I ever write something with general-purpose utility for
persons besides myself, sure, will do! Meantime, I'll simply note
observable patterns for the record as it's germane to the
discussion.
On Fri, 30 Jan 2026 19:18:32 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
Fog Lamps, n.:
Excessively (often obnoxiously) bright lamps mounted on the
fronts of automobiles; used on dry, clear nights to indicate
that the driver's brain is in a fog. See also "Idiot
Lights".
Sadly, this statement is now out of date. Many standard headlights
are now excessively, obnoxiously, and dangerously bright. It started
in the late '80s with the new concept of daytime running lights being
implemented on the high beam lamps, and has evolved into (sometimes
deliberately) misadjusted HID and LED lamps. And automobile ads
glorify it.
Nothing like trying to watch the guide lines on a twisty mountain road
at night while getting stabbed in the eye by oncoming vehicles :/ There really oughta be a law; I have to wonder how many people have been
killed by this, over the years...
Pip Installs Packages.
Aha, a recursive acronym!
That's the legend but I'm not sure I buy it.
It moves data around. Many of the things it does can be done using the
TYPE, COPY, DIR commands.
cross@spitfire.i.gajendra.net (Dan Cross) writes:
In article <unix-20260128130650@ram.dialup.fu-berlin.de>,
Stefan Ram <ram@zedat.fu-berlin.de> wrote:
Niklas Karlsson <nikke.karlsson@gmail.com> wrote or quoted:
I do find the name of the TYPE command a bit counterintuitive, though. >>>Not that "more", or worse, "cat" or "less", is any better.
This is probably a textbook case of bikeshedding. For people
who aren't into this stuff, the first thing that clicks for
them are the command names, so that's what they end up talking
about. Doesn't mean it's wrong to talk about command names.
Still, you could say that a name like "rm" instead of "remove"
is quicker to type and helps avoid the mistake of thinking you
can just use the command word like the regular English verb.
And that was the original motivation, of course.
Multics had a concept of an official name for a command, and
then a short version. So to list the contents of the current
working directory, one might run the `list` command:
<snip description of list vs. ls on Multics>
DEC's VMS supported abbreviating commands
to the shortest unique first characters of the command name.
My only connection with ed is that I use :x in vim to save and quit.
On 2026-01-29, Charlie Gibbs wrote:
On 2026-01-28, Daniel <me@sc1f1dan.com> wrote:
Not sure what drives the apple cult, to be honest.
And that's what it is, innit? See my .sig.
But but UI consistency is bad! Hardware buttons are bad! You're holding
it wrong!
I'm left handed so the first thing I do is reverse the buttons. It's interesting watching someone try to use it. I sometimes forget that before logging into a Linux session the buttons are not reversed.
On 2026-01-30, Chris Ahlstrom <OFeem1987@teleworm.us> wrote:
<snip>
Fog Lamps, n.:
Excessively (often obnoxiously) bright lamps mounted on the fronts
of automobiles; used on dry, clear nights to indicate that the
driver's brain is in a fog. See also "Idiot Lights".
Sadly, this statement is now out of date. Many standard headlights
are now excessively, obnoxiously, and dangerously bright. It started
in the late '80s with the new concept of daytime running lights being implemented on the high beam lamps, and has evolved into (sometimes deliberately) misadjusted HID and LED lamps. And automobile ads
glorify it.
Completion and abbreviation aren't exactly the same thing, and
completion in the TOPS-20 sense is much more evolved than
anything Unix has done.
On Fri, 30 Jan 2026 07:44:21 -0700, Peter Flass wrote:
The shell is a very powerful feature, which unix borrowed from
Multics and extended.
Not sure if the shell ran as a separate process under Multics, though. Multics still subscribed to the traditional idea of the user doing
just about everything within a single process context.
The Unix innovation of creating a separate process to run every
program was revolutionary because many saw it as wasteful and
inefficient, even if it did offer much greater flexibility.
On Thu, 29 Jan 2026 14:50:23 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wrote:
Completion and abbreviation aren't exactly the same thing, and
completion in the TOPS-20 sense is much more evolved than anything
Unix has done.
Powershell in WinNT has a fairly capable completion system. Sadly, PS
is so sesquipedalian that it practically *requires* one.
It's a shame that the industry collectively is so fixated on Unix-y
systems and spends so little looking at other historical designs:
there are a lot of great lessons to be learned out there, if folks
would just take a look.
Yeah, that's long been a pet peeve of mine. Unix had some great ideas,
of course, but there've been other interesting concepts in systems
before and since that were mostly left by the wayside.
On 2026-01-29, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
Completion and abbreviation aren't exactly the same thing, and
completion in the TOPS-20 sense is much more evolved than
anything Unix has done.
No indeed, they aren't the same thing. I was only trying to say that
it's the closest you'll typically get on a *nix system.
I suppose one could write a shell that does support abbreviation. I
don't know of any such attempts (but would be very interested if they
did exist), and I could see it getting messy the way things work on
*nix.
On Fri, 30 Jan 2026 15:48:42 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
The shell is a very powerful feature, which unix borrowed from
Multics and extended. Previous to this the command interpreter
(like command.com) was part of the OS and couldn't be changed much.
To run a program, you had to type "run <program>" and programs
couldn't easily be connected.
To be fair, real operating systems (the set of which doesn't include
either Windows or MS-DOS), had mechanisms to add custom commands to
the command interpreter. DCL on VMS, for example, allowed user-
defined commands.
True, though the particulars varied by system; DCL was certainly one of
the more capable examples.
(I am curious, was Multics truly the first system to make user programs >first-class citizens of the command shell? It's such a natural way to
do things from a retrospective point of view that it seems hard to
imagine *nobody* else coming up with it 'til over a decade into the
history of interactive computing...)
Charlie Gibbs wrote to alt.folklore.computers <=-
Don't laugh. The other day I was on the phone with our
User from Hell - I was having trouble getting him to
double-click an icon.
On 1/30/26 14:18, Lawrence D?Oliveiro wrote:
On Fri, 30 Jan 2026 07:44:21 -0700, Peter Flass wrote:
The shell is a very powerful feature, which unix borrowed from
Multics and extended.
Not sure if the shell ran as a separate process under Multics, though.
Multics still subscribed to the traditional idea of the user doing
just about everything within a single process context.
The Unix innovation of creating a separate process to run every
program was revolutionary because many saw it as wasteful and
inefficient, even if it did offer much greater flexibility.
I was waiting for a reply from someone who knows more about Multics than
I do. Seeing none, I'll say I believe a user runs everything in a single >process. Late in life I think there were some moves toward multiple >threads/processes.
When I first read about the unix model, it was also my reaction that it
was extremely wasteful of resources. Obviously having the system track >multiple processes and address spaces had to add to overhead. Now
systems are powerful enough that no one cares.
On Fri, 30 Jan 2026 07:44:21 -0700, Peter Flass wrote:
The shell is a very powerful feature, which unix borrowed from
Multics and extended.
Not sure if the shell ran as a separate process under Multics, though. >Multics still subscribed to the traditional idea of the user doing
just about everything within a single process context.
The Unix innovation of creating a separate process to run every
program was revolutionary
I know about :x and ZZ, but :wq is so deep-seated in my muscle memory
that I'll probably never change that habit.
On Sat, 31 Jan 2026 06:59:30 -0500, Chris Ahlstrom wrote:
I left a brightly lit parking lot with only my running lights on,
and they were quite enough for me to see while driving at night. Then I
was so flustered I pulled out a credit card instead of my license. :-D
I did the same at dusk. The cop saw the headlights and no taillights and pulled me over for defective equipment. That was the last Toyota and the DLRs were always on. This one has a separate setting for DLR but I don't
use it.
One of the selling points for always on headlights on bikes was to help
them stand out in traffic. DLR negates that.
I'm told that early Unix was described as "profligate with
processes," but I've never found a direct quote.
I suppose one could write a shell that does support abbreviation.
Yes, the program obeys PAGER variable. But the problem is of having
sensible default for clueless users.
When I first read about the unix model, it was also my reaction that
it was extremely wasteful of resources. Obviously having the system
track multiple processes and address spaces had to add to overhead.
Now systems are powerful enough that no one cares.
And ZZ is a terrible idea.
On Sat, 31 Jan 2026 19:22:30 +0000, Dennis Boone wrote:
And ZZ is a terrible idea.
?ZZ? to save and quit, ?:q!? to abandon changes and quit. Easy enough
to remember ...
I put up with vi in the early part of my Unix-admin days, until all
the proprietary Unixes (that I had to deal with) went extinct and
Linux became dominant. At that point I could assume that Emacs would
always be available (or at least easily installable), so I switched to
using that.
Worth also pointing out that, at the time of MS-DOS 2.0 with its
introduction of some bizarro-Unix features, the commonly-available PC hardware was already more powerful than the original PDP-11 systems
that Unix was created on. So why couldn?t Microsoft (or IBM) provide a
full Unix-equivalent OS for PC hardware back then?
On 2026-01-31, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
Worth also pointing out that, at the time of MS-DOS 2.0 with its
introduction of some bizarro-Unix features, the commonly-available
PC hardware was already more powerful than the original PDP-11
systems that Unix was created on. So why couldn?t Microsoft (or
IBM) provide a full Unix-equivalent OS for PC hardware back then?
Microsoft had Xenix, which was licenced from AT&T.
I've looked at emacs a few times, but each time I come away thinking
that we're from different planets.
I?ve always been accustomed to text editors where you could begin
entering text straight away, instead of having to enter some kind of
special ?insert? mode.
You?ve done command-line editing in Bash and other apps that used GNU readline? The default key bindings for that come from Emacs.
Yeah, I definitely swear by emacs-style behavior on the command
line, even though for editing text I swear by vi(m).
On 1 Feb 2026 05:44:59 GMT, Niklas Karlsson wrote:
Yeah, I definitely swear by emacs-style behavior on the command
line, even though for editing text I swear by vi(m).
I wonder why you would settle for an editor that doesn?t offer a GUI
mode.
Emacs can run both ways.
On Sat, 31 Jan 2026 22:52:46 GMT, Charlie Gibbs wrote:
On 2026-01-31, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
Worth also pointing out that, at the time of MS-DOS 2.0 with its
introduction of some bizarro-Unix features, the commonly-available
PC hardware was already more powerful than the original PDP-11
systems that Unix was created on. So why couldn?t Microsoft (or
IBM) provide a full Unix-equivalent OS for PC hardware back then?
Microsoft had Xenix, which was licenced from AT&T.
But there was never any thought of making it more useful as a personal-computing-oriented OS.
For example, having a simple frame-buffer driver which allowed mapping
video RAM directly into a process address space. In lieu of a more
elaborate graphics API abstraction, that would have allowed the
greater immediacy of interactivity that was commonplace on single-user systems at the time.
Instead, MS-DOS followed the CP/M mindset of treating the keyboard
and screen as though they were a dumb terminal at the other end of
a low-bandwidth serial line.
On 2026-02-01, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
Instead, MS-DOS followed the CP/M mindset of treating the keyboard
and screen as though they were a dumb terminal at the other end of
a low-bandwidth serial line.
True, but if you're after a "Unix-equivalent OS", that's what Unix
was doing.
On 2026-02-01, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
On 1 Feb 2026 05:44:59 GMT, Niklas Karlsson wrote:
Yeah, I definitely swear by emacs-style behavior on the command
line, even though for editing text I swear by vi(m).
I wonder why you would settle for an editor that doesn?t offer a
GUI mode.
Emacs can run both ways.
And you think vim can't? Never heard of gvim?
That said, given the nature of my work, I often find myself working
on remote machines using SSH, and I don't usually really need the
GUI features when I'm doing that ...
On 1 Feb 2026 06:23:45 GMT, Niklas Karlsson wrote:
On 2026-02-01, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
On 1 Feb 2026 05:44:59 GMT, Niklas Karlsson wrote:
Yeah, I definitely swear by emacs-style behavior on the command
line, even though for editing text I swear by vi(m).
I wonder why you would settle for an editor that doesn?t offer a
GUI mode.
Emacs can run both ways.
And you think vim can't? Never heard of gvim?
That?s a separate program, not a separate mode of the same program.
That said, given the nature of my work, I often find myself working
on remote machines using SSH, and I don't usually really need the
GUI features when I'm doing that ...
Emacs lets me work that way too.
Worth also pointing out that, at the time of MS-DOS 2.0 with its
introduction of some bizarro-Unix features, the commonly-available PC hardware was already more powerful than the original PDP-11 systems
that Unix was created on. So why couldn?t Microsoft (or IBM) provide a
full Unix-equivalent OS for PC hardware back then?
On 1/31/26 14:05, Lawrence D?Oliveiro wrote:
Worth also pointing out that, at the time of MS-DOS 2.0 with its
introduction of some bizarro-Unix features, the commonly-available
PC hardware was already more powerful than the original PDP-11
systems that Unix was created on. So why couldn?t Microsoft (or
IBM) provide a full Unix-equivalent OS for PC hardware back then?
No memory protection or memory mapping until the 386. There were
unix-like OSs for 8086, but they were terrible fragile without
memory protection. I don't know how it was managed on the PDP-11.
On 1/30/26 14:18, Lawrence D?Oliveiro wrote:
On Fri, 30 Jan 2026 07:44:21 -0700, Peter Flass wrote:
The shell is a very powerful feature, which unix borrowed from
Multics and extended.
Not sure if the shell ran as a separate process under Multics, though.
Multics still subscribed to the traditional idea of the user doing
just about everything within a single process context.
The Unix innovation of creating a separate process to run every
program was revolutionary because many saw it as wasteful and
inefficient, even if it did offer much greater flexibility.
I was waiting for a reply from someone who knows more about Multics than
I do. Seeing none, I'll say I believe a user runs everything in a single process. Late in life I think there were some moves toward multiple threads/processes.
When I first read about the unix model, it was also my reaction that it
was extremely wasteful of resources. Obviously having the system track multiple processes and address spaces had to add to overhead. Now
systems are powerful enough that no one cares.
In article <10ll48q$2vbi7$1@dont-email.me>,
Peter Flass <Peter@Iron-Spring.com> wrote:
On 1/30/26 14:18, Lawrence D?Oliveiro wrote:
On Fri, 30 Jan 2026 07:44:21 -0700, Peter Flass wrote:
The shell is a very powerful feature, which unix borrowed from
Multics and extended.
Not sure if the shell ran as a separate process under Multics, though.
Multics still subscribed to the traditional idea of the user doing
just about everything within a single process context.
The Unix innovation of creating a separate process to run every
program was revolutionary because many saw it as wasteful and
inefficient, even if it did offer much greater flexibility.
I was waiting for a reply from someone who knows more about Multics than
I do. Seeing none, I'll say I believe a user runs everything in a single >>process. Late in life I think there were some moves toward multiple >>threads/processes.
When I first read about the unix model, it was also my reaction that it >>was extremely wasteful of resources. Obviously having the system track >>multiple processes and address spaces had to add to overhead. Now
systems are powerful enough that no one cares.
I'm told that early Unix was described as "profligate with
processes," but I've never found a direct quote.
I know about :x and ZZ, but :wq is so deep-seated in my muscle memory
that I'll probably never change that habit.
And ZZ is a terrible idea. If you don't know whether you intended
to change the file, that'll just make sure that accidental changes
get committed blindly.
On Sat, 31 Jan 2026 19:22:30 +0000, Dennis Boone wrote:
And ZZ is a terrible idea.
?ZZ? to save and quit, ?:q!? to abandon changes and quit. Easy enough
to remember ...
I put up with vi in the early part of my Unix-admin days, until all
the proprietary Unixes (that I had to deal with) went extinct and
Linux became dominant. At that point I could assume that Emacs would
always be available (or at least easily installable), so I switched to
using that.
On Sun, 1 Feb 2026 06:15:37 -0000 (UTC), Lawrence D?Oliveiro wrote:
On 1 Feb 2026 05:44:59 GMT, Niklas Karlsson wrote:
Yeah, I definitely swear by emacs-style behavior on the command line,
even though for editing text I swear by vi(m).
I wonder why you would settle for an editor that doesn?t offer a GUI
mode.
Emacs can run both ways.
gVim is a GUI (vim-gtk). If I'm in i3 or sway I use vim in one terminal. Otherwise I use gVim. It's an old habit. gVim is a standalone GUI so I
don't lose a terminal. However I very rarely use the menu items.
I haven't touched emacs in years but that one I have to use the GUI and
the menus since I can't remember the three finger salutes for everything.
I never cared for it. Back when HDDs were tiny Vim took about 3 MB and
emacs was 24 MB. I could live without an 'editor' that told fortunes and played go.
I also use the Vim extensions in VS Code. I think Visual Stdio also has
Vim keybindings but I haven't used it for a while.
On 1/31/26 14:05, Lawrence D?Oliveiro wrote:
Worth also pointing out that, at the time of MS-DOS 2.0 with its
introduction of some bizarro-Unix features, the commonly-available PC
hardware was already more powerful than the original PDP-11 systems
that Unix was created on. So why couldn?t Microsoft (or IBM) provide a
full Unix-equivalent OS for PC hardware back then?
No memory protection or memory mapping until the 386. There were
unix-like OSs for 8086, but they were terrible fragile without memory >protection. I don't know how it was managed on the PDP-11.
I'm told that early Unix was described as "profligate with
processes," but I've never found a direct quote.
"Get a fork, get a fork, get a fork fork fork"? :)
One developer I worked with pronounced SQL as "squirrel" and PL/SQL as "peeled squirrel". This was the guy with several squirrel skulls on the
top of his monitor. I inherited those when he was fired for punching
someone fairly senior in management. -- John Burnham
John Levine has posted before about a port of Unix to the 8086,
that made use of the segmentation system to more or less protect
the OS from errant user programs; the C compiler simply did not
emit instructions to change the segmentation registers, so it
worked pretty well as I understand it.
The "TSS" (Task State Segment) has been overloaded in
64-bit "long" mode to hold a table of stack pointers that can be
used with various traps so that, say, the double-fault, NMI or debug/breakpoint handlers can run on dedicated stacks.
also some business about allowing non-privileged access to IO
ports for programmed IO from user-mode code. Anyway.
The 80386 was designed as a 32-bit CPU for the Unix workstation
market, and supported paging natively. I must say, all things
considered they did a pretty good job overall with the design of
the MMU and page table format. To maintain backwards
compabibility they extended the segmentation mechanism; the
intent was that you would define segments covering the entire
32-bit address space and then more or less ignore them.
I'm still disappointed that they didn't adopt the Multics model for
segments.
On Sun, 1 Feb 2026 12:54:26 -0700, Peter Flass wrote:
I'm still disappointed that they didn't adopt the Multics model for
segments.
I think the Multics model imposed a limit on file sizes based on the
size of the directly-accessible virtual address space. That meant that
32-bit machines could not have coped with multi-gigabyte files.
On 2/1/26 12:57, Lawrence D?Oliveiro wrote:
I think the Multics model imposed a limit on file sizes based on
the size of the directly-accessible virtual address space. That
meant that 32-bit machines could not have coped with multi-gigabyte
files.
They came up with multi-segment files to solve this problem.
The DEC systems were much more user friendly and the commands were >consistant. DELETE. COPY. RENAME. APPEND.
My only connection with ed is that I use :x in vim to save and quit.
pg(1) appeared in east coast unix. It is first documented in Research
v8, best I can tell. It's now been removed from the POSIX spec, and ...
On Sun, 1 Feb 2026 08:28:26 -0500, Chris Ahlstrom wrote:
I once tried out vi-like bindings for Microsoft Word. It did nothing to
reduce the pain of using Microsoft Word.
Even LibreOffice bugs me at times. For anything big it's LaTeX for me.
I've never used Word and for me LibreOffice is a read-only application if someone sends me a docx file. There are a lot of 'must have' applications that I've never had a use for. Unlike the famous line from 'Quigley Down Under' I can't use them either.
On 2/1/26 12:57, Lawrence D?Oliveiro wrote:
On Sun, 1 Feb 2026 12:54:26 -0700, Peter Flass wrote:
I'm still disappointed that they didn't adopt the Multics model for
segments.
I think the Multics model imposed a limit on file sizes based on the
size of the directly-accessible virtual address space. That meant that
32-bit machines could not have coped with multi-gigabyte files.
They came up with multi-segment files to solve this problem.
Charlie Gibbs wrote:
My only connection with ed is that I use :x in vim to save and quit.
That's a connection with ex not ed.
In POSIX there is no x command in ed. Some implementations have one as
an extension, but not the same as the x in ex. For example in GNU ed:
(.)x
Copies (puts) the contents of the cut buffer to after the addressed line.
In FreeBSD it looks like it used to have something to do with encryption,
but now it's not in the man page and, although the syntax is accepted, it just gives an error message (when they are enabled with H):
$ ed
H
x
?
crypt unavailable
But there was never any thought of making it more useful as a personal-computing-oriented OS.
For example, having a simple frame-buffer driver which allowed mapping
video RAM directly into a process address space. In lieu of a more
elaborate graphics API abstraction, that would have allowed the
greater immediacy of interactivity that was commonplace on single-user systems at the time.
Instead, MS-DOS followed the CP/M mindset of treating the keyboard and
screen as though they were a dumb terminal at the other end of a low- bandwidth serial line.
On Sun, 1 Feb 2026 15:06:54 -0000 (UTC), Dan Cross wrote:
The 80386 was designed as a 32-bit CPU for the Unix workstation market,
and supported paging natively. I must say, all things considered they
did a pretty good job overall with the design of the MMU and page table
format. To maintain backwards compabibility they extended the
segmentation mechanism; the intent was that you would define segments
covering the entire 32-bit address space and then more or less ignore
them.
I would say the ill fated iAPX 432 was the design for Unix workstations.
The 8086 family just sort of happened.
On 2/1/26 08:06, Dan Cross wrote:
John Levine has posted before about a port of Unix to the 8086,
that made use of the segmentation system to more or less protect
the OS from errant user programs; the C compiler simply did not
emit instructions to change the segmentation registers, so it
worked pretty well as I understand it.
As long is everything is limited to 64K data and 64K program.
The "TSS" (Task State Segment) has been overloaded in
64-bit "long" mode to hold a table of stack pointers that can be
used with various traps so that, say, the double-fault, NMI or
debug/breakpoint handlers can run on dedicated stacks.
I can see where this would be useful.
There's
also some business about allowing non-privileged access to IO
ports for programmed IO from user-mode code. Anyway.
The 80386 was designed as a 32-bit CPU for the Unix workstation
market, and supported paging natively. I must say, all things
considered they did a pretty good job overall with the design of
the MMU and page table format. To maintain backwards
compabibility they extended the segmentation mechanism; the
intent was that you would define segments covering the entire
32-bit address space and then more or less ignore them.
I'm still disappointed that they didn't adopt the Multics model for >segments.
On 2/1/26 12:57, Lawrence D?Oliveiro wrote:
On Sun, 1 Feb 2026 12:54:26 -0700, Peter Flass wrote:
I'm still disappointed that they didn't adopt the Multics model for
segments.
I think the Multics model imposed a limit on file sizes based on the
size of the directly-accessible virtual address space. That meant that
32-bit machines could not have coped with multi-gigabyte files.
They came up with multi-segment files to solve this problem.
a DECI suppose one could write a shell that does support abbreviation.
Can?t see the point, myself. In a less dynamic environment (e.g.
OS), where new commands are not added that frequently, you might bethink
able to get away with it. In a typical *nix environment, I don?t
it would work.
On Mon, 02 Feb 2026 17:36:54 GMT, Charlie Gibbs wrote:
'ed' is even more cryptic. So much for the bad old days.
rbowman <bowman@montana.com> writes:
On Mon, 02 Feb 2026 17:36:54 GMT, Charlie Gibbs wrote:
<snip>
'ed' is even more cryptic. So much for the bad old days.
There's chapter 6 in Kernighan and Plaugher's _Software Tools_
that describes ed syntax (and how to write a version of ed they call
edit).
John Levine has posted before about a port of Unix to the 8086,
that made use of the segmentation system to more or less protect
the OS from errant user programs; the C compiler simply did not
emit instructions to change the segmentation registers, so it
worked pretty well as I understand it.
As long is everything is limited to 64K data and 64K program.
I'm still disappointed that they didn't adopt the Multics model for
segments.
Multics did pioneer a few things, including the use of ACLs. One
interesting feature was that multiple entities could have ownership
rights to the same object. This something that Linux cannot manage
even today. Though Windows can do it.
A patch was submitted some years ago to add Windows-style ACL features
to Linux, but it was rejected on the grounds that they can too often
produce surprising and counterintuitive effects. Which is something
that Windows sysadmins would be all too familiar with ...
On Sun, 1 Feb 2026 12:54:26 -0700, Peter Flass wrote:
I'm still disappointed that they didn't adopt the Multics model for
segments.
Multics did pioneer a few things, including the use of ACLs.
WordStar came bundled with the CP/M computer I bought. [...]
SuperCalc was also bundled but I never figured out what to do with it.
On 2026-02-03, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
Multics did pioneer a few things, including the use of ACLs. One
interesting feature was that multiple entities could have ownership
rights to the same object. This something that Linux cannot manage
even today. Though Windows can do it.
A patch was submitted some years ago to add Windows-style ACL
features to Linux, but it was rejected on the grounds that they can
too often produce surprising and counterintuitive effects. Which is
something that Windows sysadmins would be all too familiar with ...
WTF are you talking about? POSIX ACLs have been a part of Linux for
a VERY long time now.
On 3 Feb 2026 10:56:51 GMT, Niklas Karlsson wrote:
On 2026-02-03, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
Multics did pioneer a few things, including the use of ACLs. One
interesting feature was that multiple entities could have ownership
rights to the same object. This something that Linux cannot manage
even today. Though Windows can do it.
A patch was submitted some years ago to add Windows-style ACL
features to Linux, but it was rejected on the grounds that they can
too often produce surprising and counterintuitive effects. Which is
something that Windows sysadmins would be all too familiar with ...
WTF are you talking about? POSIX ACLs have been a part of Linux for
a VERY long time now.
Maybe you should reread what I wrote. I didn?t say that Linux doesn?t
support ACLs.
Also, there are no such things as ?POSIX? ACLs. the ?POSIX? ACL
proposal never actually became part of POSIX.
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
On Sun, 1 Feb 2026 12:54:26 -0700, Peter Flass wrote:
I'm still disappointed that they didn't adopt the Multics model for
segments.
Multics did pioneer a few things, including the use of ACLs.
Again with the trolling.
Burroughs guard files (ACLs) were available in the same timeframe,
if not earlier.
Burroughs had a lot of good stuff. The problem was that no one knew
they had it. They were like a stealth company.
In article <mucdenFbufpU1@mid.individual.net>,
rbowman <bowman@montana.com> wrote:
WordStar came bundled with the CP/M computer I bought. [...]
SuperCalc was also bundled but I never figured out what to do with it.
Was it an Osborne? :) That's where I first encountered WordStar and SuperCalc.
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
On 3 Feb 2026 10:56:51 GMT, Niklas Karlsson wrote:
On 2026-02-03, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
A patch was submitted some years ago to add Windows-style ACL
features to Linux, but it was rejected on the grounds that they can
too often produce surprising and counterintuitive effects. Which is
something that Windows sysadmins would be all too familiar with ...
WTF are you talking about? POSIX ACLs have been a part of Linux for
a VERY long time now.
Maybe you should reread what I wrote. I didn?t say that Linux doesn?t >>support ACLs.
Also, there are no such things as ?POSIX? ACLs. the ?POSIX? ACL
proposal never actually became part of POSIX.
Your google-fu is failing, yet again.
https://docs.redhat.com/en/documentation/red_hat_gluster_storage/3/html/administration_guide/sect-posix_access_control_lists
I don't think anyone was thinking about Unix with the 432; the capability-based address and ties to Ada or whatever more or
less rendered it impossible.
Scott Lurndal wrote:
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
On 3 Feb 2026 10:56:51 GMT, Niklas Karlsson wrote:
On 2026-02-03, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
A patch was submitted some years ago to add Windows-style ACL
features to Linux, but it was rejected on the grounds that they can
too often produce surprising and counterintuitive effects. Which is
something that Windows sysadmins would be all too familiar with ...
WTF are you talking about? POSIX ACLs have been a part of Linux for
a VERY long time now.
Maybe you should reread what I wrote. I didn?t say that Linux doesn?t >>>support ACLs.
Also, there are no such things as ?POSIX? ACLs. the ?POSIX? ACL
proposal never actually became part of POSIX.
Your google-fu is failing, yet again.
Actually, yours is. Lawrence is correct.
On 2/3/26 08:02, Scott Lurndal wrote:
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
On Sun, 1 Feb 2026 12:54:26 -0700, Peter Flass wrote:
I'm still disappointed that they didn't adopt the Multics model for
segments.
Multics did pioneer a few things, including the use of ACLs.
Again with the trolling.
Burroughs guard files (ACLs) were available in the same timeframe,
if not earlier.
Burroughs had a lot of good stuff. The problem was that no one knew they
had it. They were like a stealth company.
On 2 Feb 2026, Dan Cross wrote
(in article <10lqp1g$et1$1@reader2.panix.com>):
I don't think anyone was thinking about Unix with the 432; the
capability-based address and ties to Ada or whatever more or
less rendered it impossible.
The ties to Ada were imaginary.
The whole point of Ada is that it was designed to provide both
high security and high efficiency o conventional architecture.
On 3 Feb 2026 10:56:51 GMT, Niklas Karlsson wrote:
On 2026-02-03, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
Multics did pioneer a few things, including the use of ACLs. One
interesting feature was that multiple entities could have ownership
rights to the same object. This something that Linux cannot manage
even today. Though Windows can do it.
A patch was submitted some years ago to add Windows-style ACL
features to Linux, but it was rejected on the grounds that they can
too often produce surprising and counterintuitive effects. Which is
something that Windows sysadmins would be all too familiar with ...
WTF are you talking about? POSIX ACLs have been a part of Linux for
a VERY long time now.
Maybe you should reread what I wrote. I didn?t say that Linux doesn?t
support ACLs.
On 2 Feb 2026, Dan Cross wrote
(in article <10lqp1g$et1$1@reader2.panix.com>):
I don't think anyone was thinking about Unix with the 432; the
capability-based address and ties to Ada or whatever more or
less rendered it impossible.
The ties to Ada were imaginary.
The whole point of Ada is that it was designed to provide both
high security and high efficiency o conventional architecture.
On 2/4/26 08:07, Bill Findlay wrote:
On 2 Feb 2026, Dan Cross wrote
(in article <10lqp1g$et1$1@reader2.panix.com>):
I don't think anyone was thinking about Unix with the 432; the
capability-based address and ties to Ada or whatever more or
less rendered it impossible.
The ties to Ada were imaginary.
The whole point of Ada is that it was designed to provide both
high security and high efficiency o conventional architecture.
It was touted as an Ada-architecture, and Intel (initially) only
provided an Ada compiler, and not a good one at that.
Can anyone tell me why they decided to use bit addressing instead of
byte addressing? One of the knocks on the architecture was the small
segment size, and they could have octupled the size with
byte-addressing. Also, it seems to me that not byte-aligning
instructions greatly increased the complexity with only a marginal
savings in storage.
In article<0001HW.2F3398230003061E30B17C38F@news.individual.net>,
Bill Findlay <findlaybill@blueyonder.co.uk> wrote:
On 2 Feb 2026, Dan Cross wrote
(in article <10lqp1g$et1$1@reader2.panix.com>):
I don't think anyone was thinking about Unix with the 432; the capability-based address and ties to Ada or whatever more or
less rendered it impossible.
The ties to Ada were imaginary.
The whole point of Ada is that it was designed to provide both
high security and high efficiency o conventional architecture.
That's pretty much orthogonal to my earlier point, which was
that the 432 was meant to be programmed, perhaps exclusively,
in a high-level language, and it featured some abstruce hardware
facilities that made running a conventional operating system
such as Unix challenging.
Whether Ada needs something like the 432 is irrelevant (and not
at all what I said)
On 2/4/26 08:07, Bill Findlay wrote:
On 2 Feb 2026, Dan Cross wrote
(in article <10lqp1g$et1$1@reader2.panix.com>):
I don't think anyone was thinking about Unix with the 432; the capability-based address and ties to Ada or whatever more or
less rendered it impossible.
The ties to Ada were imaginary.
The whole point of Ada is that it was designed to provide both
high security and high efficiency o conventional architecture.
It was touted as an Ada-architecture, and Intel (initially) only
provided an Ada compiler, and not a good one at that.
On Tue, 3 Feb 2026 15:22:08 -0700, Peter Flass wrote:
Burroughs had a lot of good stuff. The problem was that no one knew
they had it. They were like a stealth company.
Lots of people knew they had good stuff. But IBM was the master
marketing machine.
John McCarthy, the father of LISP, was an IBM man. When he went to
Stanford, IBM gifted one of their machines at the same time. But the computing facility already had a Burroughs machine, which the people
there quite liked using. But he saw to it that access to it was made difficult, and so pushed everybody into using the IBM machine instead.
I have reread your post multiple times, and I STILL think my
response is the sensible one.
Can anyone tell me why they decided to use bit addressing instead of
byte addressing?
On 4 Feb 2026, Dan Cross wrote
(in article <10m0663$3v7$1@reader2.panix.com>):
In article<0001HW.2F3398230003061E30B17C38F@news.individual.net>,
Bill Findlay <findlaybill@blueyonder.co.uk> wrote:
On 2 Feb 2026, Dan Cross wrote
(in article <10lqp1g$et1$1@reader2.panix.com>):
I don't think anyone was thinking about Unix with the 432; the
capability-based address and ties to Ada or whatever more or
less rendered it impossible.
The ties to Ada were imaginary.
The whole point of Ada is that it was designed to provide both
high security and high efficiency o conventional architecture.
That's pretty much orthogonal to my earlier point, which was
that the 432 was meant to be programmed, perhaps exclusively,
in a high-level language, and it featured some abstruce hardware
facilities that made running a conventional operating system
such as Unix challenging.
Whether Ada needs something like the 432 is irrelevant (and not
at all what I said)
What a testy reply!
My comment was not a criticism of you, but of Intel's idiotic propaganda.
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
On Tue, 3 Feb 2026 15:22:08 -0700, Peter Flass wrote:
Burroughs had a lot of good stuff. The problem was that no one knew
they had it. They were like a stealth company.
Lots of people knew they had good stuff. But IBM was the master
marketing machine.
John McCarthy, the father of LISP, was an IBM man. When he went to
Stanford, IBM gifted one of their machines at the same time. But the
computing facility already had a Burroughs machine, which the people
there quite liked using. But he saw to it that access to it was made
difficult, and so pushed everybody into using the IBM machine instead.
The Stanford administrative data center was an IBM shop from the get-go.
McCarthy was not an IBM man, he was a computers-are-a-great-tool man.
McCarthy had nothing to do with the administrative data center; he moved to the
Stanford Artificial Intelligence Laboratory when he left the East Coast, where >he worked on their already existing PDP-1, and was responsible for obtaining >the first customer ship PDP-6 (Serial #1) for SAIL.
You've moved from troll to fucking liar.
Peter Flass <Peter@Iron-Spring.com> writes:
On 2/3/26 08:02, Scott Lurndal wrote:
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
On Sun, 1 Feb 2026 12:54:26 -0700, Peter Flass wrote:
I'm still disappointed that they didn't adopt the Multics model for
segments.
Multics did pioneer a few things, including the use of ACLs.
Again with the trolling.
Burroughs guard files (ACLs) were available in the same timeframe,
if not earlier.
Burroughs had a lot of good stuff. The problem was that no one knew they >>had it. They were like a stealth company.
Tell me about it.
On 2026-02-04, Scott Lurndal <scott@slp53.sl.home> wrote:
Peter Flass <Peter@Iron-Spring.com> writes:
On 2/3/26 08:02, Scott Lurndal wrote:
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
On Sun, 1 Feb 2026 12:54:26 -0700, Peter Flass wrote:
I'm still disappointed that they didn't adopt the Multics model for >>>>>> segments.
Multics did pioneer a few things, including the use of ACLs.
Again with the trolling.
Burroughs guard files (ACLs) were available in the same timeframe,
if not earlier.
Burroughs had a lot of good stuff. The problem was that no one knew they >>>had it. They were like a stealth company.
Tell me about it.
I never worked with any Burroughs machines, but the people I knew who
had, liked them a lot. They had several products lines, each of which
served a particular market very well, but they were all very different, >without almost any similarities.
I was particularly close to people with exposure to two very different >families.
1) A small business minicomputer family, programmed in some extended
basic. My ex-wife's first computer job was programming an inventory
control system for something like an auto parts store.
She was hired, handed a shelf full of books, and dropped off at the
customer premises with the machine and told to "Talk to the people,
find out what they need. Here are the manuals for the computer, here
is a sample system that is a good starting point for tailoring it to
their needs. We will check on your progress every week. Call if you
have questions."
2) A nuclear research station had a mid-range "scientific compute
machine programmed in extended Algol. Much less expensive than
any IBM machine of similar compute power. The physicists the loved
it, but it was a good thing they did not have a lot of visiting
reasearchers traveling with suitcases full "dusty of FORTRAN decks".
I think Osborne is still used as a business school example of how to
cut your own throat.
On Fri, 30 Jan 2026 09:56:04 +0000, Nuno Silva wrote:
I wonder, if this button swapping is common among left-handed users,
whether other naming schemes were considered for the operations. I don't
know, "Main click" and "Context click", did anything like that ever get
used or proposed?
I think it is common. Even in the ancient days of editing xorg.conf you could specify 3 2 1 for pointer. I think there are more numbers now as mice grew appendages.
2) A nuclear research station had a mid-range "scientific compute
machine programmed in extended Algol. Much less expensive than
any IBM machine of similar compute power. The physicists the loved
it, but it was a good thing they did not have a lot of visiting
reasearchers traveling with suitcases full "dusty of FORTRAN decks".
Geoff Clare <geoff@clare.See-My-Signature.invalid> writes:
Scott Lurndal wrote:
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
On 3 Feb 2026 10:56:51 GMT, Niklas Karlsson wrote:
On 2026-02-03, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
WTF are you talking about? POSIX ACLs have been a part of Linux for
A patch was submitted some years ago to add Windows-style ACL
features to Linux, but it was rejected on the grounds that they can >>>>>> too often produce surprising and counterintuitive effects. Which is >>>>>> something that Windows sysadmins would be all too familiar with ... >>>>>
a VERY long time now.
Maybe you should reread what I wrote. I didn?t say that Linux doesn?t >>>>support ACLs.
Also, there are no such things as ?POSIX? ACLs. the ?POSIX? ACL >>>>proposal never actually became part of POSIX.
Your google-fu is failing, yet again.
Actually, yours is. Lawrence is correct.
Actually, the API was designed by POSIX and there exists an
extant implementation. Regardless of whether they were accepted
or not, they certainly can be considered POSIX ACLs.
On Wed, 4 Feb 2026 23:43:44 -0000 (UTC), Lars Poulsen wrote:
2) A nuclear research station had a mid-range "scientific compute
machine programmed in extended Algol. Much less expensive than
any IBM machine of similar compute power. The physicists the loved
it, but it was a good thing they did not have a lot of visiting
reasearchers traveling with suitcases full "dusty of FORTRAN decks".
Don?t worry, Burroughs had a FORTRAN compiler. Everybody did. ;)
In article<0001HW.2F33D73000088C2D30B17C38F@news.individual.net>,
Bill Findlay <findlaybill@blueyonder.co.uk> wrote:
On 4 Feb 2026, Dan Cross wrote
(in article <10m0663$3v7$1@reader2.panix.com>):
In article<0001HW.2F3398230003061E30B17C38F@news.individual.net>,
Bill Findlay <findlaybill@blueyonder.co.uk> wrote:
On 2 Feb 2026, Dan Cross wrote
(in article <10lqp1g$et1$1@reader2.panix.com>):
I don't think anyone was thinking about Unix with the 432; the capability-based address and ties to Ada or whatever more or
less rendered it impossible.
The ties to Ada were imaginary.
The whole point of Ada is that it was designed to provide both
high security and high efficiency o conventional architecture.
That's pretty much orthogonal to my earlier point, which was
that the 432 was meant to be programmed, perhaps exclusively,
in a high-level language, and it featured some abstruce hardware facilities that made running a conventional operating system
such as Unix challenging.
Whether Ada needs something like the 432 is irrelevant (and not
at all what I said)
What a testy reply!
Oh, huh; on re-reading I can see how it came off that way, but
that's not how I meant it. Apologies!
Eh. I think their machine was a dog from the get-go;
I don't think anyone tried to blame Ada for that,As I remember there was some ill-informed comment along those lines.
Scott Lurndal wrote:
Geoff Clare <geoff@clare.See-My-Signature.invalid> writes:
Scott Lurndal wrote:
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
On 3 Feb 2026 10:56:51 GMT, Niklas Karlsson wrote:
On 2026-02-03, Lawrence D?Oliveiro <ldo@nz.invalid> wrote:
WTF are you talking about? POSIX ACLs have been a part of Linux for >>>>>> a VERY long time now.
A patch was submitted some years ago to add Windows-style ACL
features to Linux, but it was rejected on the grounds that they can >>>>>>> too often produce surprising and counterintuitive effects. Which is >>>>>>> something that Windows sysadmins would be all too familiar with ... >>>>>>
Maybe you should reread what I wrote. I didn?t say that Linux doesn?t >>>>>support ACLs.
Also, there are no such things as ?POSIX? ACLs. the ?POSIX? ACL >>>>>proposal never actually became part of POSIX.
Your google-fu is failing, yet again.
Actually, yours is. Lawrence is correct.
Actually, the API was designed by POSIX and there exists an
extant implementation. Regardless of whether they were accepted
or not, they certainly can be considered POSIX ACLs.
No disagreement there. My point was that your response to Lawrence
implied he was wrong when he claimed they "never actually became part
of POSIX". He was not wrong.
Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
On Wed, 4 Feb 2026 23:43:44 -0000 (UTC), Lars Poulsen wrote:
2) A nuclear research station had a mid-range "scientific compute
machine programmed in extended Algol. Much less expensive than
any IBM machine of similar compute power. The physicists the loved
it, but it was a good thing they did not have a lot of visiting
reasearchers traveling with suitcases full "dusty of FORTRAN decks".
Don?t worry, Burroughs had a FORTRAN compiler. Everybody did. ;)
Trolling again? Burroughs had three major lines of systems, and perhaps
a dozen others (e.g CP9500). Not all of them supported FORTRAN. While Medium Systems
had a Fortran compiler, no customer actually used it.
(I am curious, was Multics truly the first system to make user
programs first-class citizens of the command shell? It's such a
natural way to do things from a retrospective point of view that it
seems hard to imagine *nobody* else coming up with it 'til over a
decade into the history of interactive computing...)
The real genesis of the idea comes from "RUNCOM" on CTSS, as
described by Louis Pouzin, who coined the term "shell" to descibe the
command interpreter he proposed for Multics. As usual, the
Multicians web site has first-hand details:
On Sat, 31 Jan 2026 16:47:17 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wrote:
(I am curious, was Multics truly the first system to make user
programs first-class citizens of the command shell? It's such a
natural way to do things from a retrospective point of view that it
seems hard to imagine *nobody* else coming up with it 'til over a
decade into the history of interactive computing...)
The real genesis of the idea comes from "RUNCOM" on CTSS, as
described by Louis Pouzin, who coined the term "shell" to descibe the
command interpreter he proposed for Multics. As usual, the
Multicians web site has first-hand details:
Ah, many thanks. Interesting to see how closely-knit his conception is
in that writeup; the way he describes it almost charts a middle course >between shell-as-formalized-programming-language & shell-as-glue-logic. >Interesting view re: timesharing, as well:
"Time sharing, as it became popular, is a living organism in which any
user, with various degrees of expertise, can create new objects, test
them, and make them available to others, without administrative control
and hassle."
I find it interesting how so many systems sort of dance around
the same concepts, over and over. A decent conceptualization of
a "process", in the operating system sense, is that of a virtual
machine that is augmented with additional behavior: one may
think of system calls as special instructions that allow access
to IO devices, including a synthesized filing system, stream IO
abstractions, and so on. Multiprogramming to allow multiple
such virtual machines to exist simultaneously to maximize
utilization is an obvious extension, and timesharing is really
just a small tweak on top of that. To that end, Pouzin's view
makes perfect sense; a runnable program is just a callable
routine, in a sense.
If you sort of squint and look at it from the right angle,
Unix-style commands installed in the filesystem kinda sorta look
like procedures installed in a Lisp or smalltalk image, and
files are just data objects. A shell that lets users interact
with them is thus just an interpreter, little different than a
REPL.
It is also interesting to note how many systems have tried (with
varying degrees of success) to reimpose the bureaucratic
restrictions on sharing that he seems to suggest one could
transcend. And this idea of timesharing systems as a means for
interactive collaboration is something I feel like we have
(sadly) lost. Single-user computers are lonely, boring places.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 16 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 104:22:53 |
| Calls: | 207 |
| Files: | 21,502 |
| Messages: | 84,080 |