Are 'good' designs really worthwhile?

[01000101]

I have to agree with lollynoob on that last post.

but anyways, I think if the OS is not even going to be distributed, then what is the big deal here? make it as secure as YOU want if only YOU are going to use it.

but on the flip-side, I think safety nets should be included in OS's just because slip-ups do happen and it is good to know that if I accidentally click delete instead of rename, the file isn't gone forever and has a popup or something to verify that is what I truely intended on doing. As far as lowlevel protection, I think that is crucial as alot of the 'bugs' are not user based and are infact design flaws that popup later on. If a program goes crazy and starts deleting chucks of memory, there should be some security mechanism to make it stop.

[Alboin]

Also, how is it not the user's job to operate their computer safely? The operating system isn't there to hold your hand and make sure you don't delete everything by accident.

A computer is used to perform task X. (eg. word processing, music, etc.) An OS should provide a user with an interface that allows him to perform what he wants with as much simplicity and ease as possible. The end user should not have to think about using a computer, but instead, only about performing his task. He shouldn't think about 'creating file x, starting program y, installing module z, etc'. He should think 'do task'. This way, he can better do his task, and not care about things that don't matter.

[esa]

@Alboin

I guess in that case all current mainstream OSes get a failing grade in usability. What would we need to correct the situation? A single dynamic totally task-oriented GUI for the whole OS? Can we really anticipate everything the user might want to do and construct an UI for him/her beforehand to do it?

[Alboin]

@Alboin

I guess in that case all current mainstream OSes get a failing grade in usability. What would we need to correct the situation? A single dynamic totally task-oriented GUI for the whole OS? Can we really anticipate everything the user might want to do and construct an UI for him/her beforehand to do it?

No, we can't. My point there was the idea of an ideal computer. The entire goal of any operating system and computer, in fact, is as I stated: to perform a task of the user. If we could always perform the user's task perfectly, then you'd have the perfect OS.

[lollynoob]

No, we can't. My point there was the idea of an ideal computer. The entire goal of any operating system and computer, in fact, is as I stated: to perform a task of the user. If we could always perform the user's task perfectly, then you'd have the perfect OS.

Seeing as the user's goals are completely unknown to the computer, shouldn't the perfect OS be the one which is the most open-ended? Also, to achieve this, shouldn't limitations be as few as possible as far as what the user (or the user's software) can and cannot do?

[Colonel Kernel]

Seeing as the user's goals are completely unknown to the computer, shouldn't the perfect OS be the one which is the most open-ended? Also, to achieve this, shouldn't limitations be as few as possible as far as what the user (or the user's software) can and cannot do?

No, because being faced with too many choices generally has a negative impact on a person's psychological well-being.

[lollynoob]

No, because being faced with too many choices generally has a negative impact on a person's psychological well-being.

Open-endedness does not necessarily force a decision. Who's to say that the operating system wouldn't come "pre-packaged" with a suite of software? The lack of restriction would only come in, then, if the user wanted to uninstall the software in favor of another program which they would be easily able to do. Also, as far as development goes, writing software usually isn't about making choices; the programmer already knows what he is going to make before he makes it.

[oscoder]

lollynoob wrote:
Seeing as the user's goals are completely unknown to the computer, shouldn't the perfect OS be the one which is the most open-ended? Also, to achieve this, shouldn't limitations be as few as possible as far as what the user (or the user's software) can and cannot do?

No, because being faced with too many choices generally has a negative impact on a person's psychological well-being.

The problem here is that you (both I think) are considering the OS as a whole, rather than the individual parts. IMHO the core of the OS (kernel, etc) should be as open ended as possible, but the outer parts (shell, some apis, etc) should be less open, in order to make things easier on the user. The shell can always be changed if it doesn't fit the user's goals well anyway.

OScoder

[jal]

The problem here is that you (both I think) are considering the OS as a whole, rather than the individual parts. IMHO the core of the OS (kernel, etc) should be as open ended as possible, but the outer parts (shell, some apis, etc) should be less open, in order to make things easier on the user. The shell can always be changed if it doesn't fit the user's goals well anyway.

I disagree. As a programmer, I do not want many choices either. Take the 300,000,000 call Win32 API, for example. It's an example of how not to do it.


JAL

[oscoder]

The problem here is that you (both I think) are considering the OS as a whole, rather than the individual parts. IMHO the core of the OS (kernel, etc) should be as open ended as possible, but the outer parts (shell, some apis, etc) should be less open, in order to make things easier on the user. The shell can always be changed if it doesn't fit the user's goals well anyway.

