Can we really think at a new OS design nowadays ?
Hello, Here is the start point of my reflexion : http://lists.gnu.org/archive/html/l4-hurd/2006-04/msg00053.html I believe that we can do extremely complex and reliable software with a few people, thanks to the powerful formal and design tools available now. Moreover, I think that this OS has to support three key things to be able to survive ( an essential key to have a long term development ) : synergy ,transition & usability. -The first one is the start of any important project : developers can have the possibility to share complex ideas with minimum requirements and to integrate them in a coherent environment. ( see http://www.gnu.org/software/hurd/ => 23 years old and even the goals are not well defined ) -The second feature provide any user the ability to develop on it with existing materials and to have the support of developers of legacy OS. ( see www.tunes.org => maybe too innovative and this : http://symbolx.org/ddf_news.html ). -The third one needs that a device driver framework needs to be rapidly envisaged. ( again http://www.gnu.org/software/hurd/ => no good driver kit at this date, the same for linux : http://www.kroah.com/log/2006/05/24/, 15 years later ). Who wants to have an OS that boots only a black screen with a beep sound ? If we follow the Moore law, an OS design of the future would be thought for quadruple play ( mobility, audio, video, Internet ) and security of course. Time is maybe our worst ennemy : more and more technologies are created day by day and we need to understand and to be able to use them And it's maybe our better friend : as the hardware/software becomes mor and more complex, the tools to develop them becomes more powerful too. The tools developed to understand and create complex systems give us the ability to design and implement an OS design secure & reliable. Here are my guidelines to start : _ First : Users collaboration :_ http://www.opencroquet.org _Second - Formal tools :_ http://www.fmeurope.org Z method : http://czt.sourceforge.net/ http://www.zuser.org/ B-method : http://en.wikipedia.org/wiki/B-Method http://rodin-b-sharp.sourceforge.net/index.html _Second - Software design :_ http://planetmde.org/ http://distributed-software.blogspot.com _ Third - Language Designer's Toolkit :_ http://lambda-the-ultimate.org/node/1562 http://hlvm.org/ Abstraction will be the solution, Best Regards, Guillaume FORTAINE
On Sat Aug 05, 2006 at 19:50:05 +0200, Guillaume FORTAINE wrote:
Hello,
Here is the start point of my reflexion :
http://lists.gnu.org/archive/html/l4-hurd/2006-04/msg00053.html
I believe that we can do extremely complex and reliable software with a few people, thanks to the powerful formal and design tools available now.
Moreover, I think that this OS has to support three key things to be able to survive ( an essential key to have a long term development ) : synergy ,transition & usability.
What does synergy mean, and why is it a key to an OS? Benno
Benno wrote:
On Sat Aug 05, 2006 at 19:50:05 +0200, Guillaume FORTAINE wrote:
Hello,
Here is the start point of my reflexion :
http://lists.gnu.org/archive/html/l4-hurd/2006-04/msg00053.html
I believe that we can do extremely complex and reliable software with a few people, thanks to the powerful formal and design tools available now.
Moreover, I think that this OS has to support three key things to be able to survive ( an essential key to have a long term development ) : synergy ,transition & usability.
What does synergy mean, and why is it a key to an OS?
Benno
Synergy : have enough developers with a common goal to achieve it. ( to avoid dead-born projects ) Abstraction ( meaning rigorous formalism ) : http://66.249.93.104/translate_c?hl=fr&langpair=fr%7Cen&u=http://fr.wikipedi... http://66.249.93.104/translate_c?hl=fr&langpair=fr%7Cen&u=http://fr.wikipedi... To avoid these types of errors :-) ! => have a pure reliable ( totally bug-free os ) Best Regards, Guillaume FORTAINE
Guillaume FORTAINE wrote:
Synergy : have enough developers with a common goal to achieve it. ( to avoid dead-born projects )
You do not necessarily need many developers to write an OS; many successful and well working OSes were written by < 10 people in 2-5 years. The other 1000s just tweak it here and there, add fancy features, redesign parts and thus introduce new bugs etc.
Abstraction ( meaning rigorous formalism ) :
Formally verified software can still be wrong, as it is verified against a model, which is also human-made and thus error-prone.
To avoid these types of errors :-) ! => have a pure reliable ( totally bug-free os )
Most of the code that does not have a chance to mature over time and be fixed once for all lies within device drivers and applications, not in the core OS. Moreover, even in the core OS, bugs are mainly a social problem. Amateurs prefer to hack new code rather than to fix bugs in code they wrote yesterday: Linux kernel 'getting buggier' http://news.zdnet.co.uk/0,39020330,39267255,00.htm Why instead of starting a new project you don't fix the outstanding issues in one of the many existing ones? I am sure that people working on existing OSes will be happy to list lots of tricky problems to solve for you. Here is one: why it takes two days to get a webcam working in Linux? Why can't I just connect it at at a USB port, and have Linux to query an online database, download the appropriate kernel module, and install it? Why I need to download kernel headers, download a hackish code, get it to compile, hammer it in the kernel, get crazy to get a video application to access the right device in /dev/... ? Sergio -- -- http://www.cse.unsw.edu.au/~sruocco/ ERTOS Researcher Lecturer National ICT Australia Ltd. University of New South Wales This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed.
At Sun, 6 Aug 2006 09:52:51 +1000, Benno wrote:
On Sat Aug 05, 2006 at 19:50:05 +0200, Guillaume FORTAINE wrote:
Abstraction will be the solution,
Doesn't the research of Engler show us that abstraction in operating system design is bad?
I think it would be fair to argue that this is perhaps the hypothesis which drove the Exokernel research, however, it is unclear to me that the research actually proves. In "Application Performance and Flexibility on Exokernel Systems," Kaashoek et al. state that hardware page tables, although they impose policy and appear to restrict application freedom, do not actually significantly reduce application flexibility: "Unlike the MIPS architecture, the x86 architecture defines the page-table structure. Since x86 TLB refills are handled in hardware, this structure cannot be overridden by applications. . . . Although these restrictions make Xok less extensible than Aegis, they simplify the implementation of libOSes with only a small reduction in application flexiblity (9)." In fact, it simplified thigs: "User-level page tables made the implementation of libOSes tricky on Aegis; since the x86 has hardware page tables, this issue disappeared on Xok/ExOS (16)." I draw from this that eliminating abstractions simply to eliminate abstractions misses an important point: some polices introduced via mechanism have negligible negative impact on performance and some such policies actually have positive impact (e.g. code simplification). This observation supports Liedtke in his challenge of the Exokernel architecture in "On u-Kernel Construction:" "In contract to our approach [L4], [Exokernel] is based on the philosophy that a kernel should /not/ provide abstractions but only a minimal set of primitives. Consequently, the Exokernel interface is architecture dependent . . . We believe that dropping the abstractional [sic] approach could only be justified by substantial performance gains. . . . It might turn out that the right abstractions are even more efficient than securely multiplexing hardware primitives or, on the other hand, that abstractions are too inflexible." Neal
participants (4)
-
Benno -
Guillaume FORTAINE -
Neal H. Walfield -
Sergio Ruocco