30 Dec
2021
30 Dec
'21
9:45 a.m.
From: Bakul Shah
My guess is *not* storing a path instead of a ptr to
the inode was done
to save on memory.
More probably speed; those old disks were not fast, and on a PDP-11, disk
caches were so small that converting the path to the current directory to its
in memory inode could take a bunch of disk reads.
Every inode has a linkcount so detecting when the last
conn. is severed
not a problem.
Depends; if a directory _has_ to be empty before it can be deleted, maybe; but
if not, no. (Consider if /a/b/c/d exists, and /a/b is removed; the tree
underneath it has to be walked and the components deleted. That could take a
while...) In the general case (e.g. without the restriction to a tree), it's
basically the same problem as garbage collection in LISP.
Noel
30 Dec
30 Dec
10:02 a.m.
New subject: moving directories in svr2
On Dec 29, 2021, at 7:45 PM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu> wrote:
Good point!
Indeed. You can detect circularly linked nodes when you try to delete
sub directories. Then you have to ask the user whether to still delete it!
In Lisp you can simply NIL a node and let the GC take care of it.... May be
you can do the same with "rm -rf" but it may have a surprising/unintended
outcome! An important point I missed. Thanks.
From: Bakul Shah
My guess is *not* storing a path instead of a ptr
to the inode was done
to save on memory.
More probably speed; those old disks were not fast, and on a PDP-11, disk
caches were so small that converting the path to the current directory to its
in memory inode could take a bunch of disk reads. Every inode
has a linkcount so detecting when the last conn. is severed
not a problem.
Depends; if a directory _has_ to be empty before it can be deleted, maybe; but
if not, no. (Consider if /a/b/c/d exists, and /a/b is removed; the tree
underneath it has to be walked and the components deleted. That could take a
while...) In the general case (e.g. without the restriction to a tree), it's
basically the same problem as garbage collection in LISP.
Noel
10:40 p.m.
New subject: moving directories in svr2
On Wed, Dec 29, 2021 at 10:45:12PM -0500, Noel Chiappa wrote:
The other problem with storing the path as a string is that if
higher-level directories get renamed, the path would become
invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone
renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string would
become invalidated.
Sure, you could scan the pwd of all the processes running on the
system and do edit all of the strings, but once you go SMP, the
potential locking pitfalls would be numerous.
- Ted
From: Bakul
Shah
My guess is *not* storing a path instead of a ptr
to the inode was done
to save on memory.
More probably speed; those old disks were not fast, and on a PDP-11, disk
caches were so small that converting the path to the current directory to its
in memory inode could take a bunch of disk reads. 
31 Dec
31 Dec
4:31 a.m.
New subject: moving directories in svr2
On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o <tytso(a)mit.edu> wrote:
On Wed, Dec 29, 2021 at 10:45:12PM -0500, Noel Chiappa
wrote:
The other problem with storing the path as a string is that if
higher-level directories get renamed, the path would become
invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone
renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string
would
become invalidated.
Why? Presumably as you traversed the filesystem, you'd cache, (path
component, inode) pairs and keep a ref on the inode. For any given
file, including $CWD, you'd know it's pathname from the root as you
accessed it, but if it got renamed, it wouldn't matter because you'd
have cached a reference to the inode.
From:
Bakul Shah
My guess is *not* storing a path instead of a ptr
to the inode was done
to save on memory.
More probably speed; those old disks were not fast, and on a PDP-11, disk
caches were so small that converting the path to the current directory to its
in memory inode could take a bunch of disk reads. Sure, you could scan the pwd of all the processes
running on the
system and do edit all of the strings, but once you go SMP, the
potential locking pitfalls would be numerous.
I don't see the need for that. What am I missing?
- Dan C.
6:43 a.m.
New subject: moving directories in svr2
On Dec 30, 2021, at 2:31 PM, Dan Cross <crossd(a)gmail.com> wrote:
On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o <tytso(a)mit.edu> wrote:
Without the ".." entry you can't map a dir inode back to a path.
Note that something similar can happen even today:
$ mkdir ~/a; cd ~/a; rm -rf ~/a; cd ..
cd: no such file or directory: ..
$ mkdir -p ~/a/b; ln -s ~/a/b b; cd b; mv ~/a/b ~/a/c; cd ../b
ls: ../b: No such file or directory
You can't protect the user from every such case. Storing a path
instead of the cwd inode simply changes the symptoms.
The other problem with storing the path as a string is that if
higher-level directories get renamed, the path would become
invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone
renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string
would
become invalidated.
Why? Presumably as you traversed the filesystem, you'd cache, (path
component, inode) pairs and keep a ref on the inode. For any given
file, including $CWD, you'd know it's pathname from the root as you
accessed it, but if it got renamed, it wouldn't matter because you'd
have cached a reference to the inode. 
7 a.m.
New subject: moving directories in svr2
Grumpy hat on.
Sometimes the Unix community suffers from the twin attitudes of a)
believing if it can't be done perfectly, any improvement shouldn't be
attempted at all and b) it's already done as well as is possible anyway.
I disagree with both of these positions, obviously, but have given up
pushing against them.
We're in the 6th decade of Unix and we still suffer from unintended,
fixable consequences of decisions made long long ago.
Grumpy hat off.
-rob
On Fri, Dec 31, 2021 at 11:44 AM Bakul Shah <bakul(a)iitbombay.org> wrote:
On Dec 30, 2021, at 2:31 PM, Dan Cross
<crossd(a)gmail.com> wrote:
On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o <tytso(a)mit.edu> wrote:
Without the ".." entry you can't map a dir inode back to a path.
Note that something similar can happen even today:
$ mkdir ~/a; cd ~/a; rm -rf ~/a; cd ..
cd: no such file or directory: ..
$ mkdir -p ~/a/b; ln -s ~/a/b b; cd b; mv ~/a/b ~/a/c; cd ../b
ls: ../b: No such file or directory
You can't protect the user from every such case. Storing a path
instead of the cwd inode simply changes the symptoms.
The other problem with storing the path as a string is that if
higher-level directories get renamed, the path would become
invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone
renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string
would
become invalidated.
Why? Presumably as you traversed the filesystem, you'd cache, (path
component, inode) pairs and keep a ref on the inode. For any given
file, including $CWD, you'd know it's pathname from the root as you
accessed it, but if it got renamed, it wouldn't matter because you'd
have cached a reference to the inode.
7:45 a.m.
New subject: moving directories in svr2
?
I was just explaining Ts'o's point, not agreeing with it. The first example I
gave works just fine on plan9 (unlike on unix). And since it doesn't allow
renames, the scenario T'so outlines can't happen there! But we were
discussing Unix here.
As for symlinks, if we have to have them, storing a path actually makes their
use less surprising.
We're in the 6th decade of Unix and we still
suffer from unintended, fixable consequences of decisions made long long ago.
No argument here. Perhaps you can suggest a path for fixing?
> On Dec 30, 2021, at 5:00 PM, Rob Pike <robpike(a)gmail.com> wrote:
>
> Grumpy hat on.
>
> Sometimes the Unix community suffers from the twin attitudes of a) believing if it
can't be done perfectly, any improvement shouldn't be attempted at all and b)
it's already done as well as is possible anyway.
>
> I disagree with both of these positions, obviously, but have given up pushing against
them.
>
We're in the 6th decade of Unix and we still
suffer from unintended, fixable consequences of decisions made long long ago.
>
> Grumpy hat off.
>
> -rob
>
>
> On Fri, Dec 31, 2021 at 11:44 AM Bakul Shah <bakul(a)iitbombay.org
<mailto:bakul@iitbombay.org>> wrote:
> On Dec 30, 2021, at 2:31 PM, Dan Cross <crossd(a)gmail.com
<mailto:crossd@gmail.com>> wrote:
> >
> > On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o <tytso(a)mit.edu
<mailto:tytso@mit.edu>> wrote:
> >>
> >> The other problem with storing the path as a string is that if
> >> higher-level directories get renamed, the path would become
> >> invalidated. If you store the cwd as "/foo/bar/baz/quux", and
someone
> >> renames "/foo/bar" to "/foo/sadness" the
cwd-stored-as-a-string would
> >> become invalidated.
> >
> > Why? Presumably as you traversed the filesystem, you'd cache, (path
> > component, inode) pairs and keep a ref on the inode. For any given
> > file, including $CWD, you'd know it's pathname from the root as you
> > accessed it, but if it got renamed, it wouldn't matter because you'd
> > have cached a reference to the inode.
>
> Without the ".." entry you can't map a dir inode back to a path.
> Note that something similar can happen even today:
>
> $ mkdir ~/a; cd ~/a; rm -rf ~/a; cd ..
> cd: no such file or directory: ..
>
> $ mkdir -p ~/a/b; ln -s ~/a/b b; cd b; mv ~/a/b ~/a/c; cd ../b
> ls: ../b: No such file or directory
>
> You can't protect the user from every such case. Storing a path
> instead of the cwd inode simply changes the symptoms.
>
>
8:23 a.m.
New subject: moving directories in svr2
Moving to COFF, perhaps prematurely, but...
It feels weird to be a Unix native (which I consider myself: got my first
taste of Irix and SVR3 in 1989, went to college where it was a Sun-mostly
environment, started running Linux on my own machines in 1992 and never
stopped). (For purposes of this discussion, of course Linux is Unix.)
It feels weird the same way it was weird when I was working for Express
Scripts, and then ESRX bought Medco, and all of a sudden we were the 500-lb
Gorilla. That's why I left: we (particularly my little group) had been
doing some fairly cool and innovative stuff, and after that deal closed, we
switched over entirely to playing defense, and it got really boring really
fast. My biggest win after that was showing that Pega ran perfectly fine
on Tomcat, which caused IBM to say something like "oh did we say $5 million
a year to license Websphere App Server? Uh...we meant $50K." So I saved
them a lot of money but it sucked to watch several months' work flushed
down the toilet, even though the savings to the company was many times my
salary for those months.
But the weird part is similar: Unix won. Windows *lost*. Sure, corporate
desktops still mostly run Windows, and those people who use it mostly hate
it. But people who like using computers...use Macs (or, sure, Linux, and
then there are those weirdos like me who enjoy running all sorts of
ancient-or-niche-systems, many of which are Unix). And all the people who
don't care do computing tasks on their phones, which are running either
Android--a Unix--or iOS--also a Unix. It's ubiquitous. It's the air you
breathe. It's no longer strange to be a Unix user, it means you use a
21st-century electronic device.
And, sure, it's got its warts, but it's still basically the least-worst
thing out there. And it continues to flabbergast me that a typesetting
system designed to run on single-processor 16-bit machines has, basically,
conquered the world.
Adam
P.S. It's also about time, he said with a sigh of relief, having been an
OS/2 partisan, and a BeOS partisan, back in the day. Nice to back a
winning horse for once.
On Thu, Dec 30, 2021 at 6:46 PM Bakul Shah <bakul(a)iitbombay.org> wrote:
?
I was just explaining Ts'o's point, not agreeing with it. The first
example I
gave works just fine on plan9 (unlike on unix). And since it doesn't allow
renames, the scenario T'so outlines can't happen there! But we were
discussing Unix here.
As for symlinks, if we have to have them, storing a path actually makes
their
use less surprising.
We're in the 6th decade of Unix and we still suffer from unintended,
fixable consequences of decisions made long long ago.
No argument here. Perhaps you can suggest a path for fixing?
On Dec 30, 2021, at 5:00 PM, Rob Pike <robpike(a)gmail.com> wrote:
Grumpy hat on.
Sometimes the Unix community suffers from the twin attitudes of a)
believing if it can't be done perfectly, any improvement shouldn't be
attempted at all and b) it's already done as well as is possible anyway.
I disagree with both of these positions, obviously, but have given up
pushing against them.
We're in the 6th decade of Unix and we still suffer from unintended,
fixable consequences of decisions made long long ago.
Grumpy hat off.
-rob
On Fri, Dec 31, 2021 at 11:44 AM Bakul Shah <bakul(a)iitbombay.org> wrote:
On Dec 30, 2021, at 2:31 PM, Dan Cross
<crossd(a)gmail.com> wrote:
On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o <tytso(a)mit.edu> wrote:
Without the ".." entry you can't map a dir inode back to a path.
Note that something similar can happen even today:
$ mkdir ~/a; cd ~/a; rm -rf ~/a; cd ..
cd: no such file or directory: ..
$ mkdir -p ~/a/b; ln -s ~/a/b b; cd b; mv ~/a/b ~/a/c; cd ../b
ls: ../b: No such file or directory
You can't protect the user from every such case. Storing a path
instead of the cwd inode simply changes the symptoms.
The other problem with storing the path as a string is that if
higher-level directories get renamed, the path would become
invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone
renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string
would
become invalidated.
Why? Presumably as you traversed the filesystem, you'd cache, (path
component, inode) pairs and keep a ref on the inode. For any given
file, including $CWD, you'd know it's pathname from the root as you
accessed it, but if it got renamed, it wouldn't matter because you'd
have cached a reference to the inode. 
1 Jan
1 Jan
12:56 a.m.
New subject: moving directories in svr2
On 12/30/21 7:43 PM, Bakul Shah wrote:
Without the ".." entry you can't map a
dir inode back to a path.
Note that something similar can happen even today:
$ mkdir ~/a; cd ~/a; rm -rf ~/a; cd ..
cd: no such file or directory: ..
$ mkdir -p ~/a/b; ln -s ~/a/b b; cd b; mv ~/a/b ~/a/c; cd ../b
ls: ../b: No such file or directory
Modern POSIX shells attempt to disguise this for cd and pwd, using $PWD and
a canonicalization algorithm that essentially backs up one component when
it encounters `..' and removes `.' (with verification at each step and
error handling of various quality). It's the default behavior; the
traditional physical behavior is available with -P. It's a variant of the
ksh schme that Rob's lexical names paper explores.
It has the usual weaknesses: what works for cd doesn't work for, say, ls
or any other utilities that don't understand this particular scheme.
It produces the expected behavior for the first case above, but can be
fooled by file system changes that invalidate $PWD, as in the second case.
(I assume the `ls' error message was either a typo or an artifact of a
function or alias for `cd').
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
31 Dec
31 Dec
9:08 a.m.
New subject: moving directories in svr2
On Thu, Dec 30, 2021 at 05:31:09PM -0500, Dan Cross wrote:
On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o
<tytso(a)mit.edu> wrote:
I was responding to Bakul's suggestion that the original Unix
could/should have stored the cwd as a string, instead of a pointer to
a directory inode. If you stored the cwd as a string, then you could
interpret .. by chopping off the last file name component of the
string, and so now you could have hard links to directories and the
file system tree could then be a file system DAG.
I don't think Bakul's proposal would have worked --- although I
suppose if you disallowed directory renames, I guess it could. Noel's
objection above was a performance one, in that if you had to parse the
path every single time, you'd be much more dependent on the namei
cache --- and that PDP-11 didn't have the memory to support a
sufficiently large cache.
- Ted
On Wed, Dec 29, 2021 at 10:45:12PM -0500, Noel
Chiappa wrote:
The other problem with storing the path as a string is that if
higher-level directories get renamed, the path would become
invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone
renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string
would
become invalidated.
Why? Presumably as you traversed the filesystem, you'd cache, (path
component, inode) pairs and keep a ref on the inode. For any given
file, including $CWD, you'd know it's pathname from the root as you
accessed it, but if it got renamed, it wouldn't matter because you'd
have cached a reference to the inode. From:
Bakul Shah
My guess is *not* storing a path instead of a ptr
to the inode was done
to save on memory.
More probably speed; those old disks were not fast, and on a PDP-11, disk
caches were so small that converting the path to the current directory to its
in memory inode could take a bunch of disk reads.
9:23 a.m.
New subject: moving directories in svr2
In broad strokes, that's exactly what we did in Plan 9, with great results,
as was said here a while back. The paper ended with a plea to do the same
to Unix, which I think is quite doable.
https://9p.io/sys/doc/lexnames.html
-rob
On Fri, Dec 31, 2021 at 2:09 PM Theodore Ts'o <tytso(a)mit.edu> wrote:
On Thu, Dec 30, 2021 at 05:31:09PM -0500, Dan Cross
wrote:
Why? Presumably as you traversed the filesystem, you'd cache, (path
component, inode) pairs and keep a ref on the inode. For any given
file, including $CWD, you'd know it's pathname from the root as you
accessed it, but if it got renamed, it wouldn't matter because you'd
have cached a reference to the inode.
I was responding to Bakul's suggestion that the original Unix
could/should have stored the cwd as a string, instead of a pointer to
a directory inode. If you stored the cwd as a string, then you could
interpret .. by chopping off the last file name component of the
string, and so now you could have hard links to directories and the
file system tree could then be a file system DAG.
I don't think Bakul's proposal would have worked --- although I
suppose if you disallowed directory renames, I guess it could. Noel's
objection above was a performance one, in that if you had to parse the
path every single time, you'd be much more dependent on the namei
cache --- and that PDP-11 didn't have the memory to support a
sufficiently large cache.
- Ted
On Thu, Dec 30, 2021 at 11:41 AM Theodore
Ts'o <tytso(a)mit.edu> wrote:
> On Wed, Dec 29, 2021 at 10:45:12PM -0500, Noel Chiappa wrote:
> > > From: Bakul Shah
> >
> > > My guess is *not* storing a path instead of a ptr to the inode
was done
> > > to save on memory.
> >
> > More probably speed; those old disks were not fast, and on a PDP-11,
disk
> > caches were so small that converting
the path to the current
directory to its
in memory inode could take a bunch of disk reads.
The other problem with storing the path as a string is that if
higher-level directories get renamed, the path would become
invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone
renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string
would
become invalidated.
11:16 a.m.
New subject: moving directories in svr2
On Fri, Dec 31, 2021 at 02:23:15PM +1100, Rob Pike wrote:
In broad strokes, that's exactly what we did in
Plan 9, with great results,
as was said here a while back. The paper ended with a plea to do the same
to Unix, which I think is quite doable.
https://9p.io/sys/doc/lexnames.html
I'm sure it *could* be done. In fact, Linux has a number of the
pieces of the implementations already, which could be reused for a
Plan-9-style lexical namespace. Linux has bind mounts, and a dentry is
essentially a cached directory lookup (it contains a pointer to its
parent dentry, the filename used to do the lookup and a pointer to the
resulting inode). And a struct file contains a struct dentry, which
means in Linux it is possible to determine the path used to open a
particular file. There are some differences of course; so it's not
exact, but I agree with you that it is quite "doable". (In
particular, how Linux dentries and symlinks interact appears to be
different from how Plan 9 and Channels did things, if I understand the
paper correctly.)
The question though, is whether Linux *should* do it. Or rather,
*could* we do it without breaking backwards compatibility with users
and application which expect that dot-dot works the way it does in
classical Unix implementations for the past 4 decades or so.
Granted that the combination of symlinks, and hard links, and in
Linux, bind mounts (not to mention bind namespaces, chroots, and
pivot_root operations), can be confusing. But there is a whole
ecosystem of shell scripts, programs, user's finger macros, etc., that
would break if we "made things better" or "made things simpler".
One of the benefits of research OS's is that you can experiment with
things without having to worry about the howls of angry users when you
break backwards compatibility, or eliminate some particular awkward
API or feature.
- Ted
P.S. For example, how I wish I could eliminate telldir/seekdir, or at
least change things so that telldir/seekdir used a substantially
larger "cookie" to memoize a position in a directory's readdir stream
which has to be valid effectively forever. Today, you can pass a
32-bit telldir cookie to seekdir, and readdir MUST not return a
directory entry that it had already returned, and MUST not skip a
directory entry that was present at the time of the telldir(). Thus
spake POSIX, and there are applications which depend on
telldir/seekdir/readdir having this precise set of semantics
If your directory is stored internally as a linear stream, that's not
too bad; but if you're using a more complex data structure, life gets
interesting. I know of one file system (JFS) which added an extra,
separate, on-disk b-tree structure to each directory just to be able
to provide stable telldir/seekdir cookies. (And of course, there's a
performance impact to needing to update an extra b-tree each time a
directory entry is added or removed.)
With a research OS, it's at least possible to say, "Well, *that* was a
mistake; let's pretend it never happened and let's see how much better
life would be." :-)
11:21 a.m.
New subject: moving directories in svr2
On Fri, Dec 31, 2021, 12:16 AM Theodore Ts'o <tytso(a)mit.edu> wrote:
[snip]
One of the benefits of research OS's is that you can experiment with
things without having to worry about the howls of angry users when you
break backwards compatibility, or eliminate some particular awkward
API or feature.
Ah, I see you mercifully avoiding spending a lot of time on the 9fans list
...
- Dan C.
11:55 a.m.
New subject: moving directories in svr2
Thanks for your thoughtful response (and for reading the paper).
This for me is the catch:
*But there is a whole ecosystem of shell scripts, programs, user's finger
macros, etc., that would break if we "made things better" or made things
simpler.*
And of course you're right, but we've known how to roll out breaking
changes in software for a very long time now. And we do so often. Few Unix
programs from the past would compile and run today without being updated to
"modern" interfaces and compilers.
I believe it could be done, and I believe it should be done. Rolled out
carefully and explained well it would please far more than it offends, and
is arguably far closer to correct than the current situation.
Of course, I am not volunteering, sorry. Easy for me to snipe, I admit, but
then I paid my OS dues long ago.
-rob
On Fri, Dec 31, 2021 at 4:16 PM Theodore Ts'o <tytso(a)mit.edu> wrote:
On Fri, Dec 31, 2021 at 02:23:15PM +1100, Rob Pike
wrote:
In broad strokes, that's exactly what we did
in Plan 9, with great
results,
as was said here a while back. The paper ended
with a plea to do the same
to Unix, which I think is quite doable.
https://9p.io/sys/doc/lexnames.html
I'm sure it *could* be done. In fact, Linux has a number of the
pieces of the implementations already, which could be reused for a
Plan-9-style lexical namespace. Linux has bind mounts, and a dentry is
essentially a cached directory lookup (it contains a pointer to its
parent dentry, the filename used to do the lookup and a pointer to the
resulting inode). And a struct file contains a struct dentry, which
means in Linux it is possible to determine the path used to open a
particular file. There are some differences of course; so it's not
exact, but I agree with you that it is quite "doable". (In
particular, how Linux dentries and symlinks interact appears to be
different from how Plan 9 and Channels did things, if I understand the
paper correctly.)
The question though, is whether Linux *should* do it. Or rather,
*could* we do it without breaking backwards compatibility with users
and application which expect that dot-dot works the way it does in
classical Unix implementations for the past 4 decades or so.
Granted that the combination of symlinks, and hard links, and in
Linux, bind mounts (not to mention bind namespaces, chroots, and
pivot_root operations), can be confusing. But there is a whole
ecosystem of shell scripts, programs, user's finger macros, etc., that
would break if we "made things better" or "made things simpler".
One of the benefits of research OS's is that you can experiment with
things without having to worry about the howls of angry users when you
break backwards compatibility, or eliminate some particular awkward
API or feature.
- Ted
P.S. For example, how I wish I could eliminate telldir/seekdir, or at
least change things so that telldir/seekdir used a substantially
larger "cookie" to memoize a position in a directory's readdir stream
which has to be valid effectively forever. Today, you can pass a
32-bit telldir cookie to seekdir, and readdir MUST not return a
directory entry that it had already returned, and MUST not skip a
directory entry that was present at the time of the telldir(). Thus
spake POSIX, and there are applications which depend on
telldir/seekdir/readdir having this precise set of semantics
If your directory is stored internally as a linear stream, that's not
too bad; but if you're using a more complex data structure, life gets
interesting. I know of one file system (JFS) which added an extra,
separate, on-disk b-tree structure to each directory just to be able
to provide stable telldir/seekdir cookies. (And of course, there's a
performance impact to needing to update an extra b-tree each time a
directory entry is added or removed.)
With a research OS, it's at least possible to say, "Well, *that* was a
mistake; let's pretend it never happened and let's see how much better
life would be." :-)
7:32 p.m.
New subject: moving directories in svr2
On 31 Dec 2021 16:55 +1100, from robpike(a)gmail.com (Rob Pike):
And of course you're right, but we've known
how to roll out breaking
changes in software for a very long time now. And we do so often. Few Unix
programs from the past would compile and run today without being updated to
"modern" interfaces and compilers.
I believe it could be done, and I believe it should be done. Rolled out
carefully and explained well it would please far more than it offends, and
is arguably far closer to correct than the current situation.
Seems to me that we have a decent, relatively current case study of
this with Python 2 vs Python 3.
Which is probably a good bit easier actually, because maintaining the
ability to run Python 2 applications while introducing the ability to
run Python 3 applications is likely easier than introducing changes to
how something as relatively fundamental as how ".." behaves in paths
while at the same time maintaining backwards compatibility with the
old behavior, where different users and different applications on the
same system might very well expect different behavior...
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”
9:53 p.m.
New subject: moving directories in svr2
Slightly older, but also slightly more fundamental to the system, you need
look no farther than Solaris's `/bin/sh` for an illustrated example of the
pros and cons of maintaining backwards compatibility. It was a pain by,
say, 2007, to have to check if you were running on SunOS and use
`/usr/xpg4/bin/sh` (IIRC) if you wanted a POSIX shell--by that point the
other major vendors (and Linux) had something POSIX as the default shell.
But Sun had an installed user base with a bunch of shell scripts that
depended on pre-POSIX semantics.
Of course, people don't do a particularly good job of writing POSIX shell
either. Just this past week one of our refactoring projects at the Rubin
Observatory had some difficulty because Debian uses dash as its
non-interactive POSIX shell. Some bit of some conda package that we need
claimed to work with dash (and POSIX generally) but in reality didn't. But
it always worked fine on bash and zsh, so no one had gotten bitten until we
did.
Adam
On Fri, Dec 31, 2021 at 6:40 AM Michael Kjörling <michael(a)kjorling.se>
wrote:
On 31 Dec 2021 16:55 +1100, from robpike(a)gmail.com
(Rob Pike):
And of course you're right, but we've
known how to roll out breaking
changes in software for a very long time now. And we do so often. Few
Unix
programs from the past would compile and run
today without being updated
to
"modern" interfaces and compilers.
I believe it could be done, and I believe it should be done. Rolled out
carefully and explained well it would please far more than it offends,
and
is arguably far closer to correct than the
current situation.
Seems to me that we have a decent, relatively current case study of
this with Python 2 vs Python 3.
Which is probably a good bit easier actually, because maintaining the
ability to run Python 2 applications while introducing the ability to
run Python 3 applications is likely easier than introducing changes to
how something as relatively fundamental as how ".." behaves in paths
while at the same time maintaining backwards compatibility with the
old behavior, where different users and different applications on the
same system might very well expect different behavior...
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”
10:13 p.m.
New subject: moving directories in svr2
On 12/31/2021 10:53 AM, Adam Thornton wrote:
Slightly older, but also slightly more fundamental to
the system, you
need look no farther than Solaris's `/bin/sh` for an illustrated
example of the pros and cons of maintaining backwards compatibility.
It was a pain by, say, 2007, to have to check if you were running on
SunOS and use `/usr/xpg4/bin/sh` (IIRC) if you wanted a POSIX
shell--by that point the other major vendors (and Linux) had something
POSIX as the default shell. But Sun had an installed user base with a
bunch of shell scripts that depended on pre-POSIX semantics.
Did some checking, at the risk of going off-topic:
Solaris 11.4 (current patch level, 11.4.40.107.3, December 2021):
/bin/sh looks to be Korn shell.
root@mercury:~# ls -l /bin/sh
-r-xr-xr-x 5 root bin 2946936 Dec 22 10:46 /bin/sh
root@mercury:~# strings /bin/sh | grep Korn | head -1
][-author?David Korn <dgk(a)research.att.com>][-copyright?Copyright (c)
1982-2021 AT&T Intellectual
Property][-license?http://www.eclipse.org/org/documents/epl-v10.html][--cat…
root@mercury:~# sh --version
version sh (AT&T Research) 93u+ 2012-08-01
Solaris 11.3: /bin/sh seems to be Korn shell.
medusa# ls -l /bin/sh
lrwxrwxrwx 1 root root 11 Jun 11 2016 /bin/sh -> amd64/ksh93
medusa# ls -lL /bin/sh
-r-xr-xr-x 8 root bin 2601344 Jul 1 2016 /bin/sh
medusa# strings !$ | grep dgk | head -1
strings /bin/sh | grep dgk | head -1
][-author?David Korn <dgk(a)research.att.com>][-copyright?Copyright (c)
1982-2016 AT&T Intellectual
Property][-license?http://www.eclipse.org/org/documents/epl-v10.html][--cat…
medusa# sh --version
version sh (AT&T Research) 93u+ 2012-08-01
Solaris 10: (seems /bin/sh is still Bourne at this point):
zeus<(a)medusa.kilonet.net># ls -l /bin/sh
lrwxrwxrwx 1 root root 13 Jun 6 2014 /bin/sh ->
../../sbin/sh
zeus<(a)medusa.kilonet.net># ls -lL /bin/sh
-r-xr-xr-x 1 root root 82456 Sep 22 2010 /bin/sh
sh --version just opens a new shell.
1 Jan
1 Jan
12:17 a.m.
New subject: moving directories in svr2
On Fri, Dec 31, 2021, 10:54 AM Adam Thornton <athornton(a)gmail.com> wrote:
Slightly older, but also slightly more fundamental to
the system, you need
look no farther than Solaris's `/bin/sh` for an illustrated example of the
pros and cons of maintaining backwards compatibility. [snip]
Sun is not the exemplar here: the move from SunOS 4's BSD userland to
Solaris 2's SVR4 broke tons of things. They didn't seem to mind that their
customers had to pay the cost of adaptation.
The Linux example is also a bit strange. The move from e.g. `ifconfig` and
`netstat to `ip` and `ss` required lots of local retooling (I suppose some
distros retain the older tools or let you install them as an option. I
suppose one could always install `bash` on Solaris as a shell lingua
franca, as well). Not to mention systemd. The point is, breaking changes
are introduced all the time.
- Dan C.
12:23 a.m.
New subject: moving directories in svr2
On Fri, Dec 31, 2021 at 01:17:18PM -0500, Dan Cross wrote:
On Fri, Dec 31, 2021, 10:54 AM Adam Thornton
<athornton(a)gmail.com> wrote:
I was there for that and I minded like crazy. It was a hugely bad move
in my opinion. Time has not changed that.
Slightly older, but also slightly more
fundamental to the system, you need
look no farther than Solaris's `/bin/sh` for an illustrated example of the
pros and cons of maintaining backwards compatibility. [snip]
Sun is not the exemplar here: the move from SunOS 4's BSD userland to
Solaris 2's SVR4 broke tons of things. They didn't seem to mind that their
customers had to pay the cost of adaptation. The Linux example is also a bit strange. The move from
e.g. `ifconfig` and
`netstat to `ip` and `ss` required lots of local retooling
I never understood why Linux did that.
12:37 a.m.
New subject: moving directories in svr2
On Fri, Dec 31, 2021, 1:23 PM Larry McVoy <lm(a)mcvoy.com> wrote:
On Fri, Dec 31, 2021 at 01:17:18PM -0500, Dan Cross
wrote:
their
Yeah. I work on Illumos now for Oxide, and it's...fine? But it took a long
time to get there.
When the SunOS->Solaris changeover happened, the thing that really tripped
me up was `awk`. SunOS 4's awk was nawk, but Solaris 2's awk was 7th Ed awk
and lacked functions and so forth. nawk was available as `nawk`, but it
seemed like a gratuitous regression and we had to modify a lot of local
shell scripts and so on.
On Fri, Dec 31, 2021, 10:54 AM Adam Thornton
<athornton(a)gmail.com>
wrote:
> Slightly older, but also slightly more fundamental to the system, you
need
> look no farther than Solaris's
`/bin/sh` for an illustrated example of
the
pros and
cons of maintaining backwards compatibility. [snip]
Sun is not the exemplar here: the move from SunOS 4's BSD userland to
Solaris 2's SVR4 broke tons of things. They didn't seem to mind that customers had to pay the cost of adaptation.
I was there for that and I minded like crazy. It was a hugely bad move
in my opinion. Time has not changed that.
The Linux example is also a bit strange. The move from
e.g. `ifconfig` and
I've been dealing with a couple of Linux machines over the break, and
trying to do things the canonical way instead of running back to the
familiar tools, but some things just aren't supported. `ss` doesn't know
about some of the more exotic address families, like AX.25 and NET/ROM. I
can certainly understand why (talk about a hobbyist niche...) but the irony
is that I had to install `netstat` anyway.
`netstat to `ip` and `ss` required lots of local
retooling
I never understood why Linux did that.
12:29 a.m.
New subject: moving directories in svr2
On 12/31/2021 1:17 PM, Dan Cross wrote:
I suppose one could always install `bash` on Solaris
as a shell lingua
franca, as well
zeus# uname -a
SunOS zeus 5.10 Generic_147441-10 i86pc i386 i86pc
zeus# which bash
/usr/bin/bash
Twas installed by default with Solaris 10, at least later versions that
I know of. I would usually change root's login shell to /bin/bash and
never had an issue.
art k.
6:09 a.m.
New subject: moving directories in svr2
On Fri, Dec 31, 2021 at 01:17:18PM -0500, Dan Cross wrote:
On Fri, Dec 31, 2021, 10:54 AM Adam Thornton
<athornton(a)gmail.com> wrote:
I'm sure that there were people at Sun who *did* care. The story I
had heard was that it was a decision made at the C-suite level, and
was a quid-pro-quo where to get that sweet, sweet, cash from AT&T so
Sun could stay afloat, they had to switch over to System V. (No
matter that Solaris 2 was a major step *backwards* in terms of
performance and stability compared to Sun OS....)
Slightly older, but also slightly more
fundamental to the system, you need
look no farther than Solaris's `/bin/sh` for an illustrated example of the
pros and cons of maintaining backwards compatibility. [snip]
Sun is not the exemplar here: the move from SunOS 4's BSD userland to
Solaris 2's SVR4 broke tons of things. They didn't seem to mind that their
customers had to pay the cost of adaptation. The Linux example is also a bit strange. The move from
e.g. `ifconfig` and
`netstat to `ip` and `ss` required lots of local retooling (I suppose some
distros retain the older tools or let you install them as an option. I
suppose one could always install `bash` on Solaris as a shell lingua
franca, as well). Not to mention systemd. The point is, breaking changes
are introduced all the time.
Are there distros who are no longer supplying ifconfig/netstat/route,
at least as an optional package? That's surprising if so.
All of the kernel interfaces to allow the old-style net-tools packages
to work, as well as the BSD-style ioctls/setsockopt, etc., are still
around, and fully supported. At least on my systems, I still install
net-tools because my finger macros are still used to using ifconfig,
netstat, and friends.
The reason why ip and ss were added was because there was a
significant amount of new functionality that was added to the Linux
networking stack (especially relating to routing and address aliasing)
that couldn't be expressed using the older C programming interfaces as
well as the ifconfig/route shell commands. There were two north star
principles about the new networking interfaces:
1) The old interfaces were always supposed to continue to work, and if
you didn't need the new functionality, there was no reason to use the
newer interfaces.
2) The new interfaces were *supposed* to be a strict superset of the
old interfaces.
If in fact ip and ss don't support AX.25, or other "exotic address
families" --- that's a bug, and should be reported as such. That
being said, if you don't need the fancy new features, there's no
reason to switch away from ifconfig. The whole *point* of the first
principle was that we didn't want to force users to do a forced Python
2.7 -> Python 3 style "long march" migration.
- Ted
3 Jan
3 Jan
7:35 p.m.
New subject: moving directories in svr2
On Fri, Dec 31, 2021 at 7:09 PM Theodore Ts'o <tytso(a)mit.edu> wrote:
Are there _distros_ that don't supply those things? Probably; I really
have no idea. Are there mainstream distros that do not? I doubt it.
However, they have to be installed, which is an additional step that
has to at least be accounted for. At scale, that's a pain: I imagine
that if, say, Google wanted to move to `ip` in lieu of `ifconfig` et
al in prod, it would be a multiyear process, including sunsetting the
older tools. Just identifying every use of `ifconfig` in a shell
script somewhere would be a pretty major undertaking.
On Fri, Dec 31, 2021 at 01:17:18PM -0500, Dan Cross
wrote:
Oh I think we know from first-hand accounts that there were _people_
there who cared. When I wrote "they" earlier I was referring to the
corporation (since those are people now, you know!) which clearly
didn't; or at least made a decision that indicated that they thought
the cost was worth it.
On Fri, Dec 31, 2021, 10:54 AM Adam Thornton
<athornton(a)gmail.com> wrote:
I'm sure that there were people at Sun who *did* care. Slightly older, but also slightly more
fundamental to the system, you need
look no farther than Solaris's `/bin/sh` for an illustrated example of the
pros and cons of maintaining backwards compatibility. [snip]
Sun is not the exemplar here: the move from SunOS 4's BSD userland to
Solaris 2's SVR4 broke tons of things. They didn't seem to mind that their
customers had to pay the cost of adaptation. The story I
had heard was that it was a decision made at the C-suite level, and
was a quid-pro-quo where to get that sweet, sweet, cash from AT&T so
Sun could stay afloat, they had to switch over to System V.
I wouldn't kick AT&T's $100 million out of the house for running System V.
(No
matter that Solaris 2 was a major step *backwards* in terms of
performance and stability compared to Sun OS....)
That it was, at least initially. It's actually pretty good now, but it
took a _long_ time to get there, and the forced incompatibilities
caused a lot of pain in the process, which was my original thesis.
Even now, though, I find some things gratuitously different than other
versions of Unix (network administration, for example). Managing NFS
is still something of a mystery to me.
The Linux
example is also a bit strange. The move from e.g. `ifconfig` and
`netstat to `ip` and `ss` required lots of local retooling (I suppose some
distros retain the older tools or let you install them as an option. I
suppose one could always install `bash` on Solaris as a shell lingua
franca, as well). Not to mention systemd. The point is, breaking changes
are introduced all the time.
Are there distros who are no longer supplying ifconfig/netstat/route,
at least as an optional package? That's surprising if so. All of the kernel interfaces to allow the old-style
net-tools packages
to work, as well as the BSD-style ioctls/setsockopt, etc., are still
around, and fully supported. At least on my systems, I still install
net-tools because my finger macros are still used to using ifconfig,
netstat, and friends.
By virtue of the existence of that additional step, however, there is
an incompatibility with the "older" way of doing things. By no longer
being the default, it is (in perhaps a minor way) a breaking change.
The reason why ip and ss were added was because there
was a
significant amount of new functionality that was added to the Linux
networking stack (especially relating to routing and address aliasing)
that couldn't be expressed using the older C programming interfaces as
well as the ifconfig/route shell commands.
Surely the programmatic interfaces are separate from their realization
in a tool? I can understand the rigidity of some `ioctl` based
interface that's a pain to work around; I find it harder to believe
that plugging some other interface into `ifconfig` in a relatively
graceful way is untractible. Surely, in the limit, one could extend
ifconfig with a new verb as the first positional argument that expands
to the argument set of `ip`: `ifconfig ip address ...` etc. Maybe that
was considered and rejected by the maintainers.
There were two north star
principles about the new networking interfaces:
1) The old interfaces were always supposed to continue to work, and if
you didn't need the new functionality, there was no reason to use the
newer interfaces.
2) The new interfaces were *supposed* to be a strict superset of the
old interfaces.
If in fact ip and ss don't support AX.25, or other "exotic address
families" --- that's a bug, and should be reported as such.
This is an aside, but I'd suggest taking the opposite approach: rip
AX.25 out. It has serious bugs (including, apparently, leaking kernel
memory into transmitted packets?!) that have gone unfixed for years.
My AX.25 machine panics on reboot if there are active netrom
connections, and netrom packet state isn't cleaned up properly. The
maintainers seem to be out to lunch and are unresponsive on
linux-hams.
Personally, I'd prefer to see a FUSE-like mechanism for implementing
things like AX.25 in user-space: that would make it much easier to fix
things like that. On plan9, I would implement AX.25 as a userspace
program that exported a small filesystem and bind-mount it onto /net.
On Unix, a similar thing could be done with Unix-domain sockets and
daemons muxing the radio, but it wouldn't integrate nicely with the
existing tools. That's a problem with doing everything in a tightly
coupled, monolithic way.
That
being said, if you don't need the fancy new features, there's no
reason to switch away from ifconfig. The whole *point* of the first
principle was that we didn't want to force users to do a forced Python
2.7 -> Python 3 style "long march" migration.
Well, you kind of have. It's a small thing to install another package,
sure, but still something that must be done if you want the old tools.
- Dan C.
4 Jan
4 Jan
2:23 a.m.
New subject: moving directories in svr2
On Mon, Jan 03, 2022 at 08:35:24AM -0500, Dan Cross wrote:
Yeah, to be fair, by the time Solaris 2.3 or 2.4 came around, it was
mostly up to par. (Or maybe it was because Moore's law meant that we
didn't care any more. :-)
Well, take a look at the ip-route man page. The BSD route command
assumes fundamentally there is a single routing table that you can
update. In Linux, there are multiple routing tables --- to support
NAT, VRF (virtual routing and forwarding), etc.
I suspect the other consideration was that all of this extra
functionality and complexity were done by folks who wanted the Linux
networking stack to essentially have pretty much all of the
functionality of a Cisco Router. So it made sense to create a new
user interface interface that was inspired by the Cisco IOS
configuration language. Now, if you weren't trying to do something
ala a router in the default-free zone, and were just simply doing what
most leaf nodes on the internet (99.99999% of the hosts), there really
is no reason to need to use the ip/ss interface. For that matter, you
probably don't need to use ifconfig/route --- just let the DHCP client
server of your choice take care of setting up the network, and you're
done.
(No
matter that Solaris 2 was a major step *backwards* in terms of
performance and stability compared to Sun OS....)
That it was, at least initially. It's actually pretty good now, but it
took a _long_ time to get there, and the forced incompatibilities
caused a lot of pain in the process, which was my original thesis.
Even now, though, I find some things gratuitously different than other
versions of Unix (network administration, for example). Managing NFS
is still something of a mystery to me. Are there _distros_ that don't supply those
things? Probably; I really
have no idea. Are there mainstream distros that do not? I doubt it.
However, they have to be installed, which is an additional step that
has to at least be accounted for. At scale, that's a pain: I imagine
that if, say, Google wanted to move to `ip` in lieu of `ifconfig` et
al in prod, it would be a multiyear process, including sunsetting the
older tools. Just identifying every use of `ifconfig` in a shell
script somewhere would be a pretty major undertaking.
Sure, but there's no *point* to sunset the old tools. The git tree
for net-tools is still being actively developed (the last commit was
dated December 12, 2021). And the kernel interfaces are not going to
be disappear, because of the prime directive: Thou Shalt Not Break
Userspace.
The reason why
ip and ss were added was because there was a
significant amount of new functionality that was added to the Linux
networking stack (especially relating to routing and address aliasing)
that couldn't be expressed using the older C programming interfaces as
well as the ifconfig/route shell commands.
Surely the programmatic interfaces are separate from their realization
in a tool? I can understand the rigidity of some `ioctl` based
interface that's a pain to work around; I find it harder to believe
that plugging some other interface into `ifconfig` in a relatively
graceful way is untractible. Surely, in the limit, one could extend
ifconfig with a new verb as the first positional argument that expands
to the argument set of `ip`: `ifconfig ip address ...` etc. Maybe that
was considered and rejected by the maintainers. Well, you kind of have. It's a small thing to
install another package,
sure, but still something that must be done if you want the old tools.
That's a distro-level choice. And for most users, their networking is
automatically brought up using NetworkManager, or some such, so they
probably don't care. And it's not like installing a package is that
painful. I don't see users of say, mysql complaining that they have
to install that package should they want to use it.
I'm old school, and since I generally tend to install BIND, that will
drag in net-tools as dependency, so all my systems have ifconfig
installed. But I'm not going to have a lot of sympathy for someone
who thinks that "sudo apt-get install net-tools" is massive
inconvenience.
- Ted
2:45 a.m.
New subject: moving directories in svr2
On Mon, Jan 3, 2022 at 1:24 PM Theodore Ts'o <tytso(a)mit.edu> wrote:
Well, take a look at the ip-route man page. The BSD route command
assumes fundamentally there is a single routing table that you can
update. In Linux, there are multiple routing tables --- to support
NAT, VRF (virtual routing and forwarding), etc.
The 4.4BSD route command does this. The various BSDs now support multiple
routing tables through an evolved interface...
For machines you manage, sure. It's easy. Try it with the linksys
router you can log into and it starts to get much harder... though
with those loading new firmware isn't super hard.
Warner
On Mon, Jan 03, 2022 at 08:35:24AM -0500, Dan Cross
wrote:
Yeah, to be fair, by the time Solaris 2.3 or 2.4 came around, it was
mostly up to par. (Or maybe it was because Moore's law meant that we
didn't care any more. :-)
For my corner of the world, 2.3 was stable enough to run in production. 2.4
was fast enough :)
(No
matter that Solaris 2 was a major step *backwards* in terms of
performance and stability compared to Sun OS....)
That it was, at least initially. It's actually pretty good now, but it
took a _long_ time to get there, and the forced incompatibilities
caused a lot of pain in the process, which was my original thesis.
Even now, though, I find some things gratuitously different than other
versions of Unix (network administration, for example). Managing NFS
is still something of a mystery to me. Are there
_distros_ that don't supply those things? Probably; I really
have no idea. Are there mainstream distros that do not? I doubt it.
However, they have to be installed, which is an additional step that
has to at least be accounted for. At scale, that's a pain: I imagine
that if, say, Google wanted to move to `ip` in lieu of `ifconfig` et
al in prod, it would be a multiyear process, including sunsetting the
older tools. Just identifying every use of `ifconfig` in a shell
script somewhere would be a pretty major undertaking.
Sure, but there's no *point* to sunset the old tools. The git tree
for net-tools is still being actively developed (the last commit was
dated December 12, 2021). And the kernel interfaces are not going to
be disappear, because of the prime directive: Thou Shalt Not Break
Userspace.
The
reason why ip and ss were added was because there was a
significant amount of new functionality that was added to the Linux
networking stack (especially relating to routing and address aliasing)
that couldn't be expressed using the older C programming interfaces as
well as the ifconfig/route shell commands.
Surely the programmatic interfaces are separate from their realization
in a tool? I can understand the rigidity of some `ioctl` based
interface that's a pain to work around; I find it harder to believe
that plugging some other interface into `ifconfig` in a relatively
graceful way is untractible. Surely, in the limit, one could extend
ifconfig with a new verb as the first positional argument that expands
to the argument set of `ip`: `ifconfig ip address ...` etc. Maybe that
was considered and rejected by the maintainers. I suspect the other consideration was that all of this
extra
functionality and complexity were done by folks who wanted the Linux
networking stack to essentially have pretty much all of the
functionality of a Cisco Router. So it made sense to create a new
user interface interface that was inspired by the Cisco IOS
configuration language. Now, if you weren't trying to do something
ala a router in the default-free zone, and were just simply doing what
most leaf nodes on the internet (99.99999% of the hosts), there really
is no reason to need to use the ip/ss interface. For that matter, you
probably don't need to use ifconfig/route --- just let the DHCP client
server of your choice take care of setting up the network, and you're
done.
True. The vast majority of installs today are just "use DHCP and be happy"
though somebody has to run the dhcp server :)
Well, you kind
of have. It's a small thing to install another package,
sure, but still something that must be done if you want the old tools.
That's a distro-level choice. And for most users, their networking is
automatically brought up using NetworkManager, or some such, so they
probably don't care. And it's not like installing a package is that
painful. I don't see users of say, mysql complaining that they have
to install that package should they want to use it.
I'm old school, and since I generally tend to install BIND, that will
drag in net-tools as dependency, so all my systems have ifconfig
installed. But I'm not going to have a lot of sympathy for someone
who thinks that "sudo apt-get install net-tools" is massive
inconvenience.
3:15 a.m.
New subject: moving directories in svr2
On Mon, Jan 3, 2022 at 3:23 PM Theodore Ts'o <tytso(a)mit.edu> wrote:
Within a single organization, two semi-compatible ways of doing things
seems suboptimal for a number of reasons.
I would suggest that the number of users who want to run MySQL is much
smaller than the number who want to have a functioning network. But
you're right; it's not that hard to adapt. That was kind of the point;
there have been cases where Linux users have adapted to one degree or
another.
On Mon, Jan 03, 2022 at 08:35:24AM -0500, Dan Cross
wrote:
I have some vague memories that we had to do something like double the
RAM in our SPARCstations to make Solaris 2 feel comfortable. At the
time, that was a pretty serious outlay in an academic department.
2.5.1 felt like the first version that was _truly_ usable.
That it was, at least initially. It's
actually pretty good now, but it
took a _long_ time to get there, and the forced incompatibilities
caused a lot of pain in the process, which was my original thesis.
[snip]
Yeah, to be fair, by the time Solaris 2.3 or 2.4 came around, it was
mostly up to par. (Or maybe it was because Moore's law meant that we
didn't care any more. :-) Are there
_distros_ that don't supply those things? Probably; I really
have no idea. Are there mainstream distros that do not? I doubt it.
However, they have to be installed, which is an additional step that
has to at least be accounted for. At scale, that's a pain: I imagine
that if, say, Google wanted to move to `ip` in lieu of `ifconfig` et
al in prod, it would be a multiyear process, including sunsetting the
older tools. Just identifying every use of `ifconfig` in a shell
script somewhere would be a pretty major undertaking.
Sure, but there's no *point* to sunset the old tools. The git tree
for net-tools is still being actively developed (the last commit was
dated December 12, 2021). And the kernel interfaces are not going to
be disappear, because of the prime directive: Thou Shalt Not Break
Userspace. > [snip]
> Surely the programmatic interfaces are separate from their realization
> in a tool? I can understand the rigidity of some `ioctl` based
> interface that's a pain to work around; I find it harder to believe
> that plugging some other interface into `ifconfig` in a relatively
> graceful way is untractible. Surely, in the limit, one could extend
> ifconfig with a new verb as the first positional argument that expands
> to the argument set of `ip`: `ifconfig ip address ...` etc. Maybe that
> was considered and rejected by the maintainers.
Jon Steinhart reminds me that he said largely the same thing last
week; credit where it's due!
Well, take a look at the ip-route man page. The BSD
route command
assumes fundamentally there is a single routing table that you can
update. In Linux, there are multiple routing tables --- to support
NAT, VRF (virtual routing and forwarding), etc.
As Warner mentioned, the BSDs also support multiple routing tables,
with the `route` command. To bring it back to ham radio, I
not-so-humbly offer up
https://wiki.ampr.org/wiki/Setting_up_a_gateway_on_OpenBSD as a rather
pedestrian example of their utility.
I suspect the other consideration was that all of this
extra
functionality and complexity were done by folks who wanted the Linux
networking stack to essentially have pretty much all of the
functionality of a Cisco Router. So it made sense to create a new
user interface interface that was inspired by the Cisco IOS
configuration language.
I would suggest that the latter does not necessarily follow from the
former. But if people want to evolve things, that's ok: after all, the
genesis of this discussion is that we know how to handle breaking
changes.
Now, if you weren't trying to do something
ala a router in the default-free zone, and were just simply doing what
most leaf nodes on the internet (99.99999% of the hosts), there really
is no reason to need to use the ip/ss interface.
Except that's what a lot of documentation tells you to do. :-) Really,
`ip` and `ss` are basically fine. The overriding point is that when
one says on the one hand, "we cannot change the way `..` works because
people's scripts might break..." but we fundamentally change the
default network commands on the other, the former seems to be
self-invalidating.
For that matter, you
probably don't need to use ifconfig/route --- just let the DHCP client
server of your choice take care of setting up the network, and you're
done.
That'll work on a laptop or on my home network (where I set up the
DHCP server). In a large-scale datacenter environment, maybe not so
much.
Well, you kind
of have. It's a small thing to install another package,
sure, but still something that must be done if you want the old tools.
That's a distro-level choice. And for most users, their networking is
automatically brought up using NetworkManager, or some such, so they
probably don't care. And it's not like installing a package is that
painful. I don't see users of say, mysql complaining that they have
to install that package should they want to use it. I'm old school, and since I generally tend to
install BIND, that will
drag in net-tools as dependency, so all my systems have ifconfig
installed. But I'm not going to have a lot of sympathy for someone
who thinks that "sudo apt-get install net-tools" is massive
inconvenience.
Since shells often have custom (and occasionally inconsistent)
handling of `..`, I'm not sure I'd have a lot of sympathy for that one
either. Why one and not the other? I suspect Clem got it right: it has
to do with the perceived value of the change. The networking stuff had
sufficient value that it was worth the cost incurred (which is low,
but non-zero). Perhaps changing `..` just wouldn't have the benefit. I
argue that it's hard to know those things beforehand.
The `apt install net-tools` thing is a red-herring, though: that's
explicitly why I mentioned Google prod. What works on a single system
doesn't necessarily scale to O(10^6) machines supporting O(10^7)
separately running instances of O(10^4) services in O(10) globally
distributed datacenters, that's just a single organization.
- Dan C.
4:26 a.m.
New subject: moving directories in svr2
On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote:
I've seen a number of large-scale data center environments that use
DHCP; and those that don't in Linux-land generally just edit a config
file in /etc/network/interfaces or /etc/network/interfaces.d --- and
then the init scripts would just use "ifup -a" which would bring up
the network either using DHCP or the hard-coded values in
/etc/network/interaces. No need to have sysadmins manually typing
"route add ..." commands except in extreme debugging situations.
I actually suspect the number of users who want to run MySQL is
actually larger than the number of users who need to manually
configure a network using /sbin/ifconfig and /sbin/route.... :-)
For that
matter, you
probably don't need to use ifconfig/route --- just let the DHCP client
server of your choice take care of setting up the network, and you're
done.
That'll work on a laptop or on my home network (where I set up the
DHCP server). In a large-scale datacenter environment, maybe not so
much. That's a
distro-level choice. And for most users, their networking is
automatically brought up using NetworkManager, or some such, so they
probably don't care. And it's not like installing a package is that
painful. I don't see users of say, mysql complaining that they have
to install that package should they want to use it.
I would suggest that the number of users who want to run MySQL is much
smaller than the number who want to have a functioning network. But
you're right; it's not that hard to adapt. That was kind of the point;
there have been cases where Linux users have adapted to one degree or
another. The `apt install net-tools` thing is a red-herring,
though: that's
explicitly why I mentioned Google prod. What works on a single system
doesn't necessarily scale to O(10^6) machines supporting O(10^7)
separately running instances of O(10^4) services in O(10) globally
distributed datacenters, that's just a single organization.
Google prod's easy --- Google maintains its own minimal prod
distribution where a small set of packages (less than a few dozen)
that were originally forked from Debian a number of years ago. So
it's trivial for us, because net-tools is installed by default and
there is **no** engineering upside for us to switch to ip/ss --- so we
haven't. :-)
Similarly, we're still using a *very* old version of bash (having
stayed back across multiple major releases) because it's easier to
stick with an old version of bash and keep up with the security fixes,
than it would be to audit a gazillion shell scripts and shell script
fragments for the various potential and subtle backwards-incomaptible
changes that bash has made over the past decade.
Larry has told a similar story about the advantages of using a "dead"
language like Tcl for Bitkeeper, since he didn't have to deal with
gratuitous version skew problems caused by backwards incomaptible
changes in Perl or Python. But if you manage your own userspace,
including affording to do your own FEDRAMP-compliant security updates,
you can just choose *not* to upgrade to newer versions of bash or
network utilities. Who *says* you have to use bash 5.1? Or switch to
ip/ss?
On the other hand, we did spend untold engineering hours migrating
from Python 2.7 to 3.x (and *wow* was that painful) because in that
case, that was considered less work and more secure than independently
supporting Python 2.7 ad infinitum (also, we have fewer Python
programs than we have shell script fragments in config files like
Makefiles as well actual shell scripts).
So the decision about whether to follow breaking interfaces/language
changes is an engineering decision that's made on a case by case
basis, as it should be for all organizations. In the case of bash and
net-tools, one decision was made. In the case of Python, a difference
decision was made --- although a lot of people really weren't happy
that the Python developers didn't appreciate the cost of breaking
backwards compatibility (or rather, they decided that they didn't care
and prioritized their own convenience over that of their users).
This is why I'm a big supporter of Linus's, "Thou Shalt Not Break
Userspace" rule; backwards compatibility at the lowest levels is
important! I'd draw that line higher than some people, but hey, if
you don't like the instability of Python, you can do what Bitkeeper
did and base your extension language/scripts on something like Tcl
instead.
- Ted
P.S. If you want to see the horror of trying to support a Python
program that has to be able to run on a wide variety of Linux distros,
running different versions of Python (from RHEL 6 and Python 2.3 up to
the newest bleeding edge Python 3.x), take a look at the Google's
gcloud program. Alas, unlike the Google prod environment, we can't
dictate what distro our Cloud customers might choose to use.
The gcloud command (part of the Google Cloud SDK) has to play all
sorts of portability games, and people need to continually test across
a wide range of Python versions and Linux distros to provide assurance
that it continues to correctly as new features are added and bugs are
fixed. I *completely* understand why Larry chose to implement
Bitkeeper extensions in Tcl, since it avoids this problem.
Bt yeah, it's why I wouldn't want to change dot-dot, since having seen
the pain the Python developers inflected on me, I wouldn't want to
inflict it on others...
5:10 a.m.
New subject: moving directories in svr2
On Mon, Jan 3, 2022 at 5:26 PM Theodore Ts'o <tytso(a)mit.edu> wrote:
Touche.
Recall that I was saying that the effort if Google decided, for
whatever reason, that it wanted to switch, would be multiyear. Giving
into the inertia of staying where Google is today is the easy part. As
you yourself acknowledge, the engineering effort required to switch to
the newfangled tools is non-zero. However, this creates a conundrum;
if Google wanted (again for whatever reason) to avail itself of the
new functionality provided by the new tools, it now has a choice:
either roll the new tools out, or extend the existing tools to provide
the required functionality. This is not something I would describe as
"easy." Sure, rolling the new commands out to machines would be
relatively straight-forward (though I've worked on those systems and
getting things into the production image was non-trivial politically,
if not technically), but transitioning to use them not so much.
This sort of begs the question: why not default to shipping the old
tools (route, netstat, ifconfig) and let people install the _new_
tools if they want their Linux machine to behave like a cisco router?
Google made this choice and sure: as you say, this is a distro-level
question. But it sure seems like the broad consensus around the major
distros is the opposite.
On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross
wrote:
I've seen a number of large-scale data center environments that use
DHCP; and those that don't in Linux-land generally just edit a config
file in /etc/network/interfaces or /etc/network/interfaces.d --- and
then the init scripts would just use "ifup -a" which would bring up
the network either using DHCP or the hard-coded values in
/etc/network/interaces. No need to have sysadmins manually typing
"route add ..." commands except in extreme debugging situations.
So, would you say that those are...supported by a bunch of shell
scripts that would have to be changed if those systems migrated to the
new tools for whatever reason? :-D
For that
matter, you
probably don't need to use ifconfig/route --- just let the DHCP client
server of your choice take care of setting up the network, and you're
done.
That'll work on a laptop or on my home network (where I set up the
DHCP server). In a large-scale datacenter environment, maybe not so
much. I would
suggest that the number of users who want to run MySQL is much
smaller than the number who want to have a functioning network. But
you're right; it's not that hard to adapt. That was kind of the point;
there have been cases where Linux users have adapted to one degree or
another.
I actually suspect the number of users who want to run MySQL is
actually larger than the number of users who need to manually
configure a network using /sbin/ifconfig and /sbin/route.... :-) The `apt
install net-tools` thing is a red-herring, though: that's
explicitly why I mentioned Google prod. What works on a single system
doesn't necessarily scale to O(10^6) machines supporting O(10^7)
separately running instances of O(10^4) services in O(10) globally
distributed datacenters, that's just a single organization.
Google prod's easy --- Google maintains its own minimal prod
distribution where a small set of packages (less than a few dozen)
that were originally forked from Debian a number of years ago. So
it's trivial for us, because net-tools is installed by default and
there is **no** engineering upside for us to switch to ip/ss --- so we
haven't. :-) Similarly, we're still using a *very* old version
of bash (having
stayed back across multiple major releases) because it's easier to
stick with an old version of bash and keep up with the security fixes,
than it would be to audit a gazillion shell scripts and shell script
fragments for the various potential and subtle backwards-incomaptible
changes that bash has made over the past decade.
This is an aside, but one of my continual gripes about Google was that
it took monumental efforts to deprecate anything (lookin' at you, disk
device names), often because no one had paid attention to trying to
maintain portability between different systems, let alone different
versions of the same system.
But bear in mind that even Google's monorepo doesn't exist in a
hermetic bubble: third party code and upstream dependencies for
externally imposed requirements; in some cases, that forces upgrades
of libraries, toolchains, and yes, even userspace tools.
Incidentally, this was one of the big arguments for getting the Rust
toolchain pulled into google3: even though Google wasn't authoring
first-party Rust code for prod, we _knew_ there were third-party
dependencies that would force us to have a toolchain for the same
reason we have a FORTRAN toolchain. That I was one of the people who
benefited from a Rust toolchain in g3 wasn't entirely coincidental, as
our team finally forced language tools' hands there.
Larry has told a similar story about the advantages of
using a "dead"
language like Tcl for Bitkeeper, since he didn't have to deal with
gratuitous version skew problems caused by backwards incomaptible
changes in Perl or Python. But if you manage your own userspace,
including affording to do your own FEDRAMP-compliant security updates,
you can just choose *not* to upgrade to newer versions of bash or
network utilities. Who *says* you have to use bash 5.1? Or switch to
ip/ss?
The interesting thing about this is that it ignores the unseen costs
of staying with the older versions of things. The kernel was a great
example, actually, for reasons you know well (though perhaps not super
appropriate for discussion here). This creates a negative feedback
loop: we can't upgrade anything because something will break, so we
stay with the old stuff until forced to move.
On the other hand, we did spend untold engineering
hours migrating
from Python 2.7 to 3.x (and *wow* was that painful) because in that
case, that was considered less work and more secure than independently
supporting Python 2.7 ad infinitum (also, we have fewer Python
programs than we have shell script fragments in config files like
Makefiles as well actual shell scripts).
...and also because third-party dependencies started dropping support
for Python 2.
I would love to see language stats for the claim that there's more
shell scripts than Python over there. I'd be mildly though perhaps not
completely surprised if that were true. I suppose if "shell script
fragments" includes `a && b` then I could see it. I'm not cleared for
that anymore though. But I also remember when /usr/bin/python2.4 was
really python2.7. :-(
So the decision about whether to follow breaking
interfaces/language
changes is an engineering decision that's made on a case by case
basis, as it should be for all organizations. In the case of bash and
net-tools, one decision was made.
Inertia is a hell of a drug.
In the case of Python, a difference
decision was made --- although a lot of people really weren't happy
that the Python developers didn't appreciate the cost of breaking
backwards compatibility (or rather, they decided that they didn't care
and prioritized their own convenience over that of their users).
This is why I'm a big supporter of Linus's, "Thou Shalt Not Break
Userspace" rule; backwards compatibility at the lowest levels is
important! I'd draw that line higher than some people, but hey, if
you don't like the instability of Python, you can do what Bitkeeper
did and base your extension language/scripts on something like Tcl
instead.
I guess what I'm saying is that "thou shalt not break userspace" is a
bit of a misnomer; perhaps it should be rephrased as, "thou shalt not
change the kernel in such a way that userspace code no longer works."
He is, after all, referring specifically to the kernel interface,
right? But just as sufficiently advanced technology is said to be
indistinguishable from magic, a missing command like `ifconfig`
_might_ be indistinguishable from an incompatible system interface as
far as a user is concerned.
P.S. If you want to see the horror of trying to
support a Python
program that has to be able to run on a wide variety of Linux distros,
running different versions of Python (from RHEL 6 and Python 2.3 up to
the newest bleeding edge Python 3.x), take a look at the Google's
gcloud program. Alas, unlike the Google prod environment, we can't
dictate what distro our Cloud customers might choose to use.
The gcloud command (part of the Google Cloud SDK) has to play all
sorts of portability games, and people need to continually test across
a wide range of Python versions and Linux distros to provide assurance
that it continues to correctly as new features are added and bugs are
fixed. I *completely* understand why Larry chose to implement
Bitkeeper extensions in Tcl, since it avoids this problem.
No thank you! I'm good. :-)
Bt yeah, it's why I wouldn't want to change
dot-dot, since having seen
the pain the Python developers inflected on me, I wouldn't want to
inflict it on others...
Hmm. I wonder if I have any 386 a.out binaries floating around. :-)
- Dan C.
9:45 p.m.
New subject: moving directories in svr2
On 1/3/22 5:26 PM, Theodore Ts'o wrote:
you can just choose *not* to upgrade to newer versions
of bash or
network utilities. Who *says* you have to use bash 5.1? Or switch to
ip/ss?
It's always a trade-off, isn't it? If you don't use the current version of
something, you assume the burden of maintenance. As we've seen, vendors
vary as to the attention they give old versions of software (e.g., bash-4.2
still shipping as part of RHEL 7 a decade after bash-4.3 was released).
Google can make that choice for itself, I suppose.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU chet(a)case.edu http://tiswww.cwru.edu/~chet/
10 Jan
10 Jan
1:28 a.m.
New subject: moving directories in svr2
On Mon, Jan 03, 2022 at 05:26:33PM -0500, Theodore Ts'o wrote:
Larry has told a similar story about the advantages of
using a "dead"
language like Tcl for Bitkeeper, since he didn't have to deal with
gratuitous version skew problems caused by backwards incomaptible
changes in Perl or Python.
Well, we also made very substantial changes to the Tcl source tree,
resulting in http://little-lang.org which tosses Tcl's tortured
"can't decide if I'm lisp or not" syntax in favor of something
that looks like a super pleasant superset of C.
4 Jan
4 Jan
5:21 a.m.
New subject: moving directories in svr2
On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote:
I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1 was quite
usable and stable.
Also by this time, the hardware was going in directions that SunOS wouldn't keep up
with.
On Mon, Jan 3, 2022 at 3:23 PM Theodore Ts'o
<tytso(a)mit.edu> wrote:
Yeah, to be
fair, by the time Solaris 2.3 or 2.4 came around, it was
mostly up to par. (Or maybe it was because Moore's law meant that we
didn't care any more. :-)
I have some vague memories that we had to do something like double the
RAM in our SPARCstations to make Solaris 2 feel comfortable. At the
time, that was a pretty serious outlay in an academic department.
2.5.1 felt like the first version that was _truly_ usable.
5:37 a.m.
New subject: moving directories in svr2
2.5.1 was the first Solaris that didn't often make me scream that I wanted
SunOS 4.1 back.
Adam
On Mon, Jan 3, 2022 at 4:32 PM Doug McIntyre <merlyn(a)geeks.org> wrote:
On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross
wrote:
I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1 was
quite usable and stable.
Also by this time, the hardware was going in directions that SunOS
wouldn't keep up with.
On Mon, Jan 3, 2022 at 3:23 PM Theodore Ts'o
<tytso(a)mit.edu> wrote:
Yeah, to
be fair, by the time Solaris 2.3 or 2.4 came around, it was
mostly up to par. (Or maybe it was because Moore's law meant that we
didn't care any more. :-)
I have some vague memories that we had to do something like double the
RAM in our SPARCstations to make Solaris 2 feel comfortable. At the
time, that was a pretty serious outlay in an academic department.
2.5.1 felt like the first version that was _truly_ usable. 
8:49 p.m.
New subject: moving directories in svr2
Oh, that reminded me of SunOS 4.0 that introduced streams. Broke
So I used to pine for 3.5!
Agree re 2.4/2.5.1 having gotten an O/S back to being solid and very usable
-- IIRC we had customers query whether they had good distribution media,
because the "patch" directory was empty. No patches were introduced during
beta.
On Tue, 4 Jan 2022, 07:38 Adam Thornton, <athornton(a)gmail.com> wrote:
2.5.1 was the first Solaris that didn't often
make me scream that I wanted
SunOS 4.1 back.
Adam
On Mon, Jan 3, 2022 at 4:32 PM Doug McIntyre <merlyn(a)geeks.org> wrote:
> On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote:
> > On Mon, Jan 3, 2022 at 3:23 PM Theodore Ts'o <tytso(a)mit.edu> wrote:
>
> > > Yeah, to be fair, by the time Solaris 2.3 or 2.4 came around, it was
> > > mostly up to par. (Or maybe it was because Moore's law meant that we
> > > didn't care any more. :-)
> >
> > I have some vague memories that we had to do something like double the
> > RAM in our SPARCstations to make Solaris 2 feel comfortable. At the
> > time, that was a pretty serious outlay in an academic department.
> > 2.5.1 felt like the first version that was _truly_ usable.
>
> I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1 was
> quite usable and stable.
> Also by this time, the hardware was going in directions that SunOS
> wouldn't keep up with.
>
>
>
5:44 a.m.
New subject: moving directories in svr2
On Mon, Jan 03, 2022 at 05:21:51PM -0600, Doug McIntyre wrote:
On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross
wrote:
I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1 was quite
usable and stable.
Also by this time, the hardware was going in directions that SunOS wouldn't keep up
with.
Yeah, Doug is right, SunOS was pretty simple, it didn't really take advantage
of SMP, Greg Limes tried to thread it but it was too big a job for one guy.
That's not to say that SunOS couldn't have evolved into SMP, I'm 100%
sure it could have. It just didn't. It's a shame.
On Mon, Jan 3, 2022 at 3:23 PM Theodore Ts'o
<tytso(a)mit.edu> wrote:
Yeah, to
be fair, by the time Solaris 2.3 or 2.4 came around, it was
mostly up to par. (Or maybe it was because Moore's law meant that we
didn't care any more. :-)
I have some vague memories that we had to do something like double the
RAM in our SPARCstations to make Solaris 2 feel comfortable. At the
time, that was a pretty serious outlay in an academic department.
2.5.1 felt like the first version that was _truly_ usable. 
5:56 a.m.
New subject: SMP: BSD vs System V (once was: moving directories in svr2)
On Monday, 3 January 2022 at 15:44:11 -0800, Larry McVoy wrote:
On Mon, Jan 03, 2022 at 05:21:51PM -0600, Doug
McIntyre wrote:
An interesting question. I had always thought that SMP was (one of?)
the technical reasons why Sun moved from a BSD to a System V base.
Since then, of course, we've done lots of work on SMP support for at
least FreeBSD. Does anybody have an overview of how good the support
is compared to modern Solaris? Is there any intrinsic reason why one
should be better than the other?
Greg
--
Sent from my desktop computer.
Finger grog(a)lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php
On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan
Cross wrote:
I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1 was quite
usable and stable.
Also by this time, the hardware was going in directions that SunOS wouldn't keep up
with.
Yeah, Doug is right, SunOS was pretty simple, it didn't really take advantage
of SMP, Greg Limes tried to thread it but it was too big a job for one guy.
That's not to say that SunOS couldn't have evolved into SMP, I'm 100%
sure it could have. It just didn't. It's a shame.
8 Jan
8 Jan
1:01 a.m.
New subject: SMP: BSD vs System V (once was: moving directories in svr2)
On Mon, Jan 3, 2022 at 5:03 PM Greg 'groggy' Lehey <grog(a)lemis.com>
wrote:
On Monday, 3 January 2022 at 15:44:11 -0800, Larry
McVoy wrote:
So, there were several groups that added SMP to BSD or SunOS.
Solbourne's OS/MP added MP to SunOS 4.0 as first ASMP (one CPU did all the
system calls, but jobs could run on other CPUs) and later as SMP (first as
any
CPU could run the system calls, but there was global lock and later each
subsystem had a lock that it ran with). Later versions improved locking
granularity
by pushing locks down and making things finer grained. SunOS was a 4.3BSD
with
its own VM system that was well suited for locking.
There were other efforts to do this, but none of them made it back to the
Berkeley
mother ship, so 4.4BSD shipped w/o MP support in any real sense in 1993.
System V got MP when a consortium of vendors added it to the 4.0 release
(that
didn't include sun). By 1992 this was rolled into the 4.2 release that AT&T
did
with Novell. This is what would serve as the basis for Sun's Solaris
product line.
FreeBSD, NetBSD, OpenBSD and Dragonfly BSD have all done MP in different
ways since then, of course, and Linux has added MP as well early on.
So in a very real sense, Sun was in a position where it had to re-do the
work
that David Barak and others did at Solbourne to lock the SunOS kernel (work
which really took years to complete and stabilize), or they had to go with
a solution
that was already developed. AT&T had that with System V 4.x, and Berkeley
didn't
have an equivalent set of functionality for them to draw from. I think from
a PHB
perspective, the decision was easy, mostly because they vastly
under-estimated
the maturity of System Vr4.2's MP support (but I wasn't in the room: I was
at Solbourne
which would never have licensed its OS/MP to Sun due to the... competitive
atmosphere
at the time and likely NIH inside of Sun for adopting that).
Warner
On Mon, Jan 03, 2022 at 05:21:51PM -0600, Doug
McIntyre wrote:
> On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote:
> I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1
was
quite usable and stable.
> Also by this time, the hardware was going in
directions that SunOS
wouldn't keep up with.
Yeah, Doug is right, SunOS was pretty simple, it didn't really take
advantage
of SMP, Greg Limes tried to thread it but it was
too big a job for one
guy.
That's not to say that SunOS couldn't have evolved into SMP, I'm 100%
sure it could have. It just didn't. It's a shame.
An interesting question. I had always thought that SMP was (one of?)
the technical reasons why Sun moved from a BSD to a System V base.
Since then, of course, we've done lots of work on SMP support for at
least FreeBSD. Does anybody have an overview of how good the support
is compared to modern Solaris? Is there any intrinsic reason why one
should be better than the other?
9 Jan
9 Jan
11:31 p.m.
New subject: SMP: BSD vs System V (once was: moving directories in svr2)
There were others that also did Unix SMP (some on BSD). Encore offering
BSD, AT&T or Mach (their storage arrays contained a core cluster of 2 SMP
nodes, later bought by Sun); Sequent; and Pyramid dualPort OS/x around
1985/87.
Pyramid had dual-CPU 90Mx/98x and I think a single lock (memory fades a
bit). Later more fine-grained around the time of the 1-CPU 9810 up to 4-CPU
9845. Before eventually going to MIPS CPU SMPs, then adding MPP to the MIPS
range.
IIRC, this was on a mostly-BSD 4.2/4.3 base(?) when I worked in the Pyramid
team producing their POSIX threads library & parallel debugger (late 80s).
Although Pyramid did have their ATT "unverse" incorporated into the same
Unix, hence dualPort. So there was a bunch of SVR3/4 support included:
extra set of syscalls; u.u_universe to select which; conditional symbolic
links using u.u_universe to resolve to UCB or ATT paths for lib & bin dirs;
merged TTY driver with a superset of stty attributes; etc.
Apollo Domain had something similar to conditional symbolic links, but
expanding environment variables to determine the target path. Different
flexibility/overhead tradeoff.
I wonder if any dualPort or DC/OSx Pyramid source survives...
or the old Australian promo poster from PTC BURP, where I got elected the
PHB, standing like a dork at the console of a 9840 cabinet (I think I was
the only one in a long sleeve shirt that day, and had an emergency tie at
the back of my desk drawer, so...)
On Tue, 4 Jan 2022, 08:04 Greg 'groggy' Lehey, <grog(a)lemis.com> wrote:
On Monday, 3 January 2022 at 15:44:11 -0800, Larry
McVoy wrote:
On Mon, Jan 03, 2022 at 05:21:51PM -0600, Doug
McIntyre wrote:
> On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote:
> I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1
was
quite usable and stable.
> Also by this time, the hardware was going in
directions that SunOS
wouldn't keep up with.
Yeah, Doug is right, SunOS was pretty simple, it didn't really take
advantage
of SMP, Greg Limes tried to thread it but it was
too big a job for one
guy.
That's not to say that SunOS couldn't have evolved into SMP, I'm 100%
sure it could have. It just didn't. It's a shame.
An interesting question. I had always thought that SMP was (one of?)
the technical reasons why Sun moved from a BSD to a System V base.
Since then, of course, we've done lots of work on SMP support for at
least FreeBSD. Does anybody have an overview of how good the support
is compared to modern Solaris? Is there any intrinsic reason why one
should be better than the other?
Greg
--
Sent from my desktop computer.
Finger grog(a)lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php
13 Jan
13 Jan
8:35 a.m.
New subject: SMP: BSD vs System V (once was: moving directories in svr2)
On Mon, Jan 3, 2022 at 5:03 PM Greg 'groggy' Lehey <grog(a)lemis.com>
wrote:
On Monday, 3 January 2022 at 15:44:11 -0800, Larry
McVoy wrote:
Relevant proceedings
https://www.usenix.org/legacy/publications/library/proceedings/sa92/
On Mon, Jan 03, 2022 at 05:21:51PM -0600, Doug
McIntyre wrote:
> On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan Cross wrote:
> I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1
was
quite usable and stable.
> Also by this time, the hardware was going in
directions that SunOS
wouldn't keep up with.
Yeah, Doug is right, SunOS was pretty simple, it didn't really take
advantage
of SMP, Greg Limes tried to thread it but it was
too big a job for one
guy.
That's not to say that SunOS couldn't have evolved into SMP, I'm 100%
sure it could have. It just didn't. It's a shame.
An interesting question. I had always thought that SMP was (one of?)
the technical reasons why Sun moved from a BSD to a System V base.
Since then, of course, we've done lots of work on SMP support for at
least FreeBSD. Does anybody have an overview of how good the support
is compared to modern Solaris? Is there any intrinsic reason why one
should be better than the other?
Greg
--
Sent from my desktop computer.
Finger grog(a)lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php
4 Jan
4 Jan
5:56 a.m.
New subject: moving directories in svr2
On Mon, Jan 3, 2022, 4:44 PM Larry McVoy <lm(a)mcvoy.com> wrote:
On Mon, Jan 03, 2022 at 05:21:51PM -0600, Doug
McIntyre wrote:
Solbourne had it's OS/MP which did do SMP with a subsystem locking
strategy. This worked reasonably well for the time. So it was quite
possible. Solbourne died, though because it couldn't get Solaris sources
soon enough to do a port that mattered...
Warner
On Mon, Jan 03, 2022 at 04:15:08PM -0500, Dan
Cross wrote:
I'd agree, 2.4 was pretty slow and chunky, 2.5 was alright, but 2.5.1
was
quite usable and stable.
On Mon, Jan 3, 2022 at 3:23 PM Theodore Ts'o
<tytso(a)mit.edu> wrote:
Yeah, to
be fair, by the time Solaris 2.3 or 2.4 came around, it was
mostly up to par. (Or maybe it was because Moore's law meant that we
didn't care any more. :-)
I have some vague memories that we had to do something like double the
RAM in our SPARCstations to make Solaris 2 feel comfortable. At the
time, that was a pretty serious outlay in an academic department.
2.5.1 felt like the first version that was _truly_ usable. Also by this time, the hardware was going in
directions that SunOS
wouldn't keep up with.
Yeah, Doug is right, SunOS was pretty simple, it didn't really take
advantage
of SMP, Greg Limes tried to thread it but it was too big a job for one guy.
That's not to say that SunOS couldn't have evolved into SMP, I'm 100%
sure it could have. It just didn't. It's a shame.
8:28 a.m.
New subject: moving directories in svr2
On Mon, Jan 03, 2022 at 03:44:11PM -0800, Larry McVoy wrote:
On Mon, Jan 03, 2022 at 05:21:51PM -0600, Doug
McIntyre wrote:
I would have thought that if we consider the amount of engineering
resources to that was invested to get from Solaris 2.0 to 2.5.1, if
that had instead been invested into making SunOS a scalable SMP OS,
that it would have been doable. Do you think that's fair?
Of course, that's assuming that Sun could have stayed afloat without
that injection of cash from AT&T....
- Ted
I'd agree, 2.4 was pretty slow and chunky,
2.5 was alright, but 2.5.1 was quite usable and stable.
Also by this time, the hardware was going in directions that SunOS wouldn't keep up
with.
Yeah, Doug is right, SunOS was pretty simple, it didn't really take advantage
of SMP, Greg Limes tried to thread it but it was too big a job for one guy.
That's not to say that SunOS couldn't have evolved into SMP, I'm 100%
sure it could have. It just didn't. It's a shame.
8:42 a.m.
New subject: moving directories in svr2
On Mon, Jan 03, 2022 at 09:28:02PM -0500, Theodore Ts'o wrote:
On Mon, Jan 03, 2022 at 03:44:11PM -0800, Larry McVoy
wrote:
Yes, absolutely. I worked in the kernel group in building 5. That was
pretty much the best group of people I have been a part of. That team
could have done anything, SMP was not a problem for them. They for sure
could have made SunOS scale. The people who didn't leave were the people
who made Solaris work.
That said, I have to give credit to the group of people I built who
did BitKeeper. I'd stand them up against the Sun kernel team and they
would win. Smaller group, stellar bunch of people.
I'm happy that I got to be part of both teams.
On Mon, Jan 03, 2022 at 05:21:51PM -0600, Doug
McIntyre wrote:
I would have thought that if we consider the amount of engineering
resources to that was invested to get from Solaris 2.0 to 2.5.1, if
that had instead been invested into making SunOS a scalable SMP OS,
that it would have been doable. Do you think that's fair? I'd agree, 2.4 was pretty slow and chunky,
2.5 was alright, but 2.5.1 was quite usable and stable.
Also by this time, the hardware was going in directions that SunOS wouldn't keep up
with.
Yeah, Doug is right, SunOS was pretty simple, it didn't really take advantage
of SMP, Greg Limes tried to thread it but it was too big a job for one guy.
That's not to say that SunOS couldn't have evolved into SMP, I'm 100%
sure it could have. It just didn't. It's a shame. 
3:28 p.m.
New subject: Mythical Distress Sale (was Re: moving directories in svr2)
On 1/3/2022 6:28 PM, Theodore Ts'o wrote:
Of course, that's assuming that Sun could have
stayed afloat without
that injection of cash from AT&T....
What causes you to assert that Sun was at risk of not staying afloat?
Sun went from $0/yr to over $1B/yr in revenue between 1982 and 1988, the
prototype for what people now call "unicorns".
Between 1985 and 1989 Sun grew at a compounded rate of 145% a year, and
according to Forbes was the fastest growing company in the US in those
years.
Doesn't sound like a company foundering to me, certainly not in 1987 and
1988. Didn't sound like it to AT&T either, who wanted in on the action
and so bought a bunch of Sun stock on terms very favorable to Sun (and
financially speaking of benefit to both companies when AT&T divested
some years later).
The injection of capital was certainly useful to Sun, not because of
distress or failure, but because it was bursting at the seams from all
the growth. Sun was going to get that capital without AT&T by going to
the market anyway, that it was able to do so on more favorable terms
with an already established partner was literally an example of the rich
getting richer. The partnership to inject SunOS technologies, do SVR4,
harmonize the various UNIX flavors had already been committed and
launched some months before the investment occurred and wasn't
contingent upon it.
They're not unrelated of course, the investment occurred in the context
of the already committed partnership. And if you examine the announced
expectations of that partnership it included some strong dependencies on
Sun products and technologies by AT&T in both the near and long term.
The gestalt of the investment was that it was a consequence of "well, if
we're already doing all this, then..."
Certainly the later transitions in Sun's products had lots of issues.
But lessons aren't gained from "well, they meant well, but, poor sods,
they were barely staying alive" especially when the premise isn't even
remotely accurate.
It's a much more interesting examination to consider: "they had agency,
they made choices, the context was <pretty complex>, why that and not
this, what was the alternative, etc." Since we can have the facts, why
not premise the discussions on those?
9:17 p.m.
New subject: Mythical Distress Sale (was Re: moving directories in svr2)
Rob, you've painted this picture before and it just doesn't match up
at all with what I saw. I was there. Ken Okin paid me for 6 months to
try and convince the execs to not go to SVR4. If it was all sweetness
and light, why did he do that?
You make it sound like it was a nice friendly deal. It was $200M of
Sun stock at 35% over market rate. Who does that just to be friends?
You say you could have gone to market and gotten that, well, sure,
but not at 35% over market.
SunOS was winning all the deals, as you point out, Sun was growing
like crazy. I did lots and lots of customer presentations and not once
did I hear "oh, when are you guys going to standardize on System V?"
Quite the opposite in fact. I was doing a talk at the Moscone center
on the first Sun cluster that I had built, Scott refused to let me ship
it with SunOS, so I was being a good soldier and talking up Solaris.
Over and over and over I was asked why we were forcing people to use
an obviously worse OS and I finally lost it and said "I know, I have
everything working in SunOS but they won't let me ship it."
I was on tape. Okin listened to the tape and said "get every copy of
those tapes and destroy them". Not exactly the friendly everyone
agreeing picture you paint. Not remotely like that.
Rob, I lived through that time. One of my close friends, John Pope,
did the bring up. He felt alienated from all the other kernel people
because we all loved SunOS and we hated Solaris, it made zero sense to
go that far backward. And look what it got you. Sun is gone.
If you could have gone to market and gotten the money, you would
have. Sun was killing it, everyone wanted a Sun over every other
workstation, in the SunOS days, every open source thing just built
on Suns. Everyone else had to twiddle the makefiles and the source.
Your story that people wanted a standard just doesn't hold up when
you were the standard. It also doesn't hold up when every single
customer I talked to (and I talked to them at least twice a month
in formal presentations and frequently more like twice a week,
the sales people loved me) never asked for SVR4. Not once did that
come up. And when SVR4 was being pushed on them, 100% of them
pushed back and wanted SunOS.
On Tue, Jan 04, 2022 at 01:28:20AM -0800, Rob Gingell wrote:
On 1/3/2022 6:28 PM, Theodore Ts'o wrote:
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
Of course, that's assuming that Sun could
have stayed afloat without
that injection of cash from AT&T....
What causes you to assert that Sun was at risk of not staying afloat?
Sun went from $0/yr to over $1B/yr in revenue between 1982 and 1988, the
prototype for what people now call "unicorns".
Between 1985 and 1989 Sun grew at a compounded rate of 145% a year, and
according to Forbes was the fastest growing company in the US in those
years.
Doesn't sound like a company foundering to me, certainly not in 1987 and
1988. Didn't sound like it to AT&T either, who wanted in on the action and
so bought a bunch of Sun stock on terms very favorable to Sun (and
financially speaking of benefit to both companies when AT&T divested some
years later).
The injection of capital was certainly useful to Sun, not because of
distress or failure, but because it was bursting at the seams from all the
growth. Sun was going to get that capital without AT&T by going to the
market anyway, that it was able to do so on more favorable terms with an
already established partner was literally an example of the rich getting
richer. The partnership to inject SunOS technologies, do SVR4, harmonize the
various UNIX flavors had already been committed and launched some months
before the investment occurred and wasn't contingent upon it.
They're not unrelated of course, the investment occurred in the context of
the already committed partnership. And if you examine the announced
expectations of that partnership it included some strong dependencies on Sun
products and technologies by AT&T in both the near and long term. The
gestalt of the investment was that it was a consequence of "well, if we're
already doing all this, then..."
Certainly the later transitions in Sun's products had lots of issues. But
lessons aren't gained from "well, they meant well, but, poor sods, they were
barely staying alive" especially when the premise isn't even remotely
accurate.
It's a much more interesting examination to consider: "they had agency, they
made choices, the context was <pretty complex>, why that and not this, what
was the alternative, etc." Since we can have the facts, why not premise the
discussions on those? 
9:26 p.m.
New subject: Mythical Distress Sale (was Re: moving directories in svr2)
OK, serious question. Why did Sun "sell out" to AT&T if they could
have raised capital in the market? Did the executive team just not
care about what moving to System V would mean? Or did they not understand
it?
How desperate were they? And why were they so desparate? Were there
other alternatives they could have pursued?
I too lived through those times, from the outside, and it was indeed
a shocker when they moved from SunOS to Solaris.
Thanks,
Arnold
Larry McVoy <lm(a)mcvoy.com> wrote:
Rob, you've painted this picture before and it
just doesn't match up
at all with what I saw. I was there. Ken Okin paid me for 6 months to
try and convince the execs to not go to SVR4. If it was all sweetness
and light, why did he do that?
You make it sound like it was a nice friendly deal. It was $200M of
Sun stock at 35% over market rate. Who does that just to be friends?
You say you could have gone to market and gotten that, well, sure,
but not at 35% over market.
SunOS was winning all the deals, as you point out, Sun was growing
like crazy. I did lots and lots of customer presentations and not once
did I hear "oh, when are you guys going to standardize on System V?"
Quite the opposite in fact. I was doing a talk at the Moscone center
on the first Sun cluster that I had built, Scott refused to let me ship
it with SunOS, so I was being a good soldier and talking up Solaris.
Over and over and over I was asked why we were forcing people to use
an obviously worse OS and I finally lost it and said "I know, I have
everything working in SunOS but they won't let me ship it."
I was on tape. Okin listened to the tape and said "get every copy of
those tapes and destroy them". Not exactly the friendly everyone
agreeing picture you paint. Not remotely like that.
Rob, I lived through that time. One of my close friends, John Pope,
did the bring up. He felt alienated from all the other kernel people
because we all loved SunOS and we hated Solaris, it made zero sense to
go that far backward. And look what it got you. Sun is gone.
If you could have gone to market and gotten the money, you would
have. Sun was killing it, everyone wanted a Sun over every other
workstation, in the SunOS days, every open source thing just built
on Suns. Everyone else had to twiddle the makefiles and the source.
Your story that people wanted a standard just doesn't hold up when
you were the standard. It also doesn't hold up when every single
customer I talked to (and I talked to them at least twice a month
in formal presentations and frequently more like twice a week,
the sales people loved me) never asked for SVR4. Not once did that
come up. And when SVR4 was being pushed on them, 100% of them
pushed back and wanted SunOS.
On Tue, Jan 04, 2022 at 01:28:20AM -0800, Rob Gingell wrote:
On 1/3/2022 6:28 PM, Theodore Ts'o wrote:
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm Of course, that's assuming that Sun could
have stayed afloat without
that injection of cash from AT&T....
What causes you to assert that Sun was at risk of not staying afloat?
Sun went from $0/yr to over $1B/yr in revenue between 1982 and 1988, the
prototype for what people now call "unicorns".
Between 1985 and 1989 Sun grew at a compounded rate of 145% a year, and
according to Forbes was the fastest growing company in the US in those
years.
Doesn't sound like a company foundering to me, certainly not in 1987 and
1988. Didn't sound like it to AT&T either, who wanted in on the action and
so bought a bunch of Sun stock on terms very favorable to Sun (and
financially speaking of benefit to both companies when AT&T divested some
years later).
The injection of capital was certainly useful to Sun, not because of
distress or failure, but because it was bursting at the seams from all the
growth. Sun was going to get that capital without AT&T by going to the
market anyway, that it was able to do so on more favorable terms with an
already established partner was literally an example of the rich getting
richer. The partnership to inject SunOS technologies, do SVR4, harmonize the
various UNIX flavors had already been committed and launched some months
before the investment occurred and wasn't contingent upon it.
They're not unrelated of course, the investment occurred in the context of
the already committed partnership. And if you examine the announced
expectations of that partnership it included some strong dependencies on Sun
products and technologies by AT&T in both the near and long term. The
gestalt of the investment was that it was a consequence of "well, if we're
already doing all this, then..."
Certainly the later transitions in Sun's products had lots of issues. But
lessons aren't gained from "well, they meant well, but, poor sods, they were
barely staying alive" especially when the premise isn't even remotely
accurate.
It's a much more interesting examination to consider: "they had agency, they
made choices, the context was <pretty complex>, why that and not this, what
was the alternative, etc." Since we can have the facts, why not premise the
discussions on those?
9:40 p.m.
New subject: Mythical Distress Sale (was Re: moving directories in svr2)
I think the execs did not fully appreciate what they had in SunOS.
I know that I, and many other engineers, put in a boat load of extra
effort to polish SunOS. My first job at Sun was to do POSIX conformance
(which was one hell of an education). Nobody asked me to do this,
but I made lint libraries for SVr3 (or 4, whatever was current), BSD,
POSIX, etc. My thinking was that you could develop on SunOS but target
whatever you wanted. I had to threaten to quit to get them included in
the release, Rob didn't want them in there because they added something
like 40KB to the install. He was probably right, I doubt anyone ever
used them, but my thinking was to help the customers.
That thinking was rampant amongst the engineers, you could show up at 7pm
and building 5 had piles of engineers polishing SunOS. Guy Harris quit
and went to Auspex, they licensed SunOS. He'd come pound on the door
after dinner, we'd let him in, get him logged in and he fixed bugs.
I can still here him saying "Holy smokes, they still haven't fixed
this?" and then he'd check in a fix.
I don't think the execs had a clue as to how much the engineers were
willing to make SunOS better. We did it because everyone wanted a
Sun, it was the best of the best at the time.
On Tue, Jan 04, 2022 at 08:26:23AM -0700, arnold(a)skeeve.com wrote:
OK, serious question. Why did Sun "sell out"
to AT&T if they could
have raised capital in the market? Did the executive team just not
care about what moving to System V would mean? Or did they not understand
it?
How desperate were they? And why were they so desparate? Were there
other alternatives they could have pursued?
I too lived through those times, from the outside, and it was indeed
a shocker when they moved from SunOS to Solaris.
Thanks,
Arnold
Larry McVoy <lm(a)mcvoy.com> wrote:
> Rob, you've painted this picture before and it just doesn't match up
> at all with what I saw. I was there. Ken Okin paid me for 6 months to
> try and convince the execs to not go to SVR4. If it was all sweetness
> and light, why did he do that?
>
> You make it sound like it was a nice friendly deal. It was $200M of
> Sun stock at 35% over market rate. Who does that just to be friends?
> You say you could have gone to market and gotten that, well, sure,
> but not at 35% over market.
>
> SunOS was winning all the deals, as you point out, Sun was growing
> like crazy. I did lots and lots of customer presentations and not once
> did I hear "oh, when are you guys going to standardize on System V?"
>
> Quite the opposite in fact. I was doing a talk at the Moscone center
> on the first Sun cluster that I had built, Scott refused to let me ship
> it with SunOS, so I was being a good soldier and talking up Solaris.
> Over and over and over I was asked why we were forcing people to use
> an obviously worse OS and I finally lost it and said "I know, I have
> everything working in SunOS but they won't let me ship it."
>
> I was on tape. Okin listened to the tape and said "get every copy of
> those tapes and destroy them". Not exactly the friendly everyone
> agreeing picture you paint. Not remotely like that.
>
> Rob, I lived through that time. One of my close friends, John Pope,
> did the bring up. He felt alienated from all the other kernel people
> because we all loved SunOS and we hated Solaris, it made zero sense to
> go that far backward. And look what it got you. Sun is gone.
>
> If you could have gone to market and gotten the money, you would
> have. Sun was killing it, everyone wanted a Sun over every other
> workstation, in the SunOS days, every open source thing just built
> on Suns. Everyone else had to twiddle the makefiles and the source.
> Your story that people wanted a standard just doesn't hold up when
> you were the standard. It also doesn't hold up when every single
> customer I talked to (and I talked to them at least twice a month
> in formal presentations and frequently more like twice a week,
> the sales people loved me) never asked for SVR4. Not once did that
> come up. And when SVR4 was being pushed on them, 100% of them
> pushed back and wanted SunOS.
>
> On Tue, Jan 04, 2022 at 01:28:20AM -0800, Rob Gingell wrote:
> > On 1/3/2022 6:28 PM, Theodore Ts'o wrote:
> > >Of course, that's assuming that Sun could have stayed afloat without
> > >that injection of cash from AT&T....
> >
> > What causes you to assert that Sun was at risk of not staying afloat?
> >
> > Sun went from $0/yr to over $1B/yr in revenue between 1982 and 1988, the
> > prototype for what people now call "unicorns".
> >
> > Between 1985 and 1989 Sun grew at a compounded rate of 145% a year, and
> > according to Forbes was the fastest growing company in the US in those
> > years.
> >
> > Doesn't sound like a company foundering to me, certainly not in 1987 and
> > 1988. Didn't sound like it to AT&T either, who wanted in on the action
and
> > so bought a bunch of Sun stock on terms very favorable to Sun (and
> > financially speaking of benefit to both companies when AT&T divested some
> > years later).
> >
> > The injection of capital was certainly useful to Sun, not because of
> > distress or failure, but because it was bursting at the seams from all the
> > growth. Sun was going to get that capital without AT&T by going to the
> > market anyway, that it was able to do so on more favorable terms with an
> > already established partner was literally an example of the rich getting
> > richer. The partnership to inject SunOS technologies, do SVR4, harmonize the
> > various UNIX flavors had already been committed and launched some months
> > before the investment occurred and wasn't contingent upon it.
> >
> > They're not unrelated of course, the investment occurred in the context
of
> > the already committed partnership. And if you examine the announced
> > expectations of that partnership it included some strong dependencies on Sun
> > products and technologies by AT&T in both the near and long term. The
> > gestalt of the investment was that it was a consequence of "well, if
we're
> > already doing all this, then..."
> >
> > Certainly the later transitions in Sun's products had lots of issues. But
> > lessons aren't gained from "well, they meant well, but, poor sods,
they were
> > barely staying alive" especially when the premise isn't even
remotely
> > accurate.
> >
> > It's a much more interesting examination to consider: "they had
agency, they
> > made choices, the context was <pretty complex>, why that and not this,
what
> > was the alternative, etc." Since we can have the facts, why not premise
the
> > discussions on those?
>
> --
> ---
> Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
9:48 p.m.
New subject: Mythical Distress Sale (was Re: moving directories in svr2)
Executives at tech companies rarely understand "what they have" in my
experience.
The Son/ATT "merger" terrified the industry, so much so that a bunch of
people got together and created the Open Software Foundation. The feeling
was that ATT had superior technology, and Sun could build and sell it.
Perhaps that first part was wrong, but many felt that way.
4:57 a.m.
New subject: moving directories in svr2
Theodore Ts'o wrote:
Well, take a look at the ip-route man page. The BSD
route command
assumes fundamentally there is a single routing table that you can
update. In Linux, there are multiple routing tables --- to support
NAT, VRF (virtual routing and forwarding), etc.
Non-exhaustive research (didn't look at NetBSD, OpenBSD or Dragonfly):
Looks like the FreeBSD route got the -fib argument in November 2012,
the setfib command (execute a command with an alternate routing table)
appeared in 2008.
Looks like the ip command appeared in Linux 2.2 (end of 1999), so it
doesn't look like there was a lead to follow.
Now don't get me wrong, I have no lost love for the BSD route command,
it almost always takes me at least four tries; one for a syntax error,
one to add a bad route, and another to remove the bad route!
BUT, as someone who has been using BSD based systems since 4.2, it's
hard not to feel like GNU and Linux folks have evidenced a pride that
they're better than Un*x (I remember at a Usenix (Boston in '94?)
overhearing a VA Linux employee boasting how their goal was to beat
out commercial Un*x vendors. Too bad they weren't aiming at the
Windows desktop...) and missed the boat on "Unix philosophy", but I'm
well aware that what I remember with fondness as simpler times was
contemporaneously viewed by others as "beginning to smell really bad".
Finally, I'm new here, but I can't help feeling that both complaining
and boasting about Linux aren't within the realm of "Unix Heritage"?
But discussion of lessons learned by Bell Research post 7th Edition,
are of greater interest to me.
Keeping ".." working is certainly a major pain in the a**, and I can
understand wanting to throw it in the ditch, but I came from the DEC
36-bit world (TOPS-10/20 and ITS) which didn't present a single,
uniform file name space (full paths started with "DEVICE:", and
different device handlers could treat the following name space
differently), and I've never been convinced that the Unix single
namespace hasn't brought just as much pain as benefit.
ITS in particular had device handlers that were dynamically loaded
into another process and commuinicated thru a special device handler
handler (the JOB device) that translated system calls to messages.
Listing the directory of a spooled print device would show the queue,
and there was also network file access to other ITS machines).
The DEC systems had system and user defined "logical devices", which I
do remember fondly as causing less pain than symlinks. ITS may have
had both symlink and logical device-like things...
9:40 p.m.
New subject: VRFs (was Re: moving directories in svr2)
On Mon, Jan 03, 2022 at 03:23:54PM -0500, Theodore Ts'o wrote:
Well, take a look at the ip-route man page. The BSD route command
assumes fundamentally there is a single routing table that you can
update. In Linux, there are multiple routing tables --- to support
NAT, VRF (virtual routing and forwarding), etc.
Well, I never found the multiple-table thing to be that much like
VRF stuff which one would find one cisco/juniper/etc, I found it
more like a PBR scheme...
In terms of doing stuff like VRFs, I generally just configure
multiple network namespaces, and ignore the multiple tables.
That said, there is now another explicit mechanism for VRFs in Linux,
based in part off VLANs, and special interfaces. Maybe it also uses
the multiple tables stuff?
So is that 2.5 to 3 mechanisms for achieving VRFs, and/or other weird
and wonderful networking games?
DF
31 Dec
31 Dec
11:12 a.m.
New subject: moving directories in svr2
On Dec 30, 2021, at 7:08 PM, Theodore Ts'o
<tytso(a)mit.edu> wrote:
On Thu, Dec 30, 2021 at 05:31:09PM -0500, Dan Cross wrote:
Note that this is already broken!
$ mkdir -p ~/a/b; cd ~/a/b; mv ~/a /tmp # /tmp is on a diff filesystem
$ cd ..
cd: no such file or directory: ..
At least with the change[1] I was talking about, cd .. would not be
an error! At least with this change the behavior is more consistent!
Now if you want bug for bug compatibility then yes, you can't make any
changes but usually it is more a cost/benefit tradeoff as far as any
breaking changes are concerned. NFS broke a few things for example
and most of us put up with that.
[1] cwd as string, not allowing multiple links to a dir. I speculated
about the latter but any benefit is not worth the cost.
not worth it.
On Thu, Dec 30, 2021 at 11:41 AM Theodore
Ts'o <tytso(a)mit.edu> wrote:
I was responding to Bakul's suggestion that the original Unix
could/should have stored the cwd as a string, instead of a pointer to
a directory inode. If you stored the cwd as a string, then you could
interpret .. by chopping off the last file name component of the
string, and so now you could have hard links to directories and the
file system tree could then be a file system DAG.
I don't think Bakul's proposal would have worked --- although I
suppose if you disallowed directory renames, I guess it could. On Wed, Dec 29, 2021 at 10:45:12PM -0500, Noel
Chiappa wrote:
Why? Presumably as you traversed the filesystem, you'd cache, (path
component, inode) pairs and keep a ref on the inode. For any given
file, including $CWD, you'd know it's pathname from the root as you
accessed it, but if it got renamed, it wouldn't matter because you'd
have cached a reference to the inode. > From: Bakul Shah
> My guess is *not* storing a path instead of a ptr to the inode was done
> to save on memory.
More probably speed; those old disks were not fast, and on a PDP-11, disk
caches were so small that converting the path to the current directory to its
in memory inode could take a bunch of disk reads.
The other problem with storing the path as a string is that if
higher-level directories get renamed, the path would become
invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone
renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string
would
become invalidated.
1073
days inactive
1087
days old
48 comments
20 participants
participants (20)
-
Adam Thornton -
arnold＠skeeve.com -
Arthur Krewat -
Bakul Shah -
Chet Ramey -
Dan Cross -
Derek Fawcus -
Doug McIntyre -
Greg 'groggy' Lehey -
jnc＠mercury.lcs.mit.edu -
Kevin Bowling -
Larry McVoy -
Michael Kjörling -
Phil Budne -
Richard Salz -
Rob Gingell -
Rob Pike -
Stuart Remphrey -
Theodore Ts'o -
Warner Losh