Ask HN: How would you design a Modern Operating System in 2022?

https://news.ycombinator.com/item?id=32813072

by Decabytes • 4 years ago

48 50 4 years ago

news.ycombinator.com

Disclaimer: Thought Experiment. Does not need to be "practical". Let your NIH flow and your imagination run wild

We've learned a lot about computers in the decades we've been producing. A lot of software assumes that computers work a certain way. See Go lang and how it handles file permissions. In the Linux Kernel drivers exist that supports the IBM 3270 Display System which at this point is over 50 years old. Terminal Emulators mimic the VT100. All of this makes sense given the context in which they were developed and created. But if you were developing an OS in 2022 without these constraints what would you remove and or change? Would you keep 32bit support? Arm, Risc and or x86?, monolithic or microkernel?, C, Rust, Zig, D, C++, or something else?, how would it talk to hardware?, what would your executable format look like?

Also if anyone has any interesting links to cutting edge research into Modern Operating Systems I'd love to browse them!

zamalek• 4 years ago

I think that the 'everything is a file' approach used by POSIX is partially flawed. There are certain fds that you can't interact with in the shell (I forget which, but it think it was container related). Ultimately these feel like cargo-culting and show the limitations of the POSIX model. However, a namespaced system (directories) containing endpoints (files) is a good idea.

I think that dbus does a much better job of this (and it should be possible to have a tool that interacts with the system bus on the CLI). I would definitely take more inspiration from dbus than POSIX for a modern OS.

bravetraveler• 4 years ago

I support this -- 'everything' being a file brings about some interesting scale problems.

Considering 9/10 the system we're using at any given moment is with defaults that weren't sane ten years ago...

guidoism• 4 years ago

If it’s at all going to be used as something used in real time by humans it absolutely has to be real time. Who cares if your compile takes 12ms longer if the screen doesn’t immediately react to your input.

arghnoname• 4 years ago

Academic research on this topic is limited, but ongoing. You'd want to look at OSDI and SOSP conferences--they're both OS conferences, even if only a few papers each year are actually about OS design. Lots of ideas there though.

HotOS is a workshop, but tends to be more creative and daring since it's just top researchers sharing their thoughts on OS design.

Off the top of my head in recent years you've had unikernels (e.g., mirageOS), barrel fish (multikernel), omnix (for dealing with lots of asics and other accelerators), and lots of modifications to existing OS design, like a ring-io like asynchronous system call mechanism (flexSC), systems for adding new abstractions off of modern hardware, like Dune, and of course ongoing work on microkernels, most significantly (and commercially), seL4.

Older research is still relevant. Capability systems and exokernels influence the above work and the original well-spring is still worth visiting.

Basically though, what you want to address are some of the following:

* Higher security requirements. Multitenancy is a given. Giant code blobs running without restriction in the same security domain (i.e., monolithic kernels) is a bad idea.

* Greater hardware support for differing security modes (virtualization, enclaves, trust zones, CHERI)

* Advances in compiler/language research and techniques for low-cost policy enforcement at the language level (to at least some degree), allowing for 'uploading' code into ring0 . Rust is the most popular example, but even just the eBPF trend is an example of this.

* Heterogenous hardware. How does the kernel handle differing cores with different performance characteristics, power requirements, capabilities, and even different ISAs? This is happening. Should the OS expose better primitives for ASICS and other accelerators?

* Cloud computing. Many big money work loads run under someone else's control with a hypervisor. This brings up attestation, but also raises the question if you're running a single application under a hypervisor (itself basically a microkernel), what do you need a full fledged kernel for? Similar to userland duplication with containers. Unikernels are one such response, but it's something that should be addressed.

All in all, pretty much anything I see in industry (conceptually) is trialed out in one form or another in academia many years in advance. Industry is theoretically where the really hard work of making it practical happens, but sadly this seems to very rarely happens.

benlivengood• 4 years ago

Capability systems approach what an operating system should be able to provide.

Formally proven software can close the gap. It's hard work. SeL4 is a formally proven microkernel; there is a machine-checkable proof that the C code is correct. There's also now proofs that for arm and risc the binaries are translated correctly from C [0]. It took years and is a huge accomplishment.

Operating system support for formal verification of the remaining software is the next theoretical step to achieving the security and reliability goals that modern OSs struggle with.

In addition to the parent's list, I'd add:

