[opensuse] Historical justification for the /bin - /usr/bin split.
I was just browsing through some systemd info, following the rabbit trail from article to article, when I came across this. The historical reason for the split between /bin and /usr/bin is, according to this post on by Rob Landley on the busbox mailing list, very simple, very pragmatic and would make absolutely no sense if Unix / Linux was being invented today... [I raise this because this topic was broached by some during the recent systemd discussion...] ================= Begin quote ===================== On Tuesday 30 November 2010 15:58:00 David Collier wrote:
I see that busybox spreads it's links over these 4 directories.
Is there a simple rule which decides which directory each link lives in.....
For instance I see kill is in /bin and killall in /usr/bin.... I don't have a grip on what might be the logic for that.
You know how Ken Thompson and Dennis Ritchie created Unix on a PDP-7 in 1969? Well around 1971 they upgraded to a PDP-11 with a pair of RK05 disk packs (1.5 megabytes each) for storage. When the operating system grew too big to fit on the first RK05 disk pack (their root filesystem) they let it leak into the second one, which is where all the user home directories lived (which is why the mount was called /usr). They replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and wrote files to those new directories because their original disk was out of space. When they got a third disk, they mounted it on /home and relocated all the user directories to there so the OS could consume all the space on both disks and grow to THREE WHOLE MEGABYTES (ooooh!). Of course they made rules about "when the system first boots, it has to come up enough to be able to mount the second disk on /usr, so don't put things like the mount command /usr/bin or we'll have a chicken and egg problem bringing the system up." Fairly straightforward. Also fairly specific to v6 unix of 35 years ago. The /bin vs /usr/bin split (and all the others) is an artifact of this, a 1970's implementation detail that got carried forward for decades by bureaucrats who never question _why_ they're doing things. It stopped making any sense before Linux was ever invented, for multiple reasons: 1) Early system bringup is the provice of initrd and initramfs, which deals with the "this file is needed before that file" issues. We've already _got_ a temporary system that boots the main system. 2) shared libraries (introduced by the Berkeley guys) prevent you from independently upgrading the /lib and /usr/bin parts. They two partitions have to _match_ or they won't work. This wasn't the case in 1974, back then they had a certain level of independence because everything was statically linked. 3) Cheap retail hard drives passed the 100 megabyte mark around 1990, and partition resizing software showed up somewhere around there (partition magic 3.0 shipped in 1997). Of course once the split existed, some people made other rules to justify it. Root was for the OS stuff you got from upstream and /usr was for your site- local files. Then / was for the stuff you got from AT&T and /usr was for the stuff that your distro like IBM AIX or Dec Ultrix or SGI Irix added to it, and /usr/local was for your specific installation's files. Then somebody decided /usr/local wasn't a good place to install new packages, so let's add /opt! I'm still waiting for /opt/local to show up... Of course given 30 years to fester, this split made some interesting distro- specific rules show up and go away again, such as "/tmp is cleared between reboots but /usr/tmp isn't". (Of course on Ubuntu /usr/tmp doesn't exist and on Gentoo /usr/tmp is a symlink to /var/tmp which now has the "not cleared between reboots" rule. Yes all this predated tmpfs. It has to do with read- only root filesystems, /usr is always going to be read only in that case and /var is where your writable space is, / is _mostly_ read only except for bits of /etc which they tried to move to /var but really symlinking /etc to /var/etc happens more often than not...) Standards bureaucracies like the Linux Foundation (which consumed the Free Standards Group in its' ever-growing accretion disk years ago) happily document and add to this sort of complexity without ever trying to understand why it was there in the first place. 'Ken and Dennis leaked their OS into the equivalent of home because an RK05 disk pack on the PDP-11 was too small" goes whoosh over their heads. I'm pretty sure the busybox install just puts binaries wherever other versions of those binaries have historically gone. There's no actual REASON for any of it anymore. Personally, I symlink /bin /sbin and /lib to their /usr equivalents on systems I put together. Embedded guys try to understand and simplify... Rob =============== End Quote ========================== The original post can be found archived here: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html The article that linked to it is here; http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-06-10 13:51, Rodney Baker wrote:
I was just browsing through some systemd info, following the rabbit trail from article to article, when I came across this. The historical reason for the split between /bin and /usr/bin is, according to this post on by Rob Landley on the busbox mailing list, very simple, very pragmatic and would make absolutely no sense if Unix / Linux was being invented today...
[I raise this because this topic was broached by some during the recent systemd discussion...]
================= Begin quote =====================
...
When the operating system grew too big to fit on the first RK05 disk pack (their root filesystem) they let it leak into the second one, which is where all the user home directories lived (which is why the mount was called /usr). They replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and wrote files to those new directories because their original disk was out of space. When they got a third disk, they mounted it on /home and relocated all the user directories to there so the OS could consume all the space on both disks and grow to THREE WHOLE MEGABYTES (ooooh!).
.....................++- Interesting :-) +++.....................
The /bin vs /usr/bin split (and all the others) is an artifact of this, a 1970's implementation detail that got carried forward for decades by bureaucrats who never question _why_ they're doing things. It stopped making any sense before Linux was ever invented, for multiple reasons:
...
Of course once the split existed, some people made other rules to justify it.
.....................++- Perhaps not as simple as that. Once that the split existed, it could be used for advantage, simply because it was possible. For instance, you could have a bunch of small machines sharing a single "/usr" tree remotely, over the network. This required the machine to boot, start up network, and an nfs client, using only /bin and /lib trees. Or you could split "/usr" to another local disk, just because you could. And /home on another, for the same reason. It has the advantage of spreading disk load over different disks, running faster (i/o parallelization). +++.....................
=============== End Quote ==========================
The original post can be found archived here:
http://lists.busybox.net/pipermail/busybox/2010-December/074114.html
The article that linked to it is here;
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
Of course, the /usr split makes no sense for a busybox machine, IMO. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 06/10/2014 04:10 PM, Carlos E. R. wrote:
Of course, the /usr split makes no sense for a busybox machine, IMO.
Well, space still matters - think of embedded systems etc. On the upstream coreutils mailing list, there's even a discussion [1] about a patch/RFC to build all utils into one 5.5M 'coreutils' binary, and having symlinks for every util to it, thus using argv[0] to determine the wanted behavior (df -> coreutils, du -> coreutils, ...). (This is not only about disk space, but also e.g. about the memory footprint of all coreutils running in parallel.) An interesting approach TBH. http://lists.gnu.org/archive/html/coreutils/2014-06/msg00026.html Have a nice day, Berny -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-06-10 16:57, Bernhard Voelker wrote:
On 06/10/2014 04:10 PM, Carlos E. R. wrote:
Of course, the /usr split makes no sense for a busybox machine, IMO.
Well, space still matters - think of embedded systems etc.
Yes, of course. But that space will be the same with a single root partition, or splitted. Actually, space problem is worse, because you need free space on all the partitions, instead of a single free space on the single partition.
On the upstream coreutils mailing list, there's even a discussion [1] about a patch/RFC to build all utils into one 5.5M 'coreutils' binary, and having symlinks for every util to it, thus using argv[0] to determine the wanted behavior (df -> coreutils, du -> coreutils, ...). (This is not only about disk space, but also e.g. about the memory footprint of all coreutils running in parallel.) An interesting approach TBH.
Well, that's what busybox does. For many years :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Carlos E. R. wrote:
On 2014-06-10 13:51, Rodney Baker wrote:
I was just browsing through some systemd info, following the rabbit trail from article to article, when I came across this. The historical reason for the split between /bin and /usr/bin is, according to this post on by Rob Landley on the busbox mailing list, very simple, very pragmatic and would make absolutely no sense if Unix / Linux was being invented today...
[I raise this because this topic was broached by some during the [recent systemd discussion...]
================= Begin quote =====================
...
When the operating system grew too big to fit on the first RK05 disk pack (their root filesystem) they let it leak into the second one, which is where all the user home directories lived (which is why the mount was called /usr). They replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and wrote files to those new directories because their original disk was out of space. When they got a third disk, they mounted it on /home and relocated all the user directories to there so the OS could consume all the space on both disks and grow to THREE WHOLE MEGABYTES (ooooh!).
.....................++-
Interesting :-)
+++.....................
The /bin vs /usr/bin split (and all the others) is an artifact of this, a 1970's implementation detail that got carried forward for decades by bureaucrats who never question _why_ they're doing things. It stopped making any sense before Linux was ever invented, for multiple reasons:
...
Of course once the split existed, some people made other rules to justify it.
.....................++-
Perhaps not as simple as that. Once that the split existed, it could be used for advantage, simply because it was possible.
For instance, you could have a bunch of small machines sharing a single "/usr" tree remotely, over the network. This required the machine to boot, start up network, and an nfs client, using only /bin and /lib trees.
Yes, the typical thin client setup. -- Per Jessen, Zürich (32.9°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 10 Jun 2014 17:13:31 Per Jessen wrote:
Carlos E. R. wrote:
On 2014-06-10 13:51, Rodney Baker wrote:
I was just browsing through some systemd info, following the rabbit trail from article to article, when I came across this. The historical reason for the split between /bin and /usr/bin is, according to this post on by Rob Landley on the busbox mailing list, very simple, very pragmatic and would make absolutely no sense if Unix / Linux was being invented today...
[I raise this because this topic was broached by some during the [recent systemd discussion...]
================= Begin quote =====================
...
When the operating system grew too big to fit on the first RK05 disk pack (their root filesystem) they let it leak into the second one, which is where all the user home directories lived (which is why the mount was called /usr). They replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and wrote files to those new directories because their original disk was out of space. When they got a third disk, they mounted it on /home and relocated all the user directories to there so the OS could consume all the space on both disks and grow to THREE WHOLE MEGABYTES (ooooh!).
.....................++-
Interesting :-)
+++.....................
The /bin vs /usr/bin split (and all the others) is an artifact of this, a 1970's implementation detail that got carried forward for decades by bureaucrats who never question _why_ they're doing things. It stopped making any sense before Linux was ever invented, for multiple reasons:
...
Of course once the split existed, some people made other rules to justify it.
.....................++-
Perhaps not as simple as that. Once that the split existed, it could be used for advantage, simply because it was possible.
For instance, you could have a bunch of small machines sharing a single "/usr" tree remotely, over the network. This required the machine to boot, start up network, and an nfs client, using only /bin and /lib trees.
Yes, the typical thin client setup.
Yes. And this is exactly what the other two articles are using as the strongest case for merging /bin, /lib and /sbin into /usr and simply having symlinks from /bin -> /usr/bin, /lib -> /usr/lib and /sbin -> /usr/sbin - the ability to mount /usr as read-only from multiple machines across a network (with initrd handling the initial startup and mounting /usr before handing off to systemd/init or whatever. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au ============================================================== -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Rodney Baker wrote:
On Tue, 10 Jun 2014 17:13:31 Per Jessen wrote:
Carlos E. R. wrote:
On 2014-06-10 13:51, Rodney Baker wrote:
I was just browsing through some systemd info, following the rabbit trail from article to article, when I came across this. The historical reason for the split between /bin and /usr/bin is, according to this post on by Rob Landley on the busbox mailing list, very simple, very pragmatic and would make absolutely no sense if Unix / Linux was being invented today...
[I raise this because this topic was broached by some during the [recent systemd discussion...]
================= Begin quote =====================
...
When the operating system grew too big to fit on the first RK05 disk pack (their root filesystem) they let it leak into the second one, which is where all the user home directories lived (which is why the mount was called /usr). They replicated all the OS directories under there (/bin, /sbin, /lib, /tmp...) and wrote files to those new directories because their original disk was out of space. When they got a third disk, they mounted it on /home and relocated all the user directories to there so the OS could consume all the space on both disks and grow to THREE WHOLE MEGABYTES (ooooh!).
.....................++-
Interesting :-)
+++.....................
The /bin vs /usr/bin split (and all the others) is an artifact of this, a 1970's implementation detail that got carried forward for decades by bureaucrats who never question _why_ they're doing things. It stopped making any sense before Linux was ever invented, for multiple reasons:
...
Of course once the split existed, some people made other rules to justify it.
.....................++-
Perhaps not as simple as that. Once that the split existed, it could be used for advantage, simply because it was possible.
For instance, you could have a bunch of small machines sharing a single "/usr" tree remotely, over the network. This required the machine to boot, start up network, and an nfs client, using only /bin and /lib trees.
Yes, the typical thin client setup.
Yes. And this is exactly what the other two articles are using as the strongest case for merging /bin, /lib and /sbin into /usr and simply having symlinks from /bin -> /usr/bin, /lib -> /usr/lib and /sbin -> /usr/sbin - the ability to mount /usr as read-only from multiple machines across a network (with initrd handling the initial startup and mounting /usr before handing off to systemd/init or whatever.
Which is EXACTLY BACKWARDS --- the symlinks should be be from /usr/bin to /bin, from /usr/sbin to /sbin, etc. Moving ANY system-essential executable data or executable from / to /usr is sabotage.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dirk Gently wrote:
Rodney Baker wrote:
Yes. And this is exactly what the other two articles are using as the strongest case for merging /bin, /lib and /sbin into /usr and simply having symlinks from /bin -> /usr/bin, /lib -> /usr/lib and /sbin -> /usr/sbin - the ability to mount /usr as read-only from multiple machines across a network (with initrd handling the initial startup and mounting /usr before handing off to systemd/init or whatever.
Which is EXACTLY BACKWARDS --- the symlinks should be be from /usr/bin to /bin, from /usr/sbin to /sbin, etc.
Moving ANY system-essential executable data or executable from / to /usr is sabotage. ====
*Bingo*... Go ahead, try mounting /usr/bin to make links in /bin work when /bin/mount has it's libraries on /usr... Real intelligent. That it was done on purpose -- very deliberate sabotage, IMO. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/10/2014 10:10 AM, Carlos E. R. wrote:
For instance, you could have a bunch of small machines sharing a single "/usr" tree remotely, over the network. This required the machine to boot, start up network, and an nfs client, using only /bin and /lib trees.
Ah, not! Networking wasn't available to them in those days. Well, OK, there was UUCICO/UUCP over serial lines, store and forward of files, but not the kind of networking that would allow file systems to be shared. Ethernet wasn't commercially available until 1980[1]. I'm sure DEC had other tweaks for letting machines cooperate but I don't recall them being used in even V6 and V7, for which I wrote many device drivers.
Or you could split "/usr" to another local disk, just because you could. And /home on another, for the same reason. It has the advantage of spreading disk load over different disks, running faster (i/o
Its not that simple. The disk controllers for the PDP-11 (and the early VAXen) could support up to 8 drives but could only transfer from one of them at a time. Seeks could be done in parallel with a bit of juggling. So, you say, add another controller. Well we tried that and performance dived. The real problem with the PDP-11 range was that memory was at best dual port, and one of the ports was CPU-side. I say "at best" because not all models even had dual port memory. Adding a second controller just brought about more bus contention. [1] I realise Xerox, the inventors of Ethernet, had it back in '75 -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/10/2014 01:00 PM, Anton Aylward wrote:
On 06/10/2014 10:10 AM, Carlos E. R. wrote:
Ethernet wasn't commercially available until 1980[1]. I'm sure DEC had other tweaks for letting machines cooperate but I don't recall them being used in even V6 and V7, for which I wrote many device drivers.
I say "at best" because not all models even had dual port memory.Adding a second controller just brought about more bus contention.
[1] I realise Xerox, the inventors of Ethernet, had it back in '75
******************************************************************* I don't know what kind of network it was, but in the late 70s, I could look up inventory on a terminal at a manufacturing company I worked for. The terminal was not the main i/o (maybe just "o") as there was at least one other in purchasing, and surely one in the stockroom. In about 1982, at a different company, the VP of one of the departments, who was a computer whiz, among other things, networked CPM machines and one of the first IBM PCs. That network used a central server running CPM. (I think.) It had about a dozen similar cards in it. I forget the name of the card bus the server had in it. This small network connected a small department, not the whole company. --doug (retired RF engineer) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/10/2014 01:20 PM, Doug wrote:
I don't know what kind of network it was, but in the late 70s, I could look up inventory on a terminal at a manufacturing company I worked for. The terminal was not the main i/o (maybe just "o") as there was at least one other in purchasing, and surely one in the stockroom.
Perhaps ARCnet. It was popular back then, but, like everything else, replaced by Ethernet. ARCnet had an 8 bit MAC address, set by switches or jumpers. https://en.wikipedia.org/wiki/Arcnet -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/10/2014 01:39 PM, James Knott wrote:
On 06/10/2014 01:20 PM, Doug wrote:
I don't know what kind of network it was, but in the late 70s, I could look up inventory on a terminal at a manufacturing company I worked for. The terminal was not the main i/o (maybe just "o") as there was at least one other in purchasing, and surely one in the stockroom.
Yes, I installed quite a few SCO based applications like that. You can run a RS-232 cable quite some way. IIR there was a nice 8-port card which had a 'octopus' connection. Sorry, can't recall the name.
Perhaps ARCnet. It was popular back then, but, like everything else, replaced by Ethernet. ARCnet had an 8 bit MAC address, set by switches or jumpers.
There were a lot of proprietary networks floating about at that time. Every vendor's brother in law had one that was seeking 'lock in'. Oh, and there was SNA. Mustn't forget that! I recall going to the release show where IBM announced its Token Ring network. Well Bully! I had been working on the 1553 token ring back in the early 1970s, so this was nothing revolutionary in nature. What did strike me was that there were two groups there showing software products. One, PC based, which obviously had its roots in Ethernet type stuff, and was slim, and the other, ARRP based, from the mainframe world delivered drivers that were 8-12 times the size and had 14 different ways of opening a file. One this was the first time that either of them learnt of the existence of the other. That was the IBM of those days! -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
On 06/10/2014 01:39 PM, James Knott wrote:
On 06/10/2014 01:20 PM, Doug wrote:
I don't know what kind of network it was, but in the late 70s, I could look up inventory on a terminal at a manufacturing company I worked for. The terminal was not the main i/o (maybe just "o") as there was at least one other in purchasing, and surely one in the stockroom.
Yes, I installed quite a few SCO based applications like that. You can run a RS-232 cable quite some way. IIR there was a nice 8-port card which had a 'octopus' connection. Sorry, can't recall the name.
And RS-422 you can run up to 20 miles [32 km] (it's very similar to RS-232, but it's push/pull like LVD SCSI (1/0 is determined not by +5V/0V, but by the relative polarization of two lines +- or -+.) Of course, distance * bandwith is a constant.
Perhaps ARCnet. It was popular back then, but, like everything else, replaced by Ethernet. ARCnet had an 8 bit MAC address, set by switches or jumpers.
There were a lot of proprietary networks floating about at that time. Every vendor's brother in law had one that was seeking 'lock in'.
Oh, and there was SNA. Mustn't forget that!
I recall going to the release show where IBM announced its Token Ring network. Well Bully! I had been working on the 1553 token ring back in the early 1970s, so this was nothing revolutionary in nature.
What did strike me was that there were two groups there showing software products. One, PC based, which obviously had its roots in Ethernet type stuff, and was slim, and the other, ARRP based, from the mainframe world delivered drivers that were 8-12 times the size and had 14 different ways of opening a file.
One this was the first time that either of them learnt of the existence of the other.
That was the IBM of those days!
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/10/2014 01:00 PM, Anton Aylward wrote:
Networking wasn't available to them in those days. Well, OK, there was UUCICO/UUCP over serial lines, store and forward of files, but not the kind of networking that would allow file systems to be shared.
Ethernet wasn't commercially available until 1980[1]. I'm sure DEC had other tweaks for letting machines cooperate but I don't recall them being used in even V6 and V7, for which I wrote many device drivers.
Actually, networking was available then. ARCnet was announced in 1977 and I used to work on a network that first saw use in the late '60s. I worked on some Collins C8500 computers in the Air Canada reservation system, starting in early 1978. It used an 8 Mb/s time division multiplexing (TDM) ring. An older version, running 2 Mb/s was available in the late '60s. The devices were assigned time slots in which to transmit and the receive would listen to that time slot. That network was used to connect tape stands, disk drives and more to the CPU. It even supported inter-CPU communications. So, "file sharing" over a network was certainly available by the time Unix was created. A little more than half way down the page (1968: Monstrous Computers and Huge Disk Drives) in the attached link are some "CCNT" photos. That should actually be CNT for CN Telecommunications, a company I used to work for. The equipment shown there is the older B system, which ran the 2 Mb ring and not the C system used in Air Canada, which I worked on. There are a couple of photos of disk drive cabinets shown. Those cabinets, fully loaded, supported 80 MB, IIRC. Each platter was about 4' diameter, 3/8" thick and made of magnesium. The heads were bigger than a quarter and had hydraulic servos (What a stink when there was a leak!). The drive was driven by a 3 horsepower motor. They'd connect to the CPU via 2 Mb ring running on RG-58 coaxial cable. The lower 2 boxes in the picture marked C8500 computer were the memory modules. IIRC, a full system held 64K bytes. I still have one of the core memory planes from one of those modules. Incidentally, the Collins computers were mil-spec versions of an IBM mainframe. As the page shows, those photos were taken in 1968, 4 years before I started with that company. http://www.antiquehistory.net/Collins/ I don't know why they refer to those as C8500, as that model came later, as was used in Air Canada. I've always known them to be the B8500 system. BTW, those computers shown in the article were installed on the 4th floor at 151 Front St. W., in Toronto, Ontario. The Air Canada system I worked on was on the 6th floor and later expanded to the 7th floor. That building is now a "fibre hotel" where the various carriers and ISPs meet to exchange data. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/10/2014 01:37 PM, James Knott wrote:
On 06/10/2014 01:00 PM, Anton Aylward wrote:
Networking wasn't available to them in those days. Well, OK, there was UUCICO/UUCP over serial lines, store and forward of files, but not the kind of networking that would allow file systems to be shared.
Ethernet wasn't commercially available until 1980[1]. I'm sure DEC had other tweaks for letting machines cooperate but I don't recall them being used in even V6 and V7, for which I wrote many device drivers.
Actually, networking was available then. ARCnet was announced in 1977 and I used to work on a network that first saw use in the late '60s. I worked on some Collins C8500 computers in the Air Canada reservation system, starting in early 1978. It used an 8 Mb/s time division multiplexing (TDM) ring. An older version, running 2 Mb/s was available in the late '60s. The devices were assigned time slots in which to transmit and the receive would listen to that time slot. That network was used to connect tape stands, disk drives and more to the CPU. It even supported inter-CPU communications. So, "file sharing" over a network was certainly available by the time Unix was created.
Indeed. And SNA dates back to 1974. But I was dealing with the specific case of those poor guys at Bell labs who were finessing budgets to get a PDP-11 to play with, not a fully financed mainstream development project with ample funding that could draw on leading edge technology from any vendor, pick and choose. In fact the roots of UNIX go back to 1969 and a scavenged PDP-7 ... http://cm.bell-labs.com/who/dmr/hist.html -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/10/2014 02:35 PM, Anton Aylward wrote:
In fact the roots of UNIX go back to 1969 and a scavenged PDP-7 ...
Yes, I was already aware of that, but your statement about networking not being available did not mention that specific situation, so I took the more general meaning, which indeed makes your statement wrong, as networking was around before then. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/10/2014 02:44 PM, James Knott wrote:
On 06/10/2014 02:35 PM, Anton Aylward wrote:
In fact the roots of UNIX go back to 1969 and a scavenged PDP-7 ...
Yes, I was already aware of that, but your statement about networking not being available did not mention that specific situation, so I took the more general meaning, which indeed makes your statement wrong, as networking was around before then.
I said that networking wasn't available to them then. Perhaps I should have written that emphasising the THEM or the the THEN in that clause. If I had it would have been very clear that I meant a specific situation involving specific people at a specific time. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2014-06-10 19:00, Anton Aylward wrote:
On 06/10/2014 10:10 AM, Carlos E. R. wrote:
For instance, you could have a bunch of small machines sharing a single "/usr" tree remotely, over the network. This required the machine to boot, start up network, and an nfs client, using only /bin and /lib trees.
Ah, not!
Networking wasn't available to them in those days.
But /I/ was not talking of those days ;-) Rather current days. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Rodney Baker wrote:
The /bin vs /usr/bin split (and all the others) is an artifact of this, a 1970's implementation detail that got carried forward for decades by bureaucrats who never question _why_ they're doing things. It stopped making any sense before Linux was ever invented, for multiple reasons:
---- In the 90's it made sense in that one usually partitioned the hard disk for various security, reliability and speed reasons. Most file systems still required "fsck" (even today most require "fsck") and having to wait for such on large systems can take a long time.
1) Early system bringup is the provice of initrd and initramfs, which deals with the "this file is needed before that file" issues. We've already _got_ a temporary system that boots the main system.
--- First FAIL. early system bringup, according to systemd literature, for speed, doesn't use initrd or initramfs. Therefore this is bogus point 1.
2) shared libraries (introduced by the Berkeley guys) prevent you from independently upgrading the /lib and /usr/bin parts. They two partitions have to _match_ or they won't work. This wasn't the case in 1974, back then they had a certain level of independence because everything was statically linked.
---- Bogus point #2. You put core libraries on the root disk. Things you need to support 1 user w/no network -- so no 'X', no desktop. This is where you put anything you need to restore other utils from backup. Ideally, you put stuff that doesn't need to be changed often so you can mount it r/o. Dev contained your fixed devices. If udev is broken and you didn't have the system devtmpfs, it was good sense to copy some recent version of /dev from when your system was working to /dev-static that you could copy to /dev and use for real on an emergency basis. The point above has become increasingly less useful as people who know how to operate a shell or repair their systems become a smaller fraction of the population.
3) Cheap retail hard drives passed the 100 megabyte mark around 1990, and partition resizing software showed up somewhere around there (partition magic 3.0 shipped in 1997).
---- Partition magic works for DOS, but can't resize most linux file systems. It still makes sense to have small paritions -- how big is your /boot partition? IF, you want reliability, it is separate, so you don't do things like 'defrag' it. A low-level boot strap program like lilo, doesn't need or want to know about the 20+ different file system formats, vs. something like grub[2] which becomes more complex the more file systems made available. With the direct boot ability in EFI, you are back to minimalist support. The Bios won't know about all the latest disk formats. It supports 1 partitioning scheme and something dynamic supports different file systems (if supported). The rest of the article fails being based on 3 initial false premises. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (9)
-
Anton Aylward -
Bernhard Voelker -
Carlos E. R. -
Dirk Gently -
Doug -
James Knott -
Linda Walsh -
Per Jessen -
Rodney Baker