I am a full-time software engineer working in Health IT, specialising in in-hospital cross-system integration. Our business is accepting the data feeds from lab systems, radiology systems, ED information systems, and patient administration systems, and then present the results as a cohesive single health record.
Well, you'd think standards and compliance would make it easy, but that assumes when people say they meet the standard... they ACTUALLY meet the standard. Format is one thing, but ensuring correct sequence and field validation is something else entirely. Unlike HTTP and the internet, in health there are no business drivers for integration compliance.
On the contrary - large companies (like Cerner) who can offer an "all-in-one-integrated-solution" benefit from the lack of conformance. The real obstacle is not setting up trusted health vaults, that's the easy part. The difficulty is populating it with live information, from live systems, with full trust.
Of course, that's before you mention terminology. Does a haemoglobin result mean the same thing from two different lab systems? How about normal ranges? Blood glucose or urine glucose? Presenting complaint vs discharge diagnosis? I'm not trying to be overly pessimistic, but this is a much more difficult problem than simply sticking up a database somewhere.
Google is not "halting innovation", it is following the advice of Steve Jobs (remember him?) and learning focus.
Google has not pulled money from its autonomous vehicle development.
It has not reduced the spend it has allocated to significant long term investments such as Google+ (there is nothing short-term about investing in a social network, it has taken Facebook 5 years to reach its current valuation)
In fact, Google has assigned one of its two company founders specifically to fostering new innovation.
Focus means that you don't throw a pile of muck at the wall and see what sticks.
That leaves customers and users with a bad taste in their mouth: e.g. Google Buzz.
Focus means you put the entire weight of your brand and pocket book behind a single idea, and you make it stick: e.g. iPod.
Focus means having real innovation, and ensuring the market is ready to follow, like Xbox, Android, and iPhone. It takes a lot of innovation and focus to ensure you end up with iOS, not WebOS. With Facebook, not mySpace. You can't do that when you are spreading yourself too thin, and your brand name takes a beating as a result.
Google's reputation and brand has not gained a single benefit from their investment in health. Why would they continue to do so?
Humans like to learn, and our favourite way of learning is by experimenting. We do it when we are little and put toys in our mouth, and we do it as grown ups when we put strange food in our mouth.
It's natural that we would like to learn about different social experiences to our own. Playing or watching a character different to us gives a new perspective on our own life. The more extreme the character, the more we stand to learn. This is the reason people like soaps on TV, and its also the reason we like playing as a sneaky assassin in the renaissance.
Morality (whether actions are good or bad) is without question, a matter of perspective. We need broad experience and a wide understanding of the how the world operates in order to have a healthy moral compass. I know it is a stretch, but sometimes playing the bad guy helps us learn what defines the good guys.
1) Will the kids want to play computer games? Of course, they are kids, what else are computers for at that age? That means XP.
2) Who will help them with the computer? Answer: other kids, parents and teachers. I bet your bottom dollar kids will get much better teaching from others with XP compared to Ubuntu, purely because of the install base and general familiarity.
3) Is the 2 year limit on XP relevant? Of course not, in 2 years as an XP machine it'll be due for a re-install anyway (if not before).
With half a minute of google searching, I found half a dozen references to experiments already using Electromyography to drive computer behaviour.
I remembered that most of the new work on prosthetic arms these days focuses on using EMG to drive the arm behaviour (including Dean Kamen's new bionic arm), and there's a bunch of stuff done (and papers released) with driving the mouse for people with disabilities.
Surely this patent application has to be thrown out, and isn't Microsoft just wasting the Patent Office (and our) time with applications that are so easily shown to have been demonstrated before?
What's the original part here? The patent application does not specify any specific software application (just talks about interpreting the signals), so all the prior art should hold.
I wish I could do this with my coworkers' cell phones, omg so tired of a coworker getting continuous calls from relatives/friends while we're trying to get something done, HERE is the real problem! This is the most true thing I've ever read on slashdot. Its worse for me... All my coworkers in my room don't speak English at home, so instead of being able to ignore it as background noise, I have this incredibly distracting drone of Indian or Indonesian - more distracting because your subconscious keeps trying to make out the words even though its impossible.
has not been invented. Not only does IM constantly interrupt your train of thought and derail productive activity, but it also sucks down minutes and minutes when a 15 second phone conversation would do. I find that a totally ridiculous suggestion. I'm a reasonably senior software developer with a team of 12 people working in 4 dev offices next to each other. Every case of IM is very much a "hey, whats the answer to this". I answer it quickly if I can (or ignore it till I finish my current line of progress), then if its easily answerable I answer it with a short reply.
If its not, I get up and walk to their desk in my own time and spend the 15-20 minutes required to get them back on track.
The alternative would be every developer visiting me at my desk any time they needed an answer/input from me (which is frequently). The increase in disruption would be SIGNIFICANT. If its going to require 15-20 minutes to sort out, I much prefer being able to tell them immediately, "busy right now, I'll see you soon" than having to stop what I am doing and addressing them standing next to me.
We also all have desk phones, but personally I find a ring INCREDIBLY distracting compared to a small little flashing taskbar icon. One you can ignore, the other you can not.
The problem with your logic is it totally ignores risk, reward, and performance.
If you make a piece of rubbish "game" (like daikatana) according to you the team should make about the same amount of money as a group who make the truly transcendent Bioshock.
And this isn't about the programmers anyway, its about the companies who finance them. A company can spend 20 million dollars to buy a bunch of programmers from India to make them a game according to a piece of paper you wrote. And another group can spend 100-200 million dollars to hire a team of experienced managers and coders and content developers to work together and make something worth actually buying.
The risk of course, is that you wont make your money back and so make a loss.
This is not a simple "make a house according to a plan". Thats totally naive. Any code monkey can make boilerplate code. This is about investing money and time and resources to create a product that sells a number of units to make the money back. All games are not equal, and do not cost the same to make.
And finally, lets not even get into the differences between software and physical devices. Both take the same amount of time to create, but one needs to be sold per unit, while the other can be reused without limit. If we reach a point where that difference becomes the defining feature, nobody will bother making software -> they'll just start selling hardware that incidentally happens to play a single game. Look up dongles on wikipedia if you want to know what that future looks like.
GPU's don't need to go multicore, they are already parallel processors. Thats what "16-pixel-pipelines" means. Its the equivalent of that many cores.
The rest of your post is pretty cool though. Reintroducing mainframe/thin-clients for the home. Hardly revolutionary, but here its all rendered and processed centrally rather than on the thin clients.
Hell, i don't need a modified executable to cheat! Nothing stops me changing my memory live while the game is running!
Whats that, i just bumped my local ammo/cash/lumber/HP counter back to full? that was easy!
While i agree that its a much more difficult way to cheat than just making a executable mod and building in an auto-aiming bot, the simple fact is that it doesn't matter WHAT you do to lock down a client, at the end its just a flawed approach in the first place. The only place you have any real chance of having this system work is a proprietary console running proprietary software -> and mod chips get around that anyway.
The only way to properly protect an online game is to validate inputs (are the actions they are telling the server valid according to the game rules) and behaviors (is this a human action or a computer-assisted action?).
Its orders of magnitude harder to detect aim-bots at the server, anybody with any programming experience knows that. But that doesn't mean its impossible. Its not simply a case of saying "is this person "too-good", because you can't filter that out. But you can cross-check the movement instructions with the mouse velocities and build a signed key from the pair, and on the server validate that the aiming instructions correspond with the hardware signals, rather than just coming from a software command. There are other methods in this vein, like introducing noise into the inputs sent to clients and detecting if the return signals have accurately returned the noise (if i oscillate the player 5 pixels to the left and right, does the shoot-aim return signal accurately follow the oscillations? bot!)
Couple this with some basic run-time application hashing (hash the contents of memory and the executable 2 minutes in, once the game has started, and test against THAT signature) rather than just the up-front vendor keys, and you have a much more hardened and reliable system.
You don't even have to do these tests all the time, but if they exist in your system you have ways of validating client behaviour regardless of whether you trust the client.
What my small company has been busy with the last years, is to move a lot of logic and data outside such systems. Because it's just to expensive to try and "upgrade" these huge behemoths. We develop external databases to store different data feeds, most likely received in XML-format which some of these systems is not capable of using. Actually, one of those systems are only capable of importing/exporting data with fixed length ASCII-files.
I can attest to this. I'm a software developer for a small company working at developing value-add products in health-IT, and the big systems we piggy-back on for our data feeds are some of the scariest most atrocious beasts you will ever work with. Most are based off 10 year old code that has been built as one hacked-in-patch after another, and seem to work in-spite of themselves rather than because of it. Off-the-shelf solutions in large enterprise seem a very long way from being low-maintenance commodity items.
Slashdot Mirror
I am a full-time software engineer working in Health IT, specialising in in-hospital cross-system integration. Our business is accepting the data feeds from lab systems, radiology systems, ED information systems, and patient administration systems, and then present the results as a cohesive single health record.
Well, you'd think standards and compliance would make it easy, but that assumes when people say they meet the standard... they ACTUALLY meet the standard. Format is one thing, but ensuring correct sequence and field validation is something else entirely. Unlike HTTP and the internet, in health there are no business drivers for integration compliance.
On the contrary - large companies (like Cerner) who can offer an "all-in-one-integrated-solution" benefit from the lack of conformance. The real obstacle is not setting up trusted health vaults, that's the easy part. The difficulty is populating it with live information, from live systems, with full trust.
Of course, that's before you mention terminology. Does a haemoglobin result mean the same thing from two different lab systems? How about normal ranges? Blood glucose or urine glucose? Presenting complaint vs discharge diagnosis? I'm not trying to be overly pessimistic, but this is a much more difficult problem than simply sticking up a database somewhere.
You are incorrect.
Google is not "halting innovation", it is following the advice of Steve Jobs (remember him?) and learning focus.
Google has not pulled money from its autonomous vehicle development.
It has not reduced the spend it has allocated to significant long term investments such as Google+ (there is nothing short-term about investing in a social network, it has taken Facebook 5 years to reach its current valuation)
In fact, Google has assigned one of its two company founders specifically to fostering new innovation.
Focus means that you don't throw a pile of muck at the wall and see what sticks. That leaves customers and users with a bad taste in their mouth: e.g. Google Buzz.
Focus means you put the entire weight of your brand and pocket book behind a single idea, and you make it stick: e.g. iPod.
Focus means having real innovation, and ensuring the market is ready to follow, like Xbox, Android, and iPhone. It takes a lot of innovation and focus to ensure you end up with iOS, not WebOS. With Facebook, not mySpace. You can't do that when you are spreading yourself too thin, and your brand name takes a beating as a result.
Google's reputation and brand has not gained a single benefit from their investment in health. Why would they continue to do so?
Humans like to learn, and our favourite way of learning is by experimenting. We do it when we are little and put toys in our mouth, and we do it as grown ups when we put strange food in our mouth.
It's natural that we would like to learn about different social experiences to our own. Playing or watching a character different to us gives a new perspective on our own life. The more extreme the character, the more we stand to learn. This is the reason people like soaps on TV, and its also the reason we like playing as a sneaky assassin in the renaissance.
Morality (whether actions are good or bad) is without question, a matter of perspective. We need broad experience and a wide understanding of the how the world operates in order to have a healthy moral compass. I know it is a stretch, but sometimes playing the bad guy helps us learn what defines the good guys.
Ask yourself 3 questions:
1) Will the kids want to play computer games? Of course, they are kids, what else are computers for at that age? That means XP.
2) Who will help them with the computer? Answer: other kids, parents and teachers. I bet your bottom dollar kids will get much better teaching from others with XP compared to Ubuntu, purely because of the install base and general familiarity.
3) Is the 2 year limit on XP relevant? Of course not, in 2 years as an XP machine it'll be due for a re-install anyway (if not before).
I remembered that most of the new work on prosthetic arms these days focuses on using EMG to drive the arm behaviour (including Dean Kamen's new bionic arm), and there's a bunch of stuff done (and papers released) with driving the mouse for people with disabilities.
Surely this patent application has to be thrown out, and isn't Microsoft just wasting the Patent Office (and our) time with applications that are so easily shown to have been demonstrated before?
Look Ma, No Pen! Electrical Impulses Can Reproduce Handwriting
SmartHand: Merging Mind and Machine
Application of facial electromyography in computer mouse access for people with disabilities
Demonstrating the feasibility of using forearm electromyography for muscle-computer interfaces
Electromyography sensor based control for a hand exoskeleton
What's the original part here? The patent application does not specify any specific software application (just talks about interpreting the signals), so all the prior art should hold.
If its not, I get up and walk to their desk in my own time and spend the 15-20 minutes required to get them back on track.
The alternative would be every developer visiting me at my desk any time they needed an answer/input from me (which is frequently). The increase in disruption would be SIGNIFICANT. If its going to require 15-20 minutes to sort out, I much prefer being able to tell them immediately, "busy right now, I'll see you soon" than having to stop what I am doing and addressing them standing next to me.
We also all have desk phones, but personally I find a ring INCREDIBLY distracting compared to a small little flashing taskbar icon. One you can ignore, the other you can not.
The problem with your logic is it totally ignores risk, reward, and performance. If you make a piece of rubbish "game" (like daikatana) according to you the team should make about the same amount of money as a group who make the truly transcendent Bioshock. And this isn't about the programmers anyway, its about the companies who finance them. A company can spend 20 million dollars to buy a bunch of programmers from India to make them a game according to a piece of paper you wrote. And another group can spend 100-200 million dollars to hire a team of experienced managers and coders and content developers to work together and make something worth actually buying. The risk of course, is that you wont make your money back and so make a loss. This is not a simple "make a house according to a plan". Thats totally naive. Any code monkey can make boilerplate code. This is about investing money and time and resources to create a product that sells a number of units to make the money back. All games are not equal, and do not cost the same to make. And finally, lets not even get into the differences between software and physical devices. Both take the same amount of time to create, but one needs to be sold per unit, while the other can be reused without limit. If we reach a point where that difference becomes the defining feature, nobody will bother making software -> they'll just start selling hardware that incidentally happens to play a single game. Look up dongles on wikipedia if you want to know what that future looks like.
GPU's don't need to go multicore, they are already parallel processors. Thats what "16-pixel-pipelines" means. Its the equivalent of that many cores. The rest of your post is pretty cool though. Reintroducing mainframe/thin-clients for the home. Hardly revolutionary, but here its all rendered and processed centrally rather than on the thin clients.
Hell, i don't need a modified executable to cheat! Nothing stops me changing my memory live while the game is running!
Whats that, i just bumped my local ammo/cash/lumber/HP counter back to full? that was easy!
While i agree that its a much more difficult way to cheat than just making a executable mod and building in an auto-aiming bot, the simple fact is that it doesn't matter WHAT you do to lock down a client, at the end its just a flawed approach in the first place. The only place you have any real chance of having this system work is a proprietary console running proprietary software -> and mod chips get around that anyway.
The only way to properly protect an online game is to validate inputs (are the actions they are telling the server valid according to the game rules) and behaviors (is this a human action or a computer-assisted action?).
Its orders of magnitude harder to detect aim-bots at the server, anybody with any programming experience knows that. But that doesn't mean its impossible. Its not simply a case of saying "is this person "too-good", because you can't filter that out. But you can cross-check the movement instructions with the mouse velocities and build a signed key from the pair, and on the server validate that the aiming instructions correspond with the hardware signals, rather than just coming from a software command. There are other methods in this vein, like introducing noise into the inputs sent to clients and detecting if the return signals have accurately returned the noise (if i oscillate the player 5 pixels to the left and right, does the shoot-aim return signal accurately follow the oscillations? bot!)
Couple this with some basic run-time application hashing (hash the contents of memory and the executable 2 minutes in, once the game has started, and test against THAT signature) rather than just the up-front vendor keys, and you have a much more hardened and reliable system.
You don't even have to do these tests all the time, but if they exist in your system you have ways of validating client behaviour regardless of whether you trust the client.
You actually believe that eyewitness testimony is reliable??? http://atheism.about.com/od/parapsychology/a/eyewi tness.htm