Re: [TUHS] [TUHS} cat -v and other complaints

Re: [TUHS] [TUHS} cat -v and other complaints

[Doug McIlroy]

> you can't tell me
> this system was designed with the idea of running it using text terminal
> and no mouse.  There is also no cursor addressing, no curses.

The well named Curses and the associated vi were an ugly outgrowth
of glass screens--an outgrowth many of us in the Unix lab never
adopted. That branch of evolution was unrelated to the Blit branch that
essentially preserved the old TTY interface, except that one could have
multiple terminals on screen and a mouse was available to give mechanical
help for manual cut/paste/edit activities. Plan 9 terminal-handling
smoothly continued that evolutionary branch.

Mouse support could have been used to take off in a radical direction,
but it wasn't. To my mind, the primary innovation in Plan 9 was not
terminal support, nor everything-is-a-file. Rather it was an advance in
what Vyssotsky called "distributable computing", where components can
collaborate in a uniform way, no matter where they are. The key was the 9P
protocol that unpacked the notion of file type--a unifying principle
that brought simplicity and generality to a diversity of particulars.

Re: [TUHS] [TUHS} cat -v and other complaints

[Will Senn]

Doug et al.,

I’m interested in learning about this curses vs blit business. Is there a writeup or book chapter out there that covers this in any detail?

Thanks,

Will

Sent from my iPhone

On Sep 8, 2018, at 7:02 AM, Doug McIlroy <doug@cs.dartmouth.edu> wrote:

>> you can't tell me
>> this system was designed with the idea of running it using text terminal
>> and no mouse.  There is also no cursor addressing, no curses.
> 
> The well named Curses and the associated vi were an ugly outgrowth
> of glass screens--an outgrowth many of us in the Unix lab never
> adopted. That branch of evolution was unrelated to the Blit branch that
> essentially preserved the old TTY interface, except that one could have
> multiple terminals on screen and a mouse was available to give mechanical
> help for manual cut/paste/edit activities. Plan 9 terminal-handling
> smoothly continued that evolutionary branch.
> 
> Mouse support could have been used to take off in a radical direction,
> but it wasn't. To my mind, the primary innovation in Plan 9 was not
> terminal support, nor everything-is-a-file. Rather it was an advance in
> what Vyssotsky called "distributable computing", where components can
> collaborate in a uniform way, no matter where they are. The key was the 9P
> protocol that unpacked the notion of file type--a unifying principle
> that brought simplicity and generality to a diversity of particulars.

Re: [TUHS] cat -v and other complaints

[Ralph Corderoy]

Hi Will,

> I'm interested in learning about this curses vs blit business. Is
> there a writeup or book chapter out there that covers this in any
> detail?

https://en.wikipedia.org/wiki/Blit_(computer_terminal) is a jumping-off
point.  And I suppose the same goes for curses(3):
https://en.wikipedia.org/wiki/Curses_(programming_library)

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

Re: [TUHS] cat -v and other complaints

[Arthur Krewat]

On 9/8/2018 10:22 AM, Ralph Corderoy wrote:
>
>> I'm interested in learning about this curses vs blit business. Is
>> there a writeup or book chapter out there that covers this in any
>> detail?
> https://en.wikipedia.org/wiki/Blit_(computer_terminal) is a jumping-off
> point.  And I suppose the same goes for curses(3):
> https://en.wikipedia.org/wiki/Curses_(programming_library)
>

In my opinion (as retarded as I can be sometimes), this is an 
apples-and-oranges comparison.

Blit is a completely new terminal type, with specific operating 
system/software support.

Curses is a way to control various already-existing terminal types. DEC 
terminals, Hazeltine, etc. A recent termcap on my Solaris server has 472 
entries. The wide-ranging support was quite important.

