The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Abstractions
@ 2021-02-20 23:09 M Douglas McIlroy
  2021-02-21  8:15 ` Otto Moerbeek
                   ` (3 more replies)
  0 siblings, 4 replies; 47+ messages in thread
From: M Douglas McIlroy @ 2021-02-20 23:09 UTC (permalink / raw)
  To: tuhs

>  - separation of code and data using read-only and read/write file systems

I'll bite. How do you install code in a read-only file system? And
where does a.out go?

My guess is that /bin is in a file system of its own. Executables from
 /letc and /lib are probably there too. On the other hand, I guess
users' personal code is still read/write.

I agree that such an arrangement is prudent. I don't see a way,
though, to update bin without disrupting most running programs.

Doug

^ permalink raw reply	[flat|nested] 47+ messages in thread
* Re: [TUHS] Abstractions
@ 2021-02-24  4:18 Rudi Blom
  0 siblings, 0 replies; 47+ messages in thread
From: Rudi Blom @ 2021-02-24  4:18 UTC (permalink / raw)
  To: tuhs

Some additions:

Systems with /bin a symlink to /usr/bin
Digital UNIX 4.0
Tru64 UNIX 5.0 to 5.1B
HP-UX 11i 11.23 and 11.31

Systems with separate /bin and /usr/bin
SCO UNIX 3.2 V4.0 to V4.2

-- 
The more I learn the better I understand I know nothing.

^ permalink raw reply	[flat|nested] 47+ messages in thread
* Re: [TUHS] Abstractions
@ 2021-02-23 19:37 Nelson H. F. Beebe
  2021-02-23 21:02 ` Charles H. Sauer
  2021-02-24  1:51 ` Greg A. Woods
  0 siblings, 2 replies; 47+ messages in thread
From: Nelson H. F. Beebe @ 2021-02-23 19:37 UTC (permalink / raw)
  To: tuhs

The recent discussions on the TUHS list of whether /bin and /usr/bin
are different, or symlinked, brought to mind the limited disk and tape
sizes of the 1970s and 1980s.  Especially the lower-cost tape
technologies had issues with correct recognition of an end-of-tape
condition, making it hard to span a dump across tape volumes, and
strongly suggesting that directory tree sizes be limited to what could
fit on a single tape.

I made an experiment today across a broad range of operating systems
(many with multiple versions in our test farm), and produced these two
tables, where version numbers are included only if the O/S changed
practices:

------------------------------------------------------------------------
Systems with /bin a symlink to /usr/bin (or both to yet another common
directory) [42 major variants]:

	ArchLinux		Kali			RedHat 8
	Arco			Kubuntu 19, 20		Q4OS
	Bitrig			Lite			ScientificLinux 7
	CentOS 7, 8		Lubuntu 19		Septor
	ClearLinux		Mabox			Solaris 10, 11
	Debian 10, 11		Magiea			Solydk
	Deepin			Manjaro			Sparky
	DilOS			Mint 20			Springdale
	Dyson			MXLinux 19		Ubuntu 19, 20, 21
	Fedora			Neptune			UCS
	Gnuinos			Netrunner		Ultimate
	Gobolinux		Oracle Linux		Unleashed
	Hefftor			Parrot 4.7		Void
	IRIX			PureOS			Xubuntu 19, 20

------------------------------------------------------------------------
Systems with separate /bin and /usr/bin [60 major variants]:

	Alpine			Hipster			OS108
	AltLinux		KaOS			Ovios
	Antix			KFreeBSD		PacBSD
	Bitrig			Kubuntu 18		Parrot 4.5
	Bodhi			LibertyBSD		PCBSD
	CentOS 5, 6		LMDE			PCLinuxOS
	ClonOS			Lubuntu 17		Peppermint
	Debian 7--10		LXLE			Salix
	DesktopBSD		macOS			ScientificLinux 6
	Devuan			MidnightBSD		SlackEX
	DragonFlyBSD		Mint 18--20		Slackware
	ElementaryOS		MirBSD			Solus
	FreeBSD 9--13		MXLinux 17, 18		T2
	FuryBSD			NetBSD 6-1010		Trident
	Gecko			NomadBSD		Trisquel
	Gentoo			OmniOS			TrueOS
	GhostBSD		OmniTribblix		Ubuntu 14--18
	GNU/Hurd		OpenBSD			Xubuntu 18
	HardenedBSD		OpenMandriva		Zenwalk
	Helium			openSUSE		Zorinos
	
------------------------------------------------------------------------

Some names appear in both tables, indicating a transition from
separate directories to symlinked directories in more recent O/S
releases.

Many of these system names are spelled in mixed lettercase, and if
I've botched some of them, I extend my apologies to their authors.

Some of those systems run on multiple CPU architectures, and our test
farm exploits that; however, I found no instance of the CPU type
changing the separation or symbolic linking of /bin and /usr/bin.

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

^ permalink raw reply	[flat|nested] 47+ messages in thread
* [TUHS] Abstractions
@ 2021-02-21 10:47 Paul Ruizendaal
  0 siblings, 0 replies; 47+ messages in thread
From: Paul Ruizendaal @ 2021-02-21 10:47 UTC (permalink / raw)
  To: TUHS main list

To quote from Jon’s post:

> There have been heated discussions on this list about kernel API bloat.  In my
> opinion, these discussions have mainly been people grumbling about what they
> don't like.  I'd like to flip the discussion around to what we would like.


> Ken and Dennis did a great job with initial abstractions.  Some on this list
> have claimed that these abstractions weren't sufficient for modern times.
> Now that we have new information from modern use cases, how would we rethink
> the basic abstractions?

I’d like to add the constraint of things that would have been implementable
on the hardware of the late 1970’s, let’s say a PDP11/70 with Datakit or
3Mbps Ethernet or Arpanet; maybe also Apple 2 class bitmap graphics.

