[TUHS] UNIX of choice these days?

[TUHS] UNIX of choice these days?

[Norman Wilson]

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?

Kurt H Maier:

  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).

====

Funny that that rationale isn't extended to its logical
conclusion: get rid of open and creat.  Then nobody needs
to worry about running out of file descriptors ever!

I too am saddened to see such a retrograde step, but perhaps
I'm biased.  When I arrived in 1127, the kernel had /proc but
still had ptrace as well.  Why?  Because no one was brave enough
to wade into sdb and adb.

After a couple of years, I felt brave enough, so I did it.
Once the revised sdb and adb had propagated to all our systems,
I removed the syscall.  I celebrated by physically removing
ptrace(2) from the Eighth Edition manual in the UNIX room: the
manual entry comprised two facing pages, which I glued together.

I can sympathize with FreeBSD excuse someone cited elsewhere,
that nobody used the code so it should go--I'm always in favour
of improving programs by chopping sutff out--but I think the
decision here was backwards.  The proper answer would have been
to teach ps et al to use /proc, not to invent a new complex of
system calls.

I dislike how Linux has tossed information about processes and
other system-related data into the same namespace (and now that
there is /sys as well as /proc, I wonder whether it's time to
divorce them, or even to move /proc into /sys/proc), but the
general direction of moving things into the file system makes
sense.  I have some qualms about adding more and more code to
the kernel that just does string processing (making the kernel
bigger and more complicated, and widening the attack surface
for bad guys), though; maybe most of that stuff belongs not in
the OS proper but in a user-mode program that reads /dev/mem
and presents as a file system.

Norman Wilson
Toronto ON

[TUHS] UNIX of choice these days?

[Clem Cole]

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

On Mon, Sep 25, 2017 at 8:07 AM, Norman Wilson <norman at oclsc.org> wrote:

> ​...​
>
> I too am saddened to see such a retrograde step, but perhaps
> I'm biased.  When I arrived in 1127, the kernel had /proc but
> still had ptrace as well.  Why?  Because no one was brave enough
> to wade into sdb and adb.
>
> ​...
>
>
> I can sympathize with FreeBSD excuse someone cited elsewhere,
> that nobody used the code so it should go--I'm always in favour
> of improving programs by chopping sutff out--but I think the
> decision here was backwards.  The proper answer would have been
> to teach ps et al to use /proc, not to invent a new complex of
> system calls.
>
​+1 that was my point.   If the application code had been available @ UCB
earlier before the proliferation,
I think and /proc has been part of 4.2 or at least 4.3 not 4.4, I think
there would have been a better chance
of it being used.

I also agree about garbage collection, but this is a case where the right
solution would have been to try to get people to use the new interface.​
The problem was ptrace was 'good enough' and there was no incentive so no
one did it.

Mark Litton's thesis was DBX which was being written when 4.2 was being
developed.   If Mark had had /proc the simplicity would have been
compelling.   But once the code was written, it was hard to justify
switching.

It's my same observation about why Fortran still is #1 in the high end of
the business.   It's just not interesting to replace it.

So what I'm asking us to try to do, is not just look at the technology in a
vacuum.   Why was it not interesting to /proc for BSD.   Clearly, Linux
added it (differently than Eighth Edition of course and the 4.4
implementation was much more like V8 that Linux would settle).   People did
do the work to use it.

So why did *BSD not bring those versions of the utilities back?

My >>guess<< while they had added some things (like /proc) it was different
again and we got into the BSD != Linux stuff - which has been the UNIX war
all over again.

Sigh....




>
> I dislike how Linux has tossed information about processes and
> other system-related data into the same namespace (and now that
> there is /sys as well as /proc, I wonder whether it's time to
> divorce them, or even to move /proc into /sys/proc), but the
> general direction of moving things into the file system makes
> sense.

I agree, but let's just create a /sys/proc namespace and try to be
consistent.  Here is a case where I wish *BSD would just pick up the Linux
solution and be done with it.  It's not worth arguing.,​




> I have some qualms about adding more and more code to
> the kernel that just does string processing (making the kernel
> bigger and more complicated, and widening the attack surface
> for bad guys),

​+1​



> though; maybe most of that stuff belongs not in
> the OS proper but in a user-mode program that reads /dev/mem
> and presents as a file system.

​Agree although, I would love to see consistency and moving towards one
namespace & associated API that we all used.​

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

[TUHS] UNIX of choice these days?

[Warner Losh]

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

On Mon, Sep 25, 2017 at 8:16 AM, Clem Cole <clemc at ccc.com> wrote:

>
>
> On Mon, Sep 25, 2017 at 8:07 AM, Norman Wilson <norman at oclsc.org> wrote:
>
>> ​...​
>>
>> I too am saddened to see such a retrograde step, but perhaps
>> I'm biased.  When I arrived in 1127, the kernel had /proc but
>> still had ptrace as well.  Why?  Because no one was brave enough
>> to wade into sdb and adb.
>>
>> ​...
>>
>>
>> I can sympathize with FreeBSD excuse someone cited elsewhere,
>> that nobody used the code so it should go--I'm always in favour
>> of improving programs by chopping sutff out--but I think the
>> decision here was backwards.  The proper answer would have been
>> to teach ps et al to use /proc, not to invent a new complex of
>> system calls.
>>
> ​+1 that was my point.   If the application code had been available @ UCB
> earlier before the proliferation,
> I think and /proc has been part of 4.2 or at least 4.3 not 4.4, I think
> there would have been a better chance
> of it being used.
>
> I also agree about garbage collection, but this is a case where the right
> solution would have been to try to get people to use the new interface.​
> The problem was ptrace was 'good enough' and there was no incentive so no
> one did it.
>

