Unconventional design: no processes and files?

[Meor]

Some thoughts keep occuring to me, like what if we have an OS without processes/threads and files? Instead of all that, we'll have some other mechanism to get the job done. A BAD replacement can be all we have is objects, some of which have data and other have functions, and they execute in turn when required to fulfil the purpose.

This is a great idea. Pursue it.

[mrvn]

Some thoughts keep occuring to me, like what if we have an OS without processes/threads and files? Instead of all that, we'll have some other mechanism to get the job done. A BAD replacement can be all we have is objects, some of which have data and other have functions, and they execute in turn when required to fulfil the purpose.

Process/thread and file are just names. But look at the function they fullfill in a kernel:

A process/thread is the kernels way to store state information of jobs while they aren't running and to keep track of resource informations of that job. You most likely will want some multitasking in your OS and then you need those informations. There is no way around that. The most you can do is give it different names. So instead of a process you have a task or an object or an entity. But they all have a common core.

Similar you can see a file as a common means of sharing data between processes. That might be simultanious running processes or processes running at totaly different times. You will need data sharing as well. Say you download an mp3. To listen to it you have to share that data with the mp3 player. Even if you only have one process you need to have some abstract file thing to keep track of multiple 'files' internally. Although that won't much look like a traditional unix/posix file it will still provide the sharing functionality between different code parts.



There are OSes out there that have no concept of a filesystem. No conecpt of a harddisk. The only resource they have is virtual memory. Think of the harddisk as your memory and the physical ram as cache. Also (some) processes never die. You don't reboot but instead you suspend and resume all the time. That way you can have a filesystem service as a process that will survive a power cycling. Done right the OS will always have a consistent state on disk and only minimal changes only in ram. You can just power cycle and at most you loose a second or two of work. It will just pop back up where it last synced.

MfG
Mrvn

[iammisc]

The thing about getting rid of processes and files is the same thing as getting rid of paper and pens in the world.

Processes allow you to write data, and paper allows you to record it.

However, this is not a perfect representation of the world either. However, IMNSHO my method of components models the world much better. The components are the things that store,edit,and view only their types of data but they can interface with others if the user allows it.

Of course we'll still have applications but they'll consist of a descriptor file that says how the different components are connected. For example, for a picture editor and also a component, we;ll connect the image editor component with the raw image component or another image component.

[brickhead20]

Files, processes, code are really all data.

I don't think the abstraction to an "object" as you put it is necessarily a bad thing. It allows for plenty of flexibility if you implement it correctly. But then one might argue that UN*X does a similar thing - except its object is called a file.

Much of how an operating system can work is based on the underlying hardware. It is inherently based on data in memory (be it code files or process tables etc), and the procedural processing of it. The question is how do you plan on abstracting that for the applications to run on the hardware you have.

Of course a far more interesting idea is to attack it at a hardware level. I was thinking about your idea, and the fact that a computer is procedural, typically, and thought what the possibilities might be if you constructed a new type of hardware.

This might be fun. For example:

One might think about having an area of data (computers handle data), and some processors that are reconfigurable (like FPGAs or CPLDs), that you can configure, through say some memory mapped space (so these themselves become data). Your application and OS therefore becomes a set of functions which you define in these units to act on the data.

Of course this would probably be miles slower and more bloated than the typical CPU, and would probably require some procedural elements to it. In a sense this is what a processor does anyway, but its operations are somewhat restricted. One might imagine building hardware neuron networks to operate on data at a hardware level, or creating extra graphics manipulation hardware.

The downside is, relative to brute forcing through a traditional processor, reprogramming hardware logic would be slow.

But I think my point is to change the abstractions hugely, you would need to attack the hardware.

What is a file? Its just a representation of something to contain data you want grouped together. What is a process? Its just an abstraction of what the CPU will be doing.

In my (probably disastrous) example, what is a function? Its just a hardware encoded application acting on data.

Though there may be things that can be done to current abstractions to improve them for your situation.

Just some thoughts.

[B.E]

A BAD replacement can be all we have is objects, some of which have data and other have functions, and they execute in turn when required to fulfil the purpose. Though this is a very bad alternative.

An object is nothing more than an abstraction as well, there's nothing inheritly bad about it. Since users do not like being presented with random bits, you must have some form of abstraction to present to the user. If you are clear about that, then you can design your FS to either be a direct implementation of that abstraction, or let it be a simple block allocator and build your abstraction on top of that.

This idea is already done, UNIX does and has always done this. things like named pipes, device files, etc. in fact with Bash you can do something like this:

Code: Select all

tee >(base64 -d > find_unencrypted) find_encrypted < <(base64 <(find .))

