[TUHS] Were all of you.. Hippies?

[TUHS] Were all of you.. Hippies?

[Noel Chiappa]

I can't wait to see how you all fit remote procedure calls into a file
paradigm.

	Noel

[TUHS] Were all of you.. Hippies?

[Andrew Warkentin]

On 3/25/17, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> I can't wait to see how you all fit remote procedure calls into a file
> paradigm.
>
> 	Noel
>
There are lots of RPC protocols that run over TCP which is for the
most part an unstructured byte stream, so there's no reason why RPC
couldn't be run over a local file transport in a similar way
(especially with one that preserves message boundaries, unlike TCP,
which requires application-layer protocols to implement their own
framing).

[TUHS] Were all of you.. Hippies?

[Kurt H Maier]

On Sat, Mar 25, 2017 at 11:11:22PM -0400, Noel Chiappa wrote:
> I can't wait to see how you all fit remote procedure calls into a file
> paradigm.

By making the file endpoints available to the remote side and doing a
regular procedure call.

I'm still fuzzy on why "read" and "write" are somehow too specialized 
for you, but this is rapidly getting off-topic for TUHS, so if you want
some pointers on where to read more about this stuff I guess you can
email me off-list.

khm

[TUHS] Were all of you.. Hippies?

[Dan Cross]

On Sat, Mar 25, 2017 at 11:11 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> I can't wait to see how you all fit remote procedure calls into a file
> paradigm.
>

I don't mean to sound flippant, but isn't that exactly what every RPC
protocol implemented on top of sockets has done for the last 30 or so years?

I feel like saying otherwise conflates two tangentially related things:
namespaces to name IPC endpoints in a "file" like manner, and an API to
deal with file-like objects as a byte stream on which one uses operations
like read and write. Certainly there is no REASON that sendto() et al can't
be implemented in terms of write(), but arguably the plethora of such as
*system calls* stems from the inability to name them in a way accessible to
open().

The plan9 model is imperfect but serves as the existence proof that it
*can* be done.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170325/2ac62efd/attachment-0001.html>

[TUHS] Were all of you.. Hippies?

[ron minnich]

On Sat, Mar 25, 2017 at 8:11 PM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

> I can't wait to see how you all fit remote procedure calls into a file
> paradigm.
>
>
https://www.usenix.org/legacy/event/sec02/cox/cox.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170326/140e6533/attachment.html>

[TUHS] Were all of you.. Hippies?

[Lyndon Nerenberg]

> On Mar 25, 2017, at 8:11 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> 
> I can't wait to see how you all fit remote procedure calls into a file
> paradigm.

For a simple example, see http://plan9.bell-labs.com/magic/man2html/4/ftpfs .

This uses the usual filesystem interface to the network stack to manage the underlying TCP connections.  The FTP protocol is implemented inside the ftpfs fileserver process which itself exports a directory into the filesystem namespace.  Fileservers are the natural representation of RPC protocols in plan9, and they work quite well.

Of course, not everything will naturally map to a filesystem namespace.  But a surprisingly large number of things will, given some thought to the problem.

http://plan9.bell-labs.com/sys/doc/names.pdf is a must-read to appreciate the nuances of how this works.

--lyndon

P.S.  A fun example of the simplicity of the plan9 network API is this implementation of rlogin: http://plan9.bell-labs.com/sources/contrib/rsc/rlogin

[TUHS] Were all of you.. Hippies?

[Larry McVoy]

On Sun, Mar 26, 2017 at 09:26:00AM -0700, Lyndon Nerenberg wrote:
> P.S.  A fun example of the simplicity of the
> plan9 network API is this implementation of rlogin:
> http://plan9.bell-labs.com/sources/contrib/rsc/rlogin

So while that is really neat, I personally think that's part of why Plan 9
didn't take off.  It's too clever, at least for me.  I know the rlogin
code pretty well and if you showed me that code and asked me what it was,
without the comments, I don't think I would have put it together.  On
the other hand, show me the C code and I'd be able to figure it out.

It's perhaps because I'm not the sharpest tool in the shed, but I really
like how blindingly obvious a lot of the original Unix code was.  Not saying
it was all that way, but a ton of it was sort of what you would imagine it
to be before you saw it.  Which means I understood it and could bugfix it.
-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Were all of you.. Hippies?

[Steve Simon]

> On 26 Mar 2017, at 17:40, Larry McVoy <lm at mcvoy.com> wrote:
> 
>> On Sun, Mar 26, 2017 at 09:26:00AM -0700, Lyndon Nerenberg wrote:
>> P.S.  A fun example of the simplicity of the
>> plan9 network API is this implementation of rlogin:
>> http://plan9.bell-labs.com/sources/contrib/rsc/rlogin
> 
> So while that is really neat, I personally think that's part of why Plan 9
> didn't take off.  It's too clever, at least for me.  I know the rlogin
> code pretty well and if you showed me that code and asked me what it was,
> without the comments, I don't think I would have put it together.  On
> the other hand, show me the C code and I'd be able to figure it out.
> 
> It's perhaps because I'm not the sharpest tool in the shed, but I really
> like how blindingly obvious a lot of the original Unix code was.  Not saying
> it was all that way, but a ton of it was sort of what you would imagine it
> to be before you saw it.  Which means I understood it and could bugfix it.
> -- 
> ---
> Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 

perhaps that was a rather extreme example, you can write rlogin in shell script, but con(1) is more typical - in C.

http://plan9.bell-labs.com/sources/plan9/sys/src/cmd/con/con.c

perhaps this is closer to what you would expect.

The network stuff is all wrapped up in the dial(2) library func, but note rawon and rawoff are pretty neat.

-Steve

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170326/65157afc/attachment.html>

[TUHS] Were all of you.. Hippies?

[Andy Kosela]

On Sunday, March 26, 2017, Larry McVoy <lm at mcvoy.com> wrote:

> On Sun, Mar 26, 2017 at 09:26:00AM -0700, Lyndon Nerenberg wrote:
> > P.S.  A fun example of the simplicity of the
> > plan9 network API is this implementation of rlogin:
> > http://plan9.bell-labs.com/sources/contrib/rsc/rlogin
>
> So while that is really neat, I personally think that's part of why Plan 9
> didn't take off.  It's too clever, at least for me.  I know the rlogin
> code pretty well and if you showed me that code and asked me what it was,
> without the comments, I don't think I would have put it together.  On
> the other hand, show me the C code and I'd be able to figure it out.
>
> It's perhaps because I'm not the sharpest tool in the shed, but I really
> like how blindingly obvious a lot of the original Unix code was.  Not
> saying
> it was all that way, but a ton of it was sort of what you would imagine it
> to be before you saw it.  Which means I understood it and could bugfix it.
>
>
A lot of original UNIX code was simple, but we ended up with 272 lines of
bloat in echo.c[1].  That bloat started to creep in already in the
beginning
when Rob Pike formulated his famous presentation on cat(1)[2].  I also
think that sockets implementation was the turning point.

Plan 9 was probably the last truly dedicated effort to keep it simple using
the UNIX way of doing things.  I much prefer reading its code than GNU
or FreeBSD.  I think the world really needs a Unix operating system which
is as simple and elegant as Plan 9.

[1] http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/echo.c
[2] http://harmful.cat-v.org/cat-v/unix_prog_design.pdf

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170326/1d7a1d09/attachment.html>

[TUHS] Were all of you.. Hippies?

[Doug McIlroy]

Nudging the thread back twoard Unix history:

> I really
> like how blindingly obvious a lot of the original Unix code was.  Not saying
> it was all that way, but a ton of it was sort of what you would imagine it
> to be before you saw it.  Which means I understood it and could bugfix it.

That's an important aspect of Thompson's genius--code so clean and right
that, having seen it, one cannot imagine it otherwise. But the odds are
that the same program from another hand would not have the same ring of
inevitability. As Erdos was wont to say of an elegant proof, "It comes

[TUHS] Were all of you.. Hippies?

[Noel Chiappa]

    > From: Andrew Warkentin

    > especially with one that preserves message boundaries

Records in the file-system! How very Unix-like!

      Noel

[TUHS] Were all of you.. Hippies?

[Dan Cross]

On Sat, Mar 25, 2017 at 11:32 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>     > From: Andrew Warkentin
>
>     > especially with one that preserves message boundaries
>
> Records in the file-system! How very Unix-like!
>

No. Records implemented at a layer above that of the bare system calls (or,
in the case of datagram-oriented protocols, coordinated between two layers
sandwiching read()/write()). That seems very Unix-like to me: consider
ndbm, Berkeley DB, etc. The point is that the interface as exposed by the
kernel doesn't care.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170325/c2f4c72f/attachment.html>

[TUHS] Were all of you.. Hippies?

[Ron Natalie]

Maintaining records iwas far from unheard of at the time networking showed up in UNIX.    Think about how the UNIX tape driver works.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170326/ecde84e8/attachment-0001.html>

[TUHS] Were all of you.. Hippies?

[Larry McVoy]

On Sun, Mar 26, 2017 at 07:31:30AM -0400, Ron Natalie wrote:
> Maintaining records iwas far from unheard of at the time networking showed up in UNIX.    Think about how the UNIX tape driver works.

I think that unix "records" are just a struct in binary in the file.  That's a
little different (a lot different?) than what most operating systems mean by
records.  Unless I'm mistaken.

[TUHS] Were all of you.. Hippies?

[Wesley Parish]

To give an example of what one other operating system means by records, I point you in the direction 
of:
http://www.conceptsolutionsbc.com/mvs-articles/197-mvs-file-system

"Windows and *NIX file systems are based on hierarchical directory structure. Basically, you have one 
root directory and you can create directories (sometimes called folders) or files under that root 
directory. Mainframe disk files are very different to this hierarchical approach."

"MVS datasets always have record lengths. MVS access methods read and write records in physical 
blocks. A block is made up of one or more logical record. This diagram shows the block sizes and 
difference between fixed block and variable block data sets.

The access method is responsible for splitting the block into logical records and passing the record to 
the program. Although a program can handle breaking the blocks into logical records, this task is 
normally done by the access method. A record length can be fixed or variable."

If you're familiar with the Network and Hierarchical Database systems from practical experience or from 
working through non-relational dbms books, this all looks very familiar. Essentially such file systems 
are hierarchical dbmses. As should be expected from MVS's derivation from batch systems.

I don't know anything about the DEC VAX VMS file system. I was meaning to learn a few years ago, but 
other things happened ...

FWVLIW

Wesley Parish

Quoting Larry McVoy <lm at mcvoy.com>:

> On Sun, Mar 26, 2017 at 07:31:30AM -0400, Ron Natalie wrote:
> > Maintaining records iwas far from unheard of at the time networking
> showed up in UNIX. Think about how the UNIX tape driver works.
> 
> I think that unix "records" are just a struct in binary in the file.
> That's a
> little different (a lot different?) than what most operating systems
> mean by
> records. Unless I'm mistaken.
>  



"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar

"A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn

[TUHS] Were all of you.. Hippies?

[Dave Horsfall]

On Sun, 26 Mar 2017, Ron Natalie wrote:

> Think about how the UNIX tape driver works.

I'd rather not, if you don't mind...  That thing was *ugly* (and we had 
two TU-10s on our TM-11), but if you wanted to read a 7-track tape then 
you had to courier it to Sydney University.

I don't remember how many times I rewrote that driver.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Were all of you.. Hippies?

[Warner Losh]

On Sat, Mar 25, 2017 at 9:32 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>     > From: Andrew Warkentin
>
>     > especially with one that preserves message boundaries
>
> Records in the file-system! How very Unix-like!

Multiple levels of protocols layered on top simpler primitives.
Unheard of in Unix.

Warner

[TUHS] Were all of you.. Hippies?

[Noel Chiappa]

    > From: Ron Minnich

    > There was no shortage of people at the time who were struggling to find
    > a way to make the Unix model work for networking ...  It didn't quite
    > work out

For good reason.

It's only useful to have a file-name _name_ for a thing if...  the thing acts
like a file - i.e. you can plug that file-name into other places you might use
a file-name (e.g. '> {foo}' or 'ed <foo>', etc, etc).

There is very little in the world of networking that acts like a file. Yes,
you can go all hammer-nail, and use read() and write() to get data back and
forth, and think that makes it a file - but it's not.

For instance, files, as far as I know, generally don't have timeout
semantics. Can the average application that deals with a file, deal reasonably
with the fact that sometimes one gets half-way through the 'file' - and things
stop working?  And that's a _simple_ one.  How does a file abstraction match
to a multi-cast lossy (i.e. packets may be lost) datagram group?

For another major point (and the list goes on, I just can't be bothered to go
through it all), there's usually all sorts of other higher-level protocol in
there, so only specialized applications can make use of it anyway. Look at
HTTP: there's specialized syntax one has to spit out to say what file you
want, and the HTML files you get back from that can generally only be usefully
used in a browser.

Etc, etc.

     Noel

[TUHS] Were all of you.. Hippies?

[Kurt H Maier]

On Sat, Mar 25, 2017 at 09:35:20PM -0400, Noel Chiappa wrote:
> 
> For instance, files, as far as I know, generally don't have timeout
> semantics. Can the average application that deals with a file, deal reasonably
> with the fact that sometimes one gets half-way through the 'file' - and things
> stop working?  And that's a _simple_ one. 

The unwillingness to even attempt to solve problems like these in a
generalized and consistent manner is a source of constant annoyance to
me.  Of course it's easier to pretend that never happens on a "real"
file, since disks never, ever break.  

Of course, there are parts of the world that don't make these
assumptions, and that's where I've put my career, but the wider IT
industry still likes to pretend that storage and networking are
unrelated concepts.  I've never understood why.

khm

[TUHS] Were all of you.. Hippies?

[Nick Downing]