In the case of procfs and FreeBSD, the issues were more complicated and
nuanced. The original /proc code came from 4.4BSD, and interacted with a
number of kernel subsystems. These subsystems were undergoing evolution at
the time (including a rather concerted rewrite of the VM to unify the
buffer cache). This churn there lead to inevitable changes being needed to
procfs to keep up with the new interfaces and such. Over time, there grew
the feeling that there some something quite wrong with procfs (rightly or
wrongly). There was a belief there were a number of unanticipated security
issues that were lingering in the code, but due to the changes not only in
API to the other sub-systems, but also in semantics. Kernel hackers that
studied the problem came away with an uneasy feeling, but nothing
actionable. This was the back-drop that slowed its adoption into new
utilities in the FreeBSD tree and kept people from wanting to push it
further until these misgivings could be explored and addressed. In the end,
it was easier to have a better understood code base (ptrace) that had an
icky interface over one that was cleaner, but that had clouds over it. As
fewer and fewer things used /proc, it became easier and easier to ignore,
and at some point people started worrying that this code that was basically
unused could be an attack vector on the systems, so it was retired.

It's been a number of years since all this went down, so my memory of it
may be clouded. Plus, I was FreeBSD's security officer for a time, and I'm
purposely not going back to my notes from the time since I promised to keep
all that business confidential (and I'm not exactly sure where they are).
So, there may be the odd detail wrong, or imprecision of language, but the
main thrust is there: new with issues that are hard to quantify, but have
potential for embarrassment should the misgivings bear fruit militates for
staying with the old. It also didn't help there were no strong supporters
willing to stand behind the code, which didn't help with the misgivings.
Had it not exited the tree then, the push to MP would have counted it as a
casualty absent a strong maintainer to make it MP safe.


> Mark Litton's thesis was DBX which was being written when 4.2 was being
> developed.   If Mark had had /proc the simplicity would have been
> compelling.   But once the code was written, it was hard to justify
> switching.
>
> It's my same observation about why Fortran still is #1 in the high end of
> the business.   It's just not interesting to replace it.
>
> So what I'm asking us to try to do, is not just look at the technology in
> a vacuum.   Why was it not interesting to /proc for BSD.   Clearly, Linux
> added it (differently than Eighth Edition of course and the 4.4
> implementation was much more like V8 that Linux would settle).   People did
> do the work to use it.
>
> So why did *BSD not bring those versions of the utilities back?
>
> My >>guess<< while they had added some things (like /proc) it was
> different again and we got into the BSD != Linux stuff - which has been the
> UNIX war all over again.
>

There might have been a bit of that too, but it was background noise. The
misgivings about the code, and the lack of a strong maintainer to cope with
the misgivings drive the decision. No one was there to bar the door when
the grim reaper came.

Sigh....
>
>
>
>
>>
>> I dislike how Linux has tossed information about processes and
>> other system-related data into the same namespace (and now that
>> there is /sys as well as /proc, I wonder whether it's time to
>> divorce them, or even to move /proc into /sys/proc), but the
>> general direction of moving things into the file system makes
>> sense.
>
> I agree, but let's just create a /sys/proc namespace and try to be
> consistent.  Here is a case where I wish *BSD would just pick up the Linux
> solution and be done with it.  It's not worth arguing.,​
>
>

The Linux solution has two barriers to entry though: GPL means the code
can't be shared and even if it could the radically different structures of
the kernel means little could be shared. So it would be, at best a
compatible implementation. There's bits of /proc for linux in the FreeBSD
Linux execution environment, but not the full thing.


> I have some qualms about adding more and more code to
>> the kernel that just does string processing (making the kernel
>> bigger and more complicated, and widening the attack surface
>> for bad guys),
>
> ​+1​
>
>
>
>> though; maybe most of that stuff belongs not in
>> the OS proper but in a user-mode program that reads /dev/mem
>> and presents as a file system.
>
> ​Agree although, I would love to see consistency and moving towards one
> namespace & associated API that we all used.​
>
>

I'm not so sure about that. I hate /dev/kmem solutions to problems, or any
solution that has to have many round-trips between the kernel and userland,
especially on MP systems where locking and consistency issues clash with
the desire for maximum performance...

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

[TUHS] UNIX of choice these days?

[Larry McVoy]

On Mon, Sep 25, 2017 at 10:16:11AM -0400, Clem Cole wrote:
> So what I'm asking us to try to do, is not just look at the technology in a
> vacuum.   Why was it not interesting to /proc for BSD.   Clearly, Linux
> added it (differently than Eighth Edition of course and the 4.4
> implementation was much more like V8 that Linux would settle).   People did
> do the work to use it.

Linux's /proc was hugely different than the AT&T /proc, in a good way in
my opinion.  It's sort of Tcl like :-), everything is a string.  So you
can look at the files with cat.  I think plan 9 went this way as well.

And the Linux /proc did and does so much more than AT&T /proc.  You 
can tune the system, debug the system, here's an example.  You know
something is holding something open, you want to know what.  

	$ ps 
	  PID TTY          TIME CMD
	 2668 pts/8    00:00:00 bash
	14153 pts/8    00:00:00 ps
	$ cd /proc/2668/fd
	$ ls -l
	total 0
	lrwx------ 1 lm lm 64 Sep 23 21:16 0 -> /dev/pts/8
	lrwx------ 1 lm lm 64 Sep 23 21:16 1 -> /dev/pts/8
	lrwx------ 1 lm lm 64 Sep 23 21:16 2 -> /dev/pts/8
	lrwx------ 1 lm lm 64 Sep 23 21:39 255 -> /dev/pts/8

Now isn't that pleasant?  (Yes, I know about lsof).

One could make an argument that for debugging you need a lighter weight
way to get the info, and maybe ptrace is lighter, I dunno.  But for most
stuff the Linux /proc (it's really /system because it's about way way
more than processes) is super pleasant.

> So why did *BSD not bring those versions of the utilities back?
> 
> My >>guess<< while they had added some things (like /proc) it was different
> again and we got into the BSD != Linux stuff - which has been the UNIX war
> all over again.

Yeah, I don't see the two being compat.  They could overlap but when you get
into specific tuning variables they won't match.

I suspect that no /proc in BSD is simple, there wasn't anyone who wanted to
put in the time to evolve it and maintain it.

[TUHS] UNIX of choice these days?

[Warner Losh]

On Mon, Sep 25, 2017 at 9:18 AM, Larry McVoy <lm at mcvoy.com> wrote:

> On Mon, Sep 25, 2017 at 10:16:11AM -0400, Clem Cole wrote:
> > So what I'm asking us to try to do, is not just look at the technology
> in a
> > vacuum.   Why was it not interesting to /proc for BSD.   Clearly, Linux
> > added it (differently than Eighth Edition of course and the 4.4
> > implementation was much more like V8 that Linux would settle).   People
> did
> > do the work to use it.
>
> Linux's /proc was hugely different than the AT&T /proc, in a good way in
> my opinion.  It's sort of Tcl like :-), everything is a string.  So you
> can look at the files with cat.  I think plan 9 went this way as well.
>

I both love and hate this setup...


> And the Linux /proc did and does so much more than AT&T /proc.


Which is the other issue with the inherited 4.4 /proc

[...]

> > So why did *BSD not bring those versions of the utilities back?
> >
> > My >>guess<< while they had added some things (like /proc) it was
> different
> > again and we got into the BSD != Linux stuff - which has been the UNIX
> war
> > all over again.
>
> Yeah, I don't see the two being compat.  They could overlap but when you
> get
> into specific tuning variables they won't match.
>

There was very little overlap. And much of what was exported in linux as
/proc/blah was available as a syctl which mean the pressure to expand /proc
was lessened. There's pros and cons to sysctl (which is basically a second
name space for data from/about the kernel), but it was the path taken.
Filesystems can go too far (cf the fiasco of the efivar filesystem where
you could brick your box with an rm -rf, oops), and they can also be taken
not far enough. There's good reasons to avoid filesystems that are
intrusive into every part of the system (sysctl has a more restricted
context to execute in which can be more helpful than trying to cope with
vnodes and such in every driver). There's also bad reasons to avoid
filesystems as well (say because your VFS abstraction layer is complicated
and difficult to use)...

