OSDev.org

Project XANA is an experiment in the future of the OS, testing out various concepts to see how they can be incorporated and how well they operate. I am looking for a few good developers who are not bound by canon, to aid in creating an OS that is entirely unlike any OS before it.

XANA itself is simply open source and experimental, and will probably not be sold. On the other hand, in the later stages of XANA development, it is planned that groups of XANA developers (assisted by others in the field) will break off from XANA to create OSes based on refinements of some ideas used therein, perhaps taking some code as well. These spinoff OSes can be commercial, and are not explicity experimental. Whereas XANA puts the goals of originality and experimentation over usability and marketability, these spinoffs will utilize the pieces of XANA that are most useful and innovative and redefine them to be usable and marketable.

Fields wherein development is needed include traditional OSdev, network protocols, UI design (non-traditional), porting to various platforms, programming language design, and (eventually) hardware design.

Note that one would not be paid directly for one's work on XANA, but only if one worked on a fork or a spinoff, or on the later restructuring of XANA to be usable. In these cases, one would majorly benefit from being an active developer on the original XANA. It also is a fun experience, having pretty much free reign with experimental ideas in a thinktank-type environment.

Visionaries, did you say

Well then... I see... lots of hard work ahead

Well, your hopes for XANA sounds like me and DynatOS 6 years ago. A little advice, use all this time from when you are younger working on XANA instead of... say... getting in trouble or just staring at the screen debating design policy inside your head... it starts to suck when you get older and have n-1 things to do

Learn when to walk away from the screen. Think of programming like drinking alcohol, after X amount of drinks most people don't have the sound judgment to help them realize when it is time to quit. So, in respect, after your 24th-36th hour of programming... your brain is not figuring out as much as you think it is. More often than not, you go back the next day refreshed, then you look at the code and say to yourself "WTF was I trying to do here?!?!?"

I hope you don't get discouraged when people fail to jump on board quickly. Just remember, though, that you have to cooperate on design policy and will have to audit code that may not come naturally to your brain. So try to enjoy the sanity while it lasts... then it is on to the world of CVS/Subversion and arguments about fundamental design

Also, a particular saying seems to help keep me on track... that being "First make it work... then make it work better."

Good luck with XANA

SpooK wrote:Also, a particular saying seems to help keep me on track... that being "First make it work... then make it work better."

Yeah........That doesn't work. I used to think that. I did several things that way.

"Hm....Let's get something working", I though. "Hmmm..This works. Not well, but it works...". Once working, "Wait. How can I add feature x? I made it work, but it' just works."

Planning is like an outline. When writing a paper, you often use an outline to gather your facts. It is the same in programming. Once you organize your thoughts the program builds itself.

...

Just my thoughts on the quote.......

Alboin wrote:

SpooK wrote:Also, a particular saying seems to help keep me on track... that being "First make it work... then make it work better."

Yeah........That doesn't work. I used to think that. I did several things that way.

"Hm....Let's get something working", I though. "Hmmm..This works. Not well, but it works...". Once working, "Wait. How can I add feature x? I made it work, but it' just works."

Planning is like an outline. When writing a paper, you often use an outline to gather your facts. It is the same in programming. Once you organize your thoughts the program builds itself.

...

Just my thoughts on the quote.......

It wasn't meant to replace proper design policy

The quote is more appropriate when preventing yourself from optimizing your code before it is written... and to consider optimizing entire algorithms and not instructions themselves

Actually, by "visionary", I meant someone who could come up with new, more innovative (though not necessarily more optimized) ideas.

XANA itself is certainly not optimized. The idea was to write it as simply as possible, aside from the stuff we're testing out (the experimental, "next generation" stuff). The optimization comes in the stage where everything's rewritten

