OSNews

Well... you can argue and protest all you want,
it's Robert's design decision and it won't change. ^_^

If Skyos is ever recognized to be a stable, robust, fast and reliable os, it will be proof that his decision was a good one.

I don't think that this day has come yet ^_^,
yet...the way Skyos is improving might already be proof enough, that going the C++ way and putting some stuff in the Kernel was a good choice.

Anyway, personnaly, I think that Robert knows much more about os/kernel design than most of the people that come here, including me, so I just trust him ^_^.

Can't you trust him a little bit too ?

"Even Windows has a native console interface, although Microsoft only let's you use it when you boot through the Windows 2k/XP installation CD and fire up the recovery console"

not entirely right.....the thought windows power shell comes to mind.

Because 99% of computer users are NOT techies and do not have the inclination or necessarily even the ability to fart-arse around with consoles and command lines, nor should they ever have to. CLIs are a primitive relict of a bygone age of computing when computers lacked the power to run an intuitive GUI, and while CLIs are still important for some sys-admin functions, as far as the vast majority of computer users are concerned, a GUI is the only way to interact with a computer.

Now, you can argue over the technical merits of this until the cows come home, but the fact is that only a tiny minority of computer users have any desire to go back to the bad old days of using DOS prompts and text consoles.

For most computer users, if something in the OS breaks and they get dumped back to a command line prompt, they will have no more idea what to do than if the computer doesn't boot at all, and will either A) just re-install the OS (less likely for most users) or B) take it to someone who knows what they are doing and can use some recovery tools to rescue a broken OS if possible (most likely scenario). And this is assuming some permanent breakage - it is far more likely that in the event of a GUI based OS having a serious error that a simple restart will fix it.

A GUI is the most sensible way to interact with the OS for the majority of users, as it uses the same parts of the brain we use to interact with the physical world and is hence fairly intuitive once you grasp the basic metaphors involved, whereas command lines require the user to adopt a special mode of thinking that most people find difficult, and is a highly abstract way of interacting with a computer. Many computer experts fail to realise that what comes easily to them is totally alien and incomprehensible to most "normal" people.

So, as far as I am concerned, Robert is entirely correct to require a GUI as the primary means of interacting with the operating system, and putting it in the kernel space is fine, since if the GUI breaks, the user would likely restart anyway. This is not intended as a server OS, where restarting the computer could be very disruptive. If it crashes or becomes unstable, you restart it, just like most Windows users do. And as a desktop OS, there would be little need to use a remote connection to control the computer via SSH or whatever, so a command line is largely redundant for most users and tasks.

Because 99% of computer users are NOT techies and do not have the inclination or necessarily even the ability to fart-arse around with consoles and command lines, nor should they ever have to. CLIs are a primitive relict of a bygone age of computing when computers lacked the power to run an intuitive GUI, and while CLIs are still important for some sys-admin functions, as far as the vast majority of computer users are concerned, a GUI is the only way to interact with a computer.

Now, you can argue over the technical merits of this until the cows come home, but the fact is that only a tiny minority of computer users have any desire to go back to the bad old days of using DOS prompts and text consoles.

This is a matter of vision in the end, but it's been highly fueled by a huge misconception. Every person I've met that passionately thinks GUIs are the Only Way also believes that the ultimate standard in terms of command line is command.com or cmd.exe

Get over it. Both *are* relics from CP/M. Microsoft never bothered to do anything serious about them from the days they were running on computers with 64 KB of memory. Compared even to small shells, like ash, cmd.exe seems to have suffered a full frontal lobotomy.

I'm not (and nobody is) saying that there should be no GUI whatsoever, simply that there are cases when a GUI is not the best to handle things. Try to use a GUI for a quick task like compressing all the MP3 files on your hdd which are larger than 7 MB and you'll quickly understand where's the problem with GUIs and why a strong CLI is required.

The main argument here is actually including the GUI in the kernel, and I agree that's stupid. The idea of "when it locks down, restart it" is the key to a very flawed design. Is the GUI essential to running the OS? Can the OS boot without it? Is the GUI tied to any kernelspace services that are not accessible otherwise? If the answer to all these three is no, then there's no room for the GUI in the kernel.

The thing that surprised me the most about that post was the comment that "any half decent OS must have a fallback mechanism through wich us techies can fix broken stuff".

Is it so impossible that the fallback mechanism could also use a GUI? Windows in Safe Mode is pretty much what he's talking about...

What's the real difference between a command-line interface and a GUI anyways? They both require the OS to present some sort of screen-based interface to the user. Whether it is pure text, or graphics is just a question of additional features. Input/output must still be multiplexed somehow and separated on a process by process basis. If the OS enforces access control and permissions on files, terminals, memory and CPU, why should it also not enforce access control and permissions on the shared resource that is the screen?

A well-designed GUI presents a limited list of descriptively labeled relevant options (menus and buttons) whereas a CLI requires the user to know commands from memory. A GUI can use metaphors from real life, such as folders and arrows and pictures, whereas a CLI is just a blinking cursor. GUIs are a familiar concept to many users from machines in daily life such as ATMs and cell phones; CLIs are alien to most people. GUIs are for people who need ease of use rather than unlimited power, which is most people.