Shout-out to BeOS (the old geeks will know of it) which was the last promising new OS I encountered... and that was many moons ago
Of course, most of the shit we do with junky web apps today could just be presented as a 9P service with maybe a couple shell scripts in front of it, but the junky web apps already exist and are in use.
"There is no fork."
Apparently they're from 9front, a fork of plan9: https://news.ycombinator.com/item?id=12617036
http://9front.org/img/ is filled with a bunch of random stuff. The diagram of plan9 at http://9front.org/img/fs.png seems useful.
"Plan9 has been forked": https://news.ycombinator.com/item?id=2772718
Note the discussion on rc, plan9's scripting language: https://news.ycombinator.com/item?id=2773275
Maybe someone can borrow some ideas for their next OS.
EDIT: Aha: http://9front.org/propaganda/
On the other hand, you know what OS was practically invisible? DOS. And DOS was pretty great, so maybe you're on to something.
Do you know how much work it was to redirect the input/output of an MS-DOS application? It can get pretty insane [2].
[1] You had to pick a memory model to compile against for one thing---tiny, small, medium, compact, large or huge. You had to deal with FAR and NEAR pointers, and it really drove home the point that sizeof(int) != sizeof(long) != sizeof(void *) when writing C on that system.
[2] http://boston.conman.org/2015/12/13.1 More info here: https://github.com/spc476/NaNoGenMo-2015
https://en.wikipedia.org/wiki/Mac_OS_memory_management
Anyway, in dos, .ost little utilities and such worked just fine in tiny (and you could use .com which simplified everything even more). Medium and compact were sort pointless because if you were writing anything you expected to grow beyond 64k then you used a HLL and let the compiler deal with most of the fiddly stuff. IIRC One of the compilers (may have been turboC) had an project/link option which let you cycles through all the memory models, and with a quick rebuild you could check executable sizes or run little benchmarks. I did a fair amount of programming in Turbo Pascal, and I just checked the manual, it basically hid the entire memory model argument, even going so far as to have that "overlay" functionality which was basically a software paging unit for your program which would load groups of methods from disk as necessary.
Yah, and I wrote TSR's too... and hacks to take over bios/dos INT calls, etc etc etc. These days it seems any software project that has been around for a few years is orders of magnitude more difficult than the stuff people claim was hard about DOS. Heck there are _network_ drivers in linux that are orders of magnitude more code (and more complex) than DOS or probably the vast majority of DOS applications. People simply didn't write 100 million line DOS programs so dealing with little hardware oddities is simple vs trying to ferret out VM barrier bugs in linux (or whatever).
That reduces things to almost an absurd level, and literally tries to ignore reality.
---
I want X!
Ok, we need this and that to get there...
I don't want this and that, I want X!
But you need this and that to get to X...
I don't want this and that, I want X!
---
While it's true in essence, and people should always keep the end user and lofty end goals in mind, we should never lose sight of the ground, because that's where we exist.
Besides, different users want their operating system to do different things.
> At best an operating system is absolutely invisible ... but a new non-OS would probably be a better idea than a new OS.
This train of thought can be applied to just about anything. The best product for X would just get out of the way, and assist you seamlessly to do X.
The graphical shell is an application - KDE(plasmashell) Gnome(gnome-shell) etc. the console shell is an application - bash,zsh,fish etc. The WM is an application - (KWin, Mutter, i3, xmonad etc.) The file manager is an application - (nautilus,dolphin,ranger, etc.) The package manager is an application - (apt,portage,pacman,nix etc.)
You can choose not use any one of these(or replace them with alternatives). They exist because they do something essential - and the kernel exists because it provides them with a coherent view of the users computer. It is their interface with the hardware.
OSs are not perfect, and they are facing headwinds (as well as some tailwinds like power constraints) but pretending they don't provide any benefits is just not thinking hard enough.
And I was a BeOS fan back in the day. Just stumbled across my old R5 box after cleaning out the attic. Very clever design for its time but didn't bring anything to the table in terms of networking, multi-user or distribution. It was a multimedia oriented, multi-threading speed demon and not much else.
For instance, today we don't have text terminals. We have high-dpi displays. So why is the first thing you reach for a text buffer? Stop it. Vector-based fonts should be step zero. Raster graphics ought to come along pretty far down the line when you get to texture surfaces. We don't run with video units with basic memory-mapped framebuffers any more. Our storage also isn't seek-bound in most cases, we have RAM that can bust the limits of even old filesystem designs made for bulk storage. We have more now and just like the physicists say, More Is Different.
But the next revolutionary OS will probably come along and announce their goal of POSIX compliance and people will still trick themselves into thinking its 'new'. I'd rather see an OS that realizes the things the Internet and web have taught us and integrates it. What people want is search and instant-on application functionality. They don't care if it's "an app" or its "a webpage" or whatever. They want it to work, they don't want to "install", etc. And if you can murder the browser and get back to something native and cut the eye out of every company monetizing themselves through user behavior data sales, all the better!
+1. The familiar ideas and approaches are 'easy' but not necessarily the best (or even good) today. Lets start with the notion of an operating system and why it's needed? What purpose belongs within the OS vs outside? Some fundamental research along these lines would go a long way.
I don't think applications are really the big problem these days with virtualization and all. If your OS can virtualize other OSs, that can act as your compatibility layer. Windows 7(?) did it for XP, MacOS X did something kinda like it for classic, etc.
The real problem is you have to offer a compelling reason for people to A) want to use it over alternatives, and B) develop for it over alternatives. Personally I think if you can make it really developer and power user friendly a lot of applications might show up just because the system is a joy to work in for the kinds of people who make things. You'll note that this is pretty much the opposite of where Desktop OSs have been heading.
Also, drivers. Not sure how to crack that nut.
Of course, that'll get you nowhere unless the new hotness really is so much better that cost/benefit of running it, plus oldOS in a VM, is greater than that of just running oldOS.
...but it’s in no way a departure from the status quo, even referring to itself as kernel + GNU/BSD style ecosystem.
I wonder if we will see a new paradigm anytime soon. The Hurd?
This isn't even remotely true, but we're in the age of short memories. There have been several operating systems built in Java within our (careers') lifetimes.
And dozens of operating systems that predate C. https://en.wikipedia.org/wiki/Timeline_of_operating_systems
There's nothing preventing other operating systems from being written in a safe way -- they just aren't. There are also multiple definitions of the word "safe". As in, "BSD or Linux are safe to bet the software architecture of my multi-million systems budget".
No new ideas mean no reason for me to even consider adoption until it reaches critical mass. Maybe in a decade I'll give it a look.
Edit: Multics was written in PL/I, which itself just had a new stable release this past September...
Edit2: Redox isn't really that safe even. It's pretty cavalier and leaves a lot up to the application. It uses the unsafe parts of Rust a bit. An application can still malloc and forget to free -- so aren't you right where you started? Really every time this comes up, I would like to posit that "people evangelizing Redox don't even know what the f* they're talking about", but I honestly don't have time outside of my real work to dig into the thing. jackpot51 is fantastic at PR for his project though, and I don't want to discourage anyone from working on. It's good that it has an active community, I just don't need to hear about it.
Edit3: Checking Redox' source shows that about 1.5% of the code invokes 'unsafe' and they cite this in their documentation, but what I really want to know is how frequently those lines of code are called.
I never used Rust but looked at it several times over the past years. Doesn't the 'unsafe' classification allow for future automated tools/theorem provers to challenge those specific lines? Looking for vulnerabilities/bugs in only 1.5% of the code instead of the entire code base sounds like a nice improvement.
The upside of invoking unsafe means that you were able to find out that 1.5% of the code is unsafe and you are able to focus in on it.
Put another way, it makes the haystack significantly smaller.
That was in 1961 at Burroughs, using ESPOL.
There were plenty of OS being built in Algol and PL/I variants outside AT&T walls since the 60's.
History is full of OS written in other languages that weren't either C or C++, including Apple's Lisa OS and the first editions of Mac OS.
I'd like to see something like a self-hosting library OS. The entire OS is a single giant application, software is installed by adding the source code and recompiling the whole thing, and security is done using language-level and package management constructs.
MirageOS is a library operating system ...
What I find interesting is these two projects are using a similar approach but targeting opposite ends of the spectrum. Atomic is intended as a cutting edge server OS for enterprises that want an integrated stack for running containerized infrastructure (they also started publicizing Atomic Workstation as of the last release, although I found it painful to use due to a lack of docs). Endless is targeting emerging markets, composed primarily of first-time computer users. OSTree+Flatpak allows the desktop to run similarly to a mobile OS, and there’s minimal chance of users breaking the system itself.
[1] https://www.projectatomic.io [2] https://ostree.readthedocs.io [3] https://flatpak.org [4] https://endlessos.com/for-developers
Specifically 'Managed code: Memory protection on object level, rather than on process level'
In isolation it might be superior and have laudable attributes, but you're maybe a millionth the way towards competing with current automobiles for a general purpose solution in any fairly densely populated country.
and then again a year ago https://news.ycombinator.com/item?id=12232385
I have a bunch of other random gripes with POSIX-style OS interfaces and find it a bit frustrating that these interfaces haven't changed much in decades and seem to have attained a lot of inertia of the "we do it this way because we've always done it this way" kind.
Write one.
In the case of seL4, verifiability comes from a formal specification of its key operations that is proven using a theorem prover. The spec is implemented in multiple languages including Haskell and of course C.
As it stands, formal verification is limited to very small codebases: seL4 itself is on the order of 10k lines of C. Extending the proof further outside the current boundary to cover additional functions that are typically found in OS kernels would be prohibitive to say the least!
It's immediately and very obviously useful for these fields. It is small indeed, because it follows the principle of minimality, introduced by Liedtke's L4. But do not get this wrong: It is a general purpose µkernel.
This principle of minimality (the supervisor mode µkernel should only do something if it can't be done by a service in user mode) is the difference between 1st and 2nd generation µkernels. seL4 is a 3rd generation µkernel: It's designed around capabilities.
Genode is building a framework to create OSs based on µkernels. They do support many µkernels, but there's been some serious effort put into their seL4 support. Genode isn't quite there yet for this purpose, but does have ambitions of being the base for a general purpose OS.
Here's a 2014 update on lessons learned from L4.
https://www.youtube.com/watch?v=RdoaFc5-1Rk
If at any point you've thought "sure, but doing things like this is slow", then I suggest reading this.
Or Genera?
Or even TempleOS?
Then there are some older systems worth looking at (e.g. ITS, MCP, VME/B, Oberon).
Some ideas: The system language should be the operating system. No need for files if it's image-based, just persistent objects. Atomic system calls. Capabilities instead of access control.
iOS is the new and promising operating system.
It challenged and made us review many of the assumptions that everyone considers to be universal for an OS, even though they have no reason to be:
- The need for a user-accessible "file system."
- The need for multiple, customizable windows on the screen.
iOS dared to go against the grain and people rallied against it.
Even though the vision seems to have gotten somewhat muddled post-Jobs, and some of the trademark stubbornness giving way under Tim Cook, and despite the annoying bugs and inconsistencies lately, iOS has actually worked surprisingly well; the iPad is the first computing device that many of the older people in my family can comfortably and confidently use.
It still has some way to go, but if you give it an honest chance, you'll see that an iPad [+ Smart Keyboard + Pencil] can easily perform 70%-90% of the task that most people ever need to do on a computer, without many of the jags associated with traditional desktop operating systems.
With the recent rumors about unifying iOS and macOS while still keeping desktop and mobile user interfaces distinct, I'd like to believe that Apple have some exciting plans ahead for a future OS made up of the best features from iOS+macOS.
And multiple overlapping windows was the big breakthrough with the original macos. Even then it was quite restricted (only desk accessories could overlap) until system6/multifinder added the ability to run more than one application at a time.
So, while I agree the ipad model works well for a lot of things, I think the dedicated tablet model is sort of dying now that ~6" phones are everywhere. When the ipad broke, no one missed it..
However there is still hope, when we look at the ongoing userspace transitions on mobile OSes.
I mean, the kernel might still be UNIX or Windows like, but the userspace is quite different.
Minoca is for embedded devices... not really GP
SPIN looks... very rough/early-stage
Fuchsia looks... interesting, I guess, even if it's going to be subject to the same exact mutation-related bugs and security holes that have plagued C-based OS'es for years
Thanks to NetBSD/rump kernel and the POSIX persona of the Hurd, it can get a whole bunch of device drivers with relatively little effort.
The future of OSes is stuff like android, iOS, Qubes (security) or MirageOS (simplicity for security)
Also 'make a new os' is much like 'rewrite vs improve in place'. Most mature engineers do improve in place. New systems research innovations come through improve in place operations. Change a filesystem, change that subsystem and eventually you have a new way of doing things.
Of course, it’s nowhere near polished enough for day-to-day use as macOS or Windows.
It's a network effects thing. Everyone demands POSIX compatibility, and it's getting to the point where software doesn't even try to be cross-platform anymore; it just assumes you've got POSIX and a GNU environment. Possibly even specifically Linux -- Docker will run on other OSes, but it does so by launching a Linux VM to run all the containers in.
"POSIX Abstractions in Modern Operating Systems: The Old, the New, and the Missing"
http://www.cs.columbia.edu/nsl/papers/2016/posix.eurosys16.p...
I think something interesting would be an os based on BEAM as a underlying threading and memory management model, if you could put in security guarantees.
Haiku is an open source free rewrite of BeOS and they are trying to make an OS that can run BeOS apps. https://www.haiku-os.org/
AROS is an open source and free AmigaOS 3.X rewrite, it can run old Amiga apps.
OSFree is an open source and free OS/2 clone. http://www.osfree.org/
ReactOS is an open source and free OS to try and be like XP/2003 in a way and has made some progress recently.
If I was in charge of Microsoft or Apple, I'd look into one of those OSes to fund and exchange code with instead of creating one from scratch.
While they are not ready for prime time if some billion dollar company invests one million USD in just one of them, it could get it to get out of the alpha stage and go beta or retail in a few years or so.
Many modern devices (GPUs are most famous for that but there’re others, e.g. printers) include their microcode/firmware/binary blobs as a part of their device driver. Technically you can reuse these binaries for different OS, but legally, at least if you’re on American soil, you can’t.
That’s ignoring stuff like filesystems, network protocols, shader compilers, or whatever else you need to get basic functionality out of the device.
Also, a given chip might require anywhere between 2-3 drivers (for something simple like a power controller) to hundreds + a stand-alone OS (for things with an embedded microprocessor, like a drive or some fpgas)
It is tedious work, but I’d love to see the BSD’s band together with a hardware manufacturer to produce a high end consumer-grade laptop with a 4-5 year production lifespan, and well-supported hardware.
There haven’t been any noteworthy hardware improvements in that space in the last 5 years (arguably a 2013 MBP is better than a 2018 one in most ways), so this isn’t as crazy as it used to be.
These laptops could be similar to Windows laptops also sold by the same vendor, which reduces engineering costs. Dell sort of does this for Linux, but they churn the models too quickly for the BSD’s to catch up, in practice.
The vendor could rotate a new model in every 2-3 years (maybe rotate form factors each time), and make it a sustainable business.
There is precedent for this in the embedded space. Look at PC Engines, for example.
Most people would not be willing to give a chance to what may be a great product in 5-10 years. So the next great operating system will most likely sneak in through a Trojan horse. My bet would be, containers, something, something, something, operating system.
The main problem is compatibility. The solution is virtualize. Let's say at least provide headless linux (Docker?). This is enough to start. Imagine that linux run not too bad here (ie: fast enough), just to keep dreaming.
The next is why? Why build for this OS if I "just" can run linux here?
The conventional narrative is that the OS is "boring" "invisible" etc. I think instead that is only true because most OS are boring. If we think as a master integration then is more cool.
Consider the posibility to turn the unix text stream/pipelines as the actual UI paradigm (like react) and have the ability to connect not only apps, but components inside. For example, If I'm in mail and wanna crop the image I just put here, I need to detour a lot to Photoshop then return to mail.
Why?
I think is possible to say "This is a image. Any app/component that could operate on it can do it". So, in short, is a UI manifestation of:
MailApp.currentMail.images | PhotoShop.crop > returnBack
So, like in a REST API, the apps publish their URIs with ACCEPT/HEADERS like "json", "xml", "img" etc and this allow to match to others apps that operate on them.
Having also the apps operate on "docker-like" containers by default (fully isolated) yet communicate as Erlang Actors (send messages) to any other app that "Accept: FORMAT", allowing to express to the USER what we do now on the terminal.
---
Other thing that totally need a revamp is the whole file exploring. Is just not rigth that google answer faster than a local disk search.
Also, why not isolated in containers the files of SYSTEM, APP + CONFIGS + TEMPS/CACHES, USER_DATA so if I wanna do a backup just copy the USER_DATA container and be worry free?
This is just some random ideas. Is about time to think of the OS as APP too, and start doing cool things :)
--
In the area of security is also a lot to do. A minimal thing is to acknowledge that most users perform multiples roles on a system, and the case where exist a dedicated user to be admin or dba is just a special case.
So, is reverse the roles/user.
I'm jhon. Now, I change hat to be admin. Then change to be normal user, then change to be developer. I don't need 3 user accounts to be all of this.
Because I'm all of this.
The important thing to note is that the OS show the way. Similar how iOS change everything
Regarding your filesystem suggestions: this is already commonly done on linux. Generally, separate filesystems are created on separate partitions for each of /mnt, /home, and / (everything else). If you wanted to backup all user data, you could find the partition, then run `dd if=/dev/home of=$BACKUP`.
Regarding your third point. Windows UAC already allows a user to jump into being an admin when needed. I'm unsure why you would need a separate user account for other roles. Users exist primarily to protect your stuff from other people on the computer. You shouldn't need to protect your files from yourself.
>Regarding piping between app: this is the role the clipboard serves today
This is more a "scratch" area than truly piping. If you can't do:
map(PhotoShop.listImages, zipToFile) |> map(sendEmail)
naturally then is not the idea.
> this is already commonly done on linux.
In fact this one is almost too close. But think for example in all the trash/caches/temps is stored on the HOME.
The problem is that the whole thing rely on ad-hoc, let's imagine developers and users will respect the filesystem layout...
You can totally store your photos on /bin. You can't trust ONLY your personal data is on HOME.
> Windows UAC already allows a user to jump into being an admin when needed. I'm unsure why you would need a separate user account for other roles.
Not, is the opposite, is not to create more accounts, but to switch roles per context.
I'm jhon/admin when managing computer I'm jhon/user when browsing I'm jhon/developer when compiling
A while back, I had just bought a new desktop. I couldn't just use the hodgepodge of ~1280 MB worth of RAM from my old desktop because it was a different technology, but I also couldn't afford a GB of ram that would work with the new desktop.
I kept my old desktop on the network, made a big ramdisk out of 1GB of its RAM, and exposed it to the network as a network block device (kernel driver was called 'nbd'). I mounted that device on my new desktop and used it for swap, because it was orders of magnitude to eat all the transmission, TCP, etc delays in exchange for not having to hit disk platters.
.... which is _really not all that different_ from why google can return search results faster than you can search your local hard drive.