What should a new OS have? | Hacker News Reader

What should a new OS have?

lobste.rs

12 pointscercatrova10 comments

Something I always thought would be beneficial is keeping apps in user space that don't implicitly require elevated permissions. This is something that has always bugged me about Linux, other unix like OSs and Windows. You shouldn't need root or administrator access to install apps that don't need it. Plus apps should be containerized by default. Granted there are in roads being made in Linux with things like AppImage and Flatpak but most current package systems still require root to install software without jumping through hoops. While this isn't too much of an issue with vetted apps distributed through official repositories, 3rd party packages pose serious security and stability issues in Linux. And Windows needs administrator access for seemingly everything. I shouldn't have to give up control of my OS to install something like a game.

OS choice has become pretty homogenous, even specialty OSs are generally derivatives/subsets of Linux.

I worry that detailed knowledge that results from everyday use of an OS for things like VMS, mainframe OSes, OS/2, Beos, NeXT, Plan9, etc will begin to die off, and UNIX monoculture will consign all other OS ideas to the scrap heap of history.

We'll be left with the big three (iOS/OSX, Windows, Android/Linux) which barely have done anything beyond deck chair shuffling and keeping up with hardware compatibility in the last 20 years. And OSX is a unix, and windows is evolving towards unix for cloud compatibility.

And yet I remember a Plan9 designer casually drop 10 or 12 bullet points of critique on Linux/UNIX that made me think "oh yeah".

Fundamentally, I'd like an OS that could make the task of tracking programs running on multiple machines (and architectures/OSs) more seamless. I would like something that would enable me to seamlessly run something on a raspberry Pi or raspberry VM, or a windows box, or OSX box, or a linux box. If my access key and username match.

More simply, I'd like a JSON output option for every unix command. The fact you STILL can't parse ls -la is a crime.

> I worry that detailed knowledge that results from everyday use of an OS for things like VMS, mainframe OSes, OS/2, Beos, NeXT, Plan9, etc will begin to die off, and UNIX monoculture will consign all other OS ideas to the scrap heap of history.

One idea I suggest people look at is CMS Pipelines (aka Hartmann pipelines). John Hartmann of IBM ported the concept of pipelines from Unix to VM/CMS, but in the process made a couple of major changes: (1) made the pipes record-oriented (they aren't just an unstructured stream of bytes, they have message/record boundaries); (2) made it arguably easier (compared to Unix shells) to build complex pipeline structures with multiple inputs and multiple outputs.

> More simply, I'd like a JSON output option for every unix command. The fact you STILL can't parse ls -la is a crime.

I think Unix pipes could be enhanced to have an out-of-band channel for transferring metadata, content negotiation, etc.

If I do command1 | command2, command1 should be able to send an out-of-band message "here is the MIME type of my output". If command2 knows how to receive these messages (an ioctl? ancillary data/cmsg on recvmsg?) then it can respond appropriately; if it doesn't know, well that's the same situation as at present.

A more advanced idea would be that command1 would send a message saying "I can provide output in these formats". If command2 is enhanced to support this, it can send back a message to command1 over the control channel saying e.g. "send me application/json please". There would have to be some way for the OS kernel to notify command1 if command2 doesn't understand. (e.g. if command2 doesn't call IOCTL_RECEIVE_PIPE_METADATA on the input fd before the first time it reads from it, the OS kernel synthesises an "I don't understand pipe metadata" control message back to command1)

I don't think that the OS concept amnesia will happen. Osdev is still alive and well for new hobby OSes, and there are plenty of people who dig through old software archives, so new ideas will keep being discovered and "new" ideas will keep getting rediscovered. What we really need to do is to document the non-written histories, computing cultures, and ideas, to ensure that they aren't lost to the inevitable march of time.

The future operating system is one built from the ground up to serve only as a personal data warehouse. Collecting, protecting, archiving, and analysing your life's data in a private pragmatic ways

While still a experiment, Fuchsia and its microkernel Zircon seem to be a solid foundation for a good, open source future operating system. Sadly, I don't expect it to be successful in a world in which Linux exists.

> Sadly, I don't expect it to be successful in a world in which Linux exists.

What if maybe, one day, Google came out with a new version of Android in which Fuchsia replaced Linux?

Oh, sure, that'd work, but only on mobile.

Stable. 100% stable. Every and all OSs should be stable to the point that standard use should not throw an error. It's the number 1 thing that makes using Linux so hit or miss. Distros rise and fall because of this. There are issues with many but the primary issue that prevents users from adopting an OS is because it's unstable or there is an issue with the OS that requires significant effort.

Ecosystem independence and the ability to fully function offline.

Reply on news.ycombinator.com