They've already stated, to a qualified degree. Check out. http://www.transgaming.com/webstore.php
So far they - Marble Blast - The Sims - Kohan: Immortal Sovereign (Orignial & Special award edition) - Kohan: Ahriman's Gift
These ports work by being sold with a custom modified version of winex suitable for that game to get maximum performance for it.
While these are not native (ie, use Linux libraries over wine reimplementations) it seems a reasonable alternative to to costly sytem ports until the Linux market can be proven. Hopefully avoiding yet another Loki-like embassment for the community.
OK, so maybe using mouse movements as a digital signature isn't likely to be much more than an option extra layer of security over the web.
But what about active security of terminals?
If the software could be adapted to analyse the common use of a mouse (or lack there of, I like my keyboard shortcuts too) when using a display then I might be possible to continually verify the person using the display. A failed authentication could result in a screen lock (xlock) an automated log out, account deactivation etc.
Would help stop people joyriding on your screen when you forget to lock it.
Zero defect development is tough to introduce to a development environment because it is so different from what we accept as development.
I'm going to make distinctions here between Z, a formal specification, and 'zero defect' development which I believe the author is referring to 'clean room development'
Using a formal specification, like Z, a specification can be written for a programming that can be proven to be correct. It's difficult to define 'correct' but essentially the program can be shown not to have any errors of design. With a form specification, the specification of requirments is the design.
Following this, formal methods can be iterativley applied to the specification to gradually develop the desired code. At each stage proofs can be offered to show that the code written conforms to the prevous specification + code.
When this is done in a clean room environment. The produced code is transfered to a second team who does all the testing. Any fault that is found is considered a fualt of the PROCESS. The code is THROWN AWAY and new code developed from the specification.
A recent use of this technique on a large commercial package resulted in just 173 faults being found. ONLY 3 of these were found after release.
The biggest problems with these techniques are:
1- Formal specifications are too hard for clients to understand
2- Formal techniques are difficult to learn and use with LOTS of training
3- Throwing away instead of fixing is difficult to comprehend
4- Not all things being developed can be expressed with formal languages. Client Server architectures are very difficult. Especially if they are asynchronous.
No, SMS spam is not a huge problem downunder at the moment. But just from asking around it appears that SMS spam is on the rise on Australian modile networks.
Slashdot Mirror
They've already stated, to a qualified degree. Check out.
http://www.transgaming.com/webstore.php
So far they
- Marble Blast
- The Sims
- Kohan: Immortal Sovereign (Orignial & Special award edition)
- Kohan: Ahriman's Gift
These ports work by being sold with a custom modified version of winex suitable for that game to get maximum performance for it.
While these are not native (ie, use Linux libraries over wine reimplementations) it seems a reasonable alternative to to costly sytem ports until the Linux market can be proven. Hopefully avoiding yet another Loki-like embassment for the community.
OK, so maybe using mouse movements as a digital signature isn't likely to be much more than an option extra layer of security over the web.
But what about active security of terminals?
If the software could be adapted to analyse the common use of a mouse (or lack there of, I like my keyboard shortcuts too) when using a display then I might be possible to continually verify the person using the display. A failed authentication could result in a screen lock (xlock) an automated log out, account deactivation etc.
Would help stop people joyriding on your screen when you forget to lock it.
Zero defect development is tough to introduce to a development environment because it is so different from what we accept as development. I'm going to make distinctions here between Z, a formal specification, and 'zero defect' development which I believe the author is referring to 'clean room development' Using a formal specification, like Z, a specification can be written for a programming that can be proven to be correct. It's difficult to define 'correct' but essentially the program can be shown not to have any errors of design. With a form specification, the specification of requirments is the design. Following this, formal methods can be iterativley applied to the specification to gradually develop the desired code. At each stage proofs can be offered to show that the code written conforms to the prevous specification + code. When this is done in a clean room environment. The produced code is transfered to a second team who does all the testing. Any fault that is found is considered a fualt of the PROCESS. The code is THROWN AWAY and new code developed from the specification. A recent use of this technique on a large commercial package resulted in just 173 faults being found. ONLY 3 of these were found after release. The biggest problems with these techniques are: 1- Formal specifications are too hard for clients to understand 2- Formal techniques are difficult to learn and use with LOTS of training 3- Throwing away instead of fixing is difficult to comprehend 4- Not all things being developed can be expressed with formal languages. Client Server architectures are very difficult. Especially if they are asynchronous.
No, SMS spam is not a huge problem downunder at the moment. But just from asking around it appears that SMS spam is on the rise on Australian modile networks.
Try looking into some of the techniques used in Feature Driven Development.
http://www.nebulon.com/fdd/index.html
Part of the impetise for creating this methodology was to produce a project structure that naturally builds (and rebuilds) a competent team.