I think we shouldn't[1] be making Operating Systems, per se, but something like Operating Environments. An Operating Environment (OE) would be a new interface, maybe shell and APIs to access file systems, devices, libraries and such -- possibly one that can be just launched as an application in your host OS. That way you can reuse all facilities provided by the host OS and present them in new, maybe more convenient w…
It sounds to me like you are describing Linux desktops.
Catalog of Novel Operating Systems
41–50 of 65 posts
Re: Catalog of Novel Operating Systems
#42Are there any operating systems designed from the ground up to support and fully utilize many processor systems? I'm thinking systems designed based on the assumption that there are tens, hundreds or even thousands of processors, and design assumptions are made at every level to leverage that availability
Re: Catalog of Novel Operating Systems
#43I would love to see some examples outside of the WIMP-based UI
Maybe a catalog of kernels?
Re: Catalog of Novel Operating Systems
#44Earlier quoted context omitted.
It sounds to me like you are describing Linux desktops.
I'm assuming something more like Qubes, with proper isolation between groups of processes.
Generally the idea is to expand UX in more interesting/fun directions without incurring significant hurdles associated with an OS (where everything needs to run reliably and be secure).
I've found this quite interesting related discussion: "Classical "Single user computers" were a flawed or at least limited idea" https://utcc.utoronto.ca/~cks/space/blog/tech/SingleUserComp... (discussion on lobste.rs: https://lobste.rs/s/plkdy5/classical_single_user_computers_w...)
Re: Catalog of Novel Operating Systems
#45Re: Catalog of Novel Operating Systems
#46This list should include SerenityOS IMHO. It might not be super unique but is a truly from-scratch "common" operating system built in public, which for me at least puts it at the position of a reference of an OS of whose code one person can fully understand if they'd want to understand the codebase of a whole complete-looking OS.
Re: Catalog of Novel Operating Systems
#47Earlier quoted context omitted.
I don't really understand or appreciate a distinction. The seL4 design was used as a starting point and small changes were made mostly as a matter of API convenience. I consider the design of an operating system to be by far the most difficult part, and the typing to be less impressive/important. Helios hasn't done anything novel in terms of operating system design. It's taken an excellent design and reimplemented it…
Usually "based on" means the original codebase is mirrored/extended. Arguably if what you say is true, that is Helios' design has minor differences to seL4, then "based on" in reference to the design is indeed better description than "inspired from" which makes it sound (imo) to have significant changes.
Re: Catalog of Novel Operating Systems
#48MercuryOS reminds me of the Apple Lisa - The way it managed applications invisibly was a step in the direction of selecting tools based on intentions. It was a document-centric system, which MercuryOS isn't, but a step in the same direction. For some time, Windows 95 (IIRC) had a Templates folder. You'd put documents in it and you could right-click a folder and select New->Invoice or something similar based on what y…
Re: Catalog of Novel Operating Systems
#49Re: Catalog of Novel Operating Systems
#50I think we shouldn't[1] be making Operating Systems, per se, but something like Operating Environments. An Operating Environment (OE) would be a new interface, maybe shell and APIs to access file systems, devices, libraries and such -- possibly one that can be just launched as an application in your host OS. That way you can reuse all facilities provided by the host OS and present them in new, maybe more convenient w…
My ideas involve avoiding many of the features of modern systems.
Mine does not use: ambient authority, Unicode, file names, environment variables, command-line arguments (although there is an "initial message" which has a similar use), USB, spyware, worthless excessive animations (some animations are useful (but should still be possible to adjust the speed and disable them entirely), such as objects moving around so that you can more easily see where they went to), etc.
However, as important as what to be avoided, also are things which it would include, such as:
- Separate Command and Control key (like Macintosh has). There are other differences of the keyboard as well, and also differences in the working of the keyboard manager program. The application can request the application keyboard mode, which can be TRON code, or a specialized 8-bit character set (e.g. APL), or command mode, or game mode, or hybrid mode.
- Deterministic execution. A program's execution with the exception of messages sent/received by I/O is deterministic (and the I/O can always be overridden, so if the input is recorded and replayed, the output will also be the same, even if you run it on a different computer).
- Capability-based security with proxy capabilities. All I/O must use capabilities (a program that no longer has any usable capabilities is automatically terminated (unless a debugger is attached); this is one of the two "normal" ways to terminate a program, the other being to do an uninterruptible wait for any one of an empty set of objects). All messages between capabilities consist of bytes and/or capabilities, and when a program starts it receives an initial message, which should contain some capabilities (since if it doesn't, the program is immediately terminated unless a debugger is attached). A program can also create its own "proxy capabilities" and give those instead of the original one; the receiver cannot tell the difference.
- Deterministic execution and proxy capabilities are also useful for such things as: software testing, resist fingerprinting, etc.
- File system with forks. The forks are identified by 32-bit numbers, and the 16-bit numbers have a common meaning while higher numbers have meanings specific to the files. The file management functions of the system allow accessing and dealing with all of the forks. One of these forks is used for specifying the expected type of the initial message (this is like having typed command-line arguments instead of being untyped, but it is also used to provide capabilities for I/O, and other stuff).
- Transactions and locks on multiple objects at once (including objects in the file system, but also remote objects).
- Hypertext file system. Files can contain links to other files. There are no directory structures; you can use hyperlinks instead.
- Versioned file system. A link to a file can also optionally be for a specific version of the file. This means that one of the forks can be used to make a chain of the versions of the file.
- Extended TRON character code.
- A common data format used for most files as well as for a lot of the data being communicated between programs. This is a type/length/value format, a bit like DER but with many differences. This can allow potentially any files to contain potentially any kinds of data, and has a common representation for many types which can then be extended by the use of extension types. It also allows formatted text (rather than only plain text) to be used in many more parts of the system, and allows data to more easily be transferred between programs on the system. In addition, this allows the system to work more consistently.
- Tagged data and extensions. The common format would also allow such things like tagged data, e.g. that a number is some value according to a unit of measurement (that you can then do things with it e.g. automatically convert them to other units of measurement). Extensions are also possible.
- "Reveal Codes". If the file can contain formatted text, then revealing and dealing with the formatting codes directly is necessary during editing, even if the formatted text can also be displayed without revealing the codes. WYSIWYG without reveal codes is no good; and, actually, it would not quite be WYSIWYG anyways (since the formatting does not necessarily appear the same everywhere and is not intended to do so) (although there can be print preview as well, in case you actually do want to preview exactly what it looks like, to be more WYSIWYG).
- Command, Automation, and Query Language. This is a programming language which is also used for the command shell, and the common type/length/value format can be queried and manipulated with this. It can also be used to create proxy capabilities, and for communication between programs. Many kinds of mathematical and scientific functions are also available (for example, it supports big integers and big rationals, as well as matrices, etc). Functions from other programs can also be copied and automated, e.g. a data table displayed by another program can be queried, the function of a command button can be placed inside of a loop with other commands (delays, conditions, etc), etc.
- Better i18n, m17n, l10n, a11y, etc. Paper size settings do not belong in the locale setting (they belong in the printer driver configuration instead). Date/time formats do belong with the locale setting but should not be identified by language; instead an application program can call the i18n functions to format the date/time without needing an identifier. Telephone number formats do not belong with the locale setting either; this information is a combination of the data being handled and the modem configuration. There are many other improvements to be made as well; simply translating text, date/time, etc, is not good enough. Furthermore, accessibility features can be useful for everyone, and are not only for blind people etc.
- Space-age time keeping.
- Window indicators, which are associated with the capabilities of that window and can be used to monitor and control them. Some might also be usable for arranging windows, making tabbed windows and separating them, etc. This means that the application programs do not need to do many of these things, which makes the system working more consistently as well as not requiring application programmers to add all of the functions (and those that will be added can often be easier to do).
- Improvements of the C programming language.
- All functions can be used by the command shell and most also can be used by GUI, so both are available. Command shell and GUI also can be used together in a way that works much better than most other systems do, because you can easily move and copy data between them (see above about Command, Automation, and Query Language).
- If a new version of the CPU is available with new instructions, the new version of the operating system can emulate those instructions.
- Don't try to hide stuff from the operator; allow the operator to decide what kind of security they want and to program what the operation of the computer should do. Everything must be documented, and the core system must be FOSS as well, that it can also be examined, understood, altered, etc. The system also can be customized according to your use (including colours, fonts, font sizes, window management, keyboard layouts, substitutions of various things (including proxy capabilities), etc).
- And even more things than just this, too.