A bit about solution:
Brendan wrote:It'd be more accurate to say package management helps hide the symptoms of "dependency hell"; and hiding symptoms of a problem isn't something I'll ever be fond of
Here Brendan has identified a "symptom". Also many people here have identified some others "symptoms". And next some people offered some partial "solutions" like this:
Brendan wrote:I'm currently planning to do "2 step ahead of time compiling"; where programmers compile source code into a portable format (with lots of sanity checking, optimisation, etc); and then end-users download the portable executable and their OS compiles it to native code the first time it's executed.
But as whole the ideal OS is still very far away.
Why? For how long?
Maybe forever. Just because there is no cooperation. One man can make some weak OS with just a negligible fraction of applications that Windows or Linux have. And of course such OS won't be an ideal.
But it seems to me, that while there are some people wishing to create a multi-step compiler or memory manager or file system or virtual machine or whatever else, we can move the solution a bit closer than "forever far away".
Why people start doing their personal OS? Because they think it is possible to make it better than existing solutions. But the amount of work is great and until the full amount is done the system will suck. Even if the full amount will be done the system still be sucking, because there are plenty of needs the system is not addressing. And it is the seldom best case variant, because more probably the system will suck just because of lack of good architecture or careful programming.
But if we have an architecture that is accepted by most of the osdevers? It isn't that impossible as many of you are thinking now. And it gives a way for creation of a really good OS (but still not an ideal). But why osdevers have not accepted any architecture yet? Just because they see their personal way for some parts of the proposed architecture. How can we overcome such problem?
My proposal is like this:
For the "really good OS" to be accepted it is required to define a call standard and service standard. And that's all.
First, there are components, that any OS must have. It is bootloader, memory manager, scheduler, hardware manager. What prevents us from making those components to complain with the call standard and service standard? For example a memory manger can implement the call standard and expose functionality like allocate and deallocate. And anybody here can implement it's own memory manager if he wishes. If implemented the manager is easily attached to the "Open OS". But if a person is interested in multistep compilers then it is possible to forget about memory manager (just because there already are such managers) and to concentrate on the compiler development. When a compiler is ready it can be used as another component, complaining to the service/call standard. If somebody prefers his personal variant of bytecode then he just creates personal JIT compiler and integrates the bytecode seamlessly into the "Open OS". And here the person with his own bytecode is not required to make a whole OS, it is enough just to get "Open OS" and include there personal compiler and bytecode. If then some other component of OS is seen as "not very good" then the person just implements his own variant of the component. Then we can have very good efficiency and concentration of efforts on the very task a person prefers. And always any participant have an OS ready to use (at least to debug his component). And anyone can take any preferred component to create his personal "distribution".
And yes, it is the Linux way, but with hope for "better architecture".
And now to have such "Open OS" there is a need in the architecture acceptance. As a starting point in such process I propose the "any OS must have" components.
Do you have a boot-loader? Very well, we can include it as a service with the calls like this:
Code: Select all
configureFor(int addressToPlaceSystemImage, enum filesystemUsed, Location imageLocationData);
Do you have a scheduler? We can include it with calls like this:
Code: Select all
int startProcess(long jupmAddress);
int startThread(int processId, long jupmAddress);
boolean killThread(int threadId);
SomeType anyExtraFunctionalityYourSchedulerHas(ParameterType param1, AnotherParameterType param2);
Or you have a memory manger? Or you have a device manager? Or you have anything else? You can test it with "Open OS" after implementing the call and service standard.
And of course, first releases will be just technology demonstrators, but may be after a dozen or two iterations we will have a really good OS.