* Network-aware or distributed capabilities. The Internet is a huge part of modern computing and the fact that same-origin and CORS and friends are the best network object security paradigm we have is a little silly. It should be possible to refer to and interact with remote objects securely and with native syntax/semantics and have the operating system mediate any network interactions required for that.

[0] https://docs.sel4.systems/projects/sel4/frequently-asked-que...

rz30221• 4 years ago

and even different ISAs

That is super interesting. I did some Googling but couldn't find an example of one. Do you know of an example of an OS that can handle different ISAs? I suppose in some sense an accelerator can be considered a "core with a different ISA" but I interpreted the statement as basically supporting multiple ABIs in parallel. Maybe I overreached?

thesneakin2• 4 years ago

Hardware wise, going back to the '90s, there was the Suga Genesis with a 68k padred with a z80. Since then every PC with a 3d accelerator.

Software wise: something Java? Now we have Spir-V, WASM, and UEFI adding bytecodes for ISA interop.

Wowfunhappy3• 4 years ago

This is more on the UX side than the technical side, but: I'd like to see an OS with a really robust plugin system. One which prioritized plugins over new apps.

Right now, if an important feature is missing from e.g. the built-in calendar app, your only option is to throw away the entire app and replace it with something new. This new app is probably less integrated into the rest of the system, or may be missing some other feature you use, or may come packed with features but also a cluttered and confusing interface.

This causes OS vendors to pack too many features into their default app suites. Today's default apps are at once too barebones for advanced users (like most people who read Hacker News) and too complicated for e.g. my grandmother, who keeps accidentally recording iPhone videos with slow motion enabled.

I want an OS with a base feature set similar to early versions of iOS or the original Macintosh, but which can be easily extended by third party software. Need to batch rename calendar events, or send an email at a specific time of day? There is not an app for that—but there is a plugin!

Decabytes2• 4 years ago

I wonder if an image based programming language might be the best for this. I think that was the idea with Guile and Gnome apps, but the reality is a lot of people don't want to learn a whole other separate language to modify the UI.

Something Like SBCL or Pharo which have great reflective capabilities and can modify themselves easily at runtime would be great examples

zbuf• 4 years ago

Some memories of the old RISC OS (Acorn): There was an implementation of OLE (similar to Windows, I think) where a desktop publishing tool would display a frame containing data from another application. Double-clicking would open the other application to edit it. In later year I remember this extended to a demos of a concept called PCA where the application and its toolbars existing in-place.

I feel these concepts were along the right lines (and probably they go all the way back to Xerox PARC) but it would be interesting to come up with equivalents for a non document-oriented world -- embed an image in a calendar entry, edit it, send an email containing the calendar entries etc.

warrenm2• 4 years ago

Sounds like you long for the days of BeOS :)

Wowfunhappy3• 4 years ago

Does BeOS work this way?! Maybe I need to play with it. I booted Haiku in a VM once or twice but never really dig in further.

WorldMaker2• 4 years ago

I think it's past time that we started working on hardware machines that more closely resemble higher level languages than C/C++.

It's sometimes said that C/C++ are so performant because they are close to the metal, but I think often at this point we're seeing the reverse causal arrow: C/C++ remain so performant because that's still the "virtual machine" most modern processor/computer architectures are targeting. C/C++ ideas of memory management. C/C++ ideas of process/thread concurrency. No current processor architect would dare to break that model and do something in a new "modern" mold at the risk of sabotaging the performance of C/C++ apps that don't/can't/won't migrate to new paradigms/abstractions.

(Arguably that's part of the "betrayal" of the Meltdown and Spectre CPU timing bugs/hacks: the CPU doing too many things to mimic a C/C++ "machine" even though the raw details of the underlying concurrency model at the hardware have needed to vastly change and that abstraction break bleeding into a vulnerability. What if the hardware didn't have to work so hard to pretend to be a very fast C/C++ "strictly in order" machine? Could it be a faster machine if the abstractions it was targeting themselves were more concurrent and more secure?)

Lisp machines in the 70s had hardware memory garbage collectors. We've advanced the state of the art of memory garbage collectors quite a bit in the decades after, but few since have thought to again try to express that in hardware.

There have been dalliances with chipsets designed to more closely mimic the JVM (Java Virtual Machine) or CLR (Common Language Runtime; .NET's VM) that got some play in embedded design spaces, but the common echo was that they ran C/C++ code too slowly and were themselves labeled as "slow" and "not very useful for general purposes" (because we've tautologically defined C/C++ as "for general purposes").

