New OS Seeking Help
co...@geesaman.com
http://forum.osdev.org/viewtopic.php?f=2&t=19353&p=151513
Comments Welcome
Alexei A. Frounze
> There's a detailed thread at:http://forum.osdev.org/viewtopic.php?f=2&t=19353&p=151513
>
> Comments Welcome
There've been some good comments already.
But even if you finish your OS, nobody will want it because of various
compatibility issues just like many resist upgrading to Vista. And
don't forget the hardware with its drivers.
Microsoft definitely could use faster turn around and more useful
innovations, but I wonder if you'd be able (even with a team) to beat
them when your project grows big and complicated enough that you'll
need to do lots of dev and test work to ensure that the new
functionality really works and doesn't break anything else.
I think a project like yours could find a life in specific embedded
environments (ATM terminals, for example) but as a successful
competitor to Windows, Linux, MacOS or the like, it's pretty much
doomed.
If you want to do something about Windows, either join MS to improve
it or improve Linux. :)
Alex
James Harris
> There's a detailed thread at:http://forum.osdev.org/viewtopic.php?f=2&t=19353&p=151513
>
> Comments Welcome
It's notoriously hard to get others to join someone else's effort
(i.e. yours in this case) but if you post some ideas here - preferably
one per post - you'll likely get some positive responses and useful
discussions.
James
Aaron Gray
news:e462807a-9eb5-4cff...@u1g2000vbb.googlegroups.com...
On Mar 7, 11:43 am, c...@geesaman.com wrote:
>If you want to do something about Windows, either join MS to improve
>it or improve Linux. :)
I think what is required is not a new OS but a new open desktop for Linux
based on a modern scripting language that gives power users real power to
write some really good stuff. Disolve your linux flavour bash scripts into
your scrpting language and you are away free with the birds...
Anyone up for it ?
Aaron
Rod Pemberton
news:df4ec84d-7618-4344...@p11g2000yqe.googlegroups.com...
> There's a detailed thread at:
> http://forum.osdev.org/viewtopic.php?f=2&t=19353&p=151513
>
> Comments Welcome
Well, I've discussed a number of these issues here and elsewhere with a few
people, but...
Security section:
"... attackers are expected from specific entry points and those entry
points are protected against."
The first problem is no one knows all the methods to surreptiously gain
control of execution. There are always unknown flaws in cpu's, hardware,
etc that can't be known to the OS developer. Since it takes resources:
time, life, money, effort, skill, to protect against threats, you can only
afford to protect what you expect to be highly problematic, such as
networking, file downloads, multimedia files, removable media, etc. These
are expected to be problematic because they are sources originally external
to the "secured" PC. While your expectations might be right 60% of the time
or 80% of the time, they are guaranteed to be wrong some of the time, e.g.,
security breach. You can't replace all the weak links in the chain. If you
replace one weak link, there is still a next weakest link, repeat... Once
you've replaced all weak links, you still have a chain that is limited by
it's design and construction, just like the original.
The second problem is no matter how secure you make something, it's not 100%
secure. There is always a method to create an entrance or exit. It's just
a question of the cost in terms of time, life, money, effort, skill, waste,
etc. that is required to create it.
The third problem is that the only way you can prevent abuse is by turning
the computer off, which makes the machine useless. Your users are just as
likely to be the weak-link in the security chain as is someone or something
external.
The fourth problem is that not only does the OS need to be written with
security in mind, but so does the compiler, assembler, linker, and all other
development tools. I.e., you must implement methods other than those proven
to work reliably, which could open you up to more potential threats. The
threats with existing flawed implementations are known. I.e., you can fix
them when found. If you use new methods, you could be stuck with a design
flaw you can't fix. The problem with spending resources to fix the faulty
toolchain is that anyone can bypass the compiler, or assembler, and generate
code on their own. You can actually do this with just a text editor since
the only functionality you need to program is the ability to load files,
save files, modify files, execute files, and construct binary values.
Basically, there are no methods to guarantee a completely secure a computing
platform. If you attempt to do so, one of three things happens: 1) no one
can use the platform, or 2) those that can use the system will hate you
because it's too difficult or annoying to use, or 3) the system is useable
but also at moderate risk of a breach. The best you can do is to block or
fix the most dangerous problems, and make it very costly or time consuming
to breach. Resource usage is a bit like two new mechanics opening shop.
One mechanic borrowed and spent $5000 for a complete line of tools when he
opened his shop. It took him years to recover the profits to cancel the
loan. The other mechanic had little money, so he bought tools as he needed
them. He saved thousands, and profited handsomely. If you don't know it's
a problem, it's a waste to fix it.
"Security implemented in a more strict fashion would protect against any
feasible attack ..."
This will only cause your users to hate you. Literally. One of the most
annoying "features" of modern OSes is an overabundance of security. This
will:
1) confuse or annoy the user and cause the user to implement insufficient
security levels, e.g., bypassed for useability or convenience
2) confuse or annoy the user and cause the user to implement excessive
security levels, e.g., user can no longer run required applications
But, I mention this because the most blatant example of an overabundance of
security is file protections. This is what happens with excessive file
protections from my experiences with OSes like WinNT, DEC VMS, and Stratus
VOS:
1) file protections prevents users from deleting and replacing infected or
damaged files because they are protected, e.g., required component of the OS
or in-use by an application
2) file protections prevents users from installing or running needed
applications because they lack sufficient privilege
3) file protections causes user files to become "lost", i.e., marked as
hidden, in-use, or as a component of operating system
4) file protections allow security breaches by random parties, e.g., virii
using file system privileges to hide, or installs by third parties whose
rights are protected (e.g., DMCA) granting them excessive and risky access
to *your* system
Rule #1: DO NOT ALLOW OTHERS TO HAVE RIGHTS ON YOUR SYSTEM BY ANY MEANS NO
MATTER WHAT THE LEGALITY. DOING SO IS A BLATANT SECURITY BREACH.
Threading section:
"Race conditions shouldn't be possible outside of OS development"
What? Of course, any interrupt means that a "race condition" is possible.
AFAIK, the only way "race conditions" shouldn't be possible is if everything
in a PC executes sequentially, not just the OS software and applications,
but the hardware too. But, the hardware doesn't operate sequentially with
the software, i.e., race conditions. If the software executes sequentially
*without* interrupts, there will be no software created "race conditions"
since there is only a single thread of execution. But, without interrupts,
you can't implement an OS. You have to handle the hardware interruptions,
e.g., disk drives, video, mouse, keyboard, which are beyond your full
control and you have to handle software interruptions which are beyond your
control too: cpu faults, timer interrupts required for threading and
tasking, software generated errors, etc.
RAD section:
While RAD helps to reduce the time needed to code an OS, you also need to
worry about code size, code density, and code reuse. If the code becomes
too large, too complex, or too time consuming to enhance with your team of
developers in the future, it's the end-of-life for the development the OS.
In addition to the OSes Alex pointed out, there are OSes other than Linux
which are fairly complete: Visopsys, ReactOS, and the BSD's.
Rod Pemberton
Maxim S. Shatskih
> based on a modern scripting language
This requires not the language, but scriptable objects exposed from common Linux desktop apps, callable from the scripts _in a uniform way_.
Windows ecosystem has this since mid-1990ies (OLE Automation)
In Linux, there are _several incompatible_ ways of doing this and no one of them is popular.
As about scripting languages themselves - Linux is fine with them. PHP alone is OK for unprofessional users (quick to study), and there are others, probably more powerful.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com