You want a new, visionary idea? I can give you one, but I want some kind of credit (since I haven't published this idea yet).

Edit: You don't get that idea. I wanna publish it. But I'll give you a visionary, unsolved problem:

Create a domain-specific language for describing the parameter-passing and result-returning conventions of a function. When applied to a form of Lightweight RPC, this gives you RPCs that can almost perfectly emulate function-calling semantics without stub code.

Now that's asking you to do my work for me, but that's what you did.

Crazed123 wrote:Create a domain-specific language for describing the parameter-passing and result-returning conventions of a function. When applied to a form of Lightweight RPC, this gives you RPCs that can almost perfectly emulate function-calling semantics without stub code.

DCOM, CORBA, ICE, Java RMI. Don't they all have domain-specific languages for describing the parameter passing and result-returning conventions of a function. OSKit and Mach use those in kernel environment. They are known as interface description languages or IDLs for short. In fact, you could have just said "create IDL." Then again you could consider some existing one (maybe the OMG standard, thanks to CORBA it has type mappings for practically every programming language).

Sorry to say, but not much visionary about those. Also it's unfortunate fact of life that the whole idea of emulating function-call semantics on top of network is mistaken, because you must deal with partial failures somehow, which means you need to design a protocol on top of the RPC facility anyway. All those give you is a standard method of serializing and dispatching, which you might or might not like. The hardest parts (protocol design and dealing with failures) remain. In fact, most RPC facilities that generate stubs from IDL usually only make it harder to deal with failures.

mystran wrote:

Crazed123 wrote:Create a domain-specific language for describing the parameter-passing and result-returning conventions of a function. When applied to a form of Lightweight RPC, this gives you RPCs that can almost perfectly emulate function-calling semantics without stub code.

DCOM, CORBA, ICE, Java RMI. Don't they all have domain-specific languages for describing the parameter passing and result-returning conventions of a function. OSKit and Mach use those in kernel environment. They are known as interface description languages or IDLs for short. In fact, you could have just said "create IDL." Then again you could consider some existing one (maybe the OMG standard, thanks to CORBA it has type mappings for practically every programming language).

Sorry to say, but not much visionary about those. Also it's unfortunate fact of life that the whole idea of emulating function-call semantics on top of network is mistaken, because you must deal with partial failures somehow, which means you need to design a protocol on top of the RPC facility anyway. All those give you is a standard method of serializing and dispatching, which you might or might not like. The hardest parts (protocol design and dealing with failures) remain. In fact, most RPC facilities that generate stubs from IDL usually only make it harder to deal with failures.

And this is why I never call my work RPC. You call it RPC and all of a sudden everyone thinks you're referring to message-based RPC with serialized parameters sent over a network.

I was talking about "lightweight RPC", also known as thread migration with call/return semantics. Note the phrase "without stub code".

And no, I wasn't talking about standard IDL. A standard IDL maps an abstract function signature written in the IDL to a function signature written in an actual programming language. I meant a language that describes mappings from named, typed function parameters to machine registers and stack positions in which those parameters will actually be passed.

Crazed123 wrote:I was talking about "lightweight RPC", also known as thread migration with call/return semantics. Note the phrase "without stub code".

Oh, you are talking about thread migration. Actually I believe any kind of synchronous IPC (be it RPC or something else) is flawed by design if at least one of following holds: you need to do more than one thing at once, there's potential for partial failure, or there's potential for malicious (or misbehaving) code. Now, if there's no potential for partial failure, you're on the same computer. If there's also no potential for malicious code, you could probably run all the code in the single process just as well. And if you don't need to do more than once thing, you have a batch process as all but the most trivial servers, and all interactive software other than simple command-line scripts will need to deal with several things at once.

I meant a language that describes mappings from named, typed function parameters to machine registers and stack positions in which those parameters will actually be passed.

That process is called calling convention, and I'm under the impression that some compilers have special languages for those, but unless you are writing a compiler which needs to support more than once calling convention, I don't really see a point.

mystran wrote:If there's also no potential for malicious code, you could probably run all the code in the single process just as well.

The code wouldn't have to be malicious to cause problems, just type-unsafe and buggy (all too frequent unfortunately).

@Crazed123: Have you read much about the WinCE kernel? I think it uses thread migration.

Colonel Kernel wrote:

mystran wrote:If there's also no potential for malicious code, you could probably run all the code in the single process just as well.

The code wouldn't have to be malicious to cause problems, just type-unsafe and buggy (all too frequent unfortunately).

Actually, my idea was that "malicious" would capture buggy code as well. In fact, my idea was that it would capture even buggy code not taken over by anyone. Simply the potential of code which doesn't respond in a sane amount of time can cause all kinds of nasty problems with blocking IO.

Whether or not the code is written in type-safe language is irrelevant. If the code is written in a Turing-equivalent (up to memory limits) language, there's potential for undecidable termination, and that alone basicly means synchronous IO is only good idea with known code. If the code will also have to live on the same system (to avoid partial failures) there's no point in putting it into a separate process, especially so if you have a type-safe language.

What about said code having private data it wants to keep from its callers?

Now you said that some compilers have DSLs for calling conventions? *That* will be damn useful. If you know the calling convention of code, you can use it to run security checks on the arguments.

Colonel Kernel: I'll look into the WinCE kernel. Are docs about it available to the public?

Crazed123 wrote:Colonel Kernel: I'll look into the WinCE kernel. Are docs about it available to the public?

I've found a few PowerPoint presentations on MSDN... I've never bothered to download any of the SDKs for WinCE, but I bet they have some kernel-related documentation in there.

hakware wrote:XANA puts the goals of originality and experimentation over usability and marketability, these spinoffs will utilize the pieces of XANA that are most useful and innovative and redefine them to be usable and marketable.

You can be as "original" and "experimental" as you like, but unless the result is usable you have just produced another bucket of crap like Linux. If something isn't usable, you can't "redefine" it to be usable or marketable. The market tells YOU what IT wants - not the other way around.

mathematician wrote:

hakware wrote:XANA puts the goals of originality and experimentation over usability and marketability, these spinoffs will utilize the pieces of XANA that are most useful and innovative and redefine them to be usable and marketable.

You can be as "original" and "experimental" as you like, but unless the result is usable you have just produced another bucket of crap like Linux.

How, under any possible circumstance, is Linux a piece of crap? I can see this take meaning if you're referring to the implementation that is Linux (As that itself is debatable.), but if you're referring to the UNIX architecture in general I think you're very mistaken.

mathematician wrote:If something isn't usable, you can't "redefine" it to be usable or marketable. The market tells YOU what IT wants - not the other way around.

In the words of Louis XIV: "I am the market!"