It's easy to wonder if we could escape this trap of building our hardware machines to resemble our least capable, lowest common denominator "virtual machine" like the C/C++ model and push towards higher level concepts deep in hardware.

Lisp machines and JVM/CLR machines all have more interesting reflectivity over live objects than C/C++ machines. There's at the very least component model benefits to being able to get general information about the live object states. There's roads to more "Actor" based types of designs. More "object-oriented" possibility spaces than "files".

If you are talking about true, "clean slate", no concerns about backwards compatibility whatsoever, no concerns that interoperating with older software might need to be truly emulated and might possibly be slower in trade-off for better software design of new, non-emulated stuff, I think you might start at basic hardware assumptions and architectures. There's so much more to experiment there that we don't have the budget to explore if we have to continue to keep up the illusion that "C/C++ apps are fast and close to the hardware" for backwards compatibility's sake.

eimrine• 4 years ago

I think Lisp machines have a serious drawback. It means that OS will be totally open-source with no compilation-as-obfuscation ceremony, that leads to impossibility to show users ads and to lobby non-free software. Our bosses aren't ready for that paradigm shift and most of the people are O.K. to be useds.

lispm• 4 years ago

The actually existing Lisp Machines from the past typically run compiled code. The instructions generated usually were a bit higher level (more dynamic) than that of a typical CPU. The obfuscation is not that strong then. I saw commercial software which came only in a compiled version.

WorldMaker2• 4 years ago

There were open source ad networks. Displaying ads doesn't require closed source at all. In some cases it is as simple as a dynamic IMG tag with an API driven SRC. Tracking ads is where most of the grossest proprietary/closed source would be that ad networks wouldn't trust users to see, and arguably its much more user friendly to at least force more tracking to be open source (if not disable it entirely).

But as the other comment points out, open source was never a goal nor a requirement of historic Lisp machines. They were big expensive commercial ventures with tons of their own commercial and proprietary code. My understanding was that a lot of their software shipped as "live images" rather than "S-Expressions". Live images are a directly memory mappable binary code and like most binary machine codes still have multiple layers of necessary obfuscation. Even if you are designing a processor to resemble S-expressions, disassembling machine code isn't necessarily going to give you clean source back out.

Even building a processor with the goal of being "a Lisp", it's still going to be lower level than the Lisp you'd want to write as a developer. High level functions will still expand into lots of little low level instructions. That expansion process might be "macros" rather than "compilation", but it is still a similarly obfuscating process and shrinking patterns of low level operations back into their original macro definitions still relatively hard. That's where the name "Live images" especially comes into play: they are often captured some time after the program has been running. They are captured after most or all macros have finished expanding. They are captured long after most initialization steps have completed and are no longer needed in memory. That's stronger than the obfuscation afforded by compilation: entire sections of initialization code don't even exist in the final binary. You can't disassemble it at all because it ran on someone else's machine and was shipped pre-baked.

Same too that reflectivity does not mean "open source": Lisps still have "API boundaries" and most Lisps have robust object systems with all of the usual benefits of object-oriented programming. That includes encapsulation and private fields. You may have a very easy time inspecting the public API of objects, but the private internals are sometimes just as obfuscated blocks of binary data as any other not publicly documented structures in any other OO languages.

In short, building higher level processors does not mean building "highest level" processors where the processors understand 100% of the higher level language and disassembly looks exactly like their assembly language. Open source isn't "required".

scrubs• 4 years ago

A modern o/s might start around a better take on hw. For example non von Neumann memory. Put compute and data more side by side. Second, more orientation towards unikernels as a deployment unit. That'd change the roles and responsibilities of the kernel, development languages and DevOps too but maybe in a good way.

didgetmaster• 4 years ago

The OS should operate on top of an 'object store' instead of a file system. Just like OOP which uses inheritance, these persistent storage objects would inherit traits from higher up in their class hierarchy.

Normal files would just contain a 'bag of bits' like current file systems treat files. Objects would have attributes and methods that make them different than the other objects used by the system.

For example, the 'boot object' would just point to the 'loader object' which contained the IDs of all the operating system modules that are needed to get the OS up and running. You could have multiple loader objects (one for each OS or version of the OS you wanted to boot) within the same container. Imagine being able to have every Windows or Linux version installed within the same volume and be able to boot up any one of them! Files that are shared between OS versions would just have their IDs within both loader objects.