which creates a file(find_encrypted) containing the base64 and a file(find_unencrypted) the original input (which is find .)

[dr_evil]

Two ideas:
1. Instead of files: Just a huge virtual memory space instead of files and directories. Programs would access all data as if it was in memory. This is done in some experimental OS (--> KeyOS, ...)
2. Instead of processes: Define data flow graphs or similar things. Programming would consist of connecting data and functions together, the OS would do the actual processing.

[mathematician]

This doesn't just apply to OS development, but unless you already have a new idea, which genuinely improves upon the existing way of doing things, it is unlikely that you will be able to manufacture something worthwhile just for the sake of being different.

[jal]

This doesn't just apply to OS development, but unless you already have a new idea, which genuinely improves upon the existing way of doing things, it is unlikely that you will be able to manufacture something worthwhile just for the sake of being different.

"worthwhile" is of course totally subjective. I am creating something just for the sake of being different, and having great fun with it. Anyone, whether doing such a thing or making the 30000th implementation of POSIX, who thinks his hobby OS can become more than just a personal experiment has a 99.999% chance of being wrong.


JAL

[bewing]

I agree with mathematician, certianly. Where "worthwhile" has the fairly non-subjective meaning of "an idea that spreads and grows through its adoption by others, rather than just dying with its inventor."

Realizing the need for a new innovation is trivial. Actually coming up with a worthwhile (see above) innovation and starting its spread is the difficult, non-trivial, and rare part of the design process.

[iammisc]

2. Instead of processes: Define data flow graphs or similar things. Programming would consist of connecting data and functions together, the OS would do the actual processing.

I believe that this is similar if not exactly the same to the idea I proposed a while back.

[binarysemaphore]

To give you an example, why should firefox be able to see my mp3 files or important documents. And what has mplayer to do with my mailbox data? If applications support a limited number of files, and we have only a few instances of sharing same formats among applications, we can have some way of storing files in way that each application stores what it wants/processes.

Basically, I wanted to say that we might keep the 'file' concept, but the 'filesystem' concept, with visibility for everything to everyone (if you have read permission) is an idea that can be tweaked. I still don't know if this allows us to do away with having 'directories'.

How about having a capability based security model. Traditional approach with UNIX like systems is to store access rights for owner, group and others with files. Another way to do it is to store this access rights capability matrix within given process regardless of who the owner of the file is or uid of the process.

With capability model, you can say that Firefox can access files x, y & z. UID of Firefox & owner of all other files might be same, but Firefox can only access these three files.

Just my 2 cents

Tejas Kokje

[Love4Boobies]

Everyone's wasting too much time on this thread. I've also been through unpredictable's wiki and for all I can say, he's trying too hard. For instance, look at what his OS requirements are. Tell me one (non-hobby, or even some of those) OS that can't do ALL of the things you describe there... What do you mean by doing them better? How can you listen to music in a better way? Perhaps buying a better sound system...

What I'm trying to say is that you're trying to hard to come up with ideas, just for the heck of it. You desperately try to come up with something new just so you can say you did so. You're not even sure why. That's not innovation; innovation is something else. Why replace processes? Give a reason for that. You can't just say "files are bad, we need something new". Why are files bad? Why would we need something new? Ideas are great and in this field we could really use some right now, but I'm not sure replacing files or processes is what we want. There are things like security or manycore scheduling that need addressing.

If you want to see some great ideas, check out projects like Microsoft's Singularity. Microkernels are a good idea. Using CIL for implementing a fast microkernel is a good idea. Drivers are a good idea. Scheduler activations (might) be a good idea. ZUI is a good idea. Don't just come up with a new design, come up with something that's actually useful and only where needed. Besides, some of the ideas out there may already be good. What better abstractization do you want for a picture or a paper than a file?

EDIT: And by the way, you may as well come up with the same thing, just with a different name.

[Combuster]

You're the necromancer, and you're not really helping the dicussion by claiming that it is pointless. In fact, only by thinking about things in other ways can we get to new and better ideas.

Maybe you didn't intend to do so, but your post reads like a trollpost, so please mind your derogatory remarks in the future since that's not quite the accepted standard.

[Love4Boobies]

Sorry, that wasn't really my intention. As I mentioned before, I'm not against innovation, of course. I just find it silly to desperately try to come up with new ideas just for the sake of doing so.

[jal]

I just find it silly to desperately try to come up with new ideas just for the sake of doing so.

That's your opinion. I think there's nothing silly about it. You see, when not coming up with new ideas, you are walking the beaten path, which - depending on your goals - is not bad at all of course. However, if you do not want to walk that path - if your goal is 'doing it differently' - coming up with 'new ideas just for the sake of doing so' is not silly at all.


JAL