Despite what the project name's suffix might imply, Whitix is in fact not a Linux distribution. Whitix is a new operating system, written from scratch, and aims to combine the stability of UNIX with the user friendliness of other platforms. "It will offer a consistent, clear interface and a new way to navigate the desktop while basing the fundamentals on proven system technology updated for the twenty-first century." The project released version 0.2 today.
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2006-03-20
If you build a truly advanced O/S that minimizes the problems existing operating systems have, people will come to your O/S.
Some ideas:
1) portability: build the O/S on a virtual computer architecture. Have the code be translated on the fly to native code by a mini translator kernel, thus making the O/S portable. The only part to then rewrite would be the mini translator kernel.
2) multithreading: do not program it in C. Use an object-oriented language that is Actor-based. Each actor could be potentially a thread, depending on hardware configuration. Future machines that will contain thousands of cores will run your code much faster, without the need for recompilation. Future generations will thank you immensely :-).
3) memory management: make everything garbage-collected. Easy, since you are dealing with objects. No more crashes due to erroneous pointers.
4) files: since you are using objects, store the objects in the storage, not files. This solves another big problem, i.e. I/O. Provide transactions. It also solves another big problem, i.e. how to manage a file without the application that created it.
5) filesystem: do not use a hierarchical storage system. Provide views and queries. If your object-oriented language has introspection, then data management will be greatly simplified for all the applications and for the O/S itself.
6) networking: making your object system distributed. Instant client-server architecture, easy centralized deployment.
7) gui: make GUI displays vectorized, build out of actor objects, of course. If your objects are automatically networked (see #6 above), then you also get the benefit of a remote GUI.
8) text: forget ASCII, UTF8, UTF16. Storage is plenty these days. Go for UTF32. Everything should be in UTF32.
9) security: since networking will be automated, use end-to-end encryption (goodbye security problems).
Edited 2009-01-07 21:48 UTC
Member since:2007-05-22
Hear, Hear! I absolutely agree 100%! Everyone knows how well vector graphics scale; I'm surprised no one has thought of this sooner.
Edited 2009-01-07 22:50 UTC
Member since:2006-03-01
Some ideas:
1) portability: build the O/S on a virtual computer architecture. Have the code be translated on the fly to native code by a mini translator kernel, thus making the O/S portable. The only part to then rewrite would be the mini translator kernel.
a C/C++ written kernel is also portable, if you care to structure it in a modular way and rewrite the architecure abstraction parts...
any VM must necessarily know about the underlying CPUs' ML, and/or fragments of native binary code to instantiate and run corresponding to the various high level language constructs it encounters in the sources - so it doesnt automatically provide for portability, or portability isnt' the most advantageous asset of a VM
instead, what a VM (better, in this case a JIT system) is advantageous for, is run time optimization, since the later code generation is done the better code is produced (because more of the operating context is known at runtime)
views and structures are useful for data *presentation*
but what about on disk allocation?
but very complex system design, with some tough across-network consistency problem to solve at protocol level...
do you really need it?
or maybe CloudNine would be better off by looking at the requirements of the systems "he" wants to build (distributed objects may be very cool from a "research" standpoint, or for a Grid/ Cloud Conputing system, but maybe he wants o build an effcient desktop OS), then tackle them one at a time?
it's interesting to notice that:
a) linux /unix is the only existing class of OS's on which the gui is based around a network transparent protocol and API,
but b) linux is not the predominant "desktop" OS - the dominant desktop OS even is a non-posix one, and among desktop oriented posix derivatives, the most successful one does not have a network transparent gui system (and relegates the network transparent one to an optional service for legacy/foreign app support)
c) on linux itself, more and more efforts are made to decouple the local graphic stack from the network (optimizing for local operation on a more compact server tan xorg, or on the toolkit side, moving from x primitives to rendering directly to ogl surfaces)
is it advantageous to design a gui with network transparency in mind from the start, then? i doubt, since the x protocol's focus on network transparency has been recognised as a bottleneck and a source of inefficiences, for at least a decade (mark kilgard's D11 paper is dated 1996 iirc)
unfortunately, there are whole classes of problems in the security world, beyond wire data protection...
Edited 2009-01-08 16:16 UTC
Member since:2009-01-09
Some ideas:
1) portability: build the O/S on a virtual computer architecture. Have the code be translated on the fly to native code by a mini translator kernel, thus making the O/S portable. The only part to then rewrite would be the mini translator kernel.
2) multithreading: do not program it in C. Use an object-oriented language that is Actor-based. Each actor could be potentially a thread, depending on hardware configuration. Future machines that will contain thousands of cores will run your code much faster, without the need for recompilation. Future generations will thank you immensely :-).
3) memory management: make everything garbage-collected. Easy, since you are dealing with objects. No more crashes due to erroneous pointers.
4) files: since you are using objects, store the objects in the storage, not files. This solves another big problem, i.e. I/O. Provide transactions. It also solves another big problem, i.e. how to manage a file without the application that created it.
5) filesystem: do not use a hierarchical storage system. Provide views and queries. If your object-oriented language has introspection, then data management will be greatly simplified for all the applications and for the O/S itself.
6) networking: making your object system distributed. Instant client-server architecture, easy centralized deployment.
7) gui: make GUI displays vectorized, build out of actor objects, of course. If your objects are automatically networked (see #6 above), then you also get the benefit of a remote GUI.
8) text: forget ASCII, UTF8, UTF16. Storage is plenty these days. Go for UTF32. Everything should be in UTF32.
9) security: since networking will be automated, use end-to-end encryption (goodbye security problems).
1) I like this idea but *not* for the kernel. Only userspace... Im guessing you never have used java to much? Run once debug everywhere? Which is due to differences in the JIT compiler on different hardware.
2) Bad idea OOP does not translate well into hardware. It's doable but not easy.
3) Another bad idea I want as little between me and the hardware if I'm programming something embedded.
5) I don't like it. Personally I would not want to query for data. I envision a distributed FS that automagicly replicates on demand, etc.
Member since:
2005-06-30
If the purpose is to run existing software, then existing operating systems will do fine.
If the purpose is to write new software that mimics existing software, then existing operating systems are more than enough.
You should not desire existing software to run on your operating system. You should desire the opposite: that no existing software can run on your operating system! this would mean that your operating system has some true innovations!
All the things you mention (ioctl, userspace, kernel, kernel modules, the command line, files etc) are things that belong in the classic design of operating systems.
Shouldn't you think outside of the box, if you want to make new and radical things that will make your project a big success?
Because past experience has shown that if you try and invent everything at once, (from what you're saying, I shouldn't need a C compiler, managed runtime or anything like that; but how would people develop software?) it doesn't ever get too popular (because there's no way for existing people to move over) and you may end up getting stuck in development hell.
I find the 'let's reinvent everything' approach quite attractive, but it's not practical from my particular viewpoint. I've always been a 'let's build a good base and then improve this and make it different, then this, then another thing'.
New approaches are needed both at the programming language level and operating system design level.
I like your attitude (we always need blue sky thinkers as a society) and I agree with you on the scaling point. Do you have any particular ideas you'd like to see implemented?
Edited 2009-01-07 17:02 UTC