Design goals
Re:Design goals
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
- Colonel Kernel
- Member
- Posts: 1437
- Joined: Tue Oct 17, 2006 6:06 pm
- Location: Vancouver, BC, Canada
- Contact:
Re:Design goals
Flexibility should never be an end in itself, unless you're a gymnast, acrobat, or contortionist.mystran wrote: Flexibility, scalability, security. That's my list.
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.
Top three reasons why my OS project died:
- Too much overtime at work
- Got married
- My brain got stuck in an infinite loop while trying to design the memory manager
Re:Design goals
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:
Cheers,
Brendan
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!
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Re:Design goals
/\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
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
If I were doing something that I get paid for then thats a differnt story.
If I were to scale these from 1 to 10:
dependability : 10
performance : 8
maintainability : 4
eyecandy? : 1
If I were doing something that I get paid for then thats a differnt story.
Re:Design goals
Maintainability
Extendability
Performance
That's about it, in that order, I reckon.
Extendability
Performance
That's about it, in that order, I reckon.
Regards,
Angus [Óengus] 'Midas' Lepper
Angus [Óengus] 'Midas' Lepper
Re:Design goals
Hi,
I think what I wrote wasn't very well worded...
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
I think what I wrote wasn't very well worded...
By this I mean system administration, not source code maintenance.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.
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
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Design goals
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
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.
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
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
Although I understand this list, I prefer a different order: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
- Dependability
- Maintainability
- Extensibility
- Performance
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
??? ???
:-[
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.
:-[
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.
Every good solution is obvious once you've found it.
- Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Design goals
Yes, it is: a gamer system for Andrea MaxframeSolar wrote: Without dependability, performance is nothing.