From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.5-pre1 X-Received: by 2002:a37:7805:: with SMTP id t5mr1042484qkc.157.1601321785191; Mon, 28 Sep 2020 12:36:25 -0700 (PDT) X-Received: by 2002:ac8:70c3:: with SMTP id g3mr3198431qtp.253.1601321784996; Mon, 28 Sep 2020 12:36:24 -0700 (PDT) Path: eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder1.feed.usenet.farm!feed.usenet.farm!news.uzoreto.com!feeder1.cambriumusenet.nl!feed.tweak.nl!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Mon, 28 Sep 2020 12:36:24 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=146.5.2.231; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 146.5.2.231 References: <00cd3aaa-d518-43a2-b321-58d6fae70aebo@googlegroups.com> <57eb7a65-51ea-4624-b9dc-9c4dda0fee59n@googlegroups.com> <5f70fd3b$0$13541$426a74cc@news.free.fr> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <702c634f-a6ea-4514-ade5-cb26ae60d45cn@googlegroups.com> Subject: Re: is there a version of unix written in Ada From: Shark8 Injection-Date: Mon, 28 Sep 2020 19:36:25 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader02.eternal-september.org comp.lang.ada:60322 List-Id: 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 wrot= e:=20 > > Le 27/09/2020 =C3=A0 17:01, Dmitry A. Kazakov a =C3=A9crit :=20 > > To me a new OS must have new interface, which is a huge challenge,=20 > > because interfaces of "modern" OSes are state of the art of late 70's. > Any good references about that? Ok, here=E2=80=99s some =E2=80=9Cmodern=E2=80=9D 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= =E2=80=99s overloading resolution + type-checking), iv. Have multiple sharing modes: (1) =E2=80=98shared by rununit=E2=80=99 =E2=80=94 designed for COBOL, wh= ere a rununit is =E2=80=9Can original initiating client plus the libraries = it has linked to=E2=80=9D and each rununit gets a library instance, (2) =E2=80=98shared by all=E2=80=99 =E2=80=94 all clients share the same= instance, (3) =E2=80=98private=E2=80=99 =E2=80=94 each client gets a separate inst= ance of the library. v.=09 2. https://en.wikipedia.org/wiki/Multics (1970s; appeared 1969) a. =E2=80=9Csingle-level store for data=E2=80=9D =E2=80=94 meaning there w= as no distinction between =E2=80=98disk=E2=80=99 and =E2=80=98memory=E2=80= =99 =E2=80=94 mapped all data into the address-space. In POSIX-terms this i= s similar to every single =E2=80=98file=E2=80=99 being mmap=E2=80=99ed. 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 out= set than they would have liked, by 1985 the OS reached th B2 level in the O= range 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 interoperabil= ity between different programming languages. (Similar-ish to DOTNET=E2=80= =99s CLR.) b. Integrated database. c. Easy clustering. d. DCL: An extensible command language. e. DECnet: An OSI (7=E2=80=93layer) 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-architec= ture-from-a-surprising-source/ i. =E2=80=9CThen they brought out a big whisk and mixed all the layers in= together. The IDE was the operating system. The operating system was the A= da compiler. If you opened a command window to write a quick batch job, you= wrote the batch job in Ada, using the IDE!=E2=80=9D 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 relativ= ely =E2=80=98modern=E2=80=99 features just being incorporated into newer OS= es (and IDEs in the case of the R-1000). There are also many alternative mo= des of thought as to the architectures for computers: from proposed =E2=80= =98Database-machines=E2=80=99 to =E2=80=98Dataflow-machines=E2=80=99 of the= =E2=80=9870s & =E2=80=9880s, to the modern massively parallel machines lik= e the GA=E2=80=93144, 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 =E2=80=98object=E2=80=99 rather than a bas= e =E2=80=98address=E2=80=99. 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=E2=80=A6 at le= ast 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, Con= tinuous-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=E2=80=A6 the problem here being having a good =E2=80=9Cmodel-= map=E2=80=9D. ii. =E2=80=9CWhat about vendor lock-in!!=E2=80=9D 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 reg= ardless 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 m= ethods. b. Incorporated into an OpenVMS Common Language Environment-like system, t= hus 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 =E2=80=9Ca string = with the =E2=80=98@=E2=80=99 symbol inside=E2=80=9D that are apt to occur w= ith 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 =E2=80=94 possibly allowing us to serialize/deserialize across = a cluster=E2=80=99s machines, (2) PACKAGE =E2=80=94 allowing us to have a =E2=80=98native=E2=80=99 mod= ule, (3) GENERIC =E2=80=94 allowing us to paramaterize compile-time, (4) subprograms =E2=80=94 possibly allowing us to distribute subprograms= , and (5) parameters =E2=80=94 if we generalize to an =E2=80=9Cabstract parame= ter=E2=80=9D or =E2=80=9Cparameter-interface=E2=80=9D, we could use the sam= e construct for compile-time [ie generics] and run-time. xi. If item x is implemented into the system then perhaps an interface fo= r compilers, this could allow us to hook into the SMT prover and automatica= lly get trusted compilers like 1.c. 6. OSI-style networking a. Pro: i. This could allow client-programs to be essentially independent of netw= ork protocols in source-code. b. Con: i. This would throw off a lot of people that are used to depending on thi= ngs like Connect( =E2=80=9Chttp:some.site.org=E2=80=9D, 1010 ); likely won= =E2=80=99t enjoy this; ii. Some method of indicating generalized connectivity might need designe= d. iii. Using a pipe, configuration, or some other interface to set the appr= opriate 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 deve= lopment 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) =E2=80=94 this would be useful for eliminating the inheren= t reliance on low-level implementation details outside of implementation-de= pendent packages, and would likely help reduce the scope of such packages.