Many people/institutions had a variety of terminals already, usually 
recycled from previous systems. I remember one instance when I was 17 
years old working at BOCES/LIRICS on Long Island, and an office worker 
in a local high-school looked at me like a deer in the headlights when 
they could no longer use their current-loop terminal and acoustic 
coupler. Sorry, the leased-line mux in the other room can't do that. It 
has to be RS232. We gladly gave them a new LA36. Which invoked another 
set of "how do I..." questions. Ah, progress. (This was to support 
TOPS-10 on DEC KS10's, but the same thing happened many times over my 
early career. People just didn't want to give up what they already had)

ak

Re: [TUHS] cat -v and other complaints

[Norman Wilson]

Andy Kosela:

  One still cannot ignore the fact that Unix and Plan 9 offer two
  completely different approaches to displaying text.

I admit I've never actually used Plan 9.  Can you elaborate on
the different approaches?

One difference from most of what passes for UNIX these days is
probably that the basic terminal model allows one to edit anything
on the screen, using the mouse and keyboard and a simple button-2
menu similar to that of sam.  You can edit what some program has
already printed, then pick it up and send it back as input.  You
can even edit text in the current line that hasn't been sent yet
(because you haven't hit a return yet); in effect the canonical-line
part of the tty driver is in the terminal.

But you probably don't mean that, both because it's not really
such a radical difference, and because it doesn't conflict at all
with UNIX.  In fact it originated on UNIX, five or six years before
Plan 9 was thought of: it's the model from the terminal program
in mux, the more-advanced version of the Blit/Jerq window manager
that nearly everybody used in 1127 by the time I arrived in 1984.

And I still use it every day, even on Linux (and in years past
on Solaris and IRIX and Digital UNIX and Ultrix).  The modern
version of the program to do that is called 9term.  It doesn't
work quite as well as I'd like on Linux due to changes in the
tty driver that make it hard for a program to learn right away
when tty modes are changed (in particular when echo is turned off
or on), and it does conflict with the GNU readline junk because
that turns off canonical processing, but to those of us who have
a taste for it it's still just fine.

As I say, I don't think that's the difference you mean, so please
step in and supersede me.

(And feel free to use my referring to something that is part of
the latter-day Research editions as an excuse to continue discussing
it.  I think of Plan 9 as a successor to those systems anyway, and
therefore related to UNIX heritage, at least as long as we're
comparing and contrasting the systems.)

Norman Wilson
Toronto ON

Re: [TUHS] cat -v and other complaints

[Andy Kosela]

Norman Wilson <norman@oclsc.org> wrote:

> Andy Kosela:
>
>   One still cannot ignore the fact that Unix and Plan 9 offer two
>   completely different approaches to displaying text.
>
> I admit I've never actually used Plan 9.  Can you elaborate on
> the different approaches?
>
> One difference from most of what passes for UNIX these days is
> probably that the basic terminal model allows one to edit anything
> on the screen, using the mouse and keyboard and a simple button-2
> menu similar to that of sam.  You can edit what some program has
> already printed, then pick it up and send it back as input.  You
> can even edit text in the current line that hasn't been sent yet
> (because you haven't hit a return yet); in effect the canonical-line
> part of the tty driver is in the terminal.
>
> But you probably don't mean that, both because it's not really
> such a radical difference, and because it doesn't conflict at all
> with UNIX.  In fact it originated on UNIX, five or six years before
> Plan 9 was thought of: it's the model from the terminal program
> in mux, the more-advanced version of the Blit/Jerq window manager
> that nearly everybody used in 1127 by the time I arrived in 1984.
>
> And I still use it every day, even on Linux (and in years past
> on Solaris and IRIX and Digital UNIX and Ultrix).  The modern
> version of the program to do that is called 9term.  It doesn't
> work quite as well as I'd like on Linux due to changes in the
> tty driver that make it hard for a program to learn right away
> when tty modes are changed (in particular when echo is turned off
> or on), and it does conflict with the GNU readline junk because
> that turns off canonical processing, but to those of us who have
> a taste for it it's still just fine.
>
> As I say, I don't think that's the difference you mean, so please
> step in and supersede me.

In short, character based approach vs. bitmap based.  Yes, in Unix you
also has a windowing system which is bitmap based, but IMHO this was
always an add-on and not an essential part of the system.  Plan 9 on the
other hand seems to be designed with more of a graphical based approach
than the old school character based approach.

--Andy

Re: [TUHS] cat -v and other complaints

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 3696 bytes --]

On Wed, Aug 29, 2018 at 1:07 AM Greg 'groggy' Lehey <grog@lemis.com> wrote:

> On Tuesday, 28 August 2018 at 23:23:10 -0400, Theodore Y. Ts'o wrote:
> > On Wed, Aug 29, 2018 at 11:06:05AM +1000, Dave Horsfall wrote:
> ....
>
>
> Creeping featurism!
>

No, I think its really is that many programmers that touch different
applications felt the need to pee on the code to feel that they left their
scent. 😘

Seriously, IMO the problem is you can never know what someone else really
values, so be careful at what you change.  Pike's 'cat -v' dissertation
b*tched at UCB for the some of the same issues.  Somewhere there is a
proper middle ground ( I think of as having good taste elegance).  BSD nor
Linux was no more 'perfect' that 6th or 7th edition.  Truth is a much as I
pine for the elegance, I don't want to run either of the later as my
day-2-day system in today's world and I >>loved<< running them when they
were what I had.

Rob has a real point and many of the changes really *are gratuitous* and
there *are better ways of doing* many things than adding a switch to old
command and reusing it because you can.  I also think the complaint of just
adding 'crap' because you could started with BSD but the cause wasn't that
people were bad -- there was address space relief over the PDP-11 and often
added a new switch/new functionality was easy to do, instead of creating a
whole new solution just deidcated to that problen only.  FWIW: sendmail is
my best example (useful tool that it was - there were/are much more elegant
solutions - sendmail should have been 'headerwriter' and smtpd should have
been a seperate program).

Dueling switches and functionality (dec vs -f bs -F) I fear is sometimes
ignorance of the past.  I fear there is some sort of belief we need to shed
the past because someone feeld the it gets in the way of the future (I'll
pick on my on son here - who things 2-3 years is 'old' and its time to
throw things away).  Truth is sometimes it might.  But I would rather
inject a stronger strain into the mix and let the users decide and for good
or bad, BSD did that to the original (v6/v7) and now Linux is doing/has
done it to much of BSD.

The compaint is the 'throwing the baby out with the bath water' behavior
that seems to often follow (see systemd issues on other mailing lists);
*i.e*. did you really gain something for this huge disruption.   To me when
something really new/a great innovation comes that should be celebrated.

BSD gave us VM and a number of 'useful' new utilities, and eventually an
networking API (al biet  not everyone liked it, sockets was good enough,
solved the problems and became a standard that allowed us to move on).
Mach (while Larry may not like the VM implementation), moved the bar for
the kernel's handling of memory a huge amount and almost won the uK war
(which IMO was a too bad).  BTW: other kernels would do nice VM's too, but
Mach was generally available (open source if you will and really was the
system the moived it forward).

That said, I give the Linux folks great credit for the addition of modules
was huge and it took BSD and the other UNIX systems a few years really pick
up that idea in the same way (yes Solaris, Tru64 and eventually HPUX etc..
had something too but again - my comment about being generally available
applies).

So here is the issue, how to do move the ball forward?   BSD, then Linux,
became the 'stronger strain' and pushed out the old version.   The problem
is the ROMs in my fingers (like Dave) never got reprogrammed so some of the
'new' becomes annoying.   Will I learned to like systemd?   We shall see...

Clem

[-- Attachment #2: Type: text/html, Size: 6416 bytes --]

Re: [TUHS] cat -v and other complaints

[Dave Horsfall]

[-- Attachment #1: Type: text/plain, Size: 1059 bytes --]

On Wed, 29 Aug 2018, Clem Cole wrote:

[ Excellent screed elided ]

> That said, I give the Linux folks great credit for the addition of 
> modules was huge and it took BSD and the other UNIX systems a few years 
> really pick up that idea in the same way (yes Solaris, Tru64 and 
> eventually HPUX etc.. had something too but again - my comment about 
> being generally available applies).

Wasn't SunOS first with dynamic kernel modules, or is my memory worse than 
I thought?  Linux may have been around at the time, but we never used in 
the shop until much later (Red Hat, nicknamed Dead Rat).

> So here is the issue, how to do move the ball forward?   BSD, then 
> Linux, became the 'stronger strain' and pushed out the old version.  
>  The problem is the ROMs in my fingers (like Dave) never got 
> reprogrammed so some of the 'new' becomes annoying.   Will I learned to 
> like systemd?   We shall see...

Never mind "systemd"; I'm having enough trouble coming to grips with 
"launchd" on the Mac...  Gimme /etc/inetd.conf any time.

-- Dave

Re: [TUHS] cat -v and other complaints

[Larry McVoy]

On Thu, Aug 30, 2018 at 08:34:05AM +1000, Dave Horsfall wrote:
> On Wed, 29 Aug 2018, Clem Cole wrote:
> >That said, I give the Linux folks great credit for the addition of modules
> >was huge and it took BSD and the other UNIX systems a few years really
> >pick up that idea in the same way (yes Solaris, Tru64 and eventually HPUX
> >etc.. had something too but again - my comment about being generally
> >available applies).
> 
> Wasn't SunOS first with dynamic kernel modules, or is my memory worse than I
> thought?  Linux may have been around at the time, but we never used in the
> shop until much later (Red Hat, nicknamed Dead Rat).

Yep.  And Linux has loadable modules because I posted the SunOS 4.x man
pages for the SunOS loadable modules to the kernel list.  Proving once
again that the open source guys aren't always the greatest at coming up
with the ideas but once you show them that it can be done, it gets done
quickly.  I think they had a prototype working in a week.

> Never mind "systemd"; I'm having enough trouble coming to grips with
> "launchd" on the Mac...  Gimme /etc/inetd.conf any time.

Amen, brother.

Re: [TUHS] cat -v and other complaints

[Clem cole]

Truth is I think IBM beat Sun on getting loadable modules for the kernel out first.  But I was counting the versions that people really looked at which is why I give Linux credit.   

It makes sense they modeled on SunOS btw but the fact is the Linux version is what folks like *BSD and macOS modeled after later.  

Btw you are 100% right - As for launchd I agree/no doubt -  but I’d already given up on MacOS being able to be admin’ed like a Unix box.  I can pretty much use it via iterm2 as a user like one and if mostly works as I expect (which I do appreciate).  

Linux is seductive enough to make think I should be able to admin it like I have for the last 40 years and it then bites me when I least expect it.   

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Aug 29, 2018, at 7:36 PM, Larry McVoy <lm@mcvoy.com> wrote:
> 
>> On Thu, Aug 30, 2018 at 08:34:05AM +1000, Dave Horsfall wrote:
>>> On Wed, 29 Aug 2018, Clem Cole wrote:
>>> That said, I give the Linux folks great credit for the addition of modules
>>> was huge and it took BSD and the other UNIX systems a few years really
>>> pick up that idea in the same way (yes Solaris, Tru64 and eventually HPUX
>>> etc.. had something too but again - my comment about being generally
>>> available applies).
>> 
>> Wasn't SunOS first with dynamic kernel modules, or is my memory worse than I
>> thought?  Linux may have been around at the time, but we never used in the
>> shop until much later (Red Hat, nicknamed Dead Rat).
> 
> Yep.  And Linux has loadable modules because I posted the SunOS 4.x man
> pages for the SunOS loadable modules to the kernel list.  Proving once
> again that the open source guys aren't always the greatest at coming up
> with the ideas but once you show them that it can be done, it gets done
> quickly.  I think they had a prototype working in a week.
> 
>> Never mind "systemd"; I'm having enough trouble coming to grips with
>> "launchd" on the Mac...  Gimme /etc/inetd.conf any time.
> 
> Amen, brother.

Re: [TUHS] cat -v and other complaints

[Clem cole]

And I should added I do miss inetd.conf in both cases.   

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Aug 29, 2018, at 9:14 PM, Clem cole <clemc@ccc.com> wrote:
> 
> Truth is I think IBM beat Sun on getting loadable modules for the kernel out first.  But I was counting the versions that people really looked at which is why I give Linux credit.   
> 
> It makes sense they modeled on SunOS btw but the fact is the Linux version is what folks like *BSD and macOS modeled after later.  
> 
> Btw you are 100% right - As for launchd I agree/no doubt -  but I’d already given up on MacOS being able to be admin’ed like a Unix box.  I can pretty much use it via iterm2 as a user like one and if mostly works as I expect (which I do appreciate).  
> 
> Linux is seductive enough to make think I should be able to admin it like I have for the last 40 years and it then bites me when I least expect it.   
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
>>> On Aug 29, 2018, at 7:36 PM, Larry McVoy <lm@mcvoy.com> wrote:
>>> 
>>>> On Thu, Aug 30, 2018 at 08:34:05AM +1000, Dave Horsfall wrote:
>>>> On Wed, 29 Aug 2018, Clem Cole wrote:
>>>> That said, I give the Linux folks great credit for the addition of modules
>>>> was huge and it took BSD and the other UNIX systems a few years really
>>>> pick up that idea in the same way (yes Solaris, Tru64 and eventually HPUX
>>>> etc.. had something too but again - my comment about being generally
>>>> available applies).
>>> 
>>> Wasn't SunOS first with dynamic kernel modules, or is my memory worse than I
>>> thought?  Linux may have been around at the time, but we never used in the
>>> shop until much later (Red Hat, nicknamed Dead Rat).
>> 
>> Yep.  And Linux has loadable modules because I posted the SunOS 4.x man
>> pages for the SunOS loadable modules to the kernel list.  Proving once
>> again that the open source guys aren't always the greatest at coming up
>> with the ideas but once you show them that it can be done, it gets done
>> quickly.  I think they had a prototype working in a week.
>> 
>>> Never mind "systemd"; I'm having enough trouble coming to grips with
>>> "launchd" on the Mac...  Gimme /etc/inetd.conf any time.
>> 
>> Amen, brother.

Re: [TUHS] cat -v and other complaints

[Kevin Bowling]

AIX takes a lot of shit but there were (and still are) some areas it
was quite a bit ahead of its time.

I haven't used the ROMP 2.0 version that would have been on the IBM
RT.. on my search and todo list.  This is interesting because it ran
under a hypervisor.

The 1.x version for x86 PS/2s is basically Locus.  I don't like it.  I
think it was also used as a common port base for AIX/370  You can run
1.x in VirtualBox with some careful instructions.  I'm the canonical
source for all this at http://ps-2.kev009.com/aixps2/

But the 3.x version released with POWER/RS6000 in 1990 had a fully
pagable kernel, loadable kernel modules[1], logical volume management
and disk mirroring, an object oriented thing called the ODM which is
probably extremely controversial but a pretty nice for providing
KPI/KBI/API compatibility for drivers and subsystems and configuration
thereof.  It's a good mix of BSD and interesting to see how that was
accomplished https://technologists.com/sauer/Convergence_of_AIX_and_4.3BSD.pdf

[1] http://bitsavers.org/pdf/ibm/rs6000/aix_3.0/SC23-2207-0_Kernel_Extensions_and_Device_Support_Programming_Concepts_Mar90.pdf
See for instance page 6-10

Regards,
Kevin

On Wed, Aug 29, 2018 at 6:14 PM, Clem cole <clemc@ccc.com> wrote:
> Truth is I think IBM beat Sun on getting loadable modules for the kernel out first.  But I was counting the versions that people really looked at which is why I give Linux credit.
>
> It makes sense they modeled on SunOS btw but the fact is the Linux version is what folks like *BSD and macOS modeled after later.
>
> Btw you are 100% right - As for launchd I agree/no doubt -  but I’d already given up on MacOS being able to be admin’ed like a Unix box.  I can pretty much use it via iterm2 as a user like one and if mostly works as I expect (which I do appreciate).
>
> Linux is seductive enough to make think I should be able to admin it like I have for the last 40 years and it then bites me when I least expect it.
>
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
>
>> On Aug 29, 2018, at 7:36 PM, Larry McVoy <lm@mcvoy.com> wrote:
>>
>>> On Thu, Aug 30, 2018 at 08:34:05AM +1000, Dave Horsfall wrote:
>>>> On Wed, 29 Aug 2018, Clem Cole wrote:
>>>> That said, I give the Linux folks great credit for the addition of modules
>>>> was huge and it took BSD and the other UNIX systems a few years really
>>>> pick up that idea in the same way (yes Solaris, Tru64 and eventually HPUX
>>>> etc.. had something too but again - my comment about being generally
>>>> available applies).
>>>
>>> Wasn't SunOS first with dynamic kernel modules, or is my memory worse than I
>>> thought?  Linux may have been around at the time, but we never used in the
>>> shop until much later (Red Hat, nicknamed Dead Rat).
>>
>> Yep.  And Linux has loadable modules because I posted the SunOS 4.x man
>> pages for the SunOS loadable modules to the kernel list.  Proving once
>> again that the open source guys aren't always the greatest at coming up
>> with the ideas but once you show them that it can be done, it gets done
>> quickly.  I think they had a prototype working in a week.
>>
>>> Never mind "systemd"; I'm having enough trouble coming to grips with
>>> "launchd" on the Mac...  Gimme /etc/inetd.conf any time.
>>
>> Amen, brother.

Re: [TUHS] cat -v and other complaints

[George Michaelson]

if you staid inside the reservation (so to speak) I think AIX made
huge sense. I ran the BSD/RT stuff, it was very fine. The
documentation was rigorous. If you stuck to the docs, you couldn't go
wrong. But it was a frozen moment in time and as X10/X11 moved on, the
RT port got older and older.

the uni I worked at had a dying IBM mainframe. I think if we'd
committed more to the IBM model and dived in, AIX would have worked
well. But psych, compsci, engineering, arts/liberal-arts all went to
Suns and the computer centre (where I was) had been DEC10/Vax as well
as IBM)

We were half-pregnant. Its a difficult state to be in.

I don't really want to knock AIX, I think compared to the choices HPUX
made, or Apollo Domain/OS made, the AIX choices were more self
consistent. The unit I ran briefly in the research centre was rock
solid and most of my complaints are 'principle of least surprise
broken' coming from non-AIX world. I think if you were in it, it was
fine.

But really, thats the same thing about Solaris. I personally preferred
SunOS but the company backed this other model, and if you were in it,
the kickstart mechanism to do canned machine deployment, and disk
config, and all that goodness, It was fine. I jumped ship well before
Sun moved into the 'mainframe' world but I knew people who ran huge
non-stop high transactional services on the E1000 series, and were
very very happy.

Tandem (to riff on that) had its niche. I love the story about sales
engineers in the east coast pulling cards on the demo machine to show
"look it works" live and the West coast maintenance people tearing
their hair out at automatic supply-chain logistics shipping parts over
to fix the borked node.. (this is an Aussie story) But I never had to
handle the OS.

SCO, I did have to work on. As long as you stayed inside the
reservation.. No I can't go there. SCO was just awful.

Re: [TUHS] cat -v and other complaints

[Dave Horsfall]

On Wed, 29 Aug 2018, Kevin Bowling wrote:

> AIX takes a lot of shit but there were (and still are) some areas it was 
> quite a bit ahead of its time.

The standing joke with AIX was that it was pronounced "aches" (as in 
pains), but I was glad that it ran "smit" for admin stuff, as there was no 
way that I could remember the appropriate Shell commands.

-- Dave

Re: [TUHS] cat -v and other complaints

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

On Thu, Aug 30, 2018, 8:27 PM Dave Horsfall <dave@horsfall.org> wrote:

> On Wed, 29 Aug 2018, Kevin Bowling wrote:
>
> > AIX takes a lot of shit but there were (and still are) some areas it was
> > quite a bit ahead of its time.
>
> The standing joke with AIX was that it was pronounced "aches" (as in
> pains), but I was glad that it ran "smit" for admin stuff, as there was no
> way that I could remember the appropriate Shell commands.
>

"SMIT happens "

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 969 bytes --]

Re: [TUHS] cat -v and other complaints

[Larry McVoy]

On Thu, Aug 30, 2018 at 08:41:26PM -0400, Dan Cross wrote:
> On Thu, Aug 30, 2018, 8:27 PM Dave Horsfall <dave@horsfall.org> wrote:
> 
> > On Wed, 29 Aug 2018, Kevin Bowling wrote:
> >
> > > AIX takes a lot of shit but there were (and still are) some areas it was
> > > quite a bit ahead of its time.
> >
> > The standing joke with AIX was that it was pronounced "aches" (as in
> > pains), but I was glad that it ran "smit" for admin stuff, as there was no
> > way that I could remember the appropriate Shell commands.
> >
> 
> "SMIT happens "

So back in the BitKeeper days, we supported everything, including AIX.  I've
got a fairly beefy AIX box in my shop in case we need it, 1ghz, lots of ram,
we're never gonna turn that on.  I went into smit and I was just like can 
you just frigging let me edit /etc/inetd.conf or whatever, but no.

SMIT happens.  And I did not like it.  I think that's one of the reasons
that SunOS was cool, it was just a better, bugfixed BSD.  So we all knew
how to deal with it.  SMIT not so much.

Re: [TUHS] cat -v and other complaints

[ron]

> The standing joke with AIX was that it was pronounced "aches" (as in
pains),
> but I was glad that it ran "smit" for admin stuff, as there was no way
that I
> could remember the appropriate Shell commands.

We wanted to call the window manager "panes" on Aix (Aches and Pains).

My only real memory of beating on the RS/6000 was that while it had a 24-bit
graphics card, the X server didn't have a 24-bit visual.
That and I was able to break into the demo box IBM sent me by turning the
key to the "wrench" position and then shell escaping out of a more command
it launched.

I spent more time hacking the 370/PS2/i860 version of the kernel which was a
unified source base.
This had switching console contexts they called the "High Function
Terminal."    We named our i860 version of it the "Low Function Terminal."

Re: [TUHS] cat -v and other complaints

[Cág]

Not completely on-topic, in my opinion one of the reasons Plan9 failed
was the fact that it presented itself overly idealistic, occasionally
sacrificing usability -- maybe it's because of coming from a Unix system
like Berkeley or IRIX, in which case, I think Brian Kernighan said, "if
you'll think of it as Unix, you'll often be frustrated because something
doesn't exist or works differently." On the one hand the `cat -v` and
some other concerns (like columnated ls(1) output) are valid, and very
well understood. On the other -- lack of find(1), shell history, and
vi are not. Well, to me at least. Both acme and sam seem to have found
its fanbase.

Note, when I'm saying failed I mean commercially. As a research
operating system, or, dare I say, esoteric, because in some way it was
and still is esoteric, it succeeded as none of the others, with its
impact going through this day.

--
caóc

Re: [TUHS] cat -v and other complaints

[Andrew Warkentin]

On 8/31/18, Cág <ca6c@bitmessage.ch> wrote:
> Not completely on-topic, in my opinion one of the reasons Plan9 failed
> was the fact that it presented itself overly idealistic, occasionally
> sacrificing usability -- maybe it's because of coming from a Unix system
> like Berkeley or IRIX, in which case, I think Brian Kernighan said, "if
> you'll think of it as Unix, you'll often be frustrated because something
> doesn't exist or works differently."

I'd definitely agree with the lack of usability-oriented features
being a part of why Plan 9 hasn't been commercially successful. In
general, it seems like Plan 9 focuses on being minimal above
everything else, whereas I'd say an ideal OS should focus on being
sufficiently general and extensible in addition to being minimal (in
other words, do things in the most minimal way that is sufficiently
general and extensible).

> On the one hand the `cat -v` and
> some other concerns (like columnated ls(1) output) are valid, and very
> well understood. On the other -- lack of find(1), shell history, and
> vi are not. Well, to me at least. Both acme and sam seem to have found
> its fanbase.
>

I'd say features like history, completion, and line editing really
don't belong in a shell. They should be handled by a separate listener
process with a simple API that shells and other client processes can
use for controlling them. That's one good example of Plan 9
prioritizing minimalism above everything else.

Re: [TUHS] cat -v and other complaints

[Cág]

Andrew Warkentin wrote:

> I'd say features like history, completion, and line editing really
> don't belong in a shell. They should be handled by a separate listener
> process with a simple API that shells and other client processes can
> use for controlling them. That's one good example of Plan 9
> prioritizing minimalism above everything else.

http://wiki.c2.com/?WhatIsNotInPlanNine

> fn history {grep '^term%' /mnt/wsys/text|sed -e 's/^term%//'} term%

This is sure better.

On top of that I don't get how Acme adheres to the philosophy. It's
basically a reverse engineered, unavailable on the console, GNU Emacs
with a mouse-driven interface.

--
caóc

Re: [TUHS] cat -v and other complaints

[Kurt H Maier]

On Mon, Sep 03, 2018 at 01:04:01PM -0500, Cág wrote:
>
> On top of that I don't get how Acme adheres to the philosophy. It's
> basically a reverse engineered, unavailable on the console, GNU Emacs
> with a mouse-driven interface.
>
       
My pet theory is that Acme was going to replace Rio, at which time it
would be 'the interface' again instead of a text editor with a
slightly-incompatible filesystem interface.  There are some hints toward
this if you squint hard enough, but I can't prove it.
       
"Unavailable on the console" is kind of a cheap shot when talking about
an operating system that deliberately doesn't support consoles.  Part of
the point was outgrowing TTYs.
       
The emacs comparison is a favorite of mine because it's so close to
being an anagram, but obviously Acme never suffered from lisp fetishism.
I still dislike Acme for basically all the same reasons I dislike emacs.
       
khm

Re: [TUHS] cat -v and other complaints

[Cág]

Kurt H Maier wrote:

> My pet theory is that Acme was going to replace Rio, at which time it
> would be 'the interface' again instead of a text editor with a
> slightly-incompatible filesystem interface.  There are some hints toward
> this if you squint hard enough, but I can't prove it.

Oberon 2.0
        
> "Unavailable on the console" is kind of a cheap shot when talking about
> an operating system that deliberately doesn't support consoles.  Part of
> the point was outgrowing TTYs.

Yeah, I guess I should've started with that :) I love Unix for the
console.

--
caóc

Re: [TUHS] cat -v and other complaints

[Andy Kosela]

[-- Attachment #1: Type: text/plain, Size: 1217 bytes --]

On Monday, September 3, 2018, Cág <ca6c@bitmessage.ch> wrote:

> Kurt H Maier wrote:
>
> > My pet theory is that Acme was going to replace Rio, at which time it
> > would be 'the interface' again instead of a text editor with a
> > slightly-incompatible filesystem interface.  There are some hints toward
> > this if you squint hard enough, but I can't prove it.
>
> Oberon 2.0
>
> > "Unavailable on the console" is kind of a cheap shot when talking about
> > an operating system that deliberately doesn't support consoles.  Part of
> > the point was outgrowing TTYs.
>
> Yeah, I guess I should've started with that :) I love Unix for the
> console.
>

Pure text interface will always be the most elegant way to converse with a
machine.  And Unix is the most elegant command line based system.

The world lost something when it moved to GUI.  I still prefer to use the
old phosphor based CRT monitors even with modern computers and because the
text mode is still inherent in modern graphics cards (as a legacy mode), it
is possible to not use GUI at all even today.

That was one of the main reasons I disliked Plan9.  It embraced the
"windows interface" trend of the mid 80s.

--Andy

[-- Attachment #2: Type: text/html, Size: 1580 bytes --]

Re: [TUHS] cat -v and other complaints

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 265 bytes --]

On Mon, Sep 3, 2018 at 11:11 PM Andy Kosela <akosela@andykosela.com> wrote:

>
> That was one of the main reasons I disliked Plan9.  It embraced the
> "windows interface" trend of the mid 80s.
>
>
>
well, you can believe that, and I can't stop you, but it's wrong.

[-- Attachment #2: Type: text/html, Size: 598 bytes --]

Re: [TUHS] cat -v and other complaints

[Andy Kosela]

[-- Attachment #1: Type: text/plain, Size: 1883 bytes --]

On Tuesday, September 4, 2018, ron minnich <rminnich@gmail.com> wrote:

>
>
> On Mon, Sep 3, 2018 at 11:11 PM Andy Kosela <akosela@andykosela.com>
> wrote:
>
>>
>> That was one of the main reasons I disliked Plan9.  It embraced the
>> "windows interface" trend of the mid 80s.
>>
>>
>>
> well, you can believe that, and I can't stop you, but it's wrong.
>

Can you elaborate more on your point of view?

There has been a slow shift in the way we use computer interfaces and the
start of the "windows computing" revolution certainly happened around mid
80s with companies like Apple, Microsoft or Commodore developing their own
version of GUI (which goes back to Xerox PARC of course).  Unix received X
Window System from MIT in 1984.

At the time people thought that GUI is the best and most useful interface
for the new era and text terminal computing is about to die pretty soon.
Well it took at least 10 more years to happen and the introduction of World
Wide Web and Windows 95 certainly help solidify it.

When Plan 9 was created in the mid-late 80s exactly those ideas
circulated.  Nothing comes from nothing, everything has its historical
context.  In the late 80s in order to "innovate" it was natural to think
that abandoning text terminals is a "progress".

Unix was born in the different era.  Same with the original IBM PC.  That
is why they revolve around pure text interface.  I'm just glad that text
mode survived and it is still available even on modern PC's.  But most kids
these days don't even know what it is...  They have GUIs everywhere, from
their smartphones to their laptops.

It is a very sad state of things when people more and more abandon text
computing for the image based computing.  I agree with Kurt that we are
already in the Information Technology ice age.

General purpose pure text based computing is slowly becoming just a retro
hobby.

--Andy

[-- Attachment #2: Type: text/html, Size: 2645 bytes --]

Re: [TUHS] cat -v and other complaints

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 5670 bytes --]

On Tue, Sep 4, 2018 at 5:35 AM Andy Kosela <akosela@andykosela.com> wrote:

> On Tuesday, September 4, 2018, ron minnich <rminnich@gmail.com> wrote:
>>
>> On Mon, Sep 3, 2018 at 11:11 PM Andy Kosela <akosela@andykosela.com>
>> wrote:
>>
>>> That was one of the main reasons I disliked Plan9.  It embraced the
>>> "windows interface" trend of the mid 80s.
>>>
>>
>> well, you can believe that, and I can't stop you, but it's wrong.
>>
>
> Can you elaborate more on your point of view?
>

I don't mean to speak for Ron, but I think I know where he's coming from.

There has been a slow shift in the way we use computer interfaces and the
> start of the "windows computing" revolution certainly happened around mid
> 80s with companies like Apple, Microsoft or Commodore developing their own
> version of GUI (which goes back to Xerox PARC of course).  Unix received X
> Window System from MIT in 1984.
>

Don't mistake "windows" (as in "stacking window manager") for "bitmapped
graphical displays."

At the time people thought that GUI is the best and most useful interface
> for the new era and text terminal computing is about to die pretty soon.
> Well it took at least 10 more years to happen and the introduction of World
> Wide Web and Windows 95 certainly help solidify it.
>
> When Plan 9 was created in the mid-late 80s exactly those ideas
> circulated.  Nothing comes from nothing, everything has its historical
> context.  In the late 80s in order to "innovate" it was natural to think
> that abandoning text terminals is a "progress".
>

This is conflating two things: textual interfaces and the graphical
presentation of those interfaces. Plan 9 is about both.

Unix was born in an era where the TTY (that is, tele-typewriter, as in
"prints to paper") was still very much a force in mediating the interaction
between user and computer. That evolved rather quickly to the "green
screen" terminals of the 70s and early 80s, but the paradigm was basically
the same: the serial terminal was a window showing the tail of an infinite
scroll of data. The "terminal", as in the TTY, was and is a central
abstraction in Unix.

By the late 80s, when plan9 got started, the paradigm had shifted: machines
now had relatively high resolution bitmapped graphical interfaces, and by
and large you weren't sitting in front of a serial terminal anymore. Being
tied to a single "terminal" was a hindrance and led to a lot of complexity
(job control, terminal interactions with process groups, POSIX sessions,
signals and ioctls for window-size changes for programs that wanted to
continue believing that they're using a serial terminal, even though they
haven't been for years...).

Plan9 wanted to take advantage of the new graphics functionality but didn't
want to be chained to the complexity associated with obsolete hardware
(e.g., the TTY abstraction, which _still persists_ and has its fingers in
weird parts of the kernel).

They still wanted a text-oriented interface though, and that's what plan9
provides. You sweep out a rio window and it's running a shell. Text in acme
is usually editable and there aren't a lot of strange glyphs to click on;
commands are strings. And you're no longer chained to a "terminal": I can
have many shells running in many windows and they're all more or less the
same. And it allowed them to move beyond the limitations of
cursor-addressed user interfaces. They could, for example, write (or more
precisely adapt) text editors like `sam`, which is fundamentally a textual
program but uses the GUI to very nice effect. It may seem dated by today's
standards, but it still works very nicely (indeed, I had to run a coworker
through a sam session last Thursday; he was a continent away from me
connecting to a plan9 system but we were able to do what needed to be done
relatively quickly because it's all text and so simple...).

I remember when I was in high school driving over to New Jersey and going
to Bell Labs and meeting Dennis Ritchie for the first time (a college
student I knew was doing an internship there and let me come visit). Dennis
showed me plan9 on his gnot (this was back in the 8.5 days), and
specifically talked about this: the focus was text, which was editable,
could be manipulated, combined, split apart, was self-explanatory etc,
instead of little icons like MS Windows and the Mac which were
simultaneously static and cryptic. It *is* a textual interface, though it's
*presented* and *multiplexed* via a bitmapped graphics display.

I distinctly remember feeling blown away by the powerful marriage of text
with bitmapped displays; it was a GUI for a Unix-like experience done
right. They didn't sacrifice anything, but they gained so much more.

Unix was born in the different era.  Same with the original IBM PC.  That
> is why they revolve around pure text interface.
>

Unix and the PC date from radically different eras.

The original IBM PC had a graphics adapter, and that was the expected mode
of interaction, not the serial port. Granted that adapter was pretty weak,
but it was there. Using a PC, you were using a graphical representation of
your text interface. Unlike a serial terminal, where you simply emit the
text to the terminal and the terminal deals with displaying it, writing an
interface for CGA or MGA -- even in text mode -- involves scrolling the
buffer, handling line feeds, tab and backspace expansion, and all the rest
of it in software (granted, lots of serial drivers for Unix handle tab and
BS expansion, too). But you, the programmer, have to manually keep track of
your position in that little 4k buffer. You have to deal with moving the
cursor around, etc.

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 7408 bytes --]

Re: [TUHS] cat -v and other complaints

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

On Tue, Sep 4, 2018 at 2:34 AM Andy Kosela <akosela@andykosela.com> wrote:

> When Plan 9 was created in the mid-late 80s exactly those ideas
> circulated.  Nothing comes from nothing, everything has its historical
> context.  In the late 80s in order to "innovate" it was natural to think
> that abandoning text terminals is a "progress".
>
>
I don't get the sense, from reading this, that you have ever used Plan 9
for serious work, or indeed done more than see or run a demo. I'm keeping
this short because this is TUHS, not T9HS. But your characterization of
Plan 9 is just wrong.

[-- Attachment #2: Type: text/html, Size: 909 bytes --]

Re: [TUHS] cat -v and other complaints

[Andy Kosela]

ron minnich <rminnich@gmail.com> wrote:

> On Tue, Sep 4, 2018 at 2:34 AM Andy Kosela <akosela@andykosela.com> wrote:
>
> > When Plan 9 was created in the mid-late 80s exactly those ideas
> > circulated.  Nothing comes from nothing, everything has its historical
> > context.  In the late 80s in order to "innovate" it was natural to think
> > that abandoning text terminals is a "progress".
> >
> >
> I don't get the sense, from reading this, that you have ever used Plan 9
> for serious work, or indeed done more than see or run a demo. I'm keeping
> this short because this is TUHS, not T9HS. But your characterization of
> Plan 9 is just wrong.

I understand that we are drifting a bit off-topic here, but for the sake
of all reading it, it probably would be relevant to at least offer some
more explanation of your point.  Saying 'you are wrong' is not very
informative.  I still think that you just misinterpret my words though.

One still cannot ignore the fact that Unix and Plan 9 offer two
completely different approaches to displaying text.  I think it also
would not be very productive nor it was intended to use Plan 9 without
mouse and rio(1).
--Andy

Re: [TUHS] cat -v and other complaints

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 722 bytes --]

On Thu, Sep 6, 2018 at 1:02 PM Andy Kosela <akosela@andykosela.com> wrote:

> One still cannot ignore the fact that Unix and Plan 9 offer two
> completely different approaches to displaying text.  I think it also
> would not be very productive nor it was intended to use Plan 9 without
> mouse and rio(1).
>

I spent four years using Plan 9 on the Blue Gene supercomputer (I led the
team that did the port). I also spent years using it on embedded systems
with no windowing system at all.

What you're saying does not accord with anything I experienced with Plan 9
over a dozen year span. I also don't believe your claims are driven by
experience using Plan 9; am I missing something? What is the basis of your
statement?

[-- Attachment #2: Type: text/html, Size: 1050 bytes --]

Re: [TUHS] cat -v and other complaints

[Andy Kosela]

ron minnich <rminnich@gmail.com> wrote:

> On Thu, Sep 6, 2018 at 1:02 PM Andy Kosela <akosela@andykosela.com> wrote:
>
> > One still cannot ignore the fact that Unix and Plan 9 offer two
> > completely different approaches to displaying text.  I think it also
> > would not be very productive nor it was intended to use Plan 9 without
> > mouse and rio(1).
> >
>
> I spent four years using Plan 9 on the Blue Gene supercomputer (I led the
> team that did the port). I also spent years using it on embedded systems
> with no windowing system at all.
>
> What you're saying does not accord with anything I experienced with Plan 9
> over a dozen year span. I also don't believe your claims are driven by
> experience using Plan 9; am I missing something? What is the basis of your
> statement?

Just from personal experience running Plan 9.  Well, you can't tell me
this system was designed with the idea of running it using text terminal
and no mouse.  There is also no cursor addressing, no curses.  Like I
written before it was born in the different era -- they tried to not
build it on the idea of character based TTY, but rather incorporate
graphical element into it.

If it is possible to be fully productive in Plan 9 using just VGA text
mode (720x400) and not any of the bitmap modes, with Unix like cursor
addressing and with no rio(1) and no mouse then it's something I never
really explored.

--Andy

Re: [TUHS] cat -v and other complaints

[Dan Cross]

[-- Attachment #1: Type: text/plain, Size: 2860 bytes --]

On Thu, Sep 6, 2018 at 5:56 PM Andy Kosela <akosela@andykosela.com> wrote:

> [snip]  Well, you can't tell me
> this system was designed with the idea of running it using text terminal
> and no mouse.


I won't, because it wouldn't be true. You are correct that it was always
intended to be used with a graphical console. But you keep talking about
"text terminals" and therein lies the confusion: our text terminals haven't
been purely "text" since the teletype days. Even green-screen serial
terminals have graphics adapters to draw characters on the screen.

There is also no cursor addressing, no curses.


Actually, there *is* a graphical program to emulate a vt-series terminal,
but pretty much no one uses it. So while strictly speaking this is
incorrect, it is essentially correct for all intents and purposes.

But it begs the question: why would you *want* to use that sort of
interface? That was appropriate for an HP or DEC terminal connected via a
low-bandwidth link (e.g., serial) or a shared host computer. Once we moved
onto personal workstation-class machines with graphics adapters, why
continue with that paradigm? Your framebuffer doesn't care that,
'\033[H\033[J' means "move the cursor to the upper-left corner and clear
the current line to the end of the screen", so why should your terminal
emulator? For that matter, if logged into the text-only console on a Linux
or FreeBSD machine, why does running `stty` say your graphics adapter has a
BAUD rate? The plan9 authors decided to leave such historical debris behind.


> Like I
> written before it was born in the different era -- they tried to not
> build it on the idea of character based TTY, but rather incorporate
> graphical element into it.
>

Correct. I wasn't there, but the observation surely must have been in part
that the user was *already* using a graphical environment, just not to very
good effect.

If it is possible to be fully productive in Plan 9 using just VGA text
> mode (720x400) and not any of the bitmap modes, with Unix like cursor
> addressing and with no rio(1) and no mouse then it's something I never
> really explored.
>

You could skip `rio` and just run `vt` on the console. I doubt the
emulation is very good and it wouldn't be an acceptable substitute for
serious use. `vt` was really intended as a stop-gap for accessing older
systems; the plan9 model was different, and instead of accessing remote
resources, the idea was that those resources would be shared with the
(plan9) network and imported locally for manipulation. That is, I wouldn't
`ssh` into some machine to make use of something on it; instead I'd use
`import` to bring those resources into my namespace locally and I'd
manipulate them there.

I did a writeup of this a while back:
http://pub.gajendra.net/2016/05/plan9part1

I should probably do parts 2 and 3....

        - Dan C.

[-- Attachment #2: Type: text/html, Size: 3955 bytes --]

Re: [TUHS] cat -v and other complaints

[Andy Kosela]

Dan Cross <crossd@gmail.com> wrote:

> On Thu, Sep 6, 2018 at 5:56 PM Andy Kosela <akosela@andykosela.com> wrote:
>
> > [snip]  Well, you can't tell me
> > this system was designed with the idea of running it using text terminal
> > and no mouse.
>
>
> I won't, because it wouldn't be true. You are correct that it was always
> intended to be used with a graphical console. But you keep talking about
> "text terminals" and therein lies the confusion: our text terminals haven't
> been purely "text" since the teletype days. Even green-screen serial
> terminals have graphics adapters to draw characters on the screen.

I think I was clear enough and meant 'text terminal' as a physical glass
TTY e.g.  vt220 from DEC, but understand now why someone might have
interpreted it differently.

There is also a big difference between a text mode (character mode)
where what we see on the screen is addressed in terms of characters
rather than individual pixels and a bitmap mode (graphics mode) also
known as APA (all points addressable) mode where every pixel is
addressable[1].

Inherent in the text mode is also the concept of monospace fonts which
some people prefer to this day.

>
> There is also no cursor addressing, no curses.
>
>
> Actually, there *is* a graphical program to emulate a vt-series terminal,
> but pretty much no one uses it. So while strictly speaking this is
> incorrect, it is essentially correct for all intents and purposes.
>
> But it begs the question: why would you *want* to use that sort of
> interface? That was appropriate for an HP or DEC terminal connected via a
> low-bandwidth link (e.g., serial) or a shared host computer. Once we moved
> onto personal workstation-class machines with graphics adapters, why
> continue with that paradigm? 

Why there are still people running C64, Atari XL/XE or Amiga?  Even
more, some of them think those computers are still better than the
machines of today...

In the Unix community there are some that still prefer to use old CRT
terminals or MS-DOS era PC monitors using only text mode.  Why I can't
speak for all of them, I can speak for myself and explain my motivation
behind it.  I instantly fell in love with a text mode when I first
started computing on Commodore and Atari machines in the 80s and then
naturally advanced to a text mode on MS-DOS era PC's. 

I never really ran Linux or *BSDs with X Window System -- always
preferred pure text mode.  It is aesthetically pleasing and most elegant
to converse with a machine using only text, and a text mode as displayed
on cathode ray tube (CRT) is the most beautiful representation of such
an idea. 

Although these days I'm using sometimes MacBook (who doesn't?)
which is using of course the bitmap mode, I still prefer to experience
the full text mode on a real CRT and actually collect them as they are
becoming more and more rare.

[1] https://en.wikipedia.org/wiki/Text_mode


--Andy

Re: [TUHS] cat -v and other complaints

[Lyndon Nerenberg]

> > "Unavailable on the console" is kind of a cheap shot when talking about
> > an operating system that deliberately doesn't support consoles.  Part of
> > the point was outgrowing TTYs.
>
> Yeah, I guess I should've started with that :) I love Unix for the
> console.

But in Plan9, the console is assumed to be a bitmap device.  Perhaps
with the exception of, say, the file server.  But there is no reason
why that has to be the case - certainly not on modern "file server"
hardware.  It's just an artifact of how cpurc is set up.  It's
trivially changable, should you desire to.

--lyndon

Re: [TUHS] cat -v and other complaints

[Bakul Shah]

On Sep 3, 2018, at 11:11 AM, Kurt H Maier <khm@sciops.net> wrote:
> 
> I still dislike Acme for basically all the same reasons I dislike emacs.

What text editor do you like?

One measure of success of a program is additional tools people build
to work with it. By that measure emacs has succeeded very well. Acme
is used by far fewer people but it too has had additional tools built. And
even standard tools such as grep work well with it. You can also view it
as an experiment and not an end product. That is, nothing to prevent
anyone from extending it or changing it. The same is true of plan9 too.
An experiment in seeing how far “representing resources as filesystems”
model can be pushed. But for some reason this never happened.  

Re: [TUHS] cat -v and other complaints

[Kurt H Maier]

On Mon, Sep 03, 2018 at 01:08:41PM -0700, Bakul Shah wrote:
> 
> One measure of success of a program is additional tools people build
> to work with it. 

This is true, but unix and plan 9 are special because they have
facilities that let many tools work together.  Unix has pipes, plan 9
has the plumber on top of that, and so forth.  I prefer tools that work
with these systems to create an environment that lets me use the whole
world to do my job.

Emacs pointlessly restricts itself to its own reinventions of the world
it inhabits.  It makes sense if you are using a LispM but it
constitutes a rejection of the 'system' component of 'operating system'
when you transplant it to an ecosystem built on a different paradigm.

The current modality of this antisocial behavior is the web; we've come
full circle, and now we have bespoke web browsers shoved into the
text-editing role, reinventing everything from character addressing to
memory management on the way, treating the underlying system as an
unfortunate accident of history instead of integrating with (or even
learning from) it.

Acme is a bad citizen in similar ways, but as I said, I suspect that's
because it was intended to supplant Rio rather than infect it.

When people talk about "the unix way," they usually hyperfocus on "do
one thing well" and leave composability by the wayside, and that's a
shame, because that's where the real power comes from.  "Do one thing
well" is a method to achieve quality when you're building a piece of a
well-integrated system.  If you're not building a well-integrated
system, you *can't* "do one thing well," because you've signed on to do
everything, come hell or high water.

khm

Re: [TUHS] cat -v and other complaints

[Bakul Shah]

On Sep 3, 2018, at 1:41 PM, Kurt H Maier <khm@sciops.net> wrote:
> 
> Acme is a bad citizen in similar ways, but as I said, I suspect that's
> because it was intended to supplant Rio rather than infect it.

I’m still not clear on why you think acme is a bad citizen. If anything it
makes its windows more accessible to other tools. Unlike emacs or vim
or any IDE. What could acme have differently or what other editor is
not a “bad citizen”.

> When people talk about "the unix way," they usually hyperfocus on "do
> one thing well" and leave composability by the wayside, and that's a
> shame, because that's where the real power comes from.  "Do one thing
> well" is a method to achieve quality when you're building a piece of a
> well-integrated system.  If you're not building a well-integrated
> system, you *can't* "do one thing well," because you've signed on to do
> everything, come hell or high water.

Composability is implicitly the key point in “the Unix way” but typically
editors are not very composable. Or composable in a different domain.
Similarly GUI. Once you add a human in your composition, further
composability falls apart! A human being the ultimate “do everything”
kitchen sink:-)

The question is what can be done to improve composability beyond the
“Unix way” or plan9 way.

Re: [TUHS] cat -v and other complaints

[Kurt H Maier]

On Mon, Sep 03, 2018 at 02:46:14PM -0700, Bakul Shah wrote:
> 
> I’m still not clear on why you think acme is a bad citizen. If anything it
> makes its windows more accessible to other tools. Unlike emacs or vim
> or any IDE. What could acme have differently or what other editor is
> not a “bad citizen”.
> 

Ok.  I apologize for expressing myself poorly.  I give up.

> Composability is implicitly the key point in “the Unix way” but typically
> editors are not very composable. Or composable in a different domain.
> Similarly GUI. Once you add a human in your composition, further
> composability falls apart! A human being the ultimate “do everything”
> kitchen sink:-)

I don't consider myself on an equal footing as the tools I use.  I don't
"add a human in my composition."  I compose.  This is a pretty
fundamental difference between me and software.

> The question is what can be done to improve composability beyond the
> “Unix way” or plan9 way.

I have about a million questions to answer first, and I suspect the
industry as a whole will collapse and re-form a few times before anyone
gets around to answering that one.

We haven't even fully developed composability in "the unix way" since
market forces seem to have frozen things in a sort of late-1980s amber.
I envy the future generation that rediscovers the core concept and
runs with it, but I doubt I'll be around then.  Information technology
is entering an ice age in which general-purpose computing is not
guaranteed to select for survival; the barrier to entry for
understanding systems has never been higher, there is a distinct and
global trend against it, and the cost of thirty years' abuse of Moore's
law is coming due.

Hunter Thompson's high-water mark comes to mind.  

I am grateful, for these reasons, for the efforts of people like TUHS
and Bitsavers, so that I can still find and use the tools that were made
back before people confused the simplistic for the simple, even if it
gets harder to make a living with them each passing year.

khm