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 425075
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[5]: Comment by mtzmtulivu
by ricegf on Mon 17th May 2010 10:58 UTC in reply to "RE[4]: Comment by mtzmtulivu"
ricegf
Member since:
2007-04-25

You can *feel* that the UNIX family targeted people running one single task at a time on a dumb terminal. Example : run a CPU-intensive task in some kind of virtual terminal. Open a new tab or use Ctl+Alt+Fx and log in. Noticed how long it took for the shell to be ready ? ... It's an issue for anything that's GUI-related.

OK, I've experienced GUI slowness, and agree that neither Gnome nor KDE are outstanding in prioritizing the GUI over background tasks by default (I know Windows is far worse, but I can't speak to other GUI shells, as I haven't used them). They should do better - although even since early Unix, nice has been available to manually address this.

BUT. Unlike Windows, KDE or Gnome are NOT part of Unix - they are just GUI shells.

Counter-example: Install gnu screen (it's a textual window manager, more or less). Start a CPU-intensive task. Create a new screen. Repeat as long as you like. Performance degrades nicely - I know, because I've used this to run a bazillion cross-compiles simultaneously without any real performance problems.

What's more, I've used this to run a bazillion cross-compiles *on dozens of computers on the local network*. All using nothing more than the command line. I know that Windows can't do this natively (you have to pay for special software); I don't have experience with other OSes in this regard, so I can't say if this is a Windows short-coming or a *nix strength.

My point, though, is that non-optimal GUI responsiveness aside (and the GUI is not the kernel), *nix not only handles multi-processing well from the primitive command line, but even multi-computing.

If you successfully write a new OS, I hope you layer it nicely like *nix rather than create a soup like Windows, so that the GUI shell will be portable. Unlike Microsoft and Apple, us Linux folks LIKE choice.

(I suspect writing a better shell is a LOT harder than it looks. That's why I haven't done it. :-D )


Then, think about UNIX's traditional startup process : it runs a script shell, which then sequentially runs several tasks.


Yes. I can't imagine why you want to multi-task during startup, though. If you have a hardware issue,can you image debugging it in a multi-tasking scenario??? *shudders*

Reply Parent Score: 1

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

"
Then, think about UNIX's traditional startup process : it runs a script shell, which then sequentially runs several tasks.


Yes. I can't imagine why you want to multi-task during startup, though. If you have a hardware issue,can you image debugging it in a multi-tasking scenario??? *shudders*
"
The reason for multitasking the startup process is simple, actually : during startup, there is a lot of IO-bound tasks. Waiting for IO is wasting precious time. Let's suppose that you want to connect to the internet at boot time. Wireless connection + DHCP request and acknowledgement takes, say, 5 seconds. During those 5 seconds, you could have loaded several modules from the HDD.

Reply Parent Score: 1