Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.os.linux.development.system > #674

UNIX(*)/ Linux history & system design (was: shred or scrub)

Show all headers | View raw

crankypuss <crankypuss@nomail.invalid> writes:
> On 04/28/2014 06:01 AM, Rainer Weikusat wrote:
>> Rainer Weikusat <rweikusat@mobileactivedefense.com> writes:
>>> crankypuss <crankypuss@nomail.invalid> writes:
>>>> On 04/27/2014 02:26 PM, Rainer Weikusat wrote:

[...]

> Linux stems from Unix, which was developed during what one might call
> "mainframe days".  During the late 1960s when Unix was developed,
> computers were not yet what they are now.  Cost and features drove a
> specific architecture to the fore.  It was necessary for many users to
> share the resources of a single machine because there simply were not
> that many machines in existence as compared to the number of
> users. Machine-to-machine communication technology was rudimentary.

Linux does not 'stem from UNIX(*)', it is (among other things) an
uncertified 'more-or-less' implementation of the POSIX/ UNIX(*)
API.

UNIX(*) wasn't developed 'in the late 1960s'. Some of the concepts came
to life in embryonic form after Bell Labs pulled out of the
Multics-project in 1969 but something which actually resembled 'current
UNIX(*)' didn't exist until 1973 (first PDP-11 UNIX(*) with a kernel
written in C) and many things people tend to associate with UNIX(*), eg
the Bourne shell or 'stdio & malloc' saw the light of the day with the
7th edition released in 1979. By that time, it was a system for 16-bit
mini-computers (not mainframes) and it would soon become one for 32-bit
mini-computers, in particular, VAXen. Since then, development has
continued both on 'mini-computer style machines', nowadays usually
referred to as 'servers', and single-user workstations, the latter being
eventually replaced by 'Linux on PC hardware' around 'the mid
2010s'.

'Networking support' was roughly added with 4.2BSD in 1983 which means
that the (ongoing) lifetime of 'the system with networking' is more than
twice as long as the lifetime of the 'system without networking' (UUCP
was also part of the 7th edition).

