Page 1 of 2

Design goals

Posted: Fri May 26, 2006 1:24 pm
by dc0d32
.

Re:Design goals

Posted: Fri May 26, 2006 1:41 pm
by GLneo
My goal is to combine them both in the best way possible, but if I *have* to decide it would be performance, there are all ready durable OS's out there but few very fast ones. But I think you should be able (with well written code) to do both

Re:Design goals

Posted: Fri May 26, 2006 1:58 pm
by mystran
Flexibility, scalability, security. That's my list.

Re:Design goals

Posted: Fri May 26, 2006 3:57 pm
by Colonel Kernel
mystran wrote: Flexibility, scalability, security. That's my list.
Flexibility should never be an end in itself, unless you're a gymnast, acrobat, or contortionist. :)

As for dependability versus performance, I believe you can have both. Yes, it's time once again to haul out the oft-used (and perhaps oft-ignored?) link to the Singularity project.

Re:Design goals

Posted: Fri May 26, 2006 7:39 pm
by Brendan
Hi,

I guess my main goal is to do everything in parallel (asynchronously) in the hope that it improves performance in "many CPU situtations" (which includes a distributed cluster of seperate computers). IMHO this will lead to reduced performance in "single CPU situations".

It also lends itself to much higher dependability (redundant services, protection, etc), which is a good thing because you don't want a (software or hardware) failure on one computer to bring down an entire group of computers.

The other concern is maintenance and administration - I would sacrifice performance if it meant that the system as a whole is easier to maintain.

Combining it all gives this list, in order or importance:
  • - dependability
    - maintainability
    - performance
    - eye candy!
Ironically, from a marketting perspective this is entirely the wrong way around... ;)


Cheers,

Brendan

Re:Design goals

Posted: Fri May 26, 2006 9:12 pm
by earlz
Combining it all gives this list, in order or importance:

- dependability
- maintainability
- performance
- eye candy!


Ironically, from a marketting perspective this is entirely the wrong way around...
/\
l
exactly except maybe maintainability
but yea that actually is the way the non-scammist should be

Re:Design goals

Posted: Sat May 27, 2006 1:02 am
by Ryu
I tie dependability and performance very close together, but ofcourse theres always gain one and loose some on the other. I would generally put dependability over performance but then always end up looking harder to find the door that meets my satisfactory in both.

If I were to scale these from 1 to 10:

dependability : 10
performance : 8
maintainability : 4
eyecandy? : 1 :P

If I were doing something that I get paid for then thats a differnt story.

Re:Design goals

Posted: Sat May 27, 2006 1:35 am
by Midas
Maintainability
Extendability
Performance

That's about it, in that order, I reckon.

Re:Design goals

Posted: Sat May 27, 2006 2:04 am
by Brendan
Hi,

I think what I wrote wasn't very well worded...
Brendan wrote:The other concern is maintenance and administration - I would sacrifice performance if it meant that the system as a whole is easier to maintain.
By this I mean system administration, not source code maintenance.

For example, imagine you're responsible for maintaining a network of 500 computers. Now consider an OS and software that automatically reports problems, keeps track of when things are due for service, maintains a list of equipment (type, manufacturer, age, serial number, etc) and a list of software (name, manufacturer, licence conditions, etc); where all of this information was available through some sort of utility; and where the utility is capable of sorting the information and sending different things to different people (e.g. hardware failures to employee #1, software problems to employee #2, security breaches to employee #3, mouse cleaning to employee #4, etc) and capable of prioritizing these things.

In this case, each employee of the maintenance department would just check their email (or something) for incoming "alerts" to find out what they need to be doing, and everything would take care of itself.

To implement this sort of thing you need software that is constantly monitoring things and keeping track of equipment, users, etc that runs in the background on every computer. It would also need to be built into device drivers, file system code, user login/logout code, etc.

For source code maintenance, that should always be near the top of the list but you shouldn't need to sacrifice anything for it...


Cheers,

Brendan

Re:Design goals

Posted: Sat May 27, 2006 3:21 am
by Pype.Clicker
Just for those who wonder "what the xxxx is 'dependability' ? what depends on what ??":
The notion of dependability, defined as the trustworthiness of a computing system which allows reliance to be justifiably placed on the service it delivers, enables these various concerns to be subsumed within a single conceptual framework. Dependability thus includes as special cases such attributes as reliability, availability, safety, security.

Re:Design goals

Posted: Sun May 28, 2006 6:16 am
by Candy
I would vote for dependability as #1, since it's the only one of the two that you can check-mark off as being "done". Performance is a measure of how fast it does something, dependability is about it NOT doing something (crash). You can check whether it doesn't do a given something.

Anyways, I consider dependability the most important bit there is. There's no point in taking a concorde if it crashes in the ocean halfway through.

Re:Design goals

Posted: Mon May 29, 2006 12:12 am
by JoeKayzA
I've also voted for dependability before performance. Although my plans are still somewhat vague, I'd say I join Midas in my list of goals:
  • Maintainability (from the admin's point of view)
  • Extensibility
  • Dependability
  • Performance

Re:Design goals

Posted: Mon May 29, 2006 2:15 pm
by Candy
JoeKayzA wrote: I've also voted for dependability before performance. Although my plans are still somewhat vague, I'd say I join Midas in my list of goals:
  • Maintainability (from the admin's point of view)
  • Extensibility
  • Dependability
  • Performance
Although I understand this list, I prefer a different order:
  • Dependability
  • Maintainability
  • Extensibility
  • Performance
1. It needs to work.
2. I need to be able to keep it working (if it didn't work, why bother having it easy to fix... make it work first, then make it easy to maintain)
3. It needs to fit in with other stuff and be able to learn / do more than originally intended. Otherwise, what use is a hammer if you can only hammer on nails?
4. It needs to be quick. Since this is a bottomless well, I'm going to put this last in any case. It is still on the list, which means that it IS something I keep track of and I design around in case of choices that don't have a direct adverse effect on any of the other three goals.

Re:Design goals

Posted: Tue May 30, 2006 3:16 am
by Solar
:o ??? :o ??? :o

:-[

I am actually shocked to see how any sane engineer could possibly vote for performance over dependability.

Of course you try to achieve both, but in an exclusive-or situation, there shouldn't be any question. Without dependability, performance is nothing.

Re:Design goals

Posted: Thu Jun 01, 2006 6:12 am
by Pype.Clicker
Solar wrote: Without dependability, performance is nothing.
Yes, it is: a gamer system for Andrea Maxframe :P