Linked by Thom Holwerda on Sat 15th May 2010 19:23 UTC
OSNews, Generic OSes There's one complaint we here at OSNews get thrown in our faces quite often: what's up with the lack of, you know, operating system news on OSNews? Why so much mobile phone news? Why so much talk of H264, HTML5, and Flash? Where's the juicy news on tomorrow's operating systems? Since it's weekend, I might as well explain why things are the way they are. Hint: it has nothing to do with a lack of willingness.
Thread beginning with comment 424954
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[4]: Comment by mtzmtulivu
by Neolander on Sun 16th May 2010 19:53 UTC in reply to "RE[3]: Comment by mtzmtulivu"
Neolander
Member since:
2010-03-08

@Neolander: I am more than willing to contribute to your project. Do you have a thread on some forum or a Sourceforge page started ?

At the moment, I only have a blog ( http://theosperiment.wordpress.com ), which I use when I want to get rid of some confusion in my head : if something is puzzling me, I write an article about it. The act of writing helps me in the task of thinking rigorously and solving design problems.

As I said above, I'll probably open a sourceforge page and make a serious page for my project once I've got a working micro-kernel. I want to do this part alone, because...
1/Writing it is quite a sequential task.
2/It's a personal challenge, to know if I'm ready to go further ;)
3/When writing code, I'll probably make new design decisions as needed. I want to have a complete and stable design doc to release along with my source code. For design doc stability, I'll wait for the kernel to be completed before making an "official" one ^^

2- As I've pointed out in another article about Ubuntu 10.04, all OSes I've tried (all Windows except 7, MacOS 10.5 and 10.6, Linux - at various times in the past 13 years but it's never looked mature enough for my taste, except Kubuntu 10.04) suck and deserve a good "zéro pointé" (meaning zero plus half of zero) spoken out loud and clear for all that's related to speed.

Yes, considering how fast are today's computer, that's extremely funny. I think this comes from ageing code which reaches end of life and gets more and more bloated. You should have a look at Haiku, as an example : it's a young project, and performance is extremely good.

In my opinion...
1/The key to actual speed is clean and lean code which scales well.
2/The key to perceived speed is good priority management (user input management as top priority), always providing some kind of feedback, and keeping the user busy. ^^

In an OS, speed and user-experience (not the geek, the lay user, like any grandmother) should be the only design concerns.

Wrong. In my opinion at least, there's other major issues : reliability, security, and adaptability are among them. Would you like a very fast and very easy to use OS where some random program can steal your e-mail credentials and send them to a big spamming corporation ?

Any current OS on a current machine should ideally start in less than 15 seconds. Applications should launch and be usable in 2 seconds. Just as snappy as uTorrent on Windows or the new Opera 10.53 on MacOSX when loading a page on a good broadband connection. Anything longer than that on today's computers is either badly crafted or inherently flawed design-related (is that correct English ?).

(Won't help you for the English, I'm french ^^)

I mostly agree, but keep thinking about perceived performance too : if you can't make some code faster for some reason, then at least make sure that the user is asked for input as soon as possible and can then do something else while waiting for the task to be completed. This way, perceived loading time and performance will be good, even though there's still some work going on in the background.

I learned it in an ergonomics manual : keeping the user busy is always a good thing (TM) ^^

My advice for your project: before heading into code, choose your design goals clearly; in all cases strive to keep things: 1- minimal, 2- extensible and 3- easily configurable by average Joe.

See blog posts starting with 28/02/2010 ^^
http://theosperiment.wordpress.com/2010/02/28/scope-statement-1-use...

There's no point in having 60+ processes (current Vista) when the system has started after 3 minutes+ of painful loading and the user hasn't launched a single program yet. I understand having to wait longer when more options are on, I don't understand having to wait that long when I just want to retrieve some info from some text file or browse the web.

I agree, again, that things must always be kept clean. Non-mandatory things must be loaded in the background, after the user is logged and gets some usable interface, without interfering with its interactions with said interface. But about processes, I might get a lot though ;) It's an inherent part of my microkernel + isolated design.

Edited 2010-05-16 20:05 UTC

Reply Parent Score: 1

RE[5]: Comment by mtzmtulivu
by ricegf on Mon 17th May 2010 11:08 in reply to "RE[4]: Comment by mtzmtulivu"
ricegf Member since:
2007-04-25

"But about processes, I might get a lot though ;) It's an inherent part of my microkernel + isolated design."

I trust that you've thoroughly studied the original Gnu Hurd design, and clearly understand why that proved impractical. It sounds vaguely like you're heading down the path they started down in 1990. (I was a big fan of the concept - imagine upgrading the kernel without restarting the computer, how... mainframe! - and was disappointed when it failed.)

By the way, have you considered working on the new Hurd instead of your own kernel? Or working on Canonical's new Linux startup manager? Collaboration generally beats the pants off of a lone wolf. I realize it's a trade-off - the lone wolf, even pants-less, is often happier than a pack member, but the pack brings down the big game.

Reply Parent Score: 1

RE[6]: Comment by mtzmtulivu
by Neolander on Mon 17th May 2010 14:54 in reply to "RE[5]: Comment by mtzmtulivu"
Neolander Member since:
2010-03-08

"But about processes, I might get a lot though ;) It's an inherent part of my microkernel + isolated design."

I trust that you've thoroughly studied the original Gnu Hurd design, and clearly understand why that proved impractical.

No. Got some doc about it ?

By the way, have you considered working on the new Hurd instead of your own kernel?

No. It seems to me that if they got no serious results in so much years, there must be some organisational nightmare around, which I don't want to get into. Moreover, we don't target the same goal : the Hurd team is looking for a cleaner UNIX, which I'd gladly run on my computer instead of Linux if it's finally released with some serious apps running on top of it. I'm trying to make a true GUI-oriented desktop OS (something more in the vein of Haiku, but without the BeOS legacy). Hurd aims at making some next-generation OS. I aim at making a current-gen OS, only one which works better ;)

Or working on Canonical's new Linux startup manager?

No. I'll never, ever, do something for Canonical, given the way Shuttleworth treats his team. And I want to play with various parts of OS development, not just system startup.

Collaboration generally beats the pants off of a lone wolf. I realize it's a trade-off - the lone wolf, even pants-less, is often happier than a pack member, but the pack brings down the big game.

Yup. I consider going in Haiku development if this attempt fails. But at the moment, I'm happy playing with some bleeding-edge code that's fully under my own control. And some experience in low-level programming will be useful if I start contributing to another OS project someday instead.

Edited 2010-05-17 14:57 UTC

Reply Parent Score: 1