I suspect that no /proc in BSD is simple, there wasn't anyone who wanted to
> put in the time to evolve it and maintain it.
>

That's it in a one line summary. I posted a few more details as well, but
that's basically it. When the time came, nobody cared enough to even
object... Certainly nobody cared enough to understand the complex
interactions with other subsystems as they evolved to keep it up to snuff,
let alone innovate with new things to keep it interesting.

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

[TUHS] UNIX of choice these days?

[Warner Losh]

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

On Mon, Sep 25, 2017 at 9:13 AM, Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Mon, Sep 25, 2017 at 8:16 AM, Clem Cole <clemc at ccc.com> wrote:
>
>>
>>
>> On Mon, Sep 25, 2017 at 8:07 AM, Norman Wilson <norman at oclsc.org> wrote:
>>
>>> ​...​
>>>
>>> I too am saddened to see such a retrograde step, but perhaps
>>> I'm biased.  When I arrived in 1127, the kernel had /proc but
>>> still had ptrace as well.  Why?  Because no one was brave enough
>>> to wade into sdb and adb.
>>>
>>> ​...
>>>
>>>
>>> I can sympathize with FreeBSD excuse someone cited elsewhere,
>>> that nobody used the code so it should go--I'm always in favour
>>> of improving programs by chopping sutff out--but I think the
>>> decision here was backwards.  The proper answer would have been
>>> to teach ps et al to use /proc, not to invent a new complex of
>>> system calls.
>>>
>> ​+1 that was my point.   If the application code had been available @
>> UCB earlier before the proliferation,
>> I think and /proc has been part of 4.2 or at least 4.3 not 4.4, I think
>> there would have been a better chance
>> of it being used.
>>
>> I also agree about garbage collection, but this is a case where the right
>> solution would have been to try to get people to use the new interface.​
>> The problem was ptrace was 'good enough' and there was no incentive so no
>> one did it.
>>
>
> In the case of procfs and FreeBSD, the issues were more complicated and
> nuanced. The original /proc code came from 4.4BSD, and interacted with a
> number of kernel subsystems. These subsystems were undergoing evolution at
> the time (including a rather concerted rewrite of the VM to unify the
> buffer cache). This churn there lead to inevitable changes being needed to
> procfs to keep up with the new interfaces and such. Over time, there grew
> the feeling that there some something quite wrong with procfs (rightly or
> wrongly). There was a belief there were a number of unanticipated security
> issues that were lingering in the code, but due to the changes not only in
> API to the other sub-systems, but also in semantics. Kernel hackers that
> studied the problem came away with an uneasy feeling, but nothing
> actionable. This was the back-drop that slowed its adoption into new
> utilities in the FreeBSD tree and kept people from wanting to push it
> further until these misgivings could be explored and addressed. In the end,
> it was easier to have a better understood code base (ptrace) that had an
> icky interface over one that was cleaner, but that had clouds over it. As
> fewer and fewer things used /proc, it became easier and easier to ignore,
> and at some point people started worrying that this code that was basically
> unused could be an attack vector on the systems, so it was retired.
>




