Describe your dream OS

[mmdmine]

my dream os boots fast, and has a clear and easy-to-use api. there's no duplicate function in its library and all of them are well documented. also it has a beauty gui. it's a user-friendly and programmer-friendly os.

[portasynthinca3]

My dream OS should boot in seconds even off of my relatively slow hard drive.
It should have the ability to launch user applications.
Its UI should be dark and flat with slightly rounded corners.
It should have some built-in way to quickly write your own programs in an easy to learn and use language like Python for all your everyday needs.
It should be UEFI-only and x86-64-only.

So, the thing that I've just described is the goal for my OS too. Because who would design an OS in such a way that they don't like it themselves?!

[nullplan]

my dream os boots fast, and has a clear and easy-to-use api. there's no duplicate function in its library and all of them are well documented. also it has a beauty gui. it's a user-friendly and programmer-friendly os.

Unfortunately, you haven't said anything there. Nobody wishes for their OS to take half an hour to boot, and have an obtuse API, lots of barely-different functions, all of them undocumented, an absolute pig of a GUI, and neither users no programmers want to work with it. All of the buzzwords you gave sound good to hear, but don't really convey meaning. How much do you want fast boot times, or rather, are you willing to compromise on functionality for the sake of faster boot times, and to what extent?

Ease of use for an API is supremely subjective. I hear there are even people who like the BSD socket API. Most others think the people who came up with it must have been drunk. Or high. It was the seventies, after all.

Duplication of functionality is often a result of evolution. E.g. Linux has system calls fork(), vfork(), and clone(), the latter being a superset of both fork() and vfork(). It was developed later. Keeping the fork() system call around, however, allows binaries originally built for Linux 0.1 to run on a laptop from this year. So are you saying you would compromise on compatibility for the sake of trimming fat from your system calls? This stance has merit, if you don't think your OS will be around for long, or the userspace will just be rebuilt every so often. It does allow for a leaner kernel.

Also, user-friendliness and programmer-friendliness are often at odds. How do you wish to achieve the former? One way would be to force programmers to all use the same widget tool kit, leading to a consistent look and feel across all applications (like e.g. Mac OS does), but programmers are not going to find you forcing things on them very friendly. I personally dislike developing for Android, just because then I have to use Java, and the only aspect of Java I like is that its inception indirectly lead to RAM prices dropping like a stone (since it is so memory-hungry).

[mmdmine]

@nullplan boot time depends on system resources. for an average system 15 seconds may be good.
your right. i didn't described in details. actually i dont know what i need myself, but i like speed and stability with good user exprience.
compalibility is needed but it make things difficult and unstable. we can still patch older programs to be compatible with newer OSes.
java on android is a bit different, that high memory usage is for jvm and android doesnt have. also android uses kotlin instead of java since 2 years ago.

[Qbyte]

If I may add my $0.02 on the "header" debate, the difference is basically this:

• what a header (ELF, PE, whatever) does is to provide necessary information (passively) in a format that can easily be parsed by another process, e.g. the dynamic loader, or debugger.
• what Qbyte is argueing here is to have the same information provided by the executable, in that the executable (actively) gives the information to the system via a series of system calls.

I tend to be on iansjack's side here.

For one, not every time I want those informations I am willing (or able!) to actually run the code (yet). Debugging springs to mind: If the code in question doesn't run, a passive header would still provide useful information, while relying on active collaboration of the binary breaks. Fat binaries, cross-compilation or multilib environments, or scatterloading are similar, where you can't just "jump to $0 and run with it".

