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 424890
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[3]: Comment by mtzmtulivu
by vodoomoth on Sun 16th May 2010 14:55 UTC in reply to "RE[2]: Comment by mtzmtulivu"
vodoomoth
Member since:
2010-03-30


That's why I'm working on a desktop operating system project. I try to prove that some real evolutions are still possible in that area. But it won't be ready tomorrow. And it could never be ready at all, even though articles like this are encouraging me to go further and prove that the desktop still has something to say.

The fact is, at the moment, I've got nothing that's worth showing. Only some written doc (targeted user experience and kernel design) and a code which turns multiboot data into something useful and arch-independent, and which *almost* turns long mode on. Until I get a fully working µkernel, there's nothing interesting here. And until I get some usable GUI running on top of it, there's nothing worth showing here at OSnews.

It'll take a year or two, at least, before I get a stable GUI, if I take the time to write clean code (which I want to do).

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

Unless such a thing exists and I'm not aware of it, I think OSNews should have a forum were topics could be forked from the news. It's quite frustrating (I repeat, "unless it already exists") that comments cannot be posted on articles that are more than five days old. I'm referring specifically to the article where there was a link to Kroc's vision of what the dream OS would be (user and task-centric, no branding, no bloated apps like iTunes; that's IIRC). Back to the topic at hand, the reasons why we don't see the silhouette of a real "revolution" necessarily comprise these two:

1- some paradigms have emerged as the best. Specifically thinking of preemptive CPU time-sharing techniques. Although I recall (probably 4 months max) reading an article about a member of Microsoft's OS core team pointing out the need to rethink how the processor is used (wrt system space and user space) due to old designs applying to more recent multiple-core architectures. I think OS originality comes from design decisions or orientations; the rest is just accessory. None of this exists today: the file system explorers on Windows and Ubuntu look like twins of Finder, with more options, true, but still clones.

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.

In an OS, speed and user-experience (not the geek, the lay user, like any grandmother) should be the only design concerns. 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 ?).

Another thing to avoid as much as possible: drivers... The situation with Windows is just insane and ludicrous: plugging the same USB device in four distinct ports installs the device driver 4 times!

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. 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.

Reply Parent Score: 1

RE[4]: Comment by mtzmtulivu
by Neolander on Sun 16th May 2010 19:53 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