Re: is there a version of unix written in Ada

[Shark8 <onewingedshark@gmail.com>]

On Monday, September 28, 2020 at 7:48:16 AM UTC-6, olivier wrote:
> On Monday, September 28, 2020 at 3:41:27 AM UTC-4, Dmitry A. Kazakov wrote: 
> > Le 27/09/2020 à 17:01, Dmitry A. Kazakov a écrit : 
> > To me a new OS must have new interface, which is a huge challenge, 
> > because interfaces of "modern" OSes are state of the art of late 70's.
> Any good references about that?

Ok, here’s some “modern” features from old Oses:
1.	https://en.wikipedia.org/wiki/Burroughs_MCP (1960s; appeared 1961)
	a.	Written exclusively in a high-level language (Algol), no assembler.
	b.	Typed, Journaling file-system.
	c.	Code can only be generated via trusted compilers.
	d.	Burroughs libraries:
		i.	Completely control access to shared resources,
		ii.	Allowed safe data-access w/o process switching,
		iii.	Offer procedural entry-points to the client which are checked for a compatible interface before the client is linked to the library (like Ada’s overloading resolution + type-checking),
		iv.	Have multiple sharing modes:
			(1)	‘shared by rununit’ — designed for COBOL, where a rununit is “an original initiating client plus the libraries it has linked to” and each rununit gets a library instance,
			(2)	‘shared by all’ — all clients share the same instance,
			(3)	‘private’ — each client gets a separate instance of the library.
		v.	
2.	https://en.wikipedia.org/wiki/Multics (1970s; appeared 1969)
	a.	“single-level store for data” — meaning there was no distinction between ‘disk’ and ‘memory’ — mapped all data into the address-space. In POSIX-terms this is similar to every single ‘file’ being mmap’ed.
	b.	CPUs, memory, and disks could be added/removed while the system was on-line due to extremely aggressive on-line reconfiguration support.
	c.	Designed to be a secure operating system, with more failures at the outset than they would have liked, by 1985 the OS reached th B2 level in the Orange Book (Trusted Computer System Evaluation Criteria; mentioned upthread).
3.	https://en.wikipedia.org/wiki/OpenVMS (1970s; appeared 1977)
	a.	Common Language Environment, a standardized mechanism for interoperability between different programming languages. (Similar-ish to DOTNET’s CLR.)
	b.	Integrated database.
	c.	Easy clustering.
	d.	DCL: An extensible command language.
	e.	DECnet: An OSI (7–layer) networking.
4.	https://en.wikipedia.org/wiki/Rational_R1000 (1985)
	a.	Combined OS, IDE, and Ada compiler into a single unit; see: http://www.somethinkodd.com/oddthinking/2006/01/07/rational-1000-a-surprising-architecture-from-a-surprising-source/
		i.	“Then they brought out a big whisk and mixed all the layers in together. The IDE was the operating system. The operating system was the Ada compiler. If you opened a command window to write a quick batch job, you wrote the batch job in Ada, using the IDE!”
	b.	Configuration management
	c.	Version control
	d.	Interactive design rule-checking and semantic-analysis
	e.	Source level debugging
	f.	Persistent memory/objects (?)

Those are just four old, and non-unix, operating systems which have relatively ‘modern’ features just being incorporated into newer OSes (and IDEs in the case of the R-1000). There are also many alternative modes of thought as to the architectures for computers: from proposed ‘Database-machines’ to ‘Dataflow-machines’ of the ‘70s & ‘80s, to the modern massively parallel machines like the GA–144, to memristor-based neural machines.

So, what would we want for an Ada OS? (Disregarding, for a moment, the base hardware.)

1.	Persistent objects (as per Dmitry)
2.	Content Addressable Memory-Architecture (?)
	a.	Pro:
		i.	Makes the natural access an ‘object’ rather than a base ‘address’.
		ii.	Actively breaks the idea that the system should be compatible with C.
	b.	Con:
		i.	Makes Ada 'Access a bit more odd.
		ii.	Makes most memory tricks invalid.
3.	Integrated Database
	a.	Pro:
		i.	Makes searching, collating, and certain manipulations easier.
		ii.	Could be integrated with analytic units.
		iii.	Provides a universal, common interface to persistency… at least across the OS.
	b.	Con:
		i.	The sort of database impacts how familiar or useful the system is.
			(1)	Relational, most familiar to DBAs;
			(2)	Hierarchical, could be used to easily implement Version-Control, Continuous-Integration, and possibly directory-like navigation;
			(3)	Document, excellent for researchers and librarians;
			(4)	Graph, very general and could likely be able to replicate any of the above models… the problem here being having a good “model-map”.
		ii.	“What about vendor lock-in!!”
4.	An integrated SMT prover?
	a.	Pro:
		i.	accessible to databases (for searching and filtering),
		ii.	accessible to compiler (perhaps for validating),
		iii.	Symbolic-execution (for analyzing programs & data),
		iv.	The ability for SPARK-style proving to be uniform on the platform regardless of client-language. (See item 7.)
	b.	Con:
		i.	More work,
		ii.	Would require some thought on the design.
5.	A SOM/DSOM-like based OS-level type-system
	a.	Extended with the base meta-object having ASN.1 serialize/deserialize methods.
	b.	Incorporated into an OpenVMS Common Language Environment-like system, thus making it available for all supported programming languages.
	c.	Having types for:
		i.	Universal Integers (?);
		ii.	Universal Floats (?);
		iii.	Universal Fixed-points (?);
		iv.	Email-address, preventing idiotic definitions like “a string with the ‘@’ symbol inside” that are apt to occur with regex;
		v.	phone numbers, the same but with phone-numbers;
		vi.	ISBN, useful for researchers/reference;
		vii.	DOI, useful for researchers/reference;
		viii.	WCS, useful for location;
		ix.	Time and Date;
		x.	If possible, more IR-ish constructs like:
			(1)	TASK — possibly allowing us to serialize/deserialize across a cluster’s machines,
			(2)	PACKAGE — allowing us to have a ‘native’ module,
			(3)	GENERIC — allowing us to paramaterize compile-time,
			(4)	subprograms — possibly allowing us to distribute subprograms, and
			(5)	parameters — if we generalize to an “abstract parameter” or “parameter-interface”, we could use the same construct for compile-time [ie generics] and run-time.
		xi.	If item x is implemented into the system then perhaps an interface for compilers, this could allow us to hook into the SMT prover and automatically get trusted compilers like 1.c.
6.	OSI-style networking
	a.	Pro:
		i.	This could allow client-programs to be essentially independent of network protocols in source-code.
	b.	Con:
		i.	This would throw off a lot of people that are used to depending on things like Connect( “http:some.site.org”, 1010 ); likely won’t enjoy this;
		ii.	Some method of indicating generalized connectivity might need designed.
		iii.	Using a pipe, configuration, or some other interface to set the appropriate parameters might be considered insecure.
7.	Ground up proving and verification via SPARK, where possible.

I have some more ideas in my notes, one of which would be simultaneous development on multiple architectures like, say, SPARC, x86, Motorola 68k, and a virtual trinary-machine (this way shift-right and -left are multiples of 3 rather than 2) — this would be useful for eliminating the inherent reliance on low-level implementation details outside of implementation-dependent packages, and would likely help reduce the scope of such packages.