I think Noel put it very well, when I saw the read()/write()  vs
recvfrom()/sendto() stuff mentioned earlier I was going to say that part of
the contract of read()/write() is that they are stream oriented thus things
like short reads and writes should behave in a predictable way and have the
expected recovery semantics. So having it be boundary preserving or having
a header on the data would in my view make it not read()/write() even if
the new call can be overlaid on read()/write() at the ABI level. I think
the contract of a syscall is an important part of its semantics even if it
may be an "unwritten rule". However, Noel said it better: If it's not
file-like then a file-like interface may not be appropriate.

Having said that, Kurt raises an equally valid point which is that the
"every file is on a fast locally attached harddisk" traditional unix
approach has serious problems. Not that I mind the simplicity: contemporary
systems had seriously arcane file abstractions that made file I/O useless
to all but the most experienced developer. I come from a microcomputer
background and I am thinking of Apple II DOS 3.3, CP/M 2.2 and its FCB
based interface and MSDOS 1.x (same). When MSDOS 2.x came along with its
Xenix-subset file API it was seriously a revelation to me and others.
Microcomputers aside, my understanding is IBM 360/370 and contemporary DEC
OS's were also complicated to use, with record based I/O etc.

So it's hard to criticize unix's model, but on the other hand the lack of
any nonblocking file I/O and the contract against short reads/writes (but
only for actual files) and the lack of proper error reporting or recovery
due to the ASSUMPTION of a write back cache, whether or not one is actually
used in practice... makes the system seriously unscaleable, in particular
as Kurt points out, the system is forced to try to hide the network
socket-like characteristics of files that are either on slow DMA or
PIO/interrupt based devices (think about a harddisk attached by serial
port, something that I actually encountered on a certain cash register
model and had to develop for back in the day), or an NFS based file, or
maybe a file on a SAN accessed by iSCSI, etc.

Luckily I think there is an easy fix, have the OS export a more socket-like
interface to files and provide a userspace compatibility library to do
things like detecting short reads/writes and retrying them, and/or blocking
while a slow read or write executes. It woukd be slightly tricky getting
the EINTR semantics correct if the second or subsequent call of a multipart
read or write was interrupted, but I think possible.

On the other hand I would not want to change the sockets API one bit, it is
perfect. (Controversial I know, I discussed this in detail in a recent
post).

Nick

On Mar 26, 2017 12:46 PM, "Kurt H Maier" <khm at sciops.net> wrote:

On Sat, Mar 25, 2017 at 09:35:20PM -0400, Noel Chiappa wrote:
>
> For instance, files, as far as I know, generally don't have timeout
> semantics. Can the average application that deals with a file, deal
reasonably
> with the fact that sometimes one gets half-way through the 'file' - and
things
> stop working?  And that's a _simple_ one.

The unwillingness to even attempt to solve problems like these in a
generalized and consistent manner is a source of constant annoyance to
me.  Of course it's easier to pretend that never happens on a "real"
file, since disks never, ever break.

Of course, there are parts of the world that don't make these
assumptions, and that's where I've put my career, but the wider IT
industry still likes to pretend that storage and networking are
unrelated concepts.  I've never understood why.

khm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170326/daa64e6b/attachment.html>

[TUHS] Were all of you.. Hippies?

[ron minnich]

On Sat, Mar 25, 2017 at 6:35 PM Noel Chiappa <jnc at mercury.lcs.mit.edu>
wrote:

>
>
>
> There is very little in the world of networking that acts like a file. Yes,
> you can go all hammer-nail, and use read() and write() to get data back and
> forth, and think that makes it a file - but it's not.
>
>
The plan 9 networking stack, in use for over 25 years now, begs to disagree
with you. The model works wonderfully well in practice and even in theory.

To take one part of your note, can file reads time out? Well, yeah. We live
in a networked world and anything we can do with anything can time out. But
even in a pre-network world, assuming that "file I/O doesn't time out"
wasn't even true when -- and especially -- in the days of RK05 disk drives.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170326/8b2f2290/attachment.html>

[TUHS] Were all of you.. Hippies?

[Andrew Warkentin]

On 3/25/17, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>     > From: Ron Minnich
>
>     > There was no shortage of people at the time who were struggling to
> find
>     > a way to make the Unix model work for networking ...  It didn't quite
>     > work out
>
> For good reason.
>
> It's only useful to have a file-name _name_ for a thing if...  the thing
> acts
> like a file - i.e. you can plug that file-name into other places you might
> use
> a file-name (e.g. '> {foo}' or 'ed <foo>', etc, etc).
>
> There is very little in the world of networking that acts like a file. Yes,
> you can go all hammer-nail, and use read() and write() to get data back and
> forth, and think that makes it a file - but it's not.
>
> For instance, files, as far as I know, generally don't have timeout
> semantics. Can the average application that deals with a file, deal
> reasonably
> with the fact that sometimes one gets half-way through the 'file' - and
> things
> stop working?  And that's a _simple_ one.  How does a file abstraction
> match
> to a multi-cast lossy (i.e. packets may be lost) datagram group?
>
> For another major point (and the list goes on, I just can't be bothered to
> go
> through it all), there's usually all sorts of other higher-level protocol
> in
> there, so only specialized applications can make use of it anyway. Look at
> HTTP: there's specialized syntax one has to spit out to say what file you
> want, and the HTML files you get back from that can generally only be
> usefully
> used in a browser.
>

Just because an OS provides unstructured files as its primary or only
IPC primitive doesn't mean that you can't run a structured protocol
over them (after all, the IP protocol suite provides only unstructured
transports - byte streams or unconnected datagrams - to the
application layer). That's what I'm planning to do in UX/RT. Services
that don't fit into an unstructured file model will run a structured
protocol over the file transport (UX/RT will provide a
message-boundary-preserving special file type specifically because
it's easier to implement RPC-like and other structured protocols over
such a transport). And just because such services will be harder to
use with tools like ed, cat, and the like doesn't mean there aren't
other advantages to having them in the filesystem. In UX/RT, the main
advantages of the file-oriented architecture for services using
structured protocols will be the unified security model and the ease
of overriding such services with filter servers (e.g. UX/RT's fakeroot
will be a pure server rather than an unreliable LD_PRELOAD hack, and
in a similar vein, jails in UX/RT will be able to virtualize as much
or as little as desired rather than being pretty much all-or-nothing
like in a lot of other OSes).

[TUHS] Were all of you.. Hippies?

[Noel Chiappa]

    > From: Random832

    > Does readlink need to exist as a system call? Maybe it should be
    > possible to open and read a symbolic link - using a flag passed to open

What difference does it make? The semantics are the same, only the details of the
syntax are different.

       Noel

[TUHS] Were all of you.. Hippies?

[Noel Chiappa]

    > From: Random832

    > "a stream consisting of a serialized sequence of all of whatever
    > information would have been supplied to/by the calls to the special
    > function" seems like a universal solution at the high level.

Yes, and when the only tool you have is a hammer, everything look like
a nail.

	Noel

[TUHS] Were all of you.. Hippies?

[Noel Chiappa]

    > From: Nick Downing

    > Programming is actually an addiction.

_Can be_ an addition. A lot of people are immune... :-)

    > What makes it addictive to a certain type of personality is that little
    > rush of satisfaction when you try your code and it *works*... ... It was
    > not just the convenience and productivity improvements but that the
    > 'hit' was coming harder and faster.

Joe Weizenbaum wrote about the addiction of programming in his famous book
"Computer Power and Human Reason" (Chapter 4, "Science and the Compulsive
Programmer"). He attributes it to the sense of power one gets, working in a
'world' where things do exactly what you tell them. There might be something
to that, but I suspect your supposition is more likely.

    > This theory is well known to those who design slot machines and other
    > forms of gambling

Oddly enough, he also analogizes to gamblers!

   Noel

[TUHS] Were all of you.. Hippies?

[Wesley Parish]

I put a certain amount of time last decade at a community centre's cybercaf in Christchurch, NZ, into 
teaching elderly people who have not previously had much experience with computers, how to use 
them. You do get a buzz when someone who's previously been full of questions, suddenly "gets it" and 
their eyes light up and no more questions, let's get things done!

It's not dissimilar to the buzz you get when you enter some code and it does what you think it should, 
not something else.

Just my 0.02c

Wesley Parish

Quoting Noel Chiappa <jnc at mercury.lcs.mit.edu>:

> > From: Nick Downing
> 
>  > Programming is actually an addiction.
> 
> _Can be_ an addition. A lot of people are immune... :-)
> 
>  > What makes it addictive to a certain type of personality is that
> little
>  > rush of satisfaction when you try your code and it *works*... ... It
> was
>  > not just the convenience and productivity improvements but that the
>  > 'hit' was coming harder and faster.
> 
> Joe Weizenbaum wrote about the addiction of programming in his famous
> book
> "Computer Power and Human Reason" (Chapter 4, "Science and the
> Compulsive
> Programmer"). He attributes it to the sense of power one gets, working
> in a
> 'world' where things do exactly what you tell them. There might be
> something
> to that, but I suspect your supposition is more likely.
> 
>  > This theory is well known to those who design slot machines and
> other
>  > forms of gambling
> 
> Oddly enough, he also analogizes to gamblers!
> 
>  Noel
>  



"I have supposed that he who buys a Method means to learn it." - Ferdinand Sor,
Method for Guitar

"A verbal contract isn't worth the paper it's written on." -- Samuel Goldwyn

[TUHS] Were all of you.. Hippies?

[Noel Chiappa]

    > From: Tim Bradshaw

    > I don't know about other people, but I think the whole dope thing is why
    > computer people tend *not* to be hippies in the 'dope smoking' sense.  I
    > need to be *really awake* to write reasonably good code ... our drugs
    > of choice are stimulants not depressants.

Speak for yourself! :-)

(Then again, I have wierd neuro-chemistry - I have modes where I have a large
over-sppply of natural stimulant... :-)

My group (which included Prof. Jerry Salzter, who's about as straight an arrow
as they make) was remarkably tolerant of my, ah, quirks... I recall at one
point having a giant tank of nitrous under the desk in my office - which they
boggled at, but didn't say anything about! ;-)

      Noel

[TUHS] Were all of you.. Hippies?

[Nick Downing]

Programming is actually an addiction. What makes it addictive to a certain
type of personality is that little rush of satisfaction when you try your
code and it *works*... and while this is still true to an extent of batch
systems from the 50s and 60s it was the interactive systems of the 70s
onwards that really spurred the development of the hacker subculture. It
was not just the convenience and productivity improvements but that the
'hit' was coming harder and faster.

This theory is well known to those who design slot machines and other forms
of gambling, it is called the theory of occasional rewards. With this in
mind, frequent long debugging sessions do not make the process any less
addictive, indeed MORE addictive since the occasional rewards are less
predictable etc. With this in mind it is unsurprising that programmers tend
to have other fixes too such as coffee, harder drugs or even gambling. Some
personalities seem to be quite susceptible to occasional-rewards things.

Nick

On Mar 23, 2017 4:49 AM, "Noel Chiappa" <jnc at mercury.lcs.mit.edu> wrote:

>     > From: Tim Bradshaw
>
>     > I don't know about other people, but I think the whole dope thing is
> why
>     > computer people tend *not* to be hippies in the 'dope smoking'
> sense.  I
>     > need to be *really awake* to write reasonably good code ... our drugs
>     > of choice are stimulants not depressants.
>
> Speak for yourself! :-)
>
> (Then again, I have wierd neuro-chemistry - I have modes where I have a
> large
> over-sppply of natural stimulant... :-)
>
> My group (which included Prof. Jerry Salzter, who's about as straight an
> arrow
> as they make) was remarkably tolerant of my, ah, quirks... I recall at one
> point having a giant tank of nitrous under the desk in my office - which
> they
> boggled at, but didn't say anything about! ;-)
>
>       Noel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170323/7ea34b04/attachment.html>

[TUHS] Were all of you.. Hippies?

[shawn wilson]

Didn't xkcd do a graph of alcohol consumption vs code output? Alcohol isn't
really my thing wrt drugs (I like the taste but don't prefer the effects)
so it doesn't much work for me, but talking with friends, it seems to be a
popular enough thing to do that there must be at least a little basis in
fact (obviously anecdotal too).

I know I used to better at thinking about the best way to approach
something under some influence - but that's not when you want to try to
debug stuff (friends who drink and code agree with that too).

Wrt the thrill of making something work - I dig that. OTOH, if I didn't
have to write code to see stuff get done, I probably wouldn't (or might
switch to something that is just for fun like smalltalk or make joke
projects like cobol on cogs - which is actually kinda cool).

On Mar 22, 2017 18:44, "Nick Downing" <downing.nick at gmail.com> wrote:

Programming is actually an addiction. What makes it addictive to a certain
type of personality is that little rush of satisfaction when you try your
code and it *works*... and while this is still true to an extent of batch
systems from the 50s and 60s it was the interactive systems of the 70s
onwards that really spurred the development of the hacker subculture. It
was not just the convenience and productivity improvements but that the
'hit' was coming harder and faster.

This theory is well known to those who design slot machines and other forms
of gambling, it is called the theory of occasional rewards. With this in
mind, frequent long debugging sessions do not make the process any less
addictive, indeed MORE addictive since the occasional rewards are less
predictable etc. With this in mind it is unsurprising that programmers tend
to have other fixes too such as coffee, harder drugs or even gambling. Some
personalities seem to be quite susceptible to occasional-rewards things.

Nick

On Mar 23, 2017 4:49 AM, "Noel Chiappa" <jnc at mercury.lcs.mit.edu> wrote:

>     > From: Tim Bradshaw
>
>     > I don't know about other people, but I think the whole dope thing is
> why
>     > computer people tend *not* to be hippies in the 'dope smoking'
> sense.  I
>     > need to be *really awake* to write reasonably good code ... our drugs
>     > of choice are stimulants not depressants.
>
> Speak for yourself! :-)
>
> (Then again, I have wierd neuro-chemistry - I have modes where I have a
> large
> over-sppply of natural stimulant... :-)
>
> My group (which included Prof. Jerry Salzter, who's about as straight an
> arrow
> as they make) was remarkably tolerant of my, ah, quirks... I recall at one
> point having a giant tank of nitrous under the desk in my office - which
> they
> boggled at, but didn't say anything about! ;-)
>
>       Noel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170323/314c3cad/attachment.html>

