BMWs haven't been reliable for a few years. The quality has been degrading rapidly since the mid 90s. Too bad. And in this case I don't see how it's WinCE which is at fault - it's not like the system is constantly crashing and needing to be rebooted, you're seeing a plethora of application bugs, i.e., BMW's shoddy coding.
Well, as long as the engines aren't randomly dropping out of the cars, they're still up on Alpha Romeo, though.
Personally I'd never drive a car where the computer has any control over critical systems.
All critical systems in modern cars are under computer control. It's such systems that give you safety features like advanced traction control, and modern antilock brake systems.
Over the next ten to fifteen years expect cars to become completely electronic, replacing almost all the moving parts. (There is, of course, a bare minimum:)
A well designed computer system is much more reliable than a human.
Perhaps you're right in a general sense, but compare this to a properly trained human and don't think you'd be correct anymore. Ignoring the vacuous case where a human is physically incapable of reacting fast enough, current computer systems just aren't able to react as well to unexpected circumstances which will arise in any real system, since the real world isn't perfect like the ideal models we want it to be.
Soon you won't be able to buy a vehicle without this stuff. And __nobody__ is doing a good job of making it.
The fundamental problem is current software methodologies suck. Almost nobody is doing a good job of making any complex software system.
I don't care if it's based on Windows, or Linux or your favourite OS of the month. None of it is good enough, and if we as software developers aren't willing to embrace fundamental change in the way software is developed, it'll never be good enough.
There's a certain amount of overhead with HyperThreading, and some additional concurrency issues. Consequently, you can see some marginal (1-3%) slowdowns in some applications.
In poorly behaved systems (such as the Linux ext2fs implementation), stupid locking can result in significant performance hits. This is primarily a result of one thread waiting on a result of another thread which is scheduled on the same physical CPU via a spin-lock. A spin-lock is really simple, it simply spins in a loop checking whether a condition is met or not. With normal SMP, this isn't too much of a problem because sitting in a spin-lock doesn't slow down the other chip, but with virtual processors a spin lock takes resources away from the other threads that are running. Tada, massive slowdown.
But, this kind of situation is a result of bad design, and even then is unlikely to occur outside of critical operating system code. Most applications these days will experience a large performance improvement from hyperthreading.
Despite how some anti-Intel people are trying to spin it, HyperThreading is for the most part a good thing. If nothing else it improves system response - even if one process is spinning, you don't have to constantly wait until the kernel preempts it before processing new user events, etc...
And your statement that SMP can't slow anything down would be correct in a world without concurrency issues. Process synchronisation incurs overhead, and in a poorly designed application this overhead can be not insignificant when run on a SMP machine. If the application does most of its work in a single thread, this overhead could actually result in slowdown. But fortunately you don't see software this badly written very often.
Linux may be reliable enough to run a decent internet server, or an embedded device on, but there's no way in hell I'd let this thing operate on my head.
This is a perfect example of the wrong tool being used for the wrong job. I'm going to assume that in surgical devices, high reliability is a Good Thing(TM), and I think that's a safe assumption. Linux is a best effort UNIX clone, Linux is not a high reliability or real time operating system.
Who wants to have the drill stuck in your head because the robot has a kernel panic, or even worse the drill bit just keeps on going through the skull and into your brain since the operating system thinks that doing some disk swapping is more important than letting the drill software run.
If they're angry that Microsoft is selling WMA9 for 50% less than MPEG-4, imagine how pissed they'd be with a fully Free software solution, selling for 100% less than MPEG-4.
which explains both sides of the story
It might explain both sides of the story, but it does it with a heavy bias against TCPA/Palladium. Your suggestion that this is a balanced presentation is somewhat disingenious.
I gave it time, and sure enough we have several better-than-IE browsers (Mozilla, Konqueror, Opera, etc).
But of those three, Mozilla and Opera were both developed by commercial companies (Netscape/AOL and Opera Software respectively). Only Konqueror is a truly free software web-browser, and as a regular Konqueror user (it's what I'm typing it in now), I can't say in good faith it's better than IE. In my experience it's slower, less robust (not just buggier, it handles unexpected circumstances poorly), poor handling of DHTML, etc... And yes, I use Konqueror 3. I use Konqueror most of the time since I dislike a few things about Mozilla, but I still have to fire up Mozilla regularly to browse certain sites; not having Mozilla or Opera (developed by commercial companies) would make webbrowsing in Linux painful.
And what's the situation with media playing in Linux? Well, it's all free software except for Real Player... who aren't releasing new versions of their software after the Linux port of RealOne was canned. Sure, the free software versions are 'good enough' 'most of the time', but they still lack the elegance/simplicity of use, robustness and general refinement that the commercial players in Windows provide.
mplayer has poor video/audio synchronisation during DVD playback. Ogle and Xine are clunky and difficult to use. All three can be painful to configure if you want to use their guis and not poke by hand through the config files.
They're fine for the current typical Linux user and they get the job done, but for anybody who is looking for more mainstream adoption, all applications, including media players, need that extra refinement that tends to come with commercial applications.
That's not exactly true...
on
E ~ mc^2
·
· Score: 4, Informative
It's not exactly true that we have no clue what string theory's predictions are.
On one hand, the formulations of string theory are Very Hard (TM). I'm sure you think youv'e seen hard math, but there's hard math and there's string theory math. Classic standard model quantum mechanics and general relativity is hard math, nice hard partial differential equations to solve. String theory math makes this look easy though. It's so hard that nobody has yet even formulated the exact equations - everybody's working with approximations. So the predictions that people are making with string theory may not be completely accurate, as they aren't working from the real threory, just an approximation of it. Nice, eh?
On the other hand, most of the quantitative predictions that string theory does generate are mindboggling hard to test anyway, since in almost all respects string theory agrees with classic quantum mechanics (there's an oxymoron...) until you get to some pretty insane energies (think plank energy).
Fortunately, recently a few physicists have come up with some more subtle qualitative predictions that should prove feasible to test (for example, string theory predicts that cosmic microwave background radiation should be pixelated - the big bang didn't do antialiasing:).
Abortion is either a factor or a nonfactor in breast cancer. There have been studies validating both sides, but Bill Clinton will have the NCI say there is no effect, and GWB will have it say there is a clear causal connection.
Since when did paralytic fear of coming to conclusions based on the evidence become part of the scientific process? Apparently when GWB got elected...
The biggest, the best and the most generally trusted studies of the issue have shown that there is no causal connection. Science is full of disagreement, but good science is looking at the evidence and coming to a conclusion based solely on the facts, not the political agendas. In this circumstance, despite the existance of some evidence to the contrary, the facts primarily support the no causal connection side of the argument.
To overlook the fact that a significant majority of the evidence is in favour of the no causal connection side, and suggest that because there is some disagreement the evidence is inconclusive isn't science. It's a weak attempt to pass off a highly political agenda as scientific fact, and censor information that the administration doesn't want revealed.
The fact that X is network transparent isn't a valid counterargument to the statement that X-Windows served its term, but isn't getting any better and so should be replaced.
X-Windows doesn't have a monopoly on network transparent UIs. Fresco, one project working on a high-quality UI, is also network transparent.
Chances are you've never seen a JITting JRE. Chances are you've only ever seen the Sun reference implementations, which are slow and bloated.
With C#/.NET, the entire bytecode is designed to be JIT compiled - you're not really even supposed to interpret it at all. In my experience, a typical.NET program runs at almost the same speed of a native program (almost being a 1 or 2% difference). They do, however, use twice the memory.
it takes 4 minutes for light from our closest neighboring star to reach earth, traveling at, well, the speed of light. In all probability, this CHIPS will be using radio frequencies which are much, much slower
You know, I could almost believe your comment about the Enrico Fermi institute, until I read this. I guess nobody's ever told you about 299,792,458m/s.
The whole 'something you are' rule is really dangerous. Almost every application I've seen of biometrics gets it wrong, and then there's the question of whether or not it's even practical at all.
The fundamental problem with biometrics is that you can't change your keys. You have a set of fingerprints, retinal patterns, DNA sequences that are really pretty damn hard to change.
Biometrics can only work with strong physical security to ensure that the tests aren't being compromised (i.e., someone hacking the device).
To steal your password I have to look over your shoulder, and once done you can change it. To steal your authentication token, I have to pick your pockets, and once done you can get a new one. But I can pull your fingerprints from anything you touch, and you'll have a much, much harder time changing those.
Biometrics are often portrayed as the panacea for authentication, but of the three 'seomthing you X', it's really the weakest. Haven't we learned yet that there's no such thing as a silver bullet?
The thing is, these are radio devices. Radio is analog, not digital, and one of the amusing things about analog is it's actually much easier to authenticate.
A possible solution is to generate a second low powered signal from the laptop; this signal would be generated from nothing more than some strongly encrypted hash, and most certainly be an AM signal. The nice thing about strong encryption is that it should be pretty much indistinguishable from random noise, so the
this signal would be indistinguishable from background noise.
Then you have the frequency the signal is broadcasted on randomly shuffled based on the current time. The laptop and the token are time-synced (not a problem, most decent cryptographic tokens are time-synced anyway), so the token is always listening on the correct frequency.
At this point you have the correct waveform, although its amplitude will depend on your distance from the device. Every tenth of a second, or something, normalise the signal based on the RMS power, then compare the input signal based on what you compute it should be (you know the secret, so you can also compute the hash).
To fool this system you have to replicate the exact signal as it bounces around frequencies. Since it's bouncing around frequencies you can't just repeat the signal you're recieving on a specific frequency, since that won't matter. Further, for each part of the signal you repeat, you'll be off in intensity by a certain amount based on the frequency you're tuning into relative to the frequency its actually being transmitted at, and unless you can exactly predict the pattern you your error will vary. You can't track the frequency since you'd need to break the encryption. Really, this is nothing more than frequency scrambling that's been used by the military to secure communication for years, used in a slightly different way.
I'm sure there are other ways to solve the problem. So yes, it could be a problem if it wasn't taken into consideration, but it is a solvable problem.
The point is to automate the whole 'active screensaver' and 'type in password' bit by using a physical token that communicates with the laptop wirelessly so it seemlessly does that without you having to do anything. More importantly, you're a lot less likely to take your watch off and leave it next to the laptop than forget to lock the screen (but I was only gone for a minute!).
Really, this is nothing new. People have been using physical tokens for authentication for years (although usually for the added security value). In this case the token is being used to increase convenience, not security direclty (although the end goal being to improve security indirectly), which is what makes it different.
Of course, if you are the kind of person who'd leave your watch next to your laptop when you go to the bathroom, I'd recommend against using this.;)
Slashdot Mirror
Well, as long as the engines aren't randomly dropping out of the cars, they're still up on Alpha Romeo, though.
All critical systems in modern cars are under computer control. It's such systems that give you safety features like advanced traction control, and modern antilock brake systems.
Over the next ten to fifteen years expect cars to become completely electronic, replacing almost all the moving parts. (There is, of course, a bare minimum:)
Perhaps you're right in a general sense, but compare this to a properly trained human and don't think you'd be correct anymore. Ignoring the vacuous case where a human is physically incapable of reacting fast enough, current computer systems just aren't able to react as well to unexpected circumstances which will arise in any real system, since the real world isn't perfect like the ideal models we want it to be.
The fundamental problem is current software methodologies suck. Almost nobody is doing a good job of making any complex software system.
I don't care if it's based on Windows, or Linux or your favourite OS of the month. None of it is good enough, and if we as software developers aren't willing to embrace fundamental change in the way software is developed, it'll never be good enough.
There's a certain amount of overhead with HyperThreading, and some additional concurrency issues. Consequently, you can see some marginal (1-3%) slowdowns in some applications.
In poorly behaved systems (such as the Linux ext2fs implementation), stupid locking can result in significant performance hits. This is primarily a result of one thread waiting on a result of another thread which is scheduled on the same physical CPU via a spin-lock. A spin-lock is really simple, it simply spins in a loop checking whether a condition is met or not. With normal SMP, this isn't too much of a problem because sitting in a spin-lock doesn't slow down the other chip, but with virtual processors a spin lock takes resources away from the other threads that are running. Tada, massive slowdown.
But, this kind of situation is a result of bad design, and even then is unlikely to occur outside of critical operating system code. Most applications these days will experience a large performance improvement from hyperthreading.
Despite how some anti-Intel people are trying to spin it, HyperThreading is for the most part a good thing. If nothing else it improves system response - even if one process is spinning, you don't have to constantly wait until the kernel preempts it before processing new user events, etc...
And your statement that SMP can't slow anything down would be correct in a world without concurrency issues. Process synchronisation incurs overhead, and in a poorly designed application this overhead can be not insignificant when run on a SMP machine. If the application does most of its work in a single thread, this overhead could actually result in slowdown. But fortunately you don't see software this badly written very often.
This is a perfect example of the wrong tool being used for the wrong job. I'm going to assume that in surgical devices, high reliability is a Good Thing(TM), and I think that's a safe assumption. Linux is a best effort UNIX clone, Linux is not a high reliability or real time operating system.
Who wants to have the drill stuck in your head because the robot has a kernel panic, or even worse the drill bit just keeps on going through the skull and into your brain since the operating system thinks that doing some disk swapping is more important than letting the drill software run.
Uh, no. x - (100% * x) = 0.
Mencoder is not a codec. It uses other codecs.
If they're angry that Microsoft is selling WMA9 for 50% less than MPEG-4, imagine how pissed they'd be with a fully Free software solution, selling for 100% less than MPEG-4.
which explains both sides of the story It might explain both sides of the story, but it does it with a heavy bias against TCPA/Palladium. Your suggestion that this is a balanced presentation is somewhat disingenious.
But of those three, Mozilla and Opera were both developed by commercial companies (Netscape/AOL and Opera Software respectively). Only Konqueror is a truly free software web-browser, and as a regular Konqueror user (it's what I'm typing it in now), I can't say in good faith it's better than IE. In my experience it's slower, less robust (not just buggier, it handles unexpected circumstances poorly), poor handling of DHTML, etc... And yes, I use Konqueror 3. I use Konqueror most of the time since I dislike a few things about Mozilla, but I still have to fire up Mozilla regularly to browse certain sites; not having Mozilla or Opera (developed by commercial companies) would make webbrowsing in Linux painful.
And what's the situation with media playing in Linux? Well, it's all free software except for Real Player... who aren't releasing new versions of their software after the Linux port of RealOne was canned. Sure, the free software versions are 'good enough' 'most of the time', but they still lack the elegance/simplicity of use, robustness and general refinement that the commercial players in Windows provide.
mplayer has poor video/audio synchronisation during DVD playback. Ogle and Xine are clunky and difficult to use. All three can be painful to configure if you want to use their guis and not poke by hand through the config files.
They're fine for the current typical Linux user and they get the job done, but for anybody who is looking for more mainstream adoption, all applications, including media players, need that extra refinement that tends to come with commercial applications.
On one hand, the formulations of string theory are Very Hard (TM). I'm sure you think youv'e seen hard math, but there's hard math and there's string theory math. Classic standard model quantum mechanics and general relativity is hard math, nice hard partial differential equations to solve. String theory math makes this look easy though. It's so hard that nobody has yet even formulated the exact equations - everybody's working with approximations. So the predictions that people are making with string theory may not be completely accurate, as they aren't working from the real threory, just an approximation of it. Nice, eh?
On the other hand, most of the quantitative predictions that string theory does generate are mindboggling hard to test anyway, since in almost all respects string theory agrees with classic quantum mechanics (there's an oxymoron...) until you get to some pretty insane energies (think plank energy).
Fortunately, recently a few physicists have come up with some more subtle qualitative predictions that should prove feasible to test (for example, string theory predicts that cosmic microwave background radiation should be pixelated - the big bang didn't do antialiasing:).
Abortion is either a factor or a nonfactor in breast cancer. There have been studies validating both sides, but Bill Clinton will have the NCI say there is no effect, and GWB will have it say there is a clear causal connection.
Since when did paralytic fear of coming to conclusions based on the evidence become part of the scientific process? Apparently when GWB got elected...
The biggest, the best and the most generally trusted studies of the issue have shown that there is no causal connection. Science is full of disagreement, but good science is looking at the evidence and coming to a conclusion based solely on the facts, not the political agendas. In this circumstance, despite the existance of some evidence to the contrary, the facts primarily support the no causal connection side of the argument.
To overlook the fact that a significant majority of the evidence is in favour of the no causal connection side, and suggest that because there is some disagreement the evidence is inconclusive isn't science. It's a weak attempt to pass off a highly political agenda as scientific fact, and censor information that the administration doesn't want revealed.
X-Windows doesn't have a monopoly on network transparent UIs. Fresco, one project working on a high-quality UI, is also network transparent.
You've never heard of the 2.4ghz band, have you?
XML isn't an 'open source' language. It has nothing to do with open source/free software. It's just a document metaformat based on SGML.
And RSA assumes I can't factor large numbers quickly. As far as I am aware, there's no way to rebroadcast a continuous spectrum of frequencies.
With C#/.NET, the entire bytecode is designed to be JIT compiled - you're not really even supposed to interpret it at all. In my experience, a typical .NET program runs at almost the same speed of a native program (almost being a 1 or 2% difference). They do, however, use twice the memory.
YMMV.
It is not a sufficient solution to prevent programmers making mistakes.
You know, I could almost believe your comment about the Enrico Fermi institute, until I read this. I guess nobody's ever told you about 299,792,458m/s.
It's not just a good idea, it's the law.
The fundamental problem with biometrics is that you can't change your keys. You have a set of fingerprints, retinal patterns, DNA sequences that are really pretty damn hard to change.
Biometrics can only work with strong physical security to ensure that the tests aren't being compromised (i.e., someone hacking the device).
To steal your password I have to look over your shoulder, and once done you can change it. To steal your authentication token, I have to pick your pockets, and once done you can get a new one. But I can pull your fingerprints from anything you touch, and you'll have a much, much harder time changing those.
Biometrics are often portrayed as the panacea for authentication, but of the three 'seomthing you X', it's really the weakest. Haven't we learned yet that there's no such thing as a silver bullet?
My god, who moderated this informative and not funny? He was making a joke since this is a dupe.
Yes, but if your keys are long enough it probably won't happen until sometime long after the universe dies. :P
A possible solution is to generate a second low powered signal from the laptop; this signal would be generated from nothing more than some strongly encrypted hash, and most certainly be an AM signal. The nice thing about strong encryption is that it should be pretty much indistinguishable from random noise, so the this signal would be indistinguishable from background noise.
Then you have the frequency the signal is broadcasted on randomly shuffled based on the current time. The laptop and the token are time-synced (not a problem, most decent cryptographic tokens are time-synced anyway), so the token is always listening on the correct frequency.
At this point you have the correct waveform, although its amplitude will depend on your distance from the device. Every tenth of a second, or something, normalise the signal based on the RMS power, then compare the input signal based on what you compute it should be (you know the secret, so you can also compute the hash).
To fool this system you have to replicate the exact signal as it bounces around frequencies. Since it's bouncing around frequencies you can't just repeat the signal you're recieving on a specific frequency, since that won't matter. Further, for each part of the signal you repeat, you'll be off in intensity by a certain amount based on the frequency you're tuning into relative to the frequency its actually being transmitted at, and unless you can exactly predict the pattern you your error will vary. You can't track the frequency since you'd need to break the encryption. Really, this is nothing more than frequency scrambling that's been used by the military to secure communication for years, used in a slightly different way.
I'm sure there are other ways to solve the problem. So yes, it could be a problem if it wasn't taken into consideration, but it is a solvable problem.
Really, this is nothing new. People have been using physical tokens for authentication for years (although usually for the added security value). In this case the token is being used to increase convenience, not security direclty (although the end goal being to improve security indirectly), which is what makes it different.
Of course, if you are the kind of person who'd leave your watch next to your laptop when you go to the bathroom, I'd recommend against using this. ;)