(Admittedly, the idea of 'a hierarchically organized system for accessing
data located on unspecified secondary storage devices' seems to have
originated with Multics (but see below) and Multics was a 'mainframe
time-sharing OS developed in the 2nd half of the 1960')

> What constituted a "filesystem" then was not what we might think of as
> a "filesystem" today... the term "filesystem" has, in a sense,
> outlasted its earliest semantics.
>
> In those days, the whole client/server model had yet to emerge, it
> wasn't until systems communicating with other systems became
> commonplace that the client/server model became obvious.  Under the
> mainframe model, sharing files between multiple users of a single
> "mainframe" was an obvious "necessity" if much actual work was to get
> done.  The world has changed, hardware has evolved, new technology and
> new viewpoints have emerged.

Even on a time-shared mini-computer (or mainframe, fwiw), files are not
really shared 'between users' but between different processes which
happen to run on behalf of different 'physical users'. I'm the sole
'actual user' on the computer I'm using to write this, however, it
nevertheless runs 121 different processes using 'the filesystem
namespace' for addressing shared resources, eg, libraries or database
files. And I'm decidedly not the sole 'real user' on 'our development
machines' which provide access to resources people don't usually have
'at home', eg, publically reachable IPv4 addresses associated with
machines with reasonable network connections. There are also a lot more
'real users' on production installations (sometimes hundreds or
thousands) which de facto do 'time-sharing[*]', except that their access to
the system is limited to interacting with 'certain applications' instead
of being allowed to use them for general-purpose computing.

[*] Every 'web server' offering users to option to access some
applications via browser is nothing but a time-sharing system, just not
a 'general purpose times-sharing system'.

> You wish to "educate" me so that "you do understand that programs,
> shared libraries and stuff like 'documentation' are ultimatively all
> files accessible via the filesystem namespace?"
>
> The answer is no, what I understand is perhaps different from what you
> think I should understand.
>
> Files are irrelevant, it is the storage and retrieval of named data
> that is relevant; "files" are a conceptual artifact held over from
> historic storage technology, a special case of the more general case
> "named data".

'file' is nothing but a term referring to some collection of 'data'
which can be accessed 'by name', ie, 'named data' ...

> You seem to like the term "namespace" and yes, it has been all the
> rage for the past decade or so to recognize the concept of a
> "namespace" and realize that a given name has one meaning in one
> namespace, another possibly quite different meaning in another
> namespace.  However the "namespace" concept is really nothing new, it
> was embodied in IBM's OS/360 as introduced in 1964 which used
> hierarchical dot-qualification to separate "namespaces", essentially
> the same thing as a linux/Unix "directory tree" but using periods
> instead of slashes.

... and organizing 'names' referring to 'collections of data' in form of
a hierarchical structure where 'generality' decreases with distance from
the root of the tree is way older than that: Libraries usually organize
books in this way.

> The idea of "namespaces" is little more than a technique for
> question-begging and unintentional obfuscation, since an individual
> element is only uniquely addressed by its fully-qualified name,
> regardless of how many "namespaces" are considered to exist.

Apart from that, we're using the term 'namespace' in a different way:
'The filesystem namespace' is something which enables resources which
are 'somehow accessible' to be named uniquely and independently of the way
the resource are actually accessed. Eg, an application can use the name
/bin/sh to execute a command interpreter with certain properties
(assuming a system conforming to certain 'standards and conventions')
without the slightest bit of an idea what kind of real or 'emulated'
device will ultimatively supply the data corresponding with the name.

[...]

> The interfaces provided by Unix, and hence by linux, for working with
> "files", no longer match the reality existent when those interfaces
> were initially defined.  In those days things were simpler, "files"
> were stored on devices that either worked or not; there were fewer
> problems in that world, if the device didn't respond "immediately" it
> was never going to respond because it had malfunctioned.  It wasn't a
> case of a response being delayed because the file-server was
> undergoing maintenance and was temporarily unavailable, or because
> there was a DNS update and just where a given domain was happened to
> be a bit wiggly, there were fewer cases and the interfaces provided in
> those early days only provided what was necessary, they didn't account
> for cases that wouldn't come into existence until years later when
> communication technology had emerged in a world where "machines" were
> cheap and plentiful.

I have to admit that I can't really make sense of that (eg, what
interfaces are you referring to?)

> Linux seems still locked into those "ancient" interfaces, and what I
> say is that it's time to set aside "Unix compatability" and build
> something more modern so that the increasingly complex world does not
> ambush us.

Judging from something you wrote earlier, you probably consider 'ACLs'
'more modern' than the simpler UNIX(*) ugo-model. They're, however,
actually older as they originated with the Multics 'secondary storage
system'. And something similar is true for a great many other things
nowadays labelled as modern: The actually are resurrected 'ancient concepts'
sold to 'sufficiently young people' who are not familiar with 'ancient
concepts' as 'more modern' than something older than them they believe
to be familiar with. Eg, UNIX(*) (AFAIK) pioneered the idea of
implementing 'system boot' in an interpreted, 'easy to use' (for people
willing to learn it or roughly familiar with 'languages used in the
1960s and 70s) programming language supporting 'automatic memory
management'. This in the process of being abandoned in favor of the
'modern concept' of using  a notoriously difficult to use
low-level language instead. For "performance reasons" since - clearly -
hardware got so much more feeble since the 1980s that the more
user-friendly, _newer_ idea can't be employed anymore.

> Some seem to disagree with that view, but then some people blindly
> parse command output with sed and use that to drive system-critical
> functionality; go figure.

I did a lot of shell-programming when I was working on 'embeddded Linux
project' some years ago because that was the most convenient programming
language available to me in that environment (ARM9 machine language and C
being the other options) and 'sed' was the most sophisticated
text-processing tool available to me. What's wrong with using it?

Back to comp.os.linux.development.system | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

