UNIX was half a billion (500000000) seconds old on Tue Nov 5 00:53:20
1985 GMT (measuring since the time(2) epoch).
-- Andy Tannenbaum
Hmmm... According to my rough calculations, it hit a billion (US) seconds
around 2000.
-- Dave
Does anyone have any experience with YP / NIS / NIS+ / LDAP as a central
directory on Unix?
I'm contemplating playing with them for historical reasons.
As such, I'm wondering what the current evolution is for a pure Unix
environment. Read: No Active Directory. Is there a current central
directory service for Unix (or Linux)? If so, what is it?
I'm guessing it's LDAP combined with Kerberos, but I'm not sure.
--
Grant. . . .
unix || die
Interesting. /crp was a regular part of the Research world
in the mid-1980s when I joined up. It was nothing special,
just an extra file system for extra junk, which might or might
not be backed up depending on the system.
I had no idea its roots ran so far back in time.
I always thought it was an abbreviation for `crap,' though,
oddly, the conventional pronunciation seemed to be creep.
Norman Wilson
Toronto ON
A. P. Garcia:
I'd be interested in knowing where a pure unix environment
exists, beyond my imagination and dreams that is.
====
For starters, the computing facility used for teaching
in the Department of Computer Science at the University
of Toronto. Linux workstations throughout our labs; Linux
file servers and other back-ends, except OpenBSD for the
Kerberos KDCs and firewalls.
And yes, we use Kerberos, including Kerberized NFS for
(almost) all exports to lab workstations, which cannot
be made wholly secure against physical breakins by students.
(There's no practical way to prevent that entirely.)
Except we also use traditional UNIX /etc/shadow files
and non-Kerberized NFS for systems that are physically
secure, including the host to which people can ssh from
outside. If you don't type a password when you log in,
you cannot get a Kerberos TGT, so you wouldn't have access
to your home directory were it Kerberized there; and we
aren't willing to (and probably couldn't) forbid use of
.ssh/authorized_keys for users who know how to do that.
Because we need to maintain the password in two places,
and because we create logins automatically in bulk from
course-registration data, we've had to write some of our
own tools. PAM and the ssh GSSAPI support suffice for
logging in, but not for password changes or account
creation and removal.
Someday we will have time to look at LDAP. Meanwhile we
distribute /etc/passwd and /etc/shadow files (the latter
mostly blanked out to most systems) via our configuration-
management system, which we need to have to manage many
other files anyway.
Norman Wilson
Toronto ON
I was just reading this book review:
http://www.pathsensitive.com/2018/10/book-review-philosophy-of-software.html
and came across these paragraphs:
<book quote>
The mechanism for file IO provided by the Unix operating system
and its descendants, such as Linux, is a beautiful example of a
deep interface. There are only five basic system calls for I/O,
with simple signatures:
int open(const char* path, int flags, mode_t permissions);
ssize_t read(int fd, void* buffer, size_t count);
ssize_t write(int fd, const void* buffer, size_t count);
off_t lseek(int fd, off_t offset, int referencePosition);
int close(int fd);
</book quote>
The POSIX file API is a great example, but not of a deep
interface. Rather, it’s a great example of how code with a very
complicated interface may look deceptively simple when reduced to C-style
function signatures. It’s a stateful API with interesting orderings
and interactions between calls. The flags and permissions parameters
of open hide an enormous amount of complexity, with hidden requirements
like “exactly one of these five bits should be specified.” open may
return 20 different error codes, each with their own meaning, and many
with references to specific implementations.
The authors of SibylIFS tried to write down an exact description of the
open interface. Their annotated version[1] of the POSIX standard is over
3000 words. Not counting basic machinery, it took them over 200 lines[2]
to write down the properties of open in higher-order logic, and another
70 to give the interactions between open and close.
[1]: https://github.com/sibylfs/sibylfs_src/blob/8a7f53ba58654249b0ec0725ce38878…
[2]: https://github.com/sibylfs/sibylfs_src/blob/8a7f53ba58654249b0ec0725ce38878…
I just thought it was a thought-provoking comment on the apparent elegance
of the Unix file API that actually has some subtle complexity.
Cheers, Warren
> From: Lars Brinkhoff
> Let's hope it's OK!
Indeed! It will be fun to see that code.
> I suppose I'll have to add a simulation of the Unibus CH11 Chaosnet
> interface to SIMH.
Why? Once 10M Ethernet hardware was available, people switched pretty rapidly
to using that, instead of the CHAOS hardware. (It was available off the shelf,
and the analog hardware was better designed.) That's part of the reason ARP is
multi-protocol.
Some hard-to-run cables (e.g. under the street from Tech Sq to main campus)
stayed CHAOS hardware because it was easier to just keep using what was there,
but most new machines got Ethernet cards.
Noel
> From: Chris Hanson
> you should virtually never use read(2), only ever something like this:
> ...
> And do this for every classic system call, since virtually no client
> code should ever have to care about EINTR.
"Virtually". Maybe there are places that want to know if their read call was
interrupted; if you don't make this version available to them, how can they
tell? Leaving the user as much choice as possible is the only way to go, IMO;
why force them to do it the way _you_ think is best?
And it makes the OS simpler; any time you can move functionality out of the
OS, to the user, that's a Good Thing, IMO. There's nothing stopping people
from using the EINTR-hiding wrapper. (Does the Standard I/O library do this,
does anyone know?)
Noel
PS: Only system calls that can block can return EINTR; there are quite a few
that don't, not sure what the counts are in modern Unix.
On Sun, 4 Nov 2018, Chris Hanson wrote:
> Every piece of code that wants to call, say, read(2) needs to handle
> not only real errors but also needs to special-case EINTR and retry
> the read. Thus you should virtually never use read(2), only ever
> something like this:
> ...
> And do this for every classic system call, since virtually no client
> code should ever have to care about EINTR. It was early an
> implementation expediency that became API and that everyone now has
> to just deal with because you can’t expect the system call interface
> you use to do this for you.
>
>This is the sort of wart that should’ve been fixed by System V and/or BSD 4 at latest.
But it *was* fixed in BSD, and it's in POSIX as the SA_RESTART flag to
sigaction (which gives you BSD signal semantics).
POSIX supports both the original V7 and BSD signal semantics, because
by then there were programs which expected system calls to be
interrupted by signals (and to be fair, there are times when that's
the more convenient way of handling an interrupt, as opposed to using
setjump/longjump to break out of a restartable system call).
- Ted
P.S. The original implementation of ERESTARTSYS / ERESTARTNOHAND /
ERESTARTNOINTR errno handling in Linux's system call return path was
my fault. :-)