I disagree. As a programmer, I do not want many choices either. Take the 300,000,000 call Win32 API, for example. It's an example of how not to do it.


JAL

Ah, but that's what layers are for! IMHO, there's nothing wrong with being able to use 300,000,000 functions, it's when you have to that's the problem . From what I remember though, the problems with the Win32 API aren't just in the amount it lets you do - it's not so well designed anyway. (I remember Tannenbaum gave a good example of this in one of his books, comparing the linux and win32 way of creating a process, or something like that).

OScoder

[bewing]

I agree with jal.

First, each API call requires some system code to handle. Which increases bloat, and slows everything down. So minimizing the number of API calls should be a design goal.

Second, it takes time for a programmer to learn how to use each API call. If there are too many, it becomes a burden ... then, with each additional call, it becomes more and more impossible.

An OS that has a lot of API calls needs to have a REALLY good documentation system, that tells you which call to use to do what, and exactly how to use it -- and not one of the current major OSes actually has such a documentation system.

And if the OS is telling you which call to use to accomplish each programming goal -- are there really 300,000,000 completely independent programming goals? Of course there are not. API calls are "primitives", and you build your programs with a nicely designed minimal set of standardized primitives.

[Cognition]

Personally I'm of the opinion that the easiest way to deal with it all is to limit the points at which a user might need to override their basic privileges. I wasn't really impressed by the way Vista did this, UAC is better then nothing but it really doesn't let you know what or why something needs supervisor access. I like the way properly configured linux does things much better personally, but configuring it isn't usually super user friendly. The best way of doing things probably lies somewhere in between and I think realistically unix style permissions are set up better to do it.

I've felt a big problem with GPL style software platforms in general is there aren't really as many standards. Sound daemons and default tools for a given task can change rapidly, projects can stagnate and so forth. Alternatives are good and so are new ideas, but overall I think it tends to make things a bit more volatile then a lot of people would like.

API's I'm kind of torn on. I think generally simpler is better, but it seems there's a growing push for things like standard template libraries and .net style base classes for common tasks, which should make software development simpler. Most this should reside outside of the kernel anyways though.

[Korona]

First, each API call requires some system code to handle. Which increases bloat, and slows everything down. So minimizing the number of API calls should be a design goal.

The windows api is a userspace library. It's something like glibc on linux. Api functions are based on a small set of system calls, Windows does not provide a system call for each api function.

Second, it takes time for a programmer to learn how to use each API call. If there are too many, it becomes a burden ... then, with each additional call, it becomes more and more impossible.

Learning how to use each system call itself would be even harder. If you would not have api/library functions even drawing a window would be impossible. Your userspace application had to care about communicating with the window manager and it had to care about lots of unimportant details e.g. resolution of the screen and color depth.

An OS that has a lot of API calls needs to have a REALLY good documentation system, that tells you which call to use to do what, and exactly how to use it -- and not one of the current major OSes actually has such a documentation system.

Languages like php or java have a very good documentation for each api call. I think MSDN provides good documentation about the windows api but I never used it so I can't be sure.

And if the OS is telling you which call to use to accomplish each programming goal -- are there really 300,000,000 completely independent programming goals? Of course there are not. API calls are "primitives", and you build your programs with a nicely designed minimal set of standardized primitives.

There are lots of different programming goals. When I want to read data from a file I usually just want to type read(file, buffer, offset, length)
instead of using primitive calls:

Code: Select all

uint bytes = read(handle, buffer, offset, length)
while(errno() != E_NOT_AVAILABLE) {
    uint thread_handle = getCurrentThread();
    letTheDriverWakeMeUp(thread_handle, handle);
    letThisThreadSleepIfDataNotAvailable(thread_handle, handle);
    bytes = read(handle, buffer, offset, length);
}
if(errno() != E_SUCCES)
    return 0;
return bytes;

[JackScott]

I think MSDN provides good documentation about the windows api but I never used it so I can't be sure.

In my experience, the MSDN library is correct and has enough info about 50% of the time. And as we know, having mostly-correct info is worse than having none at all. As an example: code samples off MSDN won't actually compile, even the "complete" ones.

[Combuster]

Once you know to filter out "Windows CE" from the results, IMO MSDN is actually a good source of information. Actually I never had a time when it couldn't tell me what I needed to know of it.

As for the windows API itself, there's usually just one obvious way to do things...

But then, I never tried asking it about .NET