shred or scrub "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-16 18:17 -0400
  Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-17 04:19 -0600
    Re: shred or scrub "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-18 22:30 -0400
      Re: shred or scrub Jasen Betts <jasen@xnet.co.nz> - 2014-04-19 07:42 +0000
        Re: shred or scrub Richard Kettlewell <rjk@greenend.org.uk> - 2014-04-19 10:04 +0100
      Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-19 02:15 -0600
      Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-19 23:05 +0100
        Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-20 02:47 -0600
          Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-20 07:56 -0500
            Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-21 03:51 -0600
              Re: shred or scrub Jasen Betts <jasen@xnet.co.nz> - 2014-04-21 11:50 +0000
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-21 06:14 -0600
            Re: shred or scrub "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-21 18:44 -0400
          Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-21 13:24 +0100
            Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-22 04:10 -0600
              Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-22 14:39 +0100
  Re: shred or scrub Kristof Provost <kristof@codepro.be> - 2014-04-17 13:15 +0000
    Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-17 09:40 -0500
      Re: shred or scrub Kristof Provost <kristof@codepro.be> - 2014-04-18 14:40 +0000
    Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-18 02:12 -0600
      Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-18 11:49 +0200
        Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-18 09:59 -0600
          Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-21 16:14 +0200
            Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-22 04:22 -0600
              Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-23 00:06 +0200
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-23 05:50 -0600
                Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-24 22:46 +0200
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-25 03:57 -0600
                Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-25 19:14 +0100
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-26 04:02 -0600
                Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-27 21:26 +0100
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-28 03:27 -0600
                Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-28 12:17 +0100
                Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-28 13:01 +0100
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-29 02:50 -0600
                UNIX(*)/ Linux history & system design (was: shred or scrub) Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-05 21:31 +0100
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-05 16:02 -0600
                Re: UNIX(*)/ Linux history & system design David Brown <david.brown@hesbynett.no> - 2014-05-06 01:17 +0200
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-06 01:46 -0600
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-06 15:09 +0100
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-06 23:47 -0600
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-07 16:23 +0100
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-07 10:51 -0600
                Re: UNIX(*)/ Linux history & system design Jerry Peters <jerry@example.invalid> - 2014-05-07 20:25 +0000
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-08 03:50 -0600
                Re: UNIX(*)/ Linux history & system design Jerry Peters <jerry@example.invalid> - 2014-05-08 20:24 +0000
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-09 02:23 -0600
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-09 18:36 +0100
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-09 21:24 +0100
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-07 22:01 +0100
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-08 03:37 -0600
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-08 14:02 +0100
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-09 02:56 -0600
                Re: UNIX(*)/ Linux history & system design David Brown <david.brown@hesbynett.no> - 2014-05-07 00:15 +0200
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-07 00:32 -0600
                Re: UNIX(*)/ Linux history & system design Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-05-07 08:47 +0000
                Re: UNIX(*)/ Linux history & system design crankypuss <crankypuss@nomail.invalid> - 2014-05-07 10:59 -0600
                Re: UNIX(*)/ Linux history & system design Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-05-06 14:35 +0100
                Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-26 16:30 +0200
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-27 05:59 -0600
                Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-27 20:15 +0100
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-28 03:29 -0600
                Re: shred or scrub Rainer Weikusat <rweikusat@mobileactivedefense.com> - 2014-04-28 12:06 +0100
                Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-27 21:41 +0200
                Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-28 04:03 -0600
                Re: shred or scrub Richard Kettlewell <rjk@greenend.org.uk> - 2014-04-28 16:44 +0100
                Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-28 23:39 +0200
      Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-18 07:37 -0500
        Re: shred or scrub crankypuss <crankypuss@nomail.invalid> - 2014-04-18 10:16 -0600
          Re: shred or scrub John Hasler <jhasler@newsguy.com> - 2014-04-18 12:01 -0500
      Re: shred or scrub Kristof Provost <kristof@codepro.be> - 2014-04-18 14:42 +0000
  Re: shred or scrub David Brown <david.brown@hesbynett.no> - 2014-04-17 16:41 +0200

csiph-web