> It's been a number of years since all this went down, so my memory of it
> may be clouded. Plus, I was FreeBSD's security officer for a time, and I'm
> purposely not going back to my notes from the time since I promised to keep
> all that business confidential (and I'm not exactly sure where they are).
> So, there may be the odd detail wrong, or imprecision of language, but the
> main thrust is there: new with issues that are hard to quantify, but have
> potential for embarrassment should the misgivings bear fruit militates for
> staying with the old. It also didn't help there were no strong supporters
> willing to stand behind the code, which didn't help with the misgivings.
> Had it not exited the tree then, the push to MP would have counted it as a
> casualty absent a strong maintainer to make it MP safe.
>

OK. I've done some software archeology and the above isn't quite right.
Sorry for the misinformation.

FreeBSD still has /proc. It's still actively maintained.

We removed /proc from the default kernel and installation years ago due to
security concerns (and not just misgivings, there were several SAs in that
area). I was remembering the 'opt-in' discussions... Should have consulted
the notes...

The ctl interface in the referenced commit message is part of the debugging
interface. It wasn't as feature rich as gdb, and nothing used it so it was
removed. There's other parts of the debugging interface that still persist,
but those are in the process of being de-orbited. There are several
debuggers that use the ptrace interface, and making them all use /proc was
seen as rowing against the tide and not completely useful since /proc
wasn't enabled by default due to security concerns.

The rest of /proc is still around, but you have to really want it.

Kinda highlights, though, problems with the kitchen-sink approach. There's
bits of /proc that are quite useful, but since it was so expansive, it
represented a big security threat and so is off by default.

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

[TUHS] UNIX of choice these days?

[Dave Horsfall]

On Mon, 25 Sep 2017, Larry McVoy wrote:

> 	lrwx------ 1 lm lm 64 Sep 23 21:39 255 -> /dev/pts/8

What the heck is file descriptor 255?

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

[TUHS] UNIX of choice these days?

[ron minnich]

On Mon, Sep 25, 2017 at 9:52 AM Warner Losh <imp at bsdimp.com> wrote:

>
>
> Kinda highlights, though, problems with the kitchen-sink approach. There's
> bits of /proc that are quite useful, but since it was so expansive, it
> represented a big security threat and so is off by default.
>
>
were you to limit proc to being just for processes are there issues still?


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

[TUHS] UNIX of choice these days?

[Chet Ramey]

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

On 9/25/17 7:49 PM, Dave Horsfall wrote:
> On Mon, 25 Sep 2017, Larry McVoy wrote:
> 
>>     lrwx------ 1 lm lm 64 Sep 23 21:39 255 -> /dev/pts/8
> 
> What the heck is file descriptor 255?

It appears to be a file descriptor open to his controlling terminal.

-- 
``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?

[Larry McVoy]

On Mon, Sep 25, 2017 at 10:06:55PM -0400, Chet Ramey wrote:
> On 9/25/17 7:49 PM, Dave Horsfall wrote:
> > On Mon, 25 Sep 2017, Larry McVoy wrote:
> > 
> >> ????????lrwx------ 1 lm lm 64 Sep 23 21:39 255 -> /dev/pts/8
> > 
> > What the heck is file descriptor 255?
> 
> It appears to be a file descriptor open to his controlling terminal.

LOL.  I think he's wondering why the fd has the value of 255 and I dunno.
Some weird bash thing?

[TUHS] UNIX of choice these days?

[Chet Ramey]

On 9/26/17 10:53 AM, Larry McVoy wrote:
> On Mon, Sep 25, 2017 at 10:06:55PM -0400, Chet Ramey wrote:
>> On 9/25/17 7:49 PM, Dave Horsfall wrote:
>>> On Mon, 25 Sep 2017, Larry McVoy wrote:
>>>
>>>> ????????lrwx------ 1 lm lm 64 Sep 23 21:39 255 -> /dev/pts/8
>>>
>>> What the heck is file descriptor 255?
>>
>> It appears to be a file descriptor open to his controlling terminal.
> 
> LOL.  I think he's wondering why the fd has the value of 255 and I dunno.
> Some weird bash thing?

It's not weird. Bash keeps a file descriptor open to the controlling
terminal to use for job control and other terminal operations. After it
opens the ctty, it dups the file descriptor to something out of the usual
range people use to save and restore fds. It uses the RLIMIT_NOFILE
resource limit to determine the upper bound, but doesn't go past 256 (some
systems set that limit pretty high). So you have a file descriptor that the
shell can use but is close-on-exec and unusual enough to avoid being
stepped on.

-- 
``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?

[Dave Horsfall]

On Tue, 26 Sep 2017, Larry McVoy wrote:

>>> What the heck is file descriptor 255?
>>
>> It appears to be a file descriptor open to his controlling terminal.
>
> LOL.  I think he's wondering why the fd has the value of 255 and I 
> dunno. Some weird bash thing?

Exactly; why 255 of all things?

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

[TUHS] UNIX of choice these days?

[Arthur Krewat]

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

Who's going to type:

<cmd> 2>&255

?


On 9/26/2017 5:23 PM, Dave Horsfall wrote:
> On Tue, 26 Sep 2017, Larry McVoy wrote:
>
>>>> What the heck is file descriptor 255?
>>>
>>> It appears to be a file descriptor open to his controlling terminal.
>>
>> LOL.  I think he's wondering why the fd has the value of 255 and I 
>> dunno. Some weird bash thing?
>
> Exactly; why 255 of all things?
>

[TUHS] UNIX of choice these days?

[Grant Taylor]

On 09/26/2017 03:23 PM, Dave Horsfall wrote:
> Exactly; why 255 of all things?

High order of 8 bits?  (Assuming low order starts at 0.)



-- 
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/aaafee2d/attachment-0001.bin>

[TUHS] UNIX of choice these days?

[Dave Horsfall]

On Tue, 26 Sep 2017, Grant Taylor wrote:

>> Exactly; why 255 of all things?
>
> High order of 8 bits?  (Assuming low order starts at 0.)

Yeah, but still doesn't answer the question, application-wise.  I'm gonna 
guess (without digging through the source) that it's a "dup2(0, 255)*" or 
something, to "save" a copy of stdin/out/err for some obscure reason.

[*]
OK, "getdtablesize() - 1" instead of 255...

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

[TUHS] UNIX of choice these days?

[Chet Ramey]

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