Configuration objects, logging objects, folder objects, policy objects, and other types of objects would be used by the OS for particular behaviors. Objects could also have attributes to distinguish between ones downloaded off the internet and ones the user created. (Why backup all those cat videos you could easily re-download?) Be able to easily distinguish all the photos from the documents even when there are millions of each and without having to memorize all their file extensions for various formats.

This is the system I have been building. https://www.Didgets.com

hoosieree2• 4 years ago

I'd like to see an OS where "your profile" is entirely in the cloud and every device you register becomes just another node. Your laptop, phone, desktop, smart watch, and homeserver are all just nodes with different capabilities. Some have touchscreens, some have GPUs, some have lots of memory, some are always-on, others are ephemeral.

I'd like to play a game on my phone but have my desktop's GPU render frames for me like Stadia.

I want my server to pick the next song in the playlist on my phone to match the tempo of the heart rate it hears from my watch.

I'd like to type "make -j" and have it transparently use every core ...on every device I own.

These things can be done today with ad-hoc hacks, but an OS designed around these ideas would mean you could write lots of programs very differently.

msmenardi• 4 years ago

Make "the cloud" a decentralized mesh network of people in your area and you're getting somewhere. I love the idea of a unified OS between all your devices, I guess Apple users have that experience already!

Decabytes2• 4 years ago

This is interesting and I have never really thought about this. Could you expand a little bit more on it? Would the still be stored locally or would the profile have all of your content (kind of like if your drop box was also your OS). And would these devices need to be always connected to the internet, or would they have capabilities on their own, and just be able to hook up to the cloud for more compute

Also how is this different from sshing into a system to do work and running jobs on a Linux box?

hoosieree2• 4 years ago

Those are great questions.

You could get 60% of the way there with Dropbox syncing your OS, with a few caveats (screen brightness should be per-device).

But if you start drafting an email on your phone, you probably would like to finish writing it and send it from your laptop. Gmail and Outlook do this today, but only because their phone app and their desktop app are working together with a remote server.

If I was building a prototype, I'd start with an always-connected model and "eager" state updates, because caching is hard. To support concurrent writers who both want to be able to undo each other's edits suggests using an OT[1] or CRDT[2] as the basic data type, rather than files. Each node regularly advertises its current capabilities (as well as things like impending sleep states or battery life) to a central scheduler which sends tasks to nodes and collects results. Note - a lot of these ideas come from a project by my colleagues called unis[3], but applied to the topic of operating systems.

There are some interesting design choices. Does the dispatcher make all the scheduling decisions, or can the user explicitly say things like "it's ok if Minecraft drops frames, but that background rendering job has to be done by 5pm"?

Synced settings are not qualitatively different from multiple clients SSHing into a Linux server, but if any client can suddenly turn around and start acting like a server on a whim, that would be cool.

[1] https://en.wikipedia.org/wiki/Operational_transformation

[2] https://en.wikipedia.org/wiki/Conflict-free_replicated_data_...

[3] https://github.com/periscope-ps/UNISrt/blob/develop/sphinx/g...

SenHeng• 4 years ago

I’ve always wanted an OS that supported multiplayers. So I can connect multiple keyboards and mice and there would be a corresponding cursor for each set. It feels like such an obvious feature but no one has it.

thesneakin2• 4 years ago

You want to play with Xorg's xinput command. Create a new keyboard / moise pair with it and two mice cursors! Window manager support still mostly lacking.

I_dev_outdoors• 4 years ago

This is possible with linux. https://forums.linuxmint.com/viewtopic.php?t=342686

It gets kinda tricky with the windowing environments which don't really support this use case this well.

speedgoose• 4 years ago

Microsoft did collaboration on the same device with the Surface/PixelSense touch tables. Many research papers were published but it wasn’t a commercial success.

vaughan• 4 years ago

Priority one would be debuggability.

Imagine being able to easily step through the entire execution from user to kernel space. And also step backwards. And also record replay.

And then make instant changes during dev to any layer of the stack.

Think about how much time is spent across so many different tools trying to figure out perf bottlenecks.

Then think about if you wanted to patch something or write a driver, how difficult it is.

Then you would also want the entire system visualizable.

Imagine if the entire data flow and data structure of the system were automatically visualizable by instrumenting the source code. Why do we draw diagrams on whiteboards if they are not the best way to understand code.