Second, as for claims to efficiency, information from a passive header can be read by e.g. the dynamic loader in one go. Actively passing the information to the system would either require multiple system calls (and thus context switches), or all the information being in one block (i.e., a header, at which point you've come full circle).

I wouldn't call it full circle, because it actually increases program flexibility without sacrificing efficiency. That is, the header can now be located anywhere within the program image, or even outside of it in a separate file if desired. Additionally, it allows a program to perform checks before it actually passes the program header to the os for initialization, which can be useful in some niche contexts. The programs which benefit from being headerless can be so, while not affecting ones that use headers in any in any signficant way, since they can simply pass a pointer or handle to the header in a system call immediately at start-up. This can also be considered part of a broader system design which states that the contents of all files should just be their raw data, with metadata being the responsibility of the host system.

[PeterX]

I personally don't understand what's so good about headerless program files or dynamic/variable headers. A fixed header at the start of the file seems like a good idea to me.

And if a program has to do a system call to initialize/request its header, then the OS has some extra work to check that a program makes such a system call.

Greetings
Peter

[SeaLiteral]

Some features:

• Boots quickly,
• has a nice GUI,
• not buggy,
• can show its interface in Danish, Spanish, English, and other languages,
• accessible,
• supports a bunch of hardware,
• plenty of userspace software,
• support for showing local time and date,
• nice source code,
• there's probably lots of things I'm missing.

And then I guess I should try to explain those in detail:

Boots quickly? I guess that's more of a problem if you don't show a progress bar than if you do. But having to wait several seconds for the progress bar to appear (or even for the screen to turn on!) isn't very nice. Also, not booting fifty times slower on some days than others just because it downloaded an update that it needs to install while booting. I guess I'd like something that gets to the login screen in less than eight seconds, and from that to the desktop in one second, would be nice.

And what's a nice GUI? One that won't randomly change icons and move them around so that I can't find the buttons I'm looking for and have to learn a new GUI every time the developer chooses to release a new cosmetic update. I like having the clock at the top of the screen, but others like it at the bottom, so I guess it would be nice to have something that lets people choose. And if someone wants a clock in each corner of the screen or no clock at all, let them have that. Also, I want a clock with hours, minutes and seconds, because without the seconds I can't see quickly if the clock has frozen/crashed. And getting into the light/dark debate, I think I like black text on pastel-colour backgrounds, if that makes sense. But like the clock, it should be configurable. Actually, cosmetic updates might be okay, but make it very easy for people to choose whether they want them or not.

I don't like bugs. So I guess I shouldn't like programming then. (Lowers eyebrows) but I think I do. (Back to a "normal" facial expression) I don't want it crashing all the time, or only booting half the times I tell it to, the other times showing a black screen (or an abstract painting). Useful error messages might make the occasional error a bit more reasonable.

Showing the interface in different languages, ideally being able to change the language without having to log out and back in. Maybe even being able to change the language of all running applications as easily as you can change the keyboard layout. I also want to be able to use the OS when writing text in any language, so non-Latin font rendering should work too.

Accessibility? Well, I mentioned pointless interface changes already. I guess you could add a screenreader, a screen section magnifier, interface customization (already mentioned that), input method customization, speech input, Braille device support, maybe even a sign language interface (or maybe just documentation on video in some sign languages).

Hardware support? I guess it depends on the OS. I don't expect MAC OS to be compatible with non-mac computers, but I would like to be able to buy any keyboard, printer or other "normal" USB device and expect it to work out of the box. Or maybe for the less common devices (except network cards!) the OS downloading drivers automatically (maybe asking first, in case I don't want to do that right now) would work too. And make it a microkernel or similar so that installing the drivers won't require restarting the computer.

In the userspace, I'd like a text editor, a shell, a calender, development tools, an image editor, a web browser, a file manager and a bunch of other things.

In my country (Denmark... although I grew up in Spain, but I'm also male, left-anded and born on a Wednesday), there's nothing odd about refering to today as the Tuesday in the 29th week of 2020. Calendar apps made in English-speaking countries tend to not know that format though. I think if I make an OS myself and it has a calendar, it should support both English timing and Danish timing.

And nice source code? Well, I don't like messy source code. Variables should have reasonable names, code should be readable, indentation consistent, comments useful... And if I'm writing it myself, I probably want it to be open-source, although I'm not quite sure which lisence to use. (Is that how you spell lisence? I don't have speech recognition on this laptop yet, so I typed everything by hand.)