And quote some other posts:

> Because it's easy pickings, I would claim that the socket system call is out
> of line with the UNIX abstractions; it exists because of practical political
> considerations, not because it's needed.  I think that it would have fit
> better folded into the open system call.

>> 
>> Somebody once suggested a filesystem interface (it certainly fits the Unix 
>> philosophy); I don't recall the exact details.
> 
> And it was done, over 30 years ago; see Plan 9 from Bell Labs....

I would argue that quite a bit of that was implementable as early as 6th
Edition. I was researching that very topic last Spring [1] and back ported
Peter Weinberger’s File System Switch (FSS) from 8th to 6th Edition; the
switch itself bloats the kernel by about half a kilobyte. I think it may be
one of the few imaginable extensions that do not dilute the incredible
bang/buck ratio of the V6 kernel.

With that change in place a lot of other things become possible:
- a Kilian style procfs
- a Weinberger style network FS
- a text/file based ioctl
- a clean approach to named pipes
- a different starting point to sockets

Each of these would add to kernel size of course, hence I’m thinking about
a split I/D kernel.

To some extent it is surprising that the FSS did not happen around 1975, as
many ideas around it were 'in the air' at the time (Heinz Lycklama’s peripheral
Unix, the Spider network Filestore, Rand ports, Arpanet Unix, etc). With the
benefit of hindsight, it isn’t a great code leap from the cdev switch to the
FSS - but probably the ex ante conceptual leap was just too big at the time.

Paul

[1] Code diffs here:
https://1587660.websites.xs4all.nl/cgi-bin/9995/vdiff?from=fab15b88a6a0f36bdb41f24f0b828a67c5f9fe03&to=b95342aaa826bb3c422963108c76d09969b1de93&sbs=1



^ permalink raw reply	[flat|nested] 47+ messages in thread
* [TUHS] Abstractions
@ 2021-02-15 19:56 Jon Steinhart
  2021-02-15 21:52 ` Dave Horsfall
                   ` (4 more replies)
  0 siblings, 5 replies; 47+ messages in thread
From: Jon Steinhart @ 2021-02-15 19:56 UTC (permalink / raw)
  To: TUHS main list

Was thinking about our recent discussion about system call bloat and such.
Seemed to me that there was some argument that it was needed in order to
support modern needs.  As I tried to say, I think that a good part of the
bloat stemmed from we-need-to-add-this-to-support-that thinking instead
of what's-the-best-way-to-extend-the-system-to-support-this-need thinking.

So if y'all are up for it, I'd like to have a discussion on what abstractions
would be appropriate in order to meet modern needs.  Any takers?

Jon

^ permalink raw reply	[flat|nested] 47+ messages in thread

end of thread, other threads:[~2021-02-27  2:48 UTC | newest]

Thread overview: 47+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-20 23:09 [TUHS] Abstractions M Douglas McIlroy
2021-02-21  8:15 ` Otto Moerbeek
2021-02-21 11:08 ` Rich Morin
2021-02-21 22:40 ` Dave Horsfall
2021-02-21 23:01   ` Steve Nickolas
2021-02-23  3:31     ` Andrew Warkentin
2021-02-23 17:29       ` [TUHS] /usr separation (was: Abstractions) Greg A. Woods
2021-02-23 18:28         ` [TUHS] /usr separation Grant Taylor via TUHS
2021-02-23 18:57           ` Theodore Ts'o
2021-02-23 20:29             ` Grant Taylor via TUHS
2021-02-24 14:14               ` Theodore Ts'o
2021-02-24 17:50                 ` Grant Taylor via TUHS
2021-02-24 18:37                   ` Theodore Ts'o
2021-02-24 18:48                     ` Grant Taylor via TUHS
2021-02-25  3:38                       ` Theodore Ts'o
2021-02-24 20:25                     ` Steve Nickolas
2021-02-24 22:08                       ` Steffen Nurpmeso
2021-02-24  3:12         ` [TUHS] /usr separation (was: Abstractions) Andrew Warkentin
2021-02-22  0:13   ` [TUHS] Abstractions Warren Toomey
2021-02-27  2:47     ` Dave Horsfall
2021-02-23  0:25   ` Wesley Parish
2021-02-23  0:38     ` Steve Nickolas
2021-02-23  2:50       ` Theodore Ts'o
2021-02-23  3:19         ` Warner Losh
2021-02-23  1:47     ` Theodore Ts'o
2021-02-21 22:54 ` Clem Cole
  -- strict thread matches above, loose matches on Subject: below --
2021-02-24  4:18 Rudi Blom
2021-02-23 19:37 Nelson H. F. Beebe
2021-02-23 21:02 ` Charles H. Sauer
2021-02-23 21:15   ` Henry Bent
2021-02-24  2:47     ` Greg A. Woods
2021-02-24  3:20       ` Warner Losh
2021-02-24 20:05         ` Greg A. Woods
2021-02-24  1:51 ` Greg A. Woods
2021-02-24  2:23   ` Nelson H. F. Beebe
2021-02-21 10:47 Paul Ruizendaal
2021-02-15 19:56 Jon Steinhart
2021-02-15 21:52 ` Dave Horsfall
2021-02-16  7:13   ` arnold
2021-02-16  8:15 ` Tom Ivar Helbekkmo via TUHS
2021-02-16 10:04   ` Wesley Parish
2021-02-16 19:59   ` Jon Steinhart
2021-02-17  4:01     ` Theodore Ts'o
2021-02-17  6:50     ` Chris Hanson
2021-02-16 12:26 ` Rich Morin
2021-02-16 22:46 ` Steffen Nurpmeso
2021-02-17 12:09 ` David Arnold

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).