On 9/26/17 8:58 PM, Dave Horsfall wrote:
> On Tue, 26 Sep 2017, Grant Taylor wrote:
> 
>>> Exactly; why 255 of all things?
>>
>> High order of 8 bits?  (Assuming low order starts at 0.)
> 
> Yeah, but still doesn't answer the question, application-wise.  I'm gonna
> guess (without digging through the source) that it's a "dup2(0, 255)*" or
> something, to "save" a copy of stdin/out/err for some obscure reason.

I already answered this.

-- 
``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?

[Larry McVoy]

On Tue, Sep 26, 2017 at 09:37:13PM -0400, Chet Ramey wrote:
> On 9/26/17 8:58 PM, Dave Horsfall wrote:
> > On Tue, 26 Sep 2017, Grant Taylor wrote:
> > 
> >>> Exactly; why 255 of all things?
> >>
> >> High order of 8 bits??? (Assuming low order starts at 0.)
> > 
> > Yeah, but still doesn't answer the question, application-wise.?? I'm gonna
> > guess (without digging through the source) that it's a "dup2(0, 255)*" or
> > something, to "save" a copy of stdin/out/err for some obscure reason.
> 
> I already answered this.

OK, I'm gonna be that guy because I've learned when I ask, I learn.  

You answered but I didn't get any insight.  Why have an extra fd talking
to the tty?  bash has 0, 1, 2 talking to it.   If it were redirected 
would it have 255 pointing to some random tty?  I don't get the reason
for the extra fd.

[TUHS] UNIX of choice these days?

[Dave Horsfall]

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

On Tue, 26 Sep 2017, Chet Ramey wrote:

>> Yeah, but still doesn't answer the question, application-wise.  I'm 
>> gonna guess (without digging through the source) that it's a "dup2(0, 
>> 255)*" or something, to "save" a copy of stdin/out/err for some obscure 
>> reason.
>
> I already answered this.

You didn't, actually, but I'll be generous and assume that you genuinely 
missed my point as opposed to being deliberately obtuse; I don't think I 
can make it any clearer, but I see that Larry "got it".

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

[TUHS] UNIX of choice these days?

[Chet Ramey]

On 9/26/17 10:02 PM, Larry McVoy wrote:

>>> Yeah, but still doesn't answer the question, application-wise.?? I'm gonna
>>> guess (without digging through the source) that it's a "dup2(0, 255)*" or
>>> something, to "save" a copy of stdin/out/err for some obscure reason.
>>
>> I already answered this.
> 
> OK, I'm gonna be that guy because I've learned when I ask, I learn.  
> 
> You answered but I didn't get any insight.  Why have an extra fd talking
> to the tty?  bash has 0, 1, 2 talking to it.   If it were redirected 
> would it have 255 pointing to some random tty?  I don't get the reason
> for the extra fd.

OK. The only way to guarantee you have a descriptor open to your
controlling terminal is to open /dev/tty yourself. You can run `bash -im'
and have yourself an interactive shell with job control enabled no matter
where stdin/stdout/stderr point, and they can be redirected at any point
during execution, so you can't count on them. But why do you have to have
the fd in the first place?

My initial message said you need it for "job control and other terminal
operations." Here's what that means.

You initially need a handle to your controlling terminal to determine
whether or not you have one and whether you're in the background. If you
don't have a controlling terminal, job control is impossible. You need the
terminal's process group to determine whether or not you're in the
foreground, and to get that you need a handle to the controlling tty. Every
shell does this.

Once you've determined the original tty pgrp, you need to become a process
group leader if you're not one already and set the terminal's process group
to your own so you can stay in the foreground. If you don't, you can't read
from the terminal. If you can't change the terminal's process group, you
can't enable job control. You need the handle to call tcsetpgrp(). Again,
this is something every shell does.

Now that you've set up job control, and you have a handle to your
controlling terminal, you might as well keep it around -- your controlling
terminal is not going to change throughout the life of the process.
You'll need that handle every time you want to set the terminal's process
group, and that's the essence of job control: setting the terminal's
process group to the process group ID of whatever you've determined is the
foreground job (which, most of the time, is yourself). So bash saves it
to an fd that is unlikely to collide with anything else, which is essential
because bash allows the file descriptor numbers used in redirections to
consist of multiple digits. (I explained the algorithm bash uses; other
shells do something different. dash and zsh use fd 10. mksh uses 24 (?).
ksh93 uses fd 2 no matter what, so you don't get job control if you
redirect stderr away from the terminal.)

There is another "terminal operation" for which the controlling terminal
is required: saving and restoring terminal state. Bash fetches the terminal
attributes before running an external command, and restores the attributes
if a process exits with a non-zero status or is stopped. The former is a
useful convenience; the latter is required. You need the handle for the
calls to tcgetattr()/tcsetattr().

You can get away without all of this stuff, of course. But that makes job
control harder and less efficient.

Chet
-- 
``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?

[Larry McVoy]

On Wed, Sep 27, 2017 at 09:50:10AM -0400, Chet Ramey wrote:
> On 9/26/17 10:02 PM, Larry McVoy wrote:
> 
> >>> Yeah, but still doesn't answer the question, application-wise.?? I'm gonna
> >>> guess (without digging through the source) that it's a "dup2(0, 255)*" or
> >>> something, to "save" a copy of stdin/out/err for some obscure reason.
> >>
> >> I already answered this.
> > 
> > OK, I'm gonna be that guy because I've learned when I ask, I learn.  
> > 
> > You answered but I didn't get any insight.  Why have an extra fd talking
> > to the tty?  bash has 0, 1, 2 talking to it.   If it were redirected 
> > would it have 255 pointing to some random tty?  I don't get the reason
> > for the extra fd.
> 
> OK. The only way to guarantee you have a descriptor open to your
> controlling terminal is to open /dev/tty yourself. You can run `bash -im'
> and have yourself an interactive shell with job control enabled no matter
> where stdin/stdout/stderr point, and they can be redirected at any point
> during execution, so you can't count on them. But why do you have to have
> the fd in the first place?