Do this first and the rest becomes easy.

fsflover• 4 years ago

Here is what I think a modern OS should look like: https://qubes-os.org. It's security-oriented and based on VMs running other, existing operating systems, with a transparent interface.

eternityforest• 4 years ago

I would start with a clone of Android, and redesign anything that got in the way of ultra low latency work, and make it less locked down. The storage access framework would go away.

I would add scripting and such to make it a better platform for servers.

I would have SSH, but I'd probably get rid of Bash completely in favor of one of the new modern shells. Or perhaps I'd have a pure logicless command prompt.

Most likely since we can do unlimited NIH here, I would aim for Dart as the system scripting language and add some JIT and caching to make it fast to compile, if I didn't just go with Python.

I'd have Ansible included natively, modified so that playbooks were a locally executable type like a shell script, so that random oneoff backup scripts and the like could be totally declarative.

Then I'd make a point to have a strong focus on not needing separate images for different hardware.

I would probably focus on RiscV on the assumption it will get big by the time that it was all finished, but I'd be sure to have strong ARM support.

I would probably get rid of "Everything is a file" completely. I'd have a stripped down dbus like thing for talking to devices. Everything is an object.

I would very aggressively hunt down and destroy anything that requires imperative modifications.

There would be a standard format for config files, where they go, and how different files override each other. Program defaults, os specific tweaks, and ram runtime values supported.

In fact, my package management would probably be based on a list of files describing what was wanted. Add a file that says I want apache, with this config setup, and the manager detects it and knows to install the package.

If you need to edit a system file, rather than add a layered override, there's a problem. If you need to ever swap out a core package, there's a problem.

This would be an extreme cattle not pets OS, designed for zero tinkering, just copy some files over and you're running.

Packages would always have everything they need to clean reinstall stored on disk.

Offline installing packages is done by copying a package file to the cache dir, then adding its config to the wanted list. You can do it in a disk image. All needed actual setup will happen at next boot.

No true containers. Instead you have apps like Android. You have API levels with everything you need, that is your standard base to build on.

Since servers need real databases sometimes, "make me a postgresql database" would be part of the OS API.

Networking would be fully mesh-first. You'd get a Yggdrasil-like IP address, with a built in firewall that blocks incoming connections. All software would be aware that these addresses are secure even without HTTPS.

And nothing would ever unnecessarily write to disk. There would be support for battery backed ram, and if available logfiles, nonsense like saving the last position of a window or what the browser was doing, would go there. It gets snapshot when you shut down.

Nothing would ever touch disk except stuff that the user actually would be upset to lose.

Everything would be Rust rather than C, aside from existing legacy stuff. Nothing else in its class seems to have that level of dedication to safety above everything else. Crap software is easy, unbuggy software is what's hard, so we should use a language that focuses on the hard part, not on banging out random MVPs, you can do that in just about any language already.

Everything should just work. Everything should be standard and consistent. And it should protect the hardware and be able to run for 30 years on a cheap eMMC.

michaelwww• 4 years ago

This would be a good place to start:

USENIX ATC '21/OSDI '21 Joint Keynote Address-It's Time for Operating Systems to Rediscover Hardware

https://www.youtube.com/watch?v=36myc8wQhLo

HereIGoAgain• 4 years ago

For a desktop OS? I'd start by looking at windows pre-8, and then look into everything MS has done since as a helpful guide of things to avoid. While completely ignoring Linux outside of purely technical details and pretend apple and mobile don't exist. I would also remember that since i'm creating a system's OS, I should treat the internet as an after thought in the core concepts of my designs. That would be a good start.

lxpz• 4 years ago

For back-end systems and distributed systems, I'd love to work on a new OS based on a microkernel and capabilities. Ditch Linux+Docker+Kubernetes, replace that with a microkernel that has a minimal set of modules to multiplex storage and networking, build an orchestrator directly on that that schedules processes as micro-VMs. In those VMs, we could run a stripped-down Linux kernel to handle legacy applications, but probaly we would want to design a few standardized abstractions for accessing other components of the system (storage, databases, queues, RPCs, the scheduler itself) as network services which we would use to implement more modern services. In many cases we could just leverage existing protocols that are built over HTTP (e.g. S3 for object storage). The scheduler would be aware of the dependencies of each services (i.e. the other services that it needs to call to function) and could have the task of directly connecting those things together. To contact one of its dependent services, a service or application would no longer use a hostname+port (resolving the hostname using DNS), it would just directly have a file descriptor to a socket or pipe or whatever kind of RPC interface that the OS directly maps to the corresponding service, either locally or on another node of the distributed system.