At this point I have a kernel I tried to write in 2017, and it seems fast to boot in QEMU, but there's no GUI, it's buggy, everything is in English, no colour changing, no non-visual output, no input (I do have some ramdisk reading code, in a language I don't have a cross compiler for, but is that even input?), just text mode output, no userland (I hope to add it sometime, along with ELF loading), and no concept of time. I guess the source code is readable though, but I might want to move some of the header files to another folder.

And there's probably lots of things I haven't even thought about, but which I will care about before I even get half of the above things right.

Stuff learned/learnt while writing this post:

• Using [*] without [list] doesn't make a list, it seems.
• It doesn't like like backslashes escape the square brackets. The only alternative I could find was bolding them.
• Today is the 197th day of 2020, according to my printed calendar. I wonder where in the world they use that date format.

[PeterX]

My ideal OS:

- written by me
- source code simple, easy to understand (no Linux kernel, no X, no systemd)
- supports most GNU/Linux applications, especially Firefox and Thunderbird and programmming tools
- supports many Windows/Wine applications
- is modular or even better layered (both the kernel and the userspace)
- has a GUI, but doesn't have to be a "cool", "modern", "elegant" or whatever GUI (I'm not a hardcore GUI fan/user)
- obvious: boots fast and is stable
- runs on UEFI-x64, Raspberry Pi (all models) and my (ARM) smartphone
- is good for tinkering with it
- supports most file systems
- has a GNU/Linux subsystem, a Windows/Wine one, a BeOS/Haiku one and an Apple/PureDarwin/GNUStep one.
- has cool and intuitive system tools.

Greetings
Peter

[thewrongchristian]

My ideal OS:

- written by me
- source code simple, easy to understand (no Linux kernel, no X, no systemd)
- supports most GNU/Linux applications, especially Firefox and Thunderbird and programmming tools
- supports many Windows/Wine applications
- is modular or even better layered (both the kernel and the userspace)
- has a GUI, but doesn't have to be a "cool", "modern", "elegant" or whatever GUI (I'm not a hardcore GUI fan/user)
- obvious: boots fast and is stable
- runs on UEFI-x64, Raspberry Pi (all models) and my (ARM) smartphone
- is good for tinkering with it
- supports most file systems
- has a GNU/Linux subsystem, a Windows/Wine one, a BeOS/Haiku one and an Apple/PureDarwin/GNUStep one.
- has cool and intuitive system tools.

Greetings
Peter

Wow, don't ask much, do you

Isn't:
- source code simple, easy to understand (no Linux kernel, no X, no systemd)

Sort of contradictory to:
- supports most GNU/Linux applications, especially Firefox and Thunderbird and programmming tools
- supports many Windows/Wine applications
- has a GNU/Linux subsystem, a Windows/Wine one, a BeOS/Haiku one and an Apple/PureDarwin/GNUStep one.

[PeterX]

Isn't:
- source code simple, easy to understand (no Linux kernel, no X, no systemd)

Sort of contradictory to:
- supports most GNU/Linux applications, especially Firefox and Thunderbird and programmming tools
- supports many Windows/Wine applications
- has a GNU/Linux subsystem, a Windows/Wine one, a BeOS/Haiku one and an Apple/PureDarwin/GNUStep one.

Yes probably it's contradictory
Maybe layered design helps? (Probably not enough...)

Greetings
Peter

[pedrolamarao]

My dream OS allows allocating temporary file storage without allocating a temporary file name.

[nullplan]

My dream OS allows allocating temporary file storage without allocating a temporary file name.

Linux has O_TMPFILE, with semantics similar to creating a file and immediately deleting it. You can even use linkat(2) to create the file later on for realsies.

[Seahorse]

I don't see why any OS needs to be perfect. Our quirks make us unique.

[eekee]

I think, after all the things I've wished for, I'm with Seahorse's opinion now. I think every OS dream contains self-contradictory elements, possibly excepting some from the most disciplined minds. Having said that, I wrote out what I thought was the biggest contradiction of my dreams, and realised it's not as bad as I thought: I want both low-level and safe, ideally. I put a in there, but then I remembered I can actually get something like that by using functional programming techniques in Forth, which is normal for Forth. My craziest dream is not completely unachievable any more than it's completely achievable... if that makes sense.

[Schol-R-LEA]

I regret everything about this thread. I apologize.