All the tty stuff wasn't my question, I get all that, I did POSIX conformance
in SunOS, there was a time when I dreamed about setsid() et al :)

> ksh93 uses fd 2 no matter what, so you don't get job control if you
> redirect stderr away from the terminal.)

So that's the behaviour I'm used to (dating myself but this is TUHS so...)

My question really was why use an extra fd?  If I run 

	bash something > /dev/null 2>&1

duh.  ksh93 wouldn't let you ^Z that, eh?  OK, makes sense, I hadn't 
thought it through.  Sorry for the brain fart.

[TUHS] UNIX of choice these days?

[Chet Ramey]

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

On 9/26/17 11:42 PM, Dave Horsfall wrote:
> On Tue, 26 Sep 2017, Chet Ramey wrote:
> 
>>> Yeah, but still doesn't answer the question, application-wise.  I'm
>>> gonna guess (without digging through the source) that it's a "dup2(0,
>>> 255)*" or something, to "save" a copy of stdin/out/err for some obscure
>>> reason.
>>
>> I already answered this.
> 
> You didn't, actually, 

I really did: job control and terminal operations. I added more detail
in another message this morning.

-- 
``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?

[Derek Fawcus]

On Wed, Sep 27, 2017 at 07:17:06AM -0700, Larry McVoy wrote:
> On Wed, Sep 27, 2017 at 09:50:10AM -0400, Chet Ramey wrote:
> 
> > ksh93 uses fd 2 no matter what, so you don't get job control if you
> > redirect stderr away from the terminal.)

I'm fairly sure bash used to do something similar.

I recall having to hack it around '07/'08 to cope with being started
(possibly passing '-i' - I can't recall), when stderr was a pipe,
stdin/stout were a pty (which was the controlling terminal), yet finding
that job control didn't work.

DF

[TUHS] UNIX of choice these days?

[Chet Ramey]

On 9/28/17 4:10 AM, Derek Fawcus wrote:
> On Wed, Sep 27, 2017 at 07:17:06AM -0700, Larry McVoy wrote:
>> On Wed, Sep 27, 2017 at 09:50:10AM -0400, Chet Ramey wrote:
>>
>>> ksh93 uses fd 2 no matter what, so you don't get job control if you
>>> redirect stderr away from the terminal.)
> 
> I'm fairly sure bash used to do something similar.
> 
> I recall having to hack it around '07/'08 to cope with being started
> (possibly passing '-i' - I can't recall), when stderr was a pipe,
> stdin/stout were a pty (which was the controlling terminal), yet finding
> that job control didn't work.

Yes, that changed in 2007 based on bug reports you filed while working
at Cisco. The first release where it appeared was bash-4.0.

-- 
``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?

[Derek Fawcus]

On Thu, Sep 28, 2017 at 06:44:20PM +0100, Derek Fawcus wrote:
> On Thu, Sep 28, 2017 at 08:34:28AM -0400, Chet Ramey wrote:
> > Yes, that changed in 2007 based on bug reports you filed while working at Cisco.
> 
> So fd 255 is my fault? :-)

Or not - given that macOS, using an older bash already used 255:

$ set|fgrep VERSION
BASH_VERSION='3.2.57(1)-release'
$ lsof -p $$|fgrep CHR
bash    6843 derek    0u   CHR  16,10  0t554677     701 /dev/ttys010
bash    6843 derek    1u   CHR  16,10  0t554677     701 /dev/ttys010
bash    6843 derek    2u   CHR  16,10  0t554677     701 /dev/ttys010
bash    6843 derek  255u   CHR  16,10  0t554677     701 /dev/ttys010

DF

[TUHS] UNIX of choice these days?

[Chet Ramey]

On 9/28/17 1:57 PM, Derek Fawcus wrote:
> On Thu, Sep 28, 2017 at 06:44:20PM +0100, Derek Fawcus wrote:
>> On Thu, Sep 28, 2017 at 08:34:28AM -0400, Chet Ramey wrote:
>>> Yes, that changed in 2007 based on bug reports you filed while working at Cisco.
>>
>> So fd 255 is my fault? :-)
> 
> Or not - given that macOS, using an older bash already used 255:

No, the opening of /dev/tty to get the controlling terminal instead of
assuming you can use fd 2 for it is your fault. :-)

Bash always used an unused fd close to the fd limit to save the handle.

-- 
``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?

[Kevin Bowling]

To understand the Linux sysfs, you have to understand what problem
they are trying to solve.  It is self inflicted, but it solves a
problem in a way the community values.  Because the kernel is an
independent project versus libc (glibc, musl, Bionic, etc), and
because the base system is from others as well (coreutils, busybox,
systemd), Linus has become fanatical about ABI stability.  The simple
text interfaces allow the kernel to change haphazardly without much
planning, and still retain binary compatibility.  In terms of code
churn and needless KPI proliferation, Torvald's "masturbating monkeys"
insult toward OpenBSD holds up pretty well for his own crew :)

Operating systems (using subtle terminology that excludes "Linux"
without more specification) don't have that problem.

I haven't played with Plan9 at all.  Read some code, the TCP stack was
cute but unrealistically simplistic.  I need to take it for a spin.

Regards,