If you are aware of anyone working on something like this, please let me know!

zzo38computer2• 4 years ago

I have many idea about operating system design. Some are inspired from other designs, including TRON, Plan9, Amiga, Hurd, TempleOS, BeOS, and others.

Here are some of my ideas (although there are a lot more that I have not listed here, but I may write about in future):

- Real-time capabilities (which can be ignored if not needed). Some applications have this as useful.

- Entirely non-Unicode. International text is supported, but it isn't based on Unicode nor requiring any unified character encoding.

- The system call interface proxy. This can be used for such things as providing file permissions, system call tracing, maintaining some parts of a process state, and other capabilities, rather than all of them being a part of the kernel. The definition of the system call interface is independent of the instruction set as much as possible; this way, it makes writing them simpler. (The way that the interface corresponds to actual features of the computer does depend on the instruction set, though.)

- Hypertext file system. Any file can contain links to other files (inherently, rather than being considered as byte sequences like other data (although of course they are still stored on disk as byte sequences)), whether a normal link (which links to whatever version is current at the time of access), or to a specific version of the file (resulting in a copy-on-write object), or to a part of a file.

- It has its own programming language (which can be used as REPL as well as full compiled programs), but C can also be used, and assembly language is also possible. (If using C, then partial compatibility with POSIX and TRON may also be possible.)

- "Objects" are "files" (they are essentially the same things), and have a "object/file descriptor" to access them. This can be used for disk files as well as for other dynamic features such as a devices, process data, dynamically translated files upon access, etc. (Devices are not a separate object type like POSIX is; they are same like anything else.) Like any file, they may contain links, which may allow you to obtain access to them.

- A common file format for most (although not quite all) purposes, similar to TRON Application Databus, but with many differences. This would also be used for the command-line interface, too. It is also possible for data shown in both command-line and GUI (e.g. if a data table or graph is shown, you can easily apply your own filters, import/export, etc, with any other program; if it is formatted text, you can easily use it with other programs too; if it is numbers using some units of measurement, to be able to convert them; etc).

- Files can have multiple streams, numbered by 32-bit numbers (which need not be consecutively assigned). Stream numbers 0 to 255 have a standardized use, and other numbers do not have a standardized use.

- You can run a program with any instruction set on any computer, whether or not it uses that instruction set; if it isn't, then it will be emulated. (Whether the program is x86 or ARM or RISC-V, it will run on any of them.) Also if it is mainly one instruction set but uses some extensions (of a newer version of that instruction set) that this computer does not have, then those instructions are emulated.

- Message bus for higher level interfaces (these can be proxied like other interfaces, too, mainly by writing your own translator). Types are required, in order that programs written using different instruction sets with differnt endianness can communicate with each other without being confused, and so that the message passing can also include links.

I have many more ideas than only these above things, though!!!

sidpatil• 4 years ago

Entirely non-Unicode. International text is supported, but it isn't based on Unicode nor requiring any unified character encoding.

What are some of the issues you see with Unicode?

zzo38computer2• 4 years ago

Some other ideas include:

- I/O lists. You can submit atomic I/O lists to be executed by the kernel or by a proxy, including locking and transactions, and atomic I/O with locking and transactions is also possible on multiple files at once.

- You can duplicate the running state of the system (or of parts of it), to be able to restore it later, examine it for debugging, etc. This is not always possible (e.g. due to hardware states), but would try to usually be possible.

- A program's configuration file normally would link to the program file, or else another file links to both of them; that is the program that you must call in order to start the program (normally), rather than the program itself. In this way, the program can find its configuration files and other files. If you do not want a program to update its own configuration file, then you can just make that file read-only, or use the versioning capability of the operating system.

(These still aren't all of them, though)

yuppie_scum• 4 years ago

From a UX perspective I’d like to throw away the numpad on the keyboard and make it into a window management interface. One hand control of window placement and switching between them in an intuitive way would be vastly more valuable to productivity

forgotmypw17• 4 years ago

I want the interface to remain stable between different versions.

ghla• 4 years ago

Mac OS X 10.6 Snow Leopard

slater• 4 years ago

A full-on retreat from EVERYTHING MUST BE BRANDED.

Your spreadsheets aren't in numbers.app or excel.exe. They're spreadsheets, and get opened in, guess what, the spreadsheets app. It shouldn't matter to the end user what's behind the spreadsheets app.

Your web browser? It's not chrome.exe, firefox.app, or Safari. It's just "the web" app.

And while we're at it re: branding. No, you don't have Excel files. Or Word files. They're spreadsheets, and documents.

And another thing:

Places where files go. Guess where your spreadsheets are? That's right, /files/spreadsheets/ -- and you'll never guess where your documents are saved!

Guess where your browser's preferences are saved?

No, not in opt/var/something/whatevz/users/your-name/lib/etc/browser/endless-UUID/prefs

It's in /preferences/browser/

This comment brought to you by someone who spent the better part of two days trying to figure out where his built-in apache2 installation, as well as the homebrew port, saved their prefs. Oh, and same with PHP.

E.O.R.

8jef• 4 years ago

The ideal OS should be centered around the Owner of a machine, be it a pc, a phone, a tablet, a smart-anything, or else. As the Owner would own many machines, these could be pooled together, or not.

A machine would be equipped with a 3 layer object system: one layer for core objects (any reusable part, locally and/or remotely stored), a personal and impenetrable by default layer (for any and all private data, personal config, tweaks, metadata - anything made and/or generated by the Owner's actions), and a third layer for deliberately shared data (open to anyone with the right key).

Modular core object interpreters could be added for Owners to access any code and/or stacks or packages, written in any language. Imagine a Windows interpreter, able to interact with compatible apps, at a cost for the Owner, should she/he choose to acquire such capabilities. Same for Mac or Linux or Android or any other interpreters.

The inter-connecting links between machines would also be designed around Owner's best interest, using differentiated air-gapped communication pipeline for each layer. The Owner would either choose to locally keep its own data, or store it in a Data Bank (and get some revenues from sharing it in part or in totality).

As for the OS interface, to each its own: from CLI to window based to personal assistants to _Her_ movie style interactions.

The thing is, between layers, hardware, data handling, core objects and interfaces - and the prerequisite for Owners to really own their data and dispose of it as they wish - it would be very hard for any one company to serve the market vertically without lots of public scrutiny. As a paying customer, I'd be incentivized to buy hardware and services from the most reputable sellers: best machines, best data bank or broker, best inter-connecting, best storage, best interfaces, best software environment, etc. Privacy, modularity and compatibility, backed by solid legislative guarantees globally.

TowerTall• 4 years ago

I would take inspiration in Microsoft Midori

https://en.wikipedia.org/wiki/Midori_(operating_system) https://web.archive.org/web/20210216182214/http://joeduffybl...

throwaway0asd• 4 years ago

A modern OS should be a distributed system allowing for the interconnection of multiple devices into a single shared unit. For example I have a desktop, laptop, and phone. These devices should comprise a single encrypted file system privately available over the internet without use of any server. I should be able to execute applications on any of these devices from any other device I own and message between them in a many to many relationship. Remote Desktop is not good enough.

MaxPengwing• 4 years ago

So what you want is Plan 9 from Bell Labs. But with a modern GUI. https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs

rapjr9• 4 years ago

Start with security in the MCU chip design and work your way up from there. If we can't secure computers they are very soon going to become useless. They are already starting to feel like they are more trouble than they are worth (ransomware and other attacks are destroying the functioning of health care, government, the military, and more), and I say that as someone who has spent their whole life working with them and likes them. I worked on computer security research over the last decade and there was a lot of hand waving ("APT's are too difficult to protect against, so we won't consider that, it's out of scope"). Now the chickens are coming home to roost and APT's are indeed a concern at every level. It only takes one person to turn an APT into a scripted hack that anyone can use (witness what has been happening with the CIA's revealed attacks). Supply chain security is a new concern when it should have been obvious for decades.

The alternative is to build a world where everyone is nice. This is the preferred solution but it seems more difficult to create than a secure system for computing. Maybe one approach to secure computing would be to invent a new paradigm for non-networked computing that does everything we can do now, but is just slower to use.

skyde• 4 years ago

definitely micro-kernel (something like L4 OS). Also we should be able to isolate process from each other as if they are running inside a true VM.

For example: one process trying to use all the memory on the machine should evict its own memory page from memory and try to swap them to disk but not evict memory page of other process.

Ask HN: How would you design a Modern Operating System in 2022?

Related Stories