[TUHS] Were all of you.. Hippies?

[Chet Ramey]

On 3/23/17 4:56 AM, shawn wilson wrote:

> I know I used to better at thinking about the best way to approach
> something under some influence - but that's not when you want to try to
> debug stuff (friends who drink and code agree with that too).

Introducing tomorrow's bugs today!


-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/

[TUHS] Were all of you.. Hippies?

[Tim Bradshaw]

On 22 Mar 2017, at 22:35, Nick Downing <downing.nick at gmail.com> wrote:
> 
> It was not just the convenience and productivity improvements but that the 'hit' was coming harder and faster.

I think this is completely right, and is the reason that really interactive / resident environments can be so catastrophically addictive.  Even on a fairly slow machine it doesn't take more than a second or so to compile a single function, and the whole edit/save/compile/link/debug cycle becomes compressed to edit/compile-one-function/debug, with cycle times of a few seconds.  I have quite seriously lost a year of my life this way, although I am reasonably sure that part of the problem is that the Xerox d-machines were actually made by the Fair Folk and using them for any length of time results in the standard issues associated with dealing with artifacts of the Fay.

[TUHS] Were all of you.. Hippies?

[Doug McIlroy]

> The hippie mentality had a lot of influence on everyone in that
> generation - including the computer nerds/hackers.

I'm not sure what hippie attributes you had in mind, but one
candidate would be "free and open". In software, though, free
and open was the style of the late 50s. By the hippie heyday
p
p

[TUHS] Were all of you.. Hippies?

[shawn wilson]

Maybe there's a generation / technology gap here. But from history, it
doesn't seem like there was much free - though most did indeed to be open -
I suppose much like the VMS model. At least not until the 80s (or maybe
bash predates that trend).

The C language might've been free, but I wonder if there were any free
compilers until gcc (hell I remember pirating Borland). Even most copies of
*BSD were mainly sold on CD vs downloaded until 10 years or so ago (even
though it was technically free - not including BSDi)


On Mar 20, 2017 7:28 PM, "Doug McIlroy" <doug at cs.dartmouth.edu> wrote:


> The hippie mentality had a lot of influence on everyone in that
> generation - including the computer nerds/hackers.

I'm not sure what hippie attributes you had in mind, but one
candidate would be "free and open". In software, though, free
and open was the style of the late 50s. By the hippie heyday
p
p
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170320/f21f6101/attachment-0001.html>

[TUHS] Were all of you.. Hippies?

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1041 bytes --]

I had a student when I was Associate Director at Rutgers.   He was sure that his key to getting a job on graduation was to go smooze people at Uniforum.     So he got on one of our “social” mailing lists at the time and inquired what appropriate dress would be (i.e., should he wear a suit).    Before anybody else could answer Erik Fair told him that the dress was indeed casual, usually shorts, but you had to wear Birkenstocks.    So here goes this kid hunting around in New Jersey in December looking for Birkenstocks.

 

A few weeks after the conference he came back sporting a hair style more commonly found on the gay men in the community.    I asked if he had gone through a lifestyle change, and he said this was how the guys he met at the conference had their hair.   I had to point out that most of the crowd we were hanging out with were indeed gay.

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170321/523e2173/attachment.html>

[TUHS] Were all of you.. Hippies?

[Derrik Walker v2.0]

On 03/20/2017 07:28 PM, Doug McIlroy wrote:
>> The hippie mentality had a lot of influence on everyone in that
>> generation - including the computer nerds/hackers.
> I'm not sure what hippie attributes you had in mind, but one
> candidate would be "free and open". In software, though, free
> and open was the style of the late 50s. By the hippie heyday
> p
> p
Wouldn't that depend on the generation?

As a long haired metal head x-gener ... yea, I'm NO hippy!!

- Derrik

-- 
-- Derrik

Derrik Walker v2.0, RHCE
dwalker at doomd.net

"Those UNIX guys, they think weird!" -- John C. Dvorak


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3703 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170320/a422bdd4/attachment.bin>

[TUHS] Were all of you.. Hippies?

[Noel Chiappa]

    > From: Steffen Nurpmeso

    > This "We owe it all to the Hippies"

Well, yes and no. Read "Hackers". There wasn't a tremendous overlap between
the set of 'nerds' (specifically, computer nerds) and 'hippies', especially in
the early days. Not that the two groups were ideologically opposed, or
incompatible, or anything like that. Just totally different.

Later on, of course, there were quite a few hackers who were also 'hippies',
to some greater or lesser degree - more from hackers taking on the hippie
vibe, than the other way around, I reckon. (I think that to be a true computer
nerd, you have to start down that road pretty early on, and with a pretty
severe commitment - so I don't think a _lot_ of hippied turned into hackers.
Although I guess the same thing, about starting early, is true of really
serious musicians.)

    > "The real legacy of the 60s generation is the Computer Revolution"

Well, there is something to that (and I think others have made this
observation). The hippie mentality had a lot of influence on everyone in that
generation - including the computer nerds/hackers. Now, the hackers may have
had a larger, impact, long-term, than the hippies did - but in some sense a
lot of hippie ideals are reflected in the stuff a lot of hackers built:
today's computer revolution can be seen as hippie idealism filtered through
computer nerds...

But remember things like this, from the dust-jacket of the biography of
Prof. Licklider:

 "More than a decade will pass before personal computers emerge from the
 garages of Silicon Valley, and a full thirty years before the Internet
 explosion of the 1990s. The word computer still has an ominous tone,
 conjuring up the image of a huge, intimidating device hidden away in an
 over-lit, air-conditioned basement, relentlessly processing punch cards for
 some large institution: _them_. Yet, sitting in a nondescript office in
 McNamara's Pentagon, a quiet ... civilian is already planning the revolution
 that will change forever the way computers are perceived. Somehow, the
 occupant of that office ... has seen a future in which computers will empower
 individuals, instead of forcing them into rigid conformity. He is almost
 alone in his conviction that computers can become not just super-fast
 calculating machines, but joyful machines: tools that will serve as new media
 of expression, inspirations to creativity, and gateways to a vast world of
 online information.

Now, technically Lick wasn't a hippie (he was, after all, 40 years old in
1965), and he sure didn't have a lot of hippie-like attributes - but he was,
in some ways, an ideological close relative of some hippies.

	Noel

[TUHS] Were all of you.. Hippies?

[Steffen Nurpmeso]

jnc at mercury.lcs.mit.edu (Noel Chiappa) wrote:
 |> From: Steffen Nurpmeso
 |
 |> This "We owe it all to the Hippies"
 |
 |Well, yes and no. Read "Hackers". There wasn't a tremendous overlap between

So you went through this 30 years ago already.  I see, maybe.

[TUHS] Were all of you.. Hippies?

[arnold]

> Later on, of course, there were quite a few hackers who were also 'hippies',
> to some greater or lesser degree - more from hackers taking on the hippie
> vibe, than the other way around, I reckon.

I think that's pretty true. Look at RMS. He still looks like a hippie, and his
ideals seem pretty influenced by what was going on then.

I was a child during the 60s and 70s, but I remember a lot of what went
on from TV, newspapers etc.  I was never a hippie myself. :-)

My $0.02,

Arnold

[TUHS] Were all of you.. Hippies?

[Jason Stevens]

Speaking of Licklider, here is an amazingly prophetic video from 1972

https://youtu.be/GjZ7ktIlSM0



On March 21, 2017 6:17:59 AM GMT+08:00, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>    > From: Steffen Nurpmeso
>
>    > This "We owe it all to the Hippies"
>
>Well, yes and no. Read "Hackers". There wasn't a tremendous overlap
>between
>the set of 'nerds' (specifically, computer nerds) and 'hippies',
>especially in
>the early days. Not that the two groups were ideologically opposed, or
>incompatible, or anything like that. Just totally different.
>
>Later on, of course, there were quite a few hackers who were also
>'hippies',
>to some greater or lesser degree - more from hackers taking on the
>hippie
>vibe, than the other way around, I reckon. (I think that to be a true
>computer
>nerd, you have to start down that road pretty early on, and with a
>pretty
>severe commitment - so I don't think a _lot_ of hippied turned into
>hackers.
>Although I guess the same thing, about starting early, is true of
>really
>serious musicians.)
>
>   > "The real legacy of the 60s generation is the Computer Revolution"
>
>Well, there is something to that (and I think others have made this
>observation). The hippie mentality had a lot of influence on everyone
>in that
>generation - including the computer nerds/hackers. Now, the hackers may
>have
>had a larger, impact, long-term, than the hippies did - but in some
>sense a
>lot of hippie ideals are reflected in the stuff a lot of hackers built:
>today's computer revolution can be seen as hippie idealism filtered
>through
>computer nerds...
>
>But remember things like this, from the dust-jacket of the biography of
>Prof. Licklider:
>
>"More than a decade will pass before personal computers emerge from the
> garages of Silicon Valley, and a full thirty years before the Internet
> explosion of the 1990s. The word computer still has an ominous tone,
>conjuring up the image of a huge, intimidating device hidden away in an
>over-lit, air-conditioned basement, relentlessly processing punch cards
>for
>some large institution: _them_. Yet, sitting in a nondescript office in
>McNamara's Pentagon, a quiet ... civilian is already planning the
>revolution
> that will change forever the way computers are perceived. Somehow, the
>occupant of that office ... has seen a future in which computers will
>empower
>individuals, instead of forcing them into rigid conformity. He is
>almost
> alone in his conviction that computers can become not just super-fast
>calculating machines, but joyful machines: tools that will serve as new
>media
>of expression, inspirations to creativity, and gateways to a vast world
>of
> online information.
>
>Now, technically Lick wasn't a hippie (he was, after all, 40 years old
>in
>1965), and he sure didn't have a lot of hippie-like attributes - but he
>was,
>in some ways, an ideological close relative of some hippies.
>
>	Noel

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170321/e5d77f66/attachment-0001.html>

[TUHS] Were all of you.. Hippies?

[Steffen Nurpmeso]

Jason Stevens <jsteve at superglobalmegacorp.com> wrote:
 |Speaking of Licklider, here is an amazingly prophetic video from 1972
 |
 |[1]https://youtu.be/GjZ7ktIlSM0[/1]

Many thanks for this link, very interesting, i soaked it all in!

--steffen

[TUHS] Were all of you.. Hippies?

[Jason Stevens]

There is some IMP stuff on SIMH, but I'll be damned if any of it makes sense.  Apparently it "runs", although it really makes no sense....

There is a test script to push a packet, so I suppose one could feed the imp via debug, although it's not quite right

On March 23, 2017 6:13:58 PM GMT+08:00, Steffen Nurpmeso <steffen at sdaoden.eu> wrote:
>Jason Stevens <jsteve at superglobalmegacorp.com> wrote:
> |Speaking of Licklider, here is an amazingly prophetic video from 1972
> |
> |[1]https://youtu.be/GjZ7ktIlSM0[/1]
>
>Many thanks for this link, very interesting, i soaked it all in!
>
>--steffen

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170323/d65a0826/attachment.html>

[TUHS] Were all of you.. Hippies?

[Steffen Nurpmeso]

Maybe of interest, here is something spacewarish..

  |I was at Berkeley until July 1981.

I had to face a radio program which purported that..

  Alles, was die digitale Kultur dominiert, haben wir den Hippies
  zu verdanken.

  Anything which dominates the digital culture is owed to the
  Hippies

This "We owe it all to the Hippies" as well as "The real legacy of
the 60s generation is the Computer Revolution" actually in English
on [1] (talking about the beginning of the actual broadcast), the
rest in German.  But it also lead(s) (me) to an article of the
Rolling Stone, December 1972, on "Fanatic Life and Symbolic Death
Among the Computer Bums"[2].

  [1] http://www.swr.de/swr2/programm/sendungen/essay/swr2-essay-flowerpowerdatenterror/-/id=659852/did=18984524/nid=659852/1cbfavu/index.html
  [2] http://www.wheels.org/spacewar/stone/rolling_stone.html

That makes me quite jealous of your long hair, i see manes
streaming in the warm wind of a golden Californian sunset.

I don't think the assessment is right, though, i rather think it
is a continous progress of science and knowledge, then maybe also
pushed by on-all-fronts efforts like "bringing a moon to the moon
by the end of the decade", and, sigh, SDI, massive engineer and
science power concentration, etc.  And crumbs thereof approaching
the general public, because of increased knowledge in the
industry.  (E.g., the director of the new experimental German
fusion reactor that finally sprang into existence claimed
something like "next time it will not be that expensive due to
what everybody has learned".)  And hunger for money, of course,
already in the 70s we had game consoles en masse in Italy, for
example, with Pacman, Donkey Kong and later then with Dragons Lair
or what its name was ("beautiful cool graphics!" i recall, though
on the street there were Italian peacocks, and meaning the
birds!).

--steffen

[TUHS] Were all of you.. Hippies?

[Dave Horsfall]

Well, I certainly had long hair and a beard (still do, at 64!), a Unix 
user since about 1976 (basically when it first arrived in Australia), and 
have "liberal" views (as in: not conservative); does that count?

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Were all of you.. Hippies?

[Ron Natalie]

Just a bunch of Unix-smoking dope gurus.


-----Original Message-----
From: TUHS [mailto:tuhs-bounces@minnie.tuhs.org] On Behalf Of Dave Horsfall
Sent: Monday, March 20, 2017 6:11 PM
To: The Eunuchs Hysterical Society
Subject: Re: [TUHS] Were all of you.. Hippies?

Well, I certainly had long hair and a beard (still do, at 64!), a Unix user
since about 1976 (basically when it first arrived in Australia), and have
"liberal" views (as in: not conservative); does that count?

--
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
suffer."

[TUHS] Were all of you.. Hippies?

[ron minnich]

At the time I got into Unix in 1976, E. F. Schumacher's "Small is
Beautiful" book was fairly popular, with IBM and the BUNCH as the bloated
counterpoint (OS/MVS kernels were 256K!), and the idea of Unix as the small
is beautiful operating system was a common theme.

It wasn't really about small. Small was the happy result of a way of
approaching problems. It was about putting in the time to think things
through, rather than just emitting gobs of code. Hence a common theme was
the idea you did your best to avoid writing code by spending time working
things through. RK05s, 16 bit address space, and Decwriter II terminals
tended to encourage that kind of economy. Those days are long gone of
course; I noticed the other day that on Linux there are 16 commands that
start with ls, that do roughly the same function, and nobody seems to think
this is a bad thing. The only place the original 'small is beautiful' Unix
ideas continue on that I know of is Plan 9.

ron

On Mon, Mar 20, 2017 at 3:32 PM Ron Natalie <ron at ronnatalie.com> wrote:

> Just a bunch of Unix-smoking dope gurus.
>
>
> -----Original Message-----
> From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Dave
> Horsfall
> Sent: Monday, March 20, 2017 6:11 PM
> To: The Eunuchs Hysterical Society
> Subject: Re: [TUHS] Were all of you.. Hippies?
>
> Well, I certainly had long hair and a beard (still do, at 64!), a Unix user
> since about 1976 (basically when it first arrived in Australia), and have
> "liberal" views (as in: not conservative); does that count?
>
> --
> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
> suffer."
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170320/c16ee16c/attachment.html>

[TUHS] Were all of you.. Hippies?

[Nick Downing]

For me the nerd stage was a bit like the caterpillar whereas the hippy
stage was the butterfly. So you know, I'm a proud ex-nerd and a proud
ex-hippy, however I moved past both things a long time ago. If my kids
were to become nerds or hippies though, I would understand, since we
all need to make our own mistakes to move forward. As to the other
topic of Ron's post, well "small is beautiful" continues here, however
I find my ideas not gaining much currency on this forum. That could
be, because it's a historical forum rather than a "how to develop and
improve unix" forum. Or it could be, because people after using
something for a lifetime tend to take for granted a lot of the design
ideas in it.
cheers, Nick

On Tue, Mar 21, 2017 at 10:05 AM, ron minnich <rminnich at gmail.com> wrote:
> At the time I got into Unix in 1976, E. F. Schumacher's "Small is Beautiful"
> book was fairly popular, with IBM and the BUNCH as the bloated counterpoint
> (OS/MVS kernels were 256K!), and the idea of Unix as the small is beautiful
> operating system was a common theme.
>
> It wasn't really about small. Small was the happy result of a way of
> approaching problems. It was about putting in the time to think things
> through, rather than just emitting gobs of code. Hence a common theme was
> the idea you did your best to avoid writing code by spending time working
> things through. RK05s, 16 bit address space, and Decwriter II terminals
> tended to encourage that kind of economy. Those days are long gone of
> course; I noticed the other day that on Linux there are 16 commands that
> start with ls, that do roughly the same function, and nobody seems to think
> this is a bad thing. The only place the original 'small is beautiful' Unix
> ideas continue on that I know of is Plan 9.
>
> ron
>
> On Mon, Mar 20, 2017 at 3:32 PM Ron Natalie <ron at ronnatalie.com> wrote:
>>
>> Just a bunch of Unix-smoking dope gurus.
>>
>>
>> -----Original Message-----
>> From: TUHS [mailto:tuhs-bounces at minnie.tuhs.org] On Behalf Of Dave
>> Horsfall
>> Sent: Monday, March 20, 2017 6:11 PM
>> To: The Eunuchs Hysterical Society
>> Subject: Re: [TUHS] Were all of you.. Hippies?
>>
>> Well, I certainly had long hair and a beard (still do, at 64!), a Unix
>> user
>> since about 1976 (basically when it first arrived in Australia), and have
>> "liberal" views (as in: not conservative); does that count?
>>
>> --
>> Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will
>> suffer."
>>
>

[TUHS] Were all of you.. Hippies?

[Josh Good]

On 2017 Mar 20, 23:05, ron minnich wrote:
> At the time I got into Unix in 1976, E. F. Schumacher's "Small is
> Beautiful" book was fairly popular

> (...) Those days are long gone of course; I noticed the other day that
> on Linux there are 16 commands that start with ls, that do roughly
> the same function, and nobody seems to think this is a bad thing. The
> only place the original 'small is beautiful' Unix ideas continue on
> that I know of is Plan 9.

In RedHat Enterprise Linux 5.11 (without X-Window) I get:

$ ls<tab>
ls           lsattr       lsb_release  lshal        lspgpot

Whereas in Ubuntu 14.04 (full desktop install) I get:

$ ls<tab>
ls           lsblk        lscpu        lsdvd        lsinitramfs  lsof         lspcmcia     lss16toppm
lsattr       lsb_release  lsdiff       lshw         lsmod        lspci        lspgpot      lsusb

But then, in UnixWare 2.1 I get:

$ bash<enter>
bash-2.01$ ls<tab>
  (...no output...)

So yeah, it's getting more bloated by the day.

Anyone can contribute how is it on a recent OpenBSD without X-Window?

-- 
Josh Good

[TUHS] Were all of you.. Hippies?

[Michael Parson]

On Tue, 21 Mar 2017, Josh Good wrote:

> Date: Tue, 21 Mar 2017 21:28:40 +0100
> From: Josh Good <pepe at naleco.com>
> To: tuhs at minnie.tuhs.org
> Subject: Re: [TUHS] Were all of you.. Hippies?
> 
> On 2017 Mar 20, 23:05, ron minnich wrote:
>> At the time I got into Unix in 1976, E. F. Schumacher's "Small is
>> Beautiful" book was fairly popular
>
>> (...) Those days are long gone of course; I noticed the other day that
>> on Linux there are 16 commands that start with ls, that do roughly
>> the same function, and nobody seems to think this is a bad thing. The
>> only place the original 'small is beautiful' Unix ideas continue on
>> that I know of is Plan 9.
>
> In RedHat Enterprise Linux 5.11 (without X-Window) I get:
>
> $ ls<tab>
> ls           lsattr       lsb_release  lshal        lspgpot
>
> Whereas in Ubuntu 14.04 (full desktop install) I get:
>
> $ ls<tab>
> ls           lsblk        lscpu        lsdvd        lsinitramfs  lsof         lspcmcia     lss16toppm
> lsattr       lsb_release  lsdiff       lshw         lsmod        lspci        lspgpot      lsusb
>
> But then, in UnixWare 2.1 I get:
>
> $ bash<enter>
> bash-2.01$ ls<tab>
>  (...no output...)
>
> So yeah, it's getting more bloated by the day.
>
> Anyone can contribute how is it on a recent OpenBSD without X-Window?

How about NetBSD 6.1.4:

$ ls<tab>
ls         lsb        lsextattr  lsof       lspci      lsx        lsz

Though only 'ls' and 'lsextattr' are part of the base install, the
others are owned by various things installed out of pkgsrc, ls[bxz] are
all from the same package.

-- 
Michael Parson
Pflugerville, TX
KF5LGQ

[TUHS] Were all of you.. Hippies?

[ron minnich]

My belief is that if a kernel requires something like lspci to enumerate
pci resources then it's forgotten an important lesson of Unix.

On Thu, Mar 23, 2017 at 1:19 PM Michael Parson <mparson at bl.org> wrote:

> On Tue, 21 Mar 2017, Josh Good wrote:
>
> > Date: Tue, 21 Mar 2017 21:28:40 +0100
> > From: Josh Good <pepe at naleco.com>
> > To: tuhs at minnie.tuhs.org
> > Subject: Re: [TUHS] Were all of you.. Hippies?
> >
> > On 2017 Mar 20, 23:05, ron minnich wrote:
> >> At the time I got into Unix in 1976, E. F. Schumacher's "Small is
> >> Beautiful" book was fairly popular
> >
> >> (...) Those days are long gone of course; I noticed the other day that
> >> on Linux there are 16 commands that start with ls, that do roughly
> >> the same function, and nobody seems to think this is a bad thing. The
> >> only place the original 'small is beautiful' Unix ideas continue on
> >> that I know of is Plan 9.
> >
> > In RedHat Enterprise Linux 5.11 (without X-Window) I get:
> >
> > $ ls<tab>
> > ls           lsattr       lsb_release  lshal        lspgpot
> >
> > Whereas in Ubuntu 14.04 (full desktop install) I get:
> >
> > $ ls<tab>
> > ls           lsblk        lscpu        lsdvd        lsinitramfs  lsof
>      lspcmcia     lss16toppm
> > lsattr       lsb_release  lsdiff       lshw         lsmod        lspci
>       lspgpot      lsusb
> >
> > But then, in UnixWare 2.1 I get:
> >
> > $ bash<enter>
> > bash-2.01$ ls<tab>
> >  (...no output...)
> >
> > So yeah, it's getting more bloated by the day.
> >
> > Anyone can contribute how is it on a recent OpenBSD without X-Window?
>
> How about NetBSD 6.1.4:
>
> $ ls<tab>
> ls         lsb        lsextattr  lsof       lspci      lsx        lsz
>
> Though only 'ls' and 'lsextattr' are part of the base install, the
> others are owned by various things installed out of pkgsrc, ls[bxz] are
> all from the same package.
>
> --
> Michael Parson
> Pflugerville, TX
> KF5LGQ
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170323/3e09d759/attachment.html>

[TUHS] Were all of you.. Hippies?

[Josh Good]

On 2017 Mar 23, 20:51, ron minnich wrote:
> My belief is that if a kernel requires something like lspci to enumerate
> pci resources then it's forgotten an important lesson of Unix.

Could you elaborate?

I think the kernel does not need lspci to enumerate PCI resources,
instead that command makes the kernel output to the console its internal
enumeration of the PCI resources.

-- 
Josh Good

[TUHS] Were all of you.. Hippies?

[Larry McVoy]

On Fri, Mar 24, 2017 at 01:18:35AM +0100, Josh Good wrote:
> On 2017 Mar 23, 20:51, ron minnich wrote:
> > My belief is that if a kernel requires something like lspci to enumerate
> > pci resources then it's forgotten an important lesson of Unix.
> 
> Could you elaborate?
> 
> I think the kernel does not need lspci to enumerate PCI resources,
> instead that command makes the kernel output to the console its internal
> enumeration of the PCI resources.

I think Ron is just in Grumpy Old Man mode (he's a friend, we go way back,
so I get to say that :)

Personally, I sort of get the ls<something> model.  ls is how you list 
things, <something> is how you say what you want to list.  Is it Unix
like?  Hmm, perhaps not.  Is it useful?  Like a lot of stuff that Linux
did, hell yes it's useful.  I've written perl scripts to paw through
/proc and /sys to do the same thing and each time I've found a ls<xxx>
that does what I want I have gleefully tossed my script.

Linux is weird.  It's not elegant like the early unix systems, it's 
not as well put together if you look at it through unix glasses (and
don't get me started on plan 9 glasses).  But it is *useful*.  They 
favored useful over elegant.  I don't think they disliked elegant,
I suspect that many of us would say they didn't have the good taste
to do elegant, whatever.  It's useful.  I'll take that.  And it's
really not that bad.  Unless you are grumpy and want a perfect world.

[TUHS] Were all of you.. Hippies?

[ron minnich]

On Thu, Mar 23, 2017 at 5:28 PM Larry McVoy <lm at mcvoy.com> wrote:

>
>
> I think Ron is just in Grumpy Old Man mode (he's a friend, we go way back,
> so I get to say that :)
>
> Personally, I sort of get the ls<something> model.  ls is how you list
> things, <something> is how you say what you want to list.  Is it Unix
> like?  Hmm, perhaps not.
>

like larry said. I'm a grumpy old man. And lspci is not Unix. And neither
is anything we use nowadays that begins with ls and has more than 2 letters.

In Unix, resources have names. They are visible in a name space, organized
into directories. The names can be enumerated by opening and reading a
directory. Information about them can be determined with stat. Their
contents can be read by open and read. They can be changed with open and
write.

it's a pretty simple and consistent model. And it works just fine with,
e.g., the the Plan 9 pnp device. From my point of view, if a user needs
lspci to enumerate PCI resources, it's because the kernel has fallen down
on the job by failing to support the Unix model.

I can argue this point all day, but I'll let it go at that :-)

thanks

ron
p.s. It's not you, it's me. "You, sir, are a curmudgeon"  -- Rob Pike, to
me, on 9fans. As a result of this note, while I was at Los Alamos I was
assigned curmudgeon at lanl.gov. Made my day.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170324/2bed247f/attachment.html>

[TUHS] Were all of you.. Hippies?

[Larry McVoy]

This reminds me of Rodger Faulkner.  Ron and Rodger would have gotten on
very well.

On Fri, Mar 24, 2017 at 01:03:03AM +0000, ron minnich wrote:
> On Thu, Mar 23, 2017 at 5:28 PM Larry McVoy <lm at mcvoy.com> wrote:
> 
> >
> >
> > I think Ron is just in Grumpy Old Man mode (he's a friend, we go way back,
> > so I get to say that :)
> >
> > Personally, I sort of get the ls<something> model.  ls is how you list
> > things, <something> is how you say what you want to list.  Is it Unix
> > like?  Hmm, perhaps not.
> >
> 
> like larry said. I'm a grumpy old man. And lspci is not Unix. And neither
> is anything we use nowadays that begins with ls and has more than 2 letters.
> 
> In Unix, resources have names. They are visible in a name space, organized
> into directories. The names can be enumerated by opening and reading a
> directory. Information about them can be determined with stat. Their
> contents can be read by open and read. They can be changed with open and
> write.
> 
> it's a pretty simple and consistent model. And it works just fine with,
> e.g., the the Plan 9 pnp device. From my point of view, if a user needs
> lspci to enumerate PCI resources, it's because the kernel has fallen down
> on the job by failing to support the Unix model.
> 
> I can argue this point all day, but I'll let it go at that :-)
> 
> thanks
> 
> ron
> p.s. It's not you, it's me. "You, sir, are a curmudgeon"  -- Rob Pike, to
> me, on 9fans. As a result of this note, while I was at Los Alamos I was
> assigned curmudgeon at lanl.gov. Made my day.

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] Were all of you.. Hippies?

[Andrew Warkentin]

On 3/23/17, ron minnich <rminnich at gmail.com> wrote:
> like larry said. I'm a grumpy old man. And lspci is not Unix. And neither
> is anything we use nowadays that begins with ls and has more than 2
> letters.
>
> In Unix, resources have names. They are visible in a name space, organized
> into directories. The names can be enumerated by opening and reading a
> directory. Information about them can be determined with stat. Their
> contents can be read by open and read. They can be changed with open and
> write.
>
> it's a pretty simple and consistent model. And it works just fine with,
> e.g., the the Plan 9 pnp device. From my point of view, if a user needs
> lspci to enumerate PCI resources, it's because the kernel has fallen down
> on the job by failing to support the Unix model.
>

While I agree 100% that all resources, including things like PCI
devices, should be exposed through special files, I still think
there's a place for commands like lspci, as long as they're
implemented as shell scripts that format information from the special
files. That's what I'm going to do in the OS I'm going to write (which
will look sort of like a cross between Plan 9 and QNX, and will be
even more filesystem-oriented than Plan 9). A lot of commands that are
binaries on other modern Unices will be shell scripts on my OS (Plan 9
does this to some extent as well).

Personally I'd say Unix started to lose its way architecturally with
the introduction of sockets in 4.2BSD. I think it's time for a new
Unix-like OS that both follows the Unix philosophy consistently and
remains compatible with conventional Unices. I'd say several of Plan
9's design decisions have held it back as a Unix successor without
providing any real advantage over a conventional Unix.

[TUHS] Were all of you.. Hippies?

[Random832]

On Thu, Mar 23, 2017, at 22:33, Andrew Warkentin wrote:
> While I agree 100% that all resources, including things like PCI
> devices, should be exposed through special files, I still think
> there's a place for commands like lspci, as long as they're
> implemented as shell scripts that format information from the special
> files.

I posted my earlier post before seeing this one - I do have to wonder,
why exactly do shell scripts (or interpreted languages generally, if it
could be an awk script or a perl script) have a special place in this
philosophy?

[TUHS] Were all of you.. Hippies?

[Erik E. Fair]

Andrew,
	I'm a fan of Plan 9's elegance and clean design, but beware of the limitations of the abstractions you choose. One place that files and connections don't work cleanly is in actual datagram networking. You can do TCP easily, but UDP and especially broadcast/multicast make a hash of the abstraction. That's how you end up with sendto(2), sendmsg(2), recvfrom(2), recvmsg(2).

One could also point to the seemingly endless number of ioctl(2) commands as a failure of the file abstraction to encompass all the necessary service elements - hence that escape mechanism.

This is the wonder and the problem of Turing machines: they can do almost anything - so what functions and services do you expose, and what do you hide? What is most useful to a large enough group of software developers and users that your model will be accepted, used, supported by contribution, and perhaps lauded?

Whenever we want total control, we can always revert to assembly and/or machine language. Or beach sand.

	Erik Fair

[TUHS] Were all of you.. Hippies?

[Random832]

On Fri, Mar 24, 2017, at 01:37, Erik E. Fair wrote:
> Andrew,
> 	I'm a fan of Plan 9's elegance and clean design, but beware of the limitations of the abstractions you choose. One place that files and connections don't work cleanly is in actual datagram networking. You can do TCP easily, but UDP and especially broadcast/multicast make a hash of the abstraction. That's how you end up with sendto(2), sendmsg(2), recvfrom(2), recvmsg(2).

Why?

For UDP, just have the data returned from read() include the length and
source address. You could do the same for write, or require a separate
socket for each destination. You could even force-fit the read side into
the connection model; have a "listening" socket that you have to
"accept" each new source address from; but you'd still need a solution
for message lengths. I'm not familiar with the issues with
broadcast/multicast/*msg functions, but "a stream consisting of a
serialized sequence of all of whatever information would have been
supplied to/by the calls to the special function" seems like a universal
solution at the high level.

[TUHS] Were all of you.. Hippies?

[Andrew Warkentin]

On 3/23/17, Larry McVoy <lm at mcvoy.com> wrote:
>
> I only know a tiny amount about Plan 9, never dove into deeply.  QNX,
> on the other hand, I knew quite well.  I was pretty good friends with
> one of the 3 or 4 people who were allowed to work on the microkernel, Dan
> Hildebrandt.  He died in 1998, but before then he and I used to call each
> other pretty often to talk about kernel stuff, how stuff ought to be done.
> The calls weren't jerk off sessions, they were pretty deep conversations,
> we challenged each other.  I was very skeptical about microkernels,
> I'd seen Mach and found it lacking, seen Minix and found it lacking
> (though that's a little unfair to Minix compared to Mach).  Dan brought
> me around to believing in the microkernel but only if the kernel was
> actually a kernel.  Their kernel didn't use up a 4K instruction cache,
> it left room for the apps and the processes that did the rest.  That's
> why only a few people were allowed to work on the kernel, they counted
> every single instruction cache footprint.
>
> So tell me more about your OS, I'm interested.

Where do I start? I've got much of the design planned out. I've
thought about the design for many years now and changed my plans on
some things quite a few times. Currently the only code I have is a
bootloader that I've been working on somewhat intermittently for a
while now, as well as a completely untested patch for seL4 to add
support for QNX-ish single image boot. I am planning to borrow Linux
and BSD code where it makes sense, so I have less work to do.

It will be called UX/RT (for Universally eXtensible Real Time
operating system, although it's also a kind of a nod to QNX originally
standing for Quick uNiX), and it will be primarily intended as a
workstation and embedded OS (although it would be also be good for
servers where security is more important than I/O throughput, and also
for HPC). It will be a microkernel-based multi-server OS.

Like I said before, it will superficially resemble QNX in its general
architecture (for example, much like QNX, the lowest-level user-mode
component will be a single root server called "proc", which will
handle process management and filesystem namespace management),
although the specifics of the IPC model will be somewhat different. I
will be using seL4 and/or Rux as the microkernel (so unlike that of
QNX, UX/RT's process server will be a completely separate program).
proc and most other first-party components will be mostly written in
Rust rather than C, although there will still be a lot of third-party
C code. The network stack, disk filesystems, and graphics drivers will
be based on the NetBSD rump kernel and/or LKL (which is a
"librarified" version of the Linux kernel; I'll probably provide both
Linux and NetBSD implementations and allow switching between them and
possibly combining them) with Rust glue layers on top. For
performance, the disk drivers and disk filesystems will run within the
same server (although there will be one disk server per host adapter),
and the network stack will also be a single server, much like in QNX
(like QNX, UX/RT will mostly avoid intermediary servers and will
usually follow a process-per-subsystem architecture rather than a
process-per-component one like a lot of other multi-sever OSes, since
intermediary servers can hurt performance).

As I said before, UX/RT will take file-oriented architecture even
further than Plan 9 does. fork() and some thread-related APIs will be
pretty much the only APIs implemented as non-file-based primitives.
Pretty much the entire POSIX/Linux API will be implemented although
most non-file-based system calls will have file-based implementations
underneath (for example, getpid() will do a readlink() of /proc/self
to get the PID). Even process memory like the process heap and stack
will be implemented as files in a per-process memory filesystem (a bit
like in Multics) rather than being anonymous like on most other OSes.
ioctl() will be a pure library function for compatibility purposes,
and will be implemented in terms of read() and write() on a secondary
file.

Unlike other microkernel-based OSes, UX/RT won't provide any way to
use message passing outside of the file-based API. read() and write()
will use kernel calls to communicate directly with the process on the
other end (unlike some microkernel Unices in which they go through an
intermediary server). There will be APIs that expose the underlying
transport (message registers for short messages and a shared per-FD
buffer for long ones), although they will still operate on file
descriptors, and read()/write() and the low-level messaging APIs will
all use the same header format so that processes don't have to care
which API the process on the other
end uses (unlike on QNX where there are a few different incompatible
messaging APIs). There will be a new "message special" file type that
will preserve message boundaries, similar to SEQPACKET Unix-domain
sockets or SCTP (these will be ideal for RPC-type APIs).

File descriptors will be implemented as sets of kernel capabilities,
meaning that servers won't have to check permissions like they do on
QNX. The API for servers will be somewhat socket-like. Each server
will listen on a "port" file in a special filesystem internal to the
process server, sort of like /mnt on Plan 9 (although it will be
possible for servers to export ports within their own filesystems as
well).  Reads from the port will produce control messages which may
transfer file descriptors. Each client file descriptor will have a
corresponding file descriptor on the server side, and servers will use
a superset of the regular file API to transfer data. Device numbers as
such will not exist (the device number field in the stat structure
will be a port ID that isn't split into major and minor numbers), and
device files will normally be exported directly by their server,
rather than residing on a filesystem exported by one driver but being
serviced by another as in conventional Unix. However, there will be a
sort of similar mechanism, allowing a server to export "firm links"
that are like cross-filesystem hard links (similar to in QNX).

Per-process namespaces like in Plan 9 will be supported. Unlike in
Plan 9, it will be possible for processes with sufficient privileges
to mount filesystems in the namespaces of other processes (to allow
more flexible scoping of mount points). Multiple mounts on one
directory will produce a union like in both QNX and Plan 9. Binding
directories as in Plan 9 will also be supported. In addition to the
per-process root on / there will also be a global root directory on //
into which filesystems are mounted. The per-process name spaces will
be constructed by binding directories from // into the / of the
process (neither direct mounts under / nor bindings in // will be
supported, but bindings between parts of / will of course be
supported).

The security model will be based on a per-process default-deny ACL
(which will be purely in memory; persisting process ACLs will be
implemented with an external daemon). It will be possible for ACL
entries to explicitly specify permissions, or to use the permissions
from the filesystem with (basically) normal Unix semantics. It will
also be possible for an entry to be a wildcard allowing access to all
files in a directory. Unlike in conventional Unix, there will be no
root-only system calls (anything security-sensitive will have a
separate device file to which access can be controlled through process
ACLs), and running as root will not automatically grant a process full
privileges. The suid and sgid bits will have no effect on executables
(the ACL management daemon will handle privilege escalation instead).

The native API will be mostly compatible with that of Linux, and a
purely library-based Linux compatibility layer will be available. The
only major thing the Linux compatibility layer specifically won't
support will be stuff dealing with logging users in (since it won't be
possible to revert to traditional Unix security, and utmp/wtmp won't
exist). The package manager will be based on dpkg and apt with hooks
to make them work in a functional way somewhat like Nix but using
per-process bindings, allowing for multiple environments or universes
consisting of different sets of packages (environments will be able to
be either native UX/RT or Linux compatibility environments, and it
will be possible to create Linux environments that aren't managed by
the UX/RT package manager to allow compatibility environments for
non-dpkg Linux distributions).

The init system will have some features in common with SMF and
systemd, but unlike those two, it will be modular, flexible, and
lightweight. System initialization such as checking/mounting
filesystems and bringing up network interfaces will be script-driven
like in traditional init systems, whereas starting daemons will be
done with declarative unit files that will be able to call (mostly
package-independent) hook scripts to set up the environment for the
daemon.

Initially I will use X11 as the window system, but I will replace it
with a lightweight compositing window server that will export
directories providing a low-level DRI-like interface per window.
Unlike a lot of other compositing window systems, UX/RT's window
system will use X11-style central client-side window management. I was
thinking of using a default desktop environment based on GNUstep
originally but I'm not completely sure if I'll still do that (a long
time ago I had wanted to put together a Mac OS X-like or NeXTStep-like
Linux distribution using a GNUstep-based desktop, a DPS-based window
server, and something like a fork of mkLinux with a stable module ABI
for a kernel, but soon decided I wanted to write a QNX-like OS
instead).

>
> Sockets are awesome but I have to agree with you, they don't "fit".
> Seems like they could have been plumbed into the file system somehow.
>

Yeah, the almost-but-not-quite-file-based nature of the socket API is
my biggest complaint about it. UX/RT will support the socket API but
it will be implemented on top of the normal file system.

> Can't speak to your plan 9 comments other than to say that the fact
> that you are looking for provided value gives me hope that you'll get
> somewhere.  No disrespect to plan 9 intended, but I never saw why it
> was important that I moved to plan 9.  If you do something and there
> is a reason to move there, you could be worse but still go farther.

I'd say a major problem with Plan 9 is the way it changes things in
incompatible ways that provide little advantage over the traditional
Unix way of doing things (for example, instead of errno, libc
functions set a pointer to an error string instead, which I don't
think provides enough of a benefit to break compatibility). Another
problem is that some facilities Plan 9 provides aren't general enough
(e.g. the heavy focus on SSI clustering, which never really was widely
adopted, or the rather 80s every-window-is-a-terminal window system).

UX/RT will try to be compatible with conventional Unices and
especially Linux wherever it is reasonable, since lack of applications
would significantly hold it back. It will also try to be as general as
possible without overcomplicating things.

[TUHS] Were all of you.. Hippies?

[Random832]

On Fri, Mar 24, 2017, at 20:41, Andrew Warkentin wrote:
> As I said before, UX/RT will take file-oriented architecture even
> further than Plan 9 does. fork() and some thread-related APIs will be
> pretty much the only APIs implemented as non-file-based primitives.
> Pretty much the entire POSIX/Linux API will be implemented although
> most non-file-based system calls will have file-based implementations
> underneath (for example, getpid() will do a readlink() of /proc/self
> to get the PID).

Does readlink need to exist as a system call? Maybe it should be
possible to open and read a symbolic link - using a flag passed to open,
like AT_SYMLINK_NOFOLLOW.

[TUHS] Were all of you.. Hippies?

[Andrew Warkentin]

On 3/24/17, Random832 <random832 at fastmail.com> wrote:
>
> Does readlink need to exist as a system call? Maybe it should be
> possible to open and read a symbolic link - using a flag passed to open,
> like AT_SYMLINK_NOFOLLOW.
>
You have a point there. UX/RT will still obviously need to retain the
readlink() function (since compatibility with conventional Unix will
be a major feature, and it's also convenient to have a single function
to get the target of a link), although it could be implemented with a
normal read underneath. Same with opendir(), readdir(), and the like,
which I was definitely planning on implementing with normal reads
(under BSD they seem to already be implemented that way).

[TUHS] Were all of you.. Hippies?

[Random832]

On Thu, Mar 23, 2017, at 21:03, ron minnich wrote:
> In Unix, resources have names. They are visible in a name space,
> organized
> into directories. The names can be enumerated by opening and reading a
> directory. Information about them can be determined with stat. Their
> contents can be read by open and read. They can be changed with open and
> write.

And if each resource has a directory (possibly organized in a
multiple-level hierarchy) containing several files that describe
attributes of that resource, what are you to do when you want to print a
report listing a summary of some information about those resources, one
per line? And of course the information in these files is numeric -
surely you don't expect the database of descriptions to be compiled into
the kernel. So the tool has to go and fetch those too.

[TUHS] Were all of you.. Hippies?

[ron minnich]

So, first, I'm not here to argue about the merits or lack thereof of the
Unix model as I described it. I am just trying to explain my view of what
the Unix model was. Since this is the TUHS, I'm trying hard to avoid things
related to LUHS, or 9UHS :-)

So, nope, I'm not responding to the comments that I see as out of scope of
TUHS. Lack of response does not indicate agreement :-)

But it got me to thinking: what aspects of the Unix model did not age well?
It's certainly aged remarkably well for 50 years. But what would we do
differently?  I'm glad that at least one subsequent effort -- by the guys
who invented these things as it happens -- fixed most of the list that
follows.

Without further ado, and based on the v6 system call set, which is where I
came in (I'm biased) ...

Device special files. These gave us the situation we have today with major
and minor numbers. I deal with it daily. I wish I did not have to. And we
don't need them.

ptrace -- there's much better ways to do what ptrace does.

Open which combines walk and open. Linux at some point added O_PATH, which
is very nice, as it lets you get an fd for a file but not actually open it,
and 9p has walk and open, but sadly plan 9 never exposed them; it just has
open which does both. There's two kernels I'm involved in which will be
breaking open out into walk and open. But who knew 50 years ago you'd want
two ops, not one?

ioctl.

unidirectional pipes. Bidirectional pipes are so much nicer.

errno. Once you get used to getting an error string from the kernel, with
detailed information, errno just drives you crazy.

integer user ids. Totally reasonable approach pre-networking on 16-bit
machines, but think of the amount of trouble that integer user ids give us.
There was a time when a file name was just an integer, and we'd never
accept that now; why do we still accept an integer for a user name?

root user.

and the big one ....

fork.The amount of abuse I've seen heaped on fork over the years is pretty
amazing. I always found it convenient, but at the same time, how much
effort have we expended as we move from processes with 16 or 128 4k pages
to processes with, in some cases, millions of fds and pages? How many gray
hairs has fork caused you over the years? Would you pick something else?

What do you see that you think could be done differently, given 50 years to
look back?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170324/51c05929/attachment.html>

[TUHS] Were all of you.. Hippies?

[Dave Horsfall]

On Fri, 24 Mar 2017, ron minnich wrote:

> What do you see that you think could be done differently, given 50 years 
> to look back?

I'd spell "creat" with an "e".

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Were all of you.. Hippies?

[Toby Thain]

On 2017-03-24 8:02 PM, Dave Horsfall wrote:
> On Fri, 24 Mar 2017, ron minnich wrote:
>
>> What do you see that you think could be done differently, given 50 years
>> to look back?
>
> I'd spell "creat" with an "e".
>


SNERK!

[TUHS] Were all of you.. Hippies?

[shawn wilson]

On Fri, Mar 24, 2017, 01:15 Random832 <random832 at fastmail.com> wrote:

> On Thu, Mar 23, 2017, at 21:03, ron minnich wrote:
> > In Unix, resources have names. They are visible in a name space,
> > organized
> > into directories. The names can be enumerated by opening and reading a
> > directory. Information about them can be determined with stat. Their
> > contents can be read by open and read. They can be changed with open and
> > write.
>
> And if each resource has a directory (possibly organized in a
> multiple-level hierarchy) containing several files that describe
> attributes of that resource, what are you to do when you want to print a
> report listing a summary of some information about those resources, one
> per line?
>

In bash -
which read -a foo; do echo <(cmd ${foo[0]});
done #...? :)

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170324/a73f1a23/attachment.html>

[TUHS] Were all of you.. Hippies?

[Josh Good]

On 2017 Mar 24, 07:23, shawn wilson wrote:
> On Fri, Mar 24, 2017, 01:15 Random832 <random832 at fastmail.com> wrote:
> 
> > On Thu, Mar 23, 2017, at 21:03, ron minnich wrote:
> > > In Unix, resources have names. They are visible in a name space,
> > > organized
> > > into directories. The names can be enumerated by opening and reading a
> > > directory. Information about them can be determined with stat. Their
> > > contents can be read by open and read. They can be changed with open and
> > > write.
> >
> > And if each resource has a directory (possibly organized in a
> > multiple-level hierarchy) containing several files that describe
> > attributes of that resource, what are you to do when you want to print a
> > report listing a summary of some information about those resources, one
> > per line?
> >
> 
> In bash -
> which read -a foo; do echo <(cmd ${foo[0]});
> done #...? :)

Yeah, because "lspci" was not hard enough to type.

Also, in Unix resources have a name when the kernel has a driver to be
able to know about those resources. But "lspci" can list also hardware
for which the kernel knows no driver (not a typical need in "pure UNIX"
running on a PDP-11 or PDP-8, I guess).

"lspci" is akin to "fdisk -l", for when you need to know what is laying
under the running kernel, at a level lower than the kernel abstractions
for the hardware which it knows about (i.e, hardware for which it has
a driver).

Which brings up a question I have: why didn't UNIX implement ethernet
network interfaces as file names in the filesystem? Was that "novelty" a
BDS development straying away from AT&T UNIX?

-- 
Josh Good

[TUHS] Were all of you.. Hippies?

[ron minnich]

On Fri, Mar 24, 2017 at 4:56 PM Josh Good <pepe at naleco.com> wrote:

>
>
> Which brings up a question I have: why didn't UNIX implement ethernet
> network interfaces as file names in the filesystem? Was that "novelty" a
> BDS development straying away from AT&T UNIX?
>
>

See https://tools.ietf.org/html/rfc681, section 4j:
 FILEDES = OPEN( "/DEV/NET/HARV",2 );

People were thinking about it. There was no shortage of people at the time
who were struggling to find a way to make the Unix model work for
networking (not me, I had no clue; I was just an interested observer). It
didn't quite work out and as a result we were left with the non-unix-like
socket interface we have today, and a feeling among many of us that we'd
missed an opportunity.

It's really hard to get this stuff right, and the approach outlined in the
RFC is not really what you want. Rob had a nice talk 20+ years ago about
the right and wrong way to do this; I can't find it and he can't find it,
and I keep hoping it'll appear.

It's a shame that Unix did not get a Unix-like model for networking, but
maybe it was just too soon.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170325/e5b16fdf/attachment.html>

[TUHS] Were all of you.. Hippies?

[Steve Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2190 bytes --]


I wasn't very keyed into the networking world at Bell Labs, but I do
know there was a lot of suspicion about Ethernet in the Unix group. 
The key problem from BTL's point of view, and this problem is still
with us today, is that you could not guarantee a minimum bandwidth of
connectivity.  At the speeds things were running at that time, this
would have made Ethernet impossible for voice, not to mention video.

Sandy Fraser's Datakit, which was a time division switch I think,
would give you a reliable end-to-end connection (although when you got
to the other end, it could still bog down in the other computer).  It
was an extremely reliable and easy-to-use system.   Exactly who did
what is murky to me, but I seem to recall that Peter Weinberger did
something much akin to NFS (I think it eventually morphed into RFS). 
I remember Bill Joy visiting the Unix group and seeing it and being
very excited.  Story is that he went back to Sun/(Stanford?) and
implemented NFS and got it to market at least two years before than. 
Also, I think Greg Chesson implemented something like ssh so you could
run processes on remote machines.

A lot of this work happened for (or was influenced by) the Blit
terminal, where you could download a 68000 program from the PDP-11 and
run it on the terminal with communications between the terminal and
the application on the PDP-11.  There were some very neat demos, and
a few real tools, but it was hard to program and debug.   If I have
a regret about Unix, I'm sorry that this particular line wasn't pushed
harder, since it's now the world we live in (in spades!) and I would
have liked to see what those minds came up with to make this easier...

Steve

On Fri, Mar 24, 2017 at 4:56 PM Josh Good <pepe at naleco.com [1]> wrote:

 Which brings up a question I have: why didn't UNIX implement ethernet
 network interfaces as file names in the filesystem? Was that
"novelty" a
 BDS development straying away from AT&T UNIX?

 

Links:
------
[1] mailto:pepe at naleco.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170324/60c008d2/attachment.html>

[TUHS] Were all of you.. Hippies?

[Jason Stevens]

Ethernet wasn't really usable until switching...  And getting off of the thicknet.

That said, AT&T had their starlan thing that I've had the misfortune of using.  At least the PC had NDIS2 drivers that Windows 95 could use.

And of course there was FDDI that was going to take over the LAN, and ATM over the high speed WAN, replacing all the old leased lines T1/E1/J1's.

The big thing is that Ethernet doesn't require royalties, and as I mentioned switching greatly reduced the issues with collisions making them point to point on a switch, along with full duplex operation.  As soon as Ethernet hit 10gig for a fraction of the cost of OC-128 it was over for ATM.

Now we just do mpls and qinq.  Can't say I'll miss v35 connectors.

On March 25, 2017 12:52:26 PM GMT+08:00, Steve Johnson <scj at yaccman.com> wrote:
>
>I wasn't very keyed into the networking world at Bell Labs, but I do
>know there was a lot of suspicion about Ethernet in the Unix group. 
>The
>key problem from BTL's point of view, and this problem is still with us
>today, is that you could not guarantee a minimum bandwidth of
>connectivity.  At the speeds things were running at that time, this
>would have made Ethernet impossible for voice, not to mention video.
>
>Sandy Fraser's Datakit, which was a time division switch I think, would
>give you a reliable end-to-end connection (although when you got to the
>other end, it could still bog down in the other computer).  It was an
>extremely reliable and easy-to-use system.   Exactly who did what is
>murky to me, but I seem to recall that Peter Weinberger did something
>much akin to NFS (I think it eventually morphed into RFS).  I remember
>Bill Joy visiting the Unix group and seeing it and being very excited.
>Story is that he went back to Sun/(Stanford?) and implemented NFS and
>got it to market at least two years before than.  Also, I think Greg
>Chesson implemented something like ssh so you could run processes on
>remote machines.
>
>A lot of this work happened for (or was influenced by) the Blit
>terminal, where you could download a 68000 program from the PDP-11 and
>run it on the terminal with communications between the terminal and the
>application on the PDP-11.  There were some very neat demos, and a few
>real tools, but it was hard to program and debug.   If I have a regret
>about Unix, I'm sorry that this particular line wasn't pushed harder,
>since it's now the world we live in (in spades!) and I would have liked
>to see what those minds came up with to make this easier...
>
>Steve
>
>
>
>
>On Fri, Mar 24, 2017 at 4:56 PM Josh Good < pepe at naleco.com
><mailto:pepe at naleco.com> > wrote:
>
>
>
>
>Which brings up a question I have: why didn't UNIX implement ethernet
>network interfaces as file names in the filesystem? Was that "novelty"
>a
>BDS development straying away from AT&T UNIX?

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170325/d5ed58ee/attachment-0001.html>

[TUHS] Were all of you.. Hippies?

[Clem Cole]

I'm traveling so can not offer a good answer at the moment.  But pre-BSD
networking was the the MIT-Chaosnet code which Ron is alluding.   Putting
devices names in the UNIX space was done.   Why Joy decided to abandon it
will never know without asking him.  Maybe it was because RIG and Accent
(Mach's predecessors) had not and Bill was definitely trying to add
features that those systems had.

Anyway, when I get back I can try to answer some questions about it.  I
think it was recently recovered.

Side note to Dan - I just quick looked at you post -- it seems excellent, I
want some time to digest.

Clem

On Fri, Mar 24, 2017 at 5:55 PM, ron minnich <rminnich at gmail.com> wrote:

>
>
> On Fri, Mar 24, 2017 at 4:56 PM Josh Good <pepe at naleco.com> wrote:
>
>>
>>
>> Which brings up a question I have: why didn't UNIX implement ethernet
>> network interfaces as file names in the filesystem? Was that "novelty" a
>> BDS development straying away from AT&T UNIX?
>>
>>
>
> See https://tools.ietf.org/html/rfc681, section 4j:
>  FILEDES = OPEN( "/DEV/NET/HARV",2 );
>
> People were thinking about it. There was no shortage of people at the time
> who were struggling to find a way to make the Unix model work for
> networking (not me, I had no clue; I was just an interested observer). It
> didn't quite work out and as a result we were left with the non-unix-like
> socket interface we have today, and a feeling among many of us that we'd
> missed an opportunity.
>
> It's really hard to get this stuff right, and the approach outlined in the
> RFC is not really what you want. Rob had a nice talk 20+ years ago about
> the right and wrong way to do this; I can't find it and he can't find it,
> and I keep hoping it'll appear.
>
> It's a shame that Unix did not get a Unix-like model for networking, but
> maybe it was just too soon.
>
> ron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170325/c7540fde/attachment.html>

[TUHS] Were all of you.. Hippies?

[Josh Good]

On 2017 Mar 25, 03:55, ron minnich wrote:
> On Fri, Mar 24, 2017 at 4:56 PM Josh Good <pepe at naleco.com> wrote:
> 
> > Which brings up a question I have: why didn't UNIX implement ethernet
> > network interfaces as file names in the filesystem? Was that "novelty"
> > a BDS development straying away from AT&T UNIX?
>
> See https://tools.ietf.org/html/rfc681, section 4j:
>  FILEDES = OPEN( "/DEV/NET/HARV",2 );
> 
> People were thinking about it. There was no shortage of people at
> the time who were struggling to find a way to make the Unix model
> work for networking (not me, I had no clue; I was just an interested
> observer). It didn't quite work out and as a result we were left with
> the non-unix-like socket interface we have today, and a feeling among
> many of us that we'd missed an opportunity.

> It's really hard to get this stuff right, and the approach outlined
> in the RFC is not really what you want. Rob had a nice talk 20+ years
> ago about the right and wrong way to do this; I can't find it and he
> can't find it, and I keep hoping it'll appear.

> It's a shame that Unix did not get a Unix-like model for networking,
> but maybe it was just too soon.

Thank you Ron for your very informative answer. I too would like to read
that Rob's paper if it ever resurfaces.

By the way, that RFC-681 you point to, has these two very interesting
paragraphs:

	RELIABILITY 

	AS  OF  THIS  WRITING, NETWORK UNIX HAS BEEN RUNNING ON A FULL
	TIME BASIS FOR ABOUT FOUR WEEKS.  DURING THAT PERIOD,  THERE WERE
	BETWEEN  THREE AND FOUR CRASHES A DAY.  THIS IS NOT A VALID
	INDICATOR BECAUSE MANY OF THE FAILURES WERE DUE TO HARDWARE
	COMPLICATIONS.  MORE RECENTLY THE HARDWARE HAS BEEN RE-CONFIGURED
	TO IMPROVE RELIABILITY AND THE CRASH RATE HAS BEEN REDUCED TO ONE
	A DAY  WITH A DOWN TIME OF 2-3 MINS.  THIS IS EXPECTED TO
	CONTINUE, BUT THE SAMPLING PERIOD HASNT BEEN LONG ENOUGH FOR ANY
	DEPENDABLE ANALYSIS.

	AVAILABILITY

	ALTHOUGH  THE UNIX NETWORK SOFTWARE WAS DEVELOPED WITHOUT ARPA
	SUPPORT, THE CENTER FOR ADVANCED COMPUTATION IS  WILLING  TO
	PROVIDE IT GRATIS TO THE PEOPLE OF THE ARPA COMMUNITY.

	HOWEVER BELL LABORATORIES MUST BE CONTACTED  FOR  A  LISCENSE  TO
	THE BASE SYSTEM ITSELF.  BELL'S POLICY IN THE PAST HAS BEEN TO
	LISCENSE THE SYSTEM TO UNIVERSITIES FOR  A  NOMINAL  FEE,
	$150.00,  AND  UNFORTUNATELY  FOR  A  COST OF $20,000.00 TO
	"NONUNIVERSITY" INSTITUTIONS.


Those are truly delicious historical tidbits about UNIX: how the
beginnings were on humble/unreliable hardware (like Linux was on PC
hardware in the early '90s), and how as early as 1975 the licensing from
big AT&T much differed from the customs in the nascent Arpa/Internet
community.

The "licenses war" was latent in UNIX from the very beginning.

And as a side note: that RFC-681 shows case sensitivity was not a
particular cause of concern back in the day. Why then was UNIX, born in
those days, so particularly case-sensitive?

-- 
Josh Good

[TUHS] Were all of you.. Hippies?

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

On Sat, Mar 25, 2017 at 12:26 PM, Josh Good <pepe at naleco.com> wrote:

> born in
> those days, so particularly case-sensitive?
>

​About to get on a lane, will try to reply next week but I've always said
case-insensitivity is a classic example of bug becoming a feature.​   Most
of my friends that worked on development of the DEC OS's agree.  It was
side effect that was turned into a (bad IMO) feature - but that is a matter
of taste.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170325/f8c159e6/attachment.html>

[TUHS] Were all of you.. Hippies?

[Tim Bradshaw]

On 24 Mar 2017, at 01:03, ron minnich <rminnich at gmail.com> wrote:
> 
> In Unix, resources have names. They are visible in a name space, organized into directories. The names can be enumerated by opening and reading a directory. Information about them can be determined with stat. Their contents can be read by open and read. They can be changed with open and write.

And if, for instance, I have a regular need to enumerate various properties of the avatars of the PCI devices in the filesystem, I might decide to write a program which does that, rather than patching together some arcane mass of cat | sed |awk each time (if even the contents of the avatars isn't some awful binary blob, which I think it should not be but whether that's a Unixism or not I am not sure).  I might call that command 'lspci'.

Or in other words, the existence of commanda like 'lspci', and the existence of PCI device avatars in the file system is not at all mutually exclusive, unless you think people should not write utilities beyond those handed down of old.

Indeed I've frequently written commands just like this which look through files in /proc for useful things.

(None of this is meant to imply that systems which have such commands have got this right -- I completely agree that they should present things in the filesystem -- just that they could have got it right and the command might still exist.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170324/ec5eaa94/attachment.html>

[TUHS] Were all of you.. Hippies?

[Random832]

On Fri, Mar 24, 2017, at 06:21, Tim Bradshaw wrote:
> And if, for instance, I have a regular need to enumerate various
> properties of the avatars of the PCI devices in the filesystem, I might
> decide to write a program which does that, rather than patching together
> some arcane mass of cat | sed |awk each time (if even the contents of the
> avatars isn't some awful binary blob, which I think it should not be but
> whether that's a Unixism or not I am not sure).

If you think parsing a binary blob can't be done in a shell script,
you're not trying hard enough. Relevant tools include dd [with the seek
and skip], od, head and tail [in byte count mode of course]. For
creating binary data, printf is sufficient.

If you think that parsing a binary blob *shouldn't* be done in a shell
script, and the suggestion is absolutely horrifying, you're of course
correct.

> (None of this is meant to imply that systems which have such commands
> have got this right -- I completely agree that they should present things
> in the filesystem -- just that they could have got it right and the
> command might still exist.)

List of files opened by lspci:
/sys/bus/pci/devices
/sys/bus/pci/devices/{each
subdirectory}/{resource,irq,vendor,device,class}
/sys/bus/pci/devices/{each subdirectory}/{config,label}
/sys/bus/pci/slots
/usr/share/misc/pci.ids{.gz,}
/etc/passwd and various other files that libc's "nsswitch" getpw* is to
blame for, to locate the home directory for the following
~/.pciids-cache
/etc/udev/udev.conf
{various directories}/hwdb.bin

Honestly I'm not sure how anyone can be aware of how extensive Linux's
/proc and /sys filesystems are and assume that tools like lspci etc are
doing anything but collating data found in them.

The content of all of those files [well, all the /proc ones that are
actually device avatars - i suspect hwdb.bin is not] is textual (often a
single hexadecimal constant), and it's therefore probably possible to
write it in sh and awk if you had to. But what's wrong with C?

[TUHS] Were all of you.. Hippies?

[Tim Bradshaw]

On 24 Mar 2017, at 13:55, Random832 <random832 at fastmail.com> wrote:
> 
> If you think that parsing a binary blob *shouldn't* be done in a shell
> script, and the suggestion is absolutely horrifying, you're of course
> correct.

Well, I don't think the information should be presented as binary unless that is absolutely necessary was what I meant to say.

> Honestly I'm not sure how anyone can be aware of how extensive Linux's
> /proc and /sys filesystems are and assume that tools like lspci etc are
> doing anything but collating data found in them.

My guess is that that's what it was doing, yes: having spent a bunch of time grovelling around /proc and /sys on Linux systems there is a lot there to be found.

Arguing that lspci (or lots of other commands) should not exist because the information should be presented in the filesystem is like saying that text editors should not exist because your text should live in the filesystem.

[TUHS] Were all of you.. Hippies?

[Dan Cross]

On Thu, Mar 23, 2017 at 8:27 PM, Larry McVoy <lm at mcvoy.com> wrote:

> [snip]
> I think Ron is just in Grumpy Old Man mode (he's a friend, we go way back,
> so I get to say that :)


Ya gotta be careful around Ron: you step on his lawn and he'll come after
you with a wooder hose while eating a cheesesteak from Gino's....

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170323/54bc7d4f/attachment.html>

[TUHS] Were all of you.. Hippies?

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]

On Thu, Mar 23, 2017 at 2:27 PM, Larry McVoy <lm at mcvoy.com> wrote:

> Linux is weird.  It's not elegant like the early unix systems, it's
> not as well put together if you look at it through unix glasses (and
> don't get me started on plan 9 glasses).  But it is *useful*.  They
> favored useful over elegant.  I don't think they disliked elegant,
> I suspect that many of us would say they didn't have the good taste
> to do elegant, whatever.  It's useful.  I'll take that.  And it's
> really not that bad.  Unless you are grumpy and want a perfect world.
>

​I'll accept that and may be add - it's practical and get the job done.
Not pretty, but damned good for what you get.
That said, I do agree with Ron, it lacks elegance and some of the the
"cool" (like monokernel *vs* ukernel which has always pained me a little)​.
  But useful and practical is hard to argue -- darned glad to have it
around.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170323/4f39f8f9/attachment.html>

[TUHS] Were all of you.. Hippies?

[shawn wilson]

On Thu, Mar 23, 2017, 20:28 Larry McVoy <lm at mcvoy.com> wrote:

>
>
> Personally, I sort of get the ls<something> model.  ls is how you list
> things, <something> is how you say what you want to list.  Is it Unix
> like?  Hmm, perhaps not.  Is it useful?  Like a lot of stuff that Linux
> did, hell yes it's useful.  I've written perl scripts to paw through
> /proc and /sys to do the same thing and each time I've found a ls<xxx>
> that does what I want I have gleefully tossed my script.
>
> Linux is weird.  It's not elegant like the early unix systems, it's
> not as well put together if you look at it through unix glasses (and
> don't get me started on plan 9 glasses).  But it is *useful*.  They
> favored useful over elegant.  I don't think they disliked elegant,
> I suspect that many of us would say they didn't have the good taste
> to do elegant, whatever.  It's useful.  I'll take that.  And it's
> really not that bad.  Unless you are grumpy and want a perfect world.
>

(From a mainly Linux background - I'm curious where the rust stains are)

Everything is still a file. I've got some arguments about the Linux kernel
build process (having to bootstrap your config system seems wrong to me -
or creating a totally new format for the config - kconfig) and don't really
appreciate their stance on security and don't really appreciate a thousand
files in etc vs using /usr/local/etc for most things.

I guess one could argue that sysfs is a bit much, and I've obviously seen
the arguments over systemd (and I admit that could've been handled better
both politically and technically) but all in all, I think that both are
decent systems.

But the system itself (and distros) seem to be pretty Unix like to me. Of
course, this is from someone who uses the hell out of the shell
autocomplete (many zsh compdef and the like) and opens new files in vim
using the servername of an existing vim instance and loves
scripts/libraries that go outside of UTF to display cool things (namely
progress bars and select bubbles) and abuses bash extglob and sits in a
split tmux (sometimes with a split vim), so... Maybe the old school Unix
mentality is lost on me.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170324/1d6b45e2/attachment.html>

[TUHS] Were all of you.. Hippies?

[Kurt H Maier]

On Fri, Mar 24, 2017 at 07:15:13AM +0000, shawn wilson wrote:
>
> Everything is still a file.

Except for your network, of course -- that might have a file interface
available... provided by your shell.  Because of course /dev/tcp should
be a shell feature.  Why would anyone put that in the kernel?

Linux (and the wider later-unixlike world) is full of these bizarre
little
quirks -- due to the earlier-mentioned practicality.  At first it was
people scratching their own itches, then it switched over to people
scratching corporate itches.

Does it work?  Sure.  But one of the things that makes a system
well-loved is consistent application of design principles.  That's why
those weirdos mourned their LispMs (and why their emacs descendants tend
to live inside their text editor).  It's why the plan 9 people won't
shut up about plan 9.  And there are lots of examples of people singing
the praise of "everything's a file" -- and even that "open, read, write,
close" specifically was enough to get things done.

Linux has around 400 system calls, and still supports just about ever
(userspace-exposed) syscall it has ever had.  This is why it needs a
thousand little binary shims to get stuff done, and the push for systemd
was the pendulum swinging back the other direction.  Since
open/read/write/close isn't enough, we'll build a layer to handle all
the weirdness, and now all you need is dbus...

But it sure boots fast!

khm

[TUHS] Were all of you.. Hippies?

[shawn wilson]

On Fri, Mar 24, 2017 at 3:37 AM, Kurt H Maier <khm at sciops.net> wrote:
> On Fri, Mar 24, 2017 at 07:15:13AM +0000, shawn wilson wrote:
>>
>> Everything is still a file.
>
> Except for your network, of course -- that might have a file interface
> available... provided by your shell.  Because of course /dev/tcp should
> be a shell feature.  Why would anyone put that in the kernel?
>

I actually have strong opinions about this (read: disagreements). Your
shell shouldn't know about connect() - I guess allowing writing to
/dev/eth0 would work for me. But in bash, IIRC that damn ghost file
thing is like half of the files in source and it helps nothing. Maybe
if the point was to allow some remote shell (like X does) I could see
it (but than I'd scream about the security implications about
something like that). And I'll say again - why? You want a socket -
nc, ncat, socat - pick one - don't abuse your shell.

> Linux (and the wider later-unixlike world) is full of these bizarre
> little
> quirks -- due to the earlier-mentioned practicality.  At first it was
> people scratching their own itches, then it switched over to people
> scratching corporate itches.
>

I've got mixed feelings about this - while I like being able to
install a Fedora or Debian on a box and it generally just work (except
for things like raid controllers, IPMI, and the like) and remember the
days of Slackware where it took a week just to get to a point where
you were ~happy with an install. I do kinda see how this went a bit
sideways and wish someone had put some thought into where things went
(memory/calls and files).

> Linux has around 400 system calls, and still supports just about ever
> (userspace-exposed) syscall it has ever had.  This is why it needs a
> thousand little binary shims to get stuff done, and the push for systemd
> was the pendulum swinging back the other direction.  Since
> open/read/write/close isn't enough, we'll build a layer to handle all
> the weirdness, and now all you need is dbus...
>

No one wants to see their pet project die :)
No one cares when it's userspace, but it adds up in kernel space.

[TUHS] Were all of you.. Hippies?

[Dan Cross]

On Fri, Mar 24, 2017 at 4:06 AM, shawn wilson <ag4ve.us at gmail.com> wrote:

> I actually have strong opinions about this (read: disagreements). Your
> shell shouldn't know about connect() - I guess allowing writing to
> /dev/eth0 would work for me. But in bash, IIRC that damn ghost file
> thing is like half of the files in source and it helps nothing. Maybe
> if the point was to allow some remote shell (like X does) I could see
> it (but than I'd scream about the security implications about
> something like that). And I'll say again - why? You want a socket -
> nc, ncat, socat - pick one - don't abuse your shell.
>

You're right; your shell should not know about connect(). But the argument
isn't that it should; the argument is that connect() itself is superfluous.

Perhaps a way to focus the discussion would be to explain how networking
works in the Plan 9 world (which is where at least Ron is coming
from...unless he corrects me).

In Unix everything is a file, but the limitations of that model become
apparent pretty quickly:
-For things that require some sort of control plane, one ends up with
ioctl() or something like it.
-Traditionally Unix required that these files exist in the directory
structure resident on the disk filesystem, hence major/minor device numbers
and file types.
-Sockets didn't fit exactly into that model so they got a whole slew of
special-purpose system calls.
-That seemed to open the flood gates to a number of other, similar
special-purpose interfaces (POSIX termios? To be fair, these [and sockets!]
were predated by s/gtty etc).

All of these are non-orthogonal: they cannot be easily combined or reused.
Little binary data structures shared between the kernel and the rest of the
world, accessed by special system calls and interpreted by arcane
user-space programs, are the order of the day; one had better hope that the
structure definitions are synchronized between building the kernel and the
tools or hilarity ensues. Since it's all binary, one has to deal with byte
ordering issues and type widths and so forth if one wants to share these
things over a network. The interface between the kernel and userspace is
very wide.

However, this has been "normal" since at least the 1980s so no one really
thinks twice about it.

By contrast in Plan 9, everything is sort of a small *filesystem* and there
exist (unprivileged) primitives for mapping these filesystems into a
process's view of the file namespace and manipulating them into various
configurations. Often, these files are synthesized on demand by a device
driver or user-space process; there is no disk-resident copy of the names.
For networking, there is no /dev/eth0 file, but there are /net/ether0 and
/net/tcp *directories*.

If I want, say, to make a TCP connection I open a file (/net/tcp/clone) and
read from it. These operations cause a new directory representing that
connection to spring into existence; that directory contains two files:
/net/tcp/$n$/ctl and /net/tcp/$n$/data (actually, the file descriptor
returned by opening /net/tcp/clone corresponds to /net/tcp/$n$/ctl, but
that's a detail). I write a string describing the port and address I wish
to connect to into the ctl file and attempt to open the data file; when
that returns successfully, I have an established connection and I
read/write the corresponding file descriptor to exchange data with the
remote system. I can further control the connection via writes of special
messages into the ctl file. Of course, the details of connection
establishment are abstracted away into a convenient library interface so I
don't really think about it for work-a-day programming, but I can also do
this little dance with e.g. cat and echo, so I can do the same from the
shell if I like. Why bother with nc, netcat, socat, etc when just plain cat
will do?

Since all of the details of actually manipulating network connections and
so forth are hidden behind this nice filesystem-based interface, neither
the shell nor the tools have to know or care that they're dealing with a
network. The control plane is handled via this `ctl` thing, which is far
superior to ioctl() in that the messages accepted by the ctl file are text,
not little binary integers and pointers. Since everything is text based, I
can share these filesystems over a network and manipulate them from remote
machines (e.g., I can import the TCP/IP stack from another machine and use
it to make connections: all with no programming whatsoever). The kernel
interface is elegant, simple, relatively narrow and highly orthogonal.

Of course, it has its downsides: sometimes it certainly DOES feel like the
"if all you have is a hammer..." thing and one finds tiny parsers for the
DSLs implemented by various ctl files and things all over the place and for
connectionless protocols like UDP one has to (wait for it...) prepend or
parse a binary header at the beginning of the data when writing/reading a
packet. For UDP this is simple enough, but clearly it shows a general
weakness in the model. It's also hard to do scatter/gather I/O. Because
things are based on open/read|write/close, lots of things are stateful that
don't have to be on e.g. Unix. Plan 9 relies heavily on convention (e.g.,
all the tools expect the network to be mounted at /net, but there's no one
with a golden hammer standing over you forcing you to put it there. You
could mount it on /foobar if you wanted...but then nothing would work); the
implementation is buggy and many would argue quirky; it's slow; most
importantly, it's incompatible with the rest of the world and requires you
to dump your old toolset and adopt the Plan 9 Way to be productive. Like
Lisp, it's great for stretching your mind but perhaps not so much for
solving real-life problems. However, I often feel that when one tries to
explain it to folks who haven't seen it, the explanations fall flat because
folks look at them with too many of their preconceptions based on how Unix
and Linux work. It's a very different model and a lot of folks with
experience on the research systems would argue that it is philosophically
more Unix-like than Unix (including Linux) these days.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170324/2876d9fd/attachment-0001.html>

[TUHS] Were all of you.. Hippies?

[Dan Cross]

On Fri, Mar 24, 2017 at 4:08 PM, Andy Kosela <andy.kosela at gmail.com> wrote:
>
> [snip]
> Dan, that was an excellent post.
>

Thanks! I thought it was rather too long/wordy, but I lacked the time to
make it shorter.

I always admired the elegance and simplicity of Plan 9 model which indeed
> seem to be more UNIX like than todays BSDs and Linux world.
>
> The question though remains -- why it has not been more successfull?  The
> adoption of Plan 9 in the real world is practically zero nowadays and even
> its creators like Rob Pike moved on to concentrate on other things, like
> the golang.
>

I think two big reasons and one little one.

1. It wasn't backwards compatible with the rest of the world and forced you
to jump headlong into embracing a new toolset. That is, there was no
particularly elegant way to move gradually to Plan 9: you had to adopt it
all from day one or not at all. That was a bridge too far for most. (Yeah,
there were some shims, but it was all rather hacky.)

2. Relatedly, it wasn't enough of an improvement over its predecessor to
pull people into its orbit. Are acme or sam really all that much better
than vi or emacs? Wait, don't answer that...but the reality is that people
didn't care enough whether they were or not. The "everything is a
file(system)" idea is pretty cool, but we've already had tools that worked
then and work now. Ultimately, few people care how elegant the abstractions
are or how well the kernel is implemented.

And the minor issue: The implementation. Plan 9 was amazing for when it was
written, but now? Not so much.

I work on two related kernels: one that is directly descended from Plan 9
(Harvey, for those interested) and one that's borrowed a lot of the code
(Akaros) and in both we've found major, sometimes decades old bugs. There
are no tests, and there are subtle race conditions or rarely tickled bugs
lurking in odd places. Since the system is used so little, these don't
really get shaken out the way they do in Linux (or to a lesser extent the
BSDs or commercial Unixes). In short, some code is better than other code
and while I'd argue that the median quality of the implementation is
probably higher than that of Linux or *BSD in terms of elegance and
understandability, it's not much higher and it's certainly buggier.

And the big implementation issue is lack of hardware support. I stood up
two plan 9 networks at work for Akaros development and we ran into major
driver issues with the ethernets that took a week or two to sort out. On
the other hand, Linux just worked.

Eventually, one of those networks got replaced with Linux and the other is
probably headed that way. In fairness, this has to do with the fact that no
one besides Ron and I was interested in using them or learning how they
work: people *want* Linux and the idea that there's this neat system out
there for them to explore and learn about the cool concepts it introduced
just isn't a draw. I gave a presentation on Plan 9 concepts to the Akaros
team a year and a half or so ago and a well-known figure in the Linux
community who working with us at the time had only to say that, "the user
interface looks like it's from 1991." None of the rest didn't interest him
at all: the CPU command usually kind of blows people's minds, but after I
went through the innards of it the response was, "why not just use SSH?"
I've had engineers ask me why Plan 9 used venti and didn't "just use git"
(git hadn't been invented yet). It's somewhat lamentable, but it's also
reality.

        - Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170324/6f91a968/attachment-0001.html>

[TUHS] Were all of you.. Hippies?

[Chet Ramey]

On 3/24/17 1:06 AM, shawn wilson wrote:

> I actually have strong opinions about this (read: disagreements). Your
> shell shouldn't know about connect() - I guess allowing writing to
> /dev/eth0 would work for me. 

Yeah, but nobody wants to do that.

> But in bash, IIRC that damn ghost file
> thing is like half of the files in source and it helps nothing. 

What does this mean?

> Maybe
> if the point was to allow some remote shell (like X does) I could see
> it (but than I'd scream about the security implications about
> something like that). And I'll say again - why? You want a socket -
> nc, ncat, socat - pick one - don't abuse your shell.

You always have the option of not compiling it into the shell.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/

[TUHS] Were all of you.. Hippies?

[Chet Ramey]

On 3/24/17 12:37 AM, Kurt H Maier wrote:
> On Fri, Mar 24, 2017 at 07:15:13AM +0000, shawn wilson wrote:
>>
>> Everything is still a file.
> 
> Except for your network, of course -- that might have a file interface
> available... provided by your shell.  Because of course /dev/tcp should
> be a shell feature.  Why would anyone put that in the kernel?

Who knows? At the time I put that into bash (around 20 years ago, and Korn
before me), nobody had it in the kernel, and there weren't any signs of
anyone doing so.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet at case.edu    http://cnswww.cns.cwru.edu/~chet/

[TUHS] Were all of you.. Hippies?

[Kurt H Maier]

On Fri, Mar 24, 2017 at 08:30:42AM -0700, Chet Ramey wrote:
> On 3/24/17 12:37 AM, Kurt H Maier wrote:
> > On Fri, Mar 24, 2017 at 07:15:13AM +0000, shawn wilson wrote:
> >>
> >> Everything is still a file.
> >
> > Except for your network, of course -- that might have a file interface
> > available... provided by your shell.  Because of course /dev/tcp should
> > be a shell feature.  Why would anyone put that in the kernel?
>
> Who knows? At the time I put that into bash (around 20 years ago, and Korn
> before me), nobody had it in the kernel, and there weren't any signs of
> anyone doing so.
       
That's my point.  It landed in the shell because it was a desired 
feature which was inexplicably never implemented where it "belongs."
Practicality landed it, not systems design.
       
khm

[TUHS] Were all of you.. Hippies?

[Dave Horsfall]

On Mon, 20 Mar 2017, Ron Natalie wrote:

> Just a bunch of Unix-smoking dope gurus.

Hey, I resemble that!  To be honest, I only tried the stuff once (at my 
boss's behest -- another hippie geek) and didn't like it.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Were all of you.. Hippies?

[Dan Cross]

On Mar 20, 2017 7:08 PM, "Dave Horsfall" <dave at horsfall.org> wrote:

On Mon, 20 Mar 2017, Ron Natalie wrote:

> Just a bunch of Unix-smoking dope gurus.

Hey, I resemble that!  To be honest, I only tried the stuff once (at my
boss's behest -- another hippie geek) and didn't like it


But did you inhale?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170320/0731d654/attachment.html>

[TUHS] Were all of you.. Hippies?

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 323 bytes --]

On Mon, 20 Mar 2017, Dan Cross wrote:

> > Hey, I resemble that!  To be honest, I only tried the stuff once (at 
> > my boss's behest -- another hippie geek) and didn't like it
> 
> But did you inhale?

Only once, and that was enough...

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Were all of you.. Hippies?

[Tim Bradshaw]

On 20 Mar 2017, at 22:32, Ron Natalie <ron at ronnatalie.com> wrote:
> 
> Just a bunch of Unix-smoking dope gurus.

I don't know about other people, but I think the whole dope thing is why computer people tend *not* to be hippies in the 'dope smoking' sense.  I need to be *really awake* to write reasonably good code (if ever I do write reasonably good code) in the same way I need to be really awake to do maths or physics.  So I live on a diet of coffee and sugar and walk around twitching as a result (this is an exaggeration, but you get the idea).  I have the strength of will to not use stronger stimulants (coffee is mostly self-limiting, speed not so much).

So I think that computer people have more in common with some kind of 50s coffee-shop jazz-listening hipster or 70/80s punk & post-punk (UK sense of both) people.  We're basically twitchy and unpleasant not mellow new-age easy-going people and our drugs of choice are stimulants not depressants.

Or perhaps I just want to be jack Kerouac (who, OK, was an alcoholic I think, but never mind I can imagine).

--tim

[TUHS] Were all of you.. Hippies?

[Dave Horsfall]

For some reason I'm thinking of that immortal phrase about LSD and BSD 
both coming out of Berkeley, and not being a coincidence..

I was brought up on V6/V7/SunOS/BSD, but was then forced to support 
SysVile to earn my crust (after an even worse period with WICAT's SysIII).

(Please don't ask me about WICAT, and the lies I had to tell when I was 
doing pre-sales demos on behalf of Lionel Singer...)

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."