On Sat, Sep 30, 2017 at 2:56 PM, Bakul Shah <bakul at bitblocks.com> wrote:
>
> On Sep 30, 2017, at 1:29 PM, Kevin Bowling <kevin.bowling at kev009.com> wrote:
>
>> I seem to recall proc is loosely deprecated in Linux anyway in favor
>> of sysfs.  GregKH mentioned people misuse both, for instance making
>> them output pretty histograms instead of simple text values, that
>> defeat the fundamental design tenants of these interfaces -- which is
>> to try and maintain a stable API.
>
>> One thing I think Linux did pretty well is the whole object
>> orientation in C thing with kobject, and that nets you automatic sysfs
>> directories and nodes for pretty much everything.
>
> The Linux /sys fs is truly bizarre. On a RaspberryPi running Linux 4.4.21+:
>
> $ find /sys | wc # total entries
> 11448
> $ find /sys -type l | wc # count of symlinks
> 1077
> $ find /sys -type f | wc  # count of "regular" files
> 8931
>
> I am not sure exposing most everything via a namespace in this
> manner is such a good idea (or at least in "good taste" :-)
> Interfaces should be lean.
>
> Similarly the /proc fs is quite strange. Why does it have any
> non process subdirectory?
>
> $ echo /proc/[0-9]* | wc -w # count of processes
> 142
> $ echo /proc/[^0-9]* | wc -w  # count of non-process directories
> 58
>
> Compare:
>
> Linux (raspberryPi + X windows):
> $ echo /proc/[0-9]* |wc -w # how many processes
> 142
> $ find /proc/[0-9]* | wc -l # how many proc related files+dirs
> 66153
>
> FreeBSD (10.3 amd64+zfs+4 lightweight jails):
> $ echo /proc/[0-9]* | wc -w # how many processes
> 123
> $ find /proc/[0-9]* | wc -l # how many proc related files+dirs
> 1075
>
> Plan9 (mostly quiescent):
> $ echo /proc/[0-9]* | wc -w
> 64
> $ du -a /proc/[0-9]* | wc -l
> 1235
>
> Anyone feeling sad about /proc in FreeBSD should consider
> the alternative!
>
>

[TUHS] UNIX of choice these days?

[Bakul Shah]

On Sep 30, 2017, at 1:29 PM, Kevin Bowling <kevin.bowling at kev009.com> wrote:

> I seem to recall proc is loosely deprecated in Linux anyway in favor
> of sysfs.  GregKH mentioned people misuse both, for instance making
> them output pretty histograms instead of simple text values, that
> defeat the fundamental design tenants of these interfaces -- which is
> to try and maintain a stable API.

> One thing I think Linux did pretty well is the whole object
> orientation in C thing with kobject, and that nets you automatic sysfs
> directories and nodes for pretty much everything.

The Linux /sys fs is truly bizarre. On a RaspberryPi running Linux 4.4.21+:

$ find /sys | wc		# total entries
11448
$ find /sys -type l | wc	# count of symlinks
1077
$ find /sys -type f | wc 	# count of "regular" files
8931

I am not sure exposing most everything via a namespace in this
manner is such a good idea (or at least in "good taste" :-)
Interfaces should be lean.

Similarly the /proc fs is quite strange. Why does it have any
non process subdirectory?

$ echo /proc/[0-9]* | wc -w 	# count of processes
142
$ echo /proc/[^0-9]* | wc -w 	# count of non-process directories
58

Compare:

Linux (raspberryPi + X windows):
$ echo /proc/[0-9]* |wc -w	# how many processes
142
$ find /proc/[0-9]* | wc -l	# how many proc related files+dirs
66153

FreeBSD (10.3 amd64+zfs+4 lightweight jails):
$ echo /proc/[0-9]* | wc -w	# how many processes
123
$ find /proc/[0-9]* | wc -l	# how many proc related files+dirs
1075

Plan9 (mostly quiescent):
$ echo /proc/[0-9]* | wc -w
64
$ du -a /proc/[0-9]* | wc -l
1235

Anyone feeling sad about /proc in FreeBSD should consider
the alternative!


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

[TUHS] UNIX of choice these days?

[Kevin Bowling]

I never really considered proc vs sysctl as deeply as this discussion.
Both seem like a little bit of a stretch and cause some impedance
mismatch in ways they are actually used.  For instance on FreeBSD you
can pass opaque structures around and that's how some of the utils
work -- these aren't displayed using sysctl(8).  So now you have ABI
over a text API anyway.

I seem to recall proc is loosely deprecated in Linux anyway in favor
of sysfs.  GregKH mentioned people misuse both, for instance making
them output pretty histograms instead of simple text values, that
defeat the fundamental design tenants of these interfaces -- which is
to try and maintain a stable API.

One thing I think Linux did pretty well is the whole object
orientation in C thing with kobject, and that nets you automatic sysfs
directories and nodes for pretty much everything.

Lots of gymnastics trying to solve a fundamentally more simple problem
of a text API vs ABI, hierarchy and maybe some object orientation.  At
risk of ridicule, I think the AIX ODM was the best planned and
executed take on all that :)

Regards,

On Sat, Sep 30, 2017 at 8:17 AM, Norman Wilson <norman at oclsc.org> wrote:
> Warner Losh:
>
>   It's an abundance of caution thing. This code had security problems in the
>   past, we're not 100% sure that we've killed all the issues, though we
>   believe we have.
>
> ====
>
> And if there isn't anyone who's actively interested in the
> code, willing to dig in to clean it up and make security
> issues less likely, deal with multiprocessing matters, and
> so on, that's a perfectly reasonable stance.
>
> I think it's an unfortunate result, and I wonder how much
> of it comes from a cultural view that sysctl >> /proc.
> (Recall how Ken and Dennis originally resisted Doug's push
> for pipelines and filters, because--as Dennis once put it
> in a talk--it just wasn't the way programs worked?)
>
> But as someone who is sometimes credited with removing
> more code than he wrote while working on the latter-day
> Research kernel, it's hard for me to argue with the principle.
> A lot of the code I tossed out was complicated stuff that
> was barely used if used at all, and that nobody was willing
> to step up to volunteer to maintain.
>
> Norman Wilson
> Toronto ON

[TUHS] UNIX of choice these days?

[Norman Wilson]

Warner Losh:

  It's an abundance of caution thing. This code had security problems in the
  past, we're not 100% sure that we've killed all the issues, though we
  believe we have.

====

And if there isn't anyone who's actively interested in the
code, willing to dig in to clean it up and make security
issues less likely, deal with multiprocessing matters, and
so on, that's a perfectly reasonable stance.

I think it's an unfortunate result, and I wonder how much
of it comes from a cultural view that sysctl >> /proc.
(Recall how Ken and Dennis originally resisted Doug's push
for pipelines and filters, because--as Dennis once put it
in a talk--it just wasn't the way programs worked?)

But as someone who is sometimes credited with removing
more code than he wrote while working on the latter-day
Research kernel, it's hard for me to argue with the principle.
A lot of the code I tossed out was complicated stuff that
was barely used if used at all, and that nobody was willing
to step up to volunteer to maintain.

Norman Wilson
Toronto ON

[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?

[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/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?

[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?

[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]

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?

[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?

[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?

[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?

[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?

[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?

[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?

[Clem Cole]

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

On Mon, Sep 25, 2017 at 8:46 AM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:

>
> Amusingly the IT department of AT&T felt that way

​+1​  thanks Doug -- great smile for a Monday morning.

​"Things are like the are today, then they have ever been before."

I've never quite fully understood this style of behavior by IT folks.
It's a control issue for sure, but when I seen my IT folks as looking at me
and my colleagues as people that can help them, it generally has worked
well.   It's funny, DEC's IT group knew never mess with research or
engineering because KO or GB would come down them.  I think they loved the
Compaq merger because quickly, the IT group 'was in charge' and we got told
to 'bugger off' - did not matter if some one in engineering or research had
invented the idea or technique and they had it configure incorrectly.  They
knew it was supposed to work ;-)

It has gotten outright silly a few times in my life.  Tektronix was great,
and DEC worked well; but I've found IT departments run by 'big iron' (IBM
back in the day, MSFT these days) don't want to listen.  They have 'the
solution' - your square peg will be made to conform.    We only have round
holes, that's all we need so that's all you should also....

Intel is mostly that way, although I will say the Macs at Intel sub-group in
IT is one of the best I have ever worked.  I think part of the reason why
they listen to people like me when the rest of IT will let them, is they
are way fewer people than they need to support the few thousand Macs at Intel.
 So, if I call they know something really is fubar, as I would have fixed
it myself it was minor or told them how to fix it for me if I could (needed
some silly IT permission).

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

[TUHS] Unix of choice these days?

[Doug McIlroy]

>>  "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.

Amusingly the IT department of AT&T felt that way and commissioned a
Harvard prof, no less, to write a report about why VMS was the way to
go on Vaxen. The hired gun (so much for academic integrity) addressed
the subject almost entirely with meta arguments:

(1) VMS was written by OS professionals; Unix was a lab experiment.

(2) One could count on support from DEC, not from Research. (So
much for USG; as far as i know the author never asked anyone in]
Bell Labs about anything.)

(3) And the real killer: VMS was clearly far advanced, witness 
its shelf of manuals vs the thin Unix volumes that fit in one's
briefcase. Lee McMahon had particular fun with this one in a
rebuttal that unleashed the full power of his Jesuit training
in analytic debate.

Doug

[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?

[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?

[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] 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?

[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, 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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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] 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?

[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?

[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?

[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?

[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?

[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?

[Nelson H. F. Beebe]

Dario Niedermann <dario at darioniedermann.it> wrote on Sat, 23 Sep 2017
11:17:04 +0200:

>> I just can't forgive FreeBSD for abandoning the proc filesystem  ...

It can be there, if you wish.

Here are two snippets from a recent log of a recent "pkg update -f ;
pkg upgrade" run on a one of my many *BSD family systems, this one
running FreeBSD 11.1-RELEASE-p1:

	Message from openjdk8-8.131.11:
	======================================================================

	This OpenJDK implementation requires fdescfs(5) mounted on
	/dev/fd and procfs(5) mounted on /proc.

	If you have not done it yet, please do the following:

		mount -t fdescfs fdesc /dev/fd mount -t procfs proc
		/proc

	To make it permanent, you need the following lines in
	/etc/fstab:

		fdesc /dev/fd fdescfs rw 0 0 proc /proc procfs rw 0 0

	======================================================================

	Message from rust-1.18.0:
	======================================================================

	Printing Rust backtraces requires procfs(5) mounted on /proc .
	If you have not already done so, please do the following:

		mount -t procfs proc /proc

	To make it permanent, you need the following lines in /etc/fstab:

		proc    /proc           procfs          rw      0       0

	======================================================================

I've seen such messages in many package installations in the *BSD
family, and I generally add the suggested lines to /etc/fstab.

Perhaps others more familiar with BSD internals might comment on
whether it is many non-BSD software, like the Java Developer's Kit,
and Mozilla's rust language, that mostly would like /proc support, or
whether there are plenty of native-BSD packages that expect it too.

The second edition of

	Marshall Kirk McKusick, George V. Neville-Neil, and Robert N. M. Watson
	The Design and Implementation of the FreeBSD Operating System
	ISBN 0-201-70245-2 (hardcover), 0-321-96897-2 (hardcover)

has 5 pages with mention of the /proc filesystem, and nothing that
suggests that it is in any way deprecated.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

[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?

[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?

[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?

[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 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?

[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?

[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?

[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?

[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?

[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?

[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?

[Rudi Blom]

Maybe I'm the odd one out here, but at home I've only got a Windows/10
notebook :-)

Mind you, at work I play with
. aDEC 400xP, DECpc MTE, Prioris XL server running SCO UNIX 3.2V4.2
. AlphaServer DS10 running Digital Unix 4.0g
. AlphaServer DS15 running Tru64 Unix 5.1B
. HP(E) rx-servers rx1620, rx2620, rx2660 running HP-UX 11.23
. HP(E) rx-servers rx2800 i2/i4 running HP-UX 11.31
. DOS 6.22, Windows/Xp, Windows/7 clients

Maintaining applications which were conceived late 80s is fun :-)

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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]

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?

[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?

[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?

[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?

[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]

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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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?

[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