Okay. So I'm currently trying to design an operating system, but I need ideas. Nevermind the feasibility right now, it's just in the design phase. If you had an OS that did whatever you wanted, what would you want it to do? Please be specific, and no "emulate unix or DOS" answers. Thank you.
closed as not constructive by ChrisF♦ Feb 5 '12 at 19:07
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.
Of course it depends on what you are to use it for, but I have some very strong opinions on how a desktop operating system should look. And first of all I would like to get rid of all the 70's ideas and attitudes that is so prevalent in todays operating systems. Why are we using files, for example? That's a throwback to the 70's where you had to make a difference between internal memory and storage. (It completely blew my mind when Plan 9 was announced, an operating system that treats everything as files. It was 15 years behind it's time already when it was announced. See the first two points below.) Today we don't separate storage and memory. We use internal memory as cache for storage, and we use storage as extended virtual internal memory. This is of course completely ridiculous.
So, here is what I'd like to see:
Simply put, if you change something, it stays changed. Or put in other ways: The hard disk is the memory. Internal memory is used only for caching the hard disk. This gives the first problem: How to address things on different hard disks. You could in theory just map address space onto different hard disks, but that wouldn't work for removable storage, which would need to be addressed as well.
So the whole memory system needs to be based on objects, where objects have a unique identifier which goes to a table that keeps track of on which persistent resource that object currently is located. (That object could, if you write things in C, just be a big binary blob that the program gets to use as internal memory, and can malloc and dealloc things in as it wishes).
This gives you another interesting possibility. The resource doesn't have to be located on the local computer. It can be transparently located anywhere, and you can access it and modify it as if it was local. Your internal memory will be used as cache for this, so once it has been downloaded, editing is fast, and synchronization will be done in the background. Possibly your internal storage can be used as a second level of cache too. Obviously you'll need a resource locking mechanism that works in this situation.
Graphics all the way
Come on, terminals? stdin/stdout? Yes, I like command line interfaces, but why do they have to emulate typing on paper? No, get rid of stdin/stdout and all other file like/terminal like things. The OS should be graphical from the get go. There is not one single device today that does not have bitmapped high resolution graphics. Use that.
No windows or desktops
The Windowing / desktop model of GUI's seemed like a good idea in the 70's and 80'. It made sense to me. "Yes, we make the computer look like a real desk, and people will know how to use it". Well, for me that started to fall apart when you threw a floppy in the trashcan to eject in on Macs. And then, i think in 1990, somebody made an environment where you had a corridor and clicked on the basement door to get to the control panel where you could change setting. That's silly. The computer is not the real world. There is no reason we should impose arbitrary restrictions on things just so they behave more like the real world. Drag and drop is a good idea for reorganizing, but not for doing things. OS X obsession with dragging one icon to a hard disk icon to install things is pathetic. How is that easier than pushing a button to run an install program? (because that's what happens in the background in OS X too)
Ironically, Windows 1 got it right. Every program should be full screen. If you have a big screen and want to have many programs up at the same time, you can tile them so each get a half/third/quarter of the screen. You have notification bars that can blink, and todays wide screens could easily have an area for a twitter-type waterfall of notifications that programs can share, if you like that kind of distractions. A dialog box should always block your whole program. If not, it's not a bloody dialogbox, it's an area of your software.
The MDI was a bad idea, the SDI even worse. The correct answer is: Tabs. Too bad it took us 30 years to figure that out, but we did.
The UI should of course support multi touch, but not require it, I think. There is a lot of research being done today on user interfaces, check that out. Other good inspirations are the UI Ubuntu uses for it's netbook edition, it has a window manager that only allows fullscreen programs.
One tricky UI issue is how to manage the distributed resources you get from my first point above. It should be easy to find a resource on any computer where you have access from any other. If you forgot your phone at home, you should be able to log into your work computer and still access everything stored on your phone, without having to browse/connect/login on that phone.
IPC and multiprocessing and such
The kernel obviously needs to have good support for process communication, also via networking. Distributing software is a tricky issue at best, but the OS should bend over backwards to make it easier.
Ideally, processors should also be shared resources, like storage so that when you on your phone makes a heavy calculation, the phone can dump the data onto your home PC over a 4G network and ask it to do it.
OK, that's all the things I can thing about ranting on right now. :-)
Update: No, two more things:
An access control system based on permissions, roles and groups.
Both Windows and Unix permission system focus mostly on files, which is limiting. Unix permission system is also limited, hard to manage and generally pretty damn stupid. A good access control system has:
Hence, the mapping goes: Principal "totte" is a member of the "2011 students" group, which has the "students" role and also the "school band" group which has the "musicians" role. The "Students" role give basic access to most things on the school network, the "Musicians" role also give you the permission to log into the music recording computers in the recording studio.
Always on (kinda)
I've seen many users having trouble understanding the difference between logging out, sleeping and shutting down. These are all pretty useless. You should always be logged in (but have to enter a password to get access if you have been idle for X minutes). If no-one is using the machine, the screen turns off. If nobody is using the hard drive and processor, they turn off too. If you are running on battery, this happens faster. When battery runs out, all non-persistent memory is flushed, and the device turns off.
A reboot button somewhere in the control panel could be handy, I guess. But it can be pretty well hidden.
Access rights per program
I would like to see an OS, where you give each program its own set of access rights. For example, a PDF reader should have rights to read files and to write to one single settings/preferences file. That way, who cares if it would be virus infected? It can't write anything to your disk anyway, execpt in its own settings file.
A word processor should have the rights to read/write in your data folder for that app, but not in the folders where executable files reside.
Protected file access
Also, file dialogs and access should be governed by the system. A normal program should not be able to open files or read directories. It should have to ask the system to present an "Open file" dialog to the user, and the system should then give the program a file handle to the file the user selected. That way, the program could not just open any file and corrupt the system if virus infected.
I believe that there isn't a globally ideal operating system. If you try to please everyone's needs, you would end up with a piece of poo.
You need to figure out what you want your OS specializes itself, and go from there. For example, only the kernel requirements are often mutually exclusive between server, desktop and embedded (scheduling). Not to mention the surrounding native libraries.
Edit: I do understand that there are stuff that can be done better, no matter what the intent. My point in this answer simply was: try to specialize, and you'll end up with a better OS for that purpose.
It should be free from the kind of buffer overruns that plague some operating systems (in particular, earlier versions of Windows) that make them easy targets for virus writers.
For more ideas, have a look here: http://research.microsoft.com/en-us/projects/singularity/
I was attracted to this prospect through work I was doing on embedded systems. At the time, I was theorizing on the best approach to 'set and forget' devices, such as long time data loggers that become inaccessible once deployed.
This led me to finding and getting involved with the HelenOS project, which aims to create (from scratch) a highly portable and modern operating system. Please note, for my purposes, a fancy window manager doesn't qualify something as 'modern', because I'd never use a window manager.
I found the following items very, very interesting:
Micro kernel design: A monolithic kernel is the most painless route to getting a working kernel. This is why Linux was such a rapid success. No kernel is 'easy' to debug, but the monolithic approach is the easiest. But, you have cases where a single crash or bug in VFS throws an abort that can't be recovered from. HelenOS strictly discourages the introduction of a 'reincarnation' server to re-start buggy services, because the existence of one would probably hide more problems than it solves. However, the ability exists and suited my need.
Elegant IPC: A notorious problem in micro kernel designs is the method services (such as vmm, vfs, networking, etc) use to communicate with one another. HelenOS solved this to a great extent in a way that eliminates, not hides a great deal of the complexity. Think, simply .. 'phone' and 'answerbox' that can be used synchronously or asynchronously. Sure, you have to watch out for races, but you don't have service B borking because it got a reply that was meant for service A telling it that a read just failed.
Home Grown C Library: In addition to the standard C functions, HelenOS offered very convenient wrappers to utilize the system IPC. Additionally, a great deal of care was put into keeping things as lean as possible. The printf sub system is impressive and modern creature comforts such as a*printf() were implemented early. Any decent C programmer can quickly become productive.
Extremely Portable: Already ported to seven architectures, HelenOS is very portable. There was, at one time a paravirtualized Xen port that allowed HelenOS to boot as a privileged or guest operating system, with minimally invasive changes. It was the subject of a thesis, and wasn't maintained after completion, but it was accomplished.
The OS was everything I wanted to see in something more mature like Minix3, without bloat and with forward thinking. While the current interface (which I wrote) resembles something like UNIX, the system is not like Unix. It could look like DOS, it could look like VMS, it could look like whatever you wanted it to look like, including your own concept of how an OS should present its features. Everything I needed was right there.
Since it did everything as well, or better than I could have done it, I just decided to work on it instead. It's been a while since I've been active in development, but only due to a lack of time. Lately, I spend my fifteen minute 'sanity breaks' answering questions on SE sites.
So in a short answer to your question "what would you want it to do?", I'd want it to be reliable and easily adapted to fit almost any need that I might have in the future, when talking about devices that I need to be able to deploy and forget about.
Don't go trying to make a new OS at first, try to make a collection of really good decisions that also happens to boot. After that, you can take it in any direction that you want, even several at a time.
Versioning file system
You don't need to expose files per se to the typical user, but you do need to have persistence that the user doesn't need to worry about. It should, in principle, be possible to go back to any version of any file, regardless of what any application does. In practice, this won't be possible, but some intelligent pruning will make it work well. Combine this with some sort of auto-save facility in the app, and awareness in the app of the file system, and we've got persistence that will suit the average user.
This will have to be overrideable, since it is sometimes necessary to remove things from the disk entirely. This should be done by overwriting the disk space with random data. Ideally, the user and the police forensics lab should see the exact same things on the disk. Also ideally, there will be full disk encryption.
Stay out of the user's way
There should be no routine maintenance the user has to do. If it's routine, automate it. There should be no decisions the user has to make other than task-related ones. Any question that the average user can't answer quickly is a big failure.
For example, UAC typically asks the user whether a certain application can do a specific thing, and typically the user has no idea whether this is good or bad, and gets into the habit of clicking OK to get rid of the dialog, which is good neither for security nor the user experience.
Intelligent off button
The desirable things here are instant off and saving the user configuration during off times, without confusing the user.
It shouldn't normally be necessary for the user to turn the computer off except for power purposes. When the user needs to turn the computer off and pull the plug, it's often urgent. Perhaps the computer needs to be unplugged and moved now, perhaps it will be closed now and put into an insulating case. If it takes more than a few seconds to turn off, that's a failure. If a sudden power failure is likely to hurt the system, that's a failure. (Yes, there's some hardware design necessary here.)
To complicate this, the windows and such should come back as they were, ready to be worked on. This may require some application support. The obvious contradictions between this and the previous paragraph are left as a exercise for the OS designer.
Simple security model
Part of this is having the OS as inherently secure as possible. The other part is in giving the user understandable tools to manage security. These have to be simple enough to understand, and that means pretty darn simple. Security needs to be action-based rather than application-based, and needs to be able to rely on the system itself to be secure. No user should ever log in as an administrator or root account.
Applications should be available at something like the app store or Linux package repositories. Installation should generate a set of deinstallation instructions, since we clearly can't rely on vendors to include deinstallation scripts.
Easy virtualization and sandboxing
Call it "safe mode" or "temporary mode" or something. People are going to go to dodgy websites, and providing the very best in virtualization or chroot jails or whatever is important. This can also be used for OS version compatibility, or even temporarily running another OS. We need the capability for average users, and it's useful for more skilled ones.
Given a local group of machines, it should be possible to instantly network them and use them for extra file storage, backup, and resource sharing automatically.
Ok, I like questions that require imagination. But it may have very least benefit for your design, really.
I wish an operating system that is the same for every device, from mobile, notebook, PC, or even mainframe. Users can choose whatever plugins need to be installed, based on their needs. And the install procedure must be the same and simple for every device, for example I can(by myself) install that OS on a mobile, like we used to do with Windows/Linux for PC.
The idea may be crazy enough, but that's what I understand your question.
My suggestion is to keep the different components like file system, gui separate. So that the developers can write their own components and the users can plug in their favorites.
Handle clustering transparently, including: process migration and ad-hoc/temporary resource discovery.
Pick a paradigm and stick with it; if everything's a file, go all the way ala Plan 9, don't stop half way like unix did.
You might want to read the Ghosts of Unix Past series at LWN to see what OS-design patterns have worked and what haven't and why.
Since you don't mention what is special with the OS you are going do design, here is a general idea: a self-learning OS which flexibly optimizes the kernel algorithms (task switching/scheduling) depending how it is used. Do not emulate DOS, Unix, Windows or anything else, since all the general ideas of modern OSes come from MULTICS and POSIX.
Single-level store. No more differentiating between memory and disk storage, everything's Just There. No more problems where you can't do something because there's no more space on one drive when there's 32G free on another. Like S/38 meets ZFS storage pools.
No more directories. All files are identified by attributes, and you can dynamically group them together by shared attributes. You should have system-defined attributes (name, size, type, creation date, last-modified date, etc.) and user-supplied attributes (project, content, description, use-by date, destroy-after date, importance, whatever). You then define "filters" or "selectors" to identify the file or files you want to work with. Make then nestable or chainable, so they can build on each other. Basically a file database, instead of a fixed hierarchy.
Small and fast, designed for extensibility. It should (theoretically) be scalable from a single-core netbook or phone to a 128-core server. Most subsystems (e.g., networking, audio, video) should be dynamically loadable.
Look at the OSes used in phone switches, they're small and fast. They can also reboot (in milliseconds) without stopping any running processes.
For personal computing, I would suggest checking out Smalltalk heritage and Lisp Genera. For a recent research on similar approaches, see http://www.viewpointsresearch.org/html/writings.php
I like the approach that Singularity from Microsoft Research takes.
It's based on the .NET CLR and works with the concept of verifiable code. Buffer overflows are not possible and a memory management mechanism like paging and separate address spaces for processes are not needed. Essentially the kernel and the applications all run in Ring 0 of CPU and the overhead of task switching is almost negligible.
I would like an operating system where files are like tables in a database. Memory can be queried transparently. Imagine typing:
just an idea : )