If the Ford Sync system is any indication, Microsoft seems to be able to pull off something like this quite well.
You're kidding right? I have the Ford Sync system from Microsoft in my new F150. And you do, literally, have to reboot the truck sometimes to get the USB interface to sync up. I mean come to a stop, turn off the ignition, wait for a few seconds and then turn it back on and pray to the sync-gods that it works this time so you can finally be on your way.
they could even make it so that if it's pulled out and facing the passenger seat instead of the driver, the screen unblanks and updates, so that a passenger can give directions.
Yeah, as long as they provide a simple work around like that that we can all use to hack/defeat the original implementation, then I'm all for the law. But anything that's going to blank the very screen I would find most useful on me when I most need it would be utterly retarded.
It is very confusing to have to rotate the map in your head even when you are walking, not to mention the effort for doing it real-time while you are driving a vehicle.
No it's not. It's completely disorienting to me when someone rotates a map around like that (i.e., my wife). She says it helps her keep left/right straight in her head. But for me, I'd rather have the map be a fixed reference and I'll just swap left/right in my head.
We argue about who's right and who's wrong and what each preference suggests about the person's spatial brain, but the point is...neither solution works well for everyone. I think forcing GPS displays down any single path is going to be fine for about half the population and make it totally disorienting for the other. I don't see this dramatically reducing accidents in any way.
I think he was saying that the act of holding the cellphone to one's ear was illegal in the jurisdiction in which he currently resides. Not that the person is violating federal immigration law by being in the country, dumbass.
FTFY
Re:Uhhhh...can you say tariff drop too?
on
Is E85 Dead Now?
·
· Score: 1
Someone mod the parent up... Despite the stupid initial question, there's some excellent info there.
Wow. I honestly never thought I'd see the day. I've been reading since forever as well and CmdTaco has ALWAYS been there. It's going to be different, no doubt about it. But it's always going to be "News for Nerds, Stuff that Matters".
(Or as my wife jokes, "News for Nerds, Stuff that Matters to People that don't")
It's been well established that the ECUs in the '90-'94 turbo Eclipses and Talons (DSMs) were made with substandard capacitors which would leak after several years causing the exact problems outlined here. Traces on the board would be destroyed and teh things would be left useless.
The difference? Mitsubish *never* acknowledged the problem. They just fixed it under the covers in '95 and never told anyone about it. Nice, huh?
I was going to e-mail you directly, but I can't seem to get at your e-mail address anywhere.
Anyway, I've been a member of that digest for 8 years now, not that it's actually been working in the last year or two.:-( And I already have a completely tunable ECU.
http://www.dsmlink.com
FWIW, I too spent a good many months with head bowed to crankwalk. I hope your story goes better than mine. 3 engine rebuilds later and they finally realized the problem was actually a faulty clutch master cylinder. Grrrr.
The article talks about Hondata which works on Hondas. An example of almost the exact same thing in the Mitsubishi world can be found here:
http://www.dsmlink.com
That software was derived entirely by brute force decryption of the '95 Mitsu Eclipse turbo ECU code. We actually wrote the thing before we knew anything about Hondata. Once it was released and I started looking around a bit more, I realized the Hondata guys had done something almost identical with the Hondas.
Interesting to point out that when my partner and I started decoding the ECU in the '95 Mitsubishi Eclipse, the OBDII section was particularly useful to us. It gave us right there in the code all the conversion factors necessary to get the internal ECU variables converted to human readable form.
> Mind you, it's far more effective to use an aftermarket ECU.
That's debateable. How's it going DG?;-)
Check out http://www.dsmlink.com. That software and ECU work was done exclusively by my partner and me. As the NYTimes article states, it takes thousands of hours to decode the ECU programming. But man, what a bunch of fun it was. I remember taking the source code with me on vacation to the Bahamas because I was into it so much at the time.
It's a true hacker's delite to dig into raw machine code and reverse engineer the concepts that went into its writing. To be able to apply that then to make your CAR faster is pure icing on the cake. Some folks may just want to buy an aftermarket ECU and slap it on, but others truly enjoy the challenge and rewards of digging into the ECU themselvse. That's the type of person this article is describing.
Seriously. Most folks on here think Java sucks, but that's typically because they haven't actually *used* it. I think perl sucks, simply because I haven't used it and don't know it well enough to be efficient at it. That's all too common. But take a closer look at Java... It's cross platform, multithreaded, scaleable ('cept that pesky GC thing, which can be handled reasonably enough with intelligent coding), and does all the stuff you're looking to do.
I used to code exclusively in assembly, then C, then C++, and now Java. Trust me, Java is a stable alternative that will solve MANY of these cross platform issues for you, if not all.
As an example, I have written a datalogger for my car. I coded everything under Linux using vi. It's a Swing based app that's multithreaded and uses the serial port to communicate with the car's computer. I never gave a second thought to cross platform support. I just coded to the Java APIs.
One day, a friend of mine wanted to run the thing on his laptop...which had Windows 98 on it. Sure enough, I put the files onto his laptop and it ran perfectly. This was not modified in any way and didn't even get recompiled! I just put the jar files from my Linux box onto this Windows laptop and away it went. I told him this "should" work, and sure enough, it did.
As for scaleability, I have also helped design a VERY large scale middleware Java RMI server architecture for a VERY large shipping company (it's a public company...you know them...I'm positive you've used them). This handles all user-based load from their VERY large website. We're talking millions of transactions a day here, not thousands. With proper attention to garbage collection, multithreading, and a distributed architecture, this system runs without flaw, 24/7.
So Java works in real world examples, it really does. Plus, it promotes code reuse so well, that I can't imagine suggesting any other solution for your problem.
The article says Zimmerman struggled with how to respond to that one hate e-mail for an entire day... Hell, I read just a few sentences of it and immediately knew how to respond.
The only way to raise enough interest from the public to get stupid laws repealed is to make people obey them. Here in MD we have TONS of 6 lane divided highways that are posted 55mph. That's ridiculous. *Nobody* drives below 70-75 on these things. It's just another way the cops have to pull you over anytime they feel like it. Posted limits are for the most part far below the real limits of the road and modern vehicles. But nobody complains because nobody is really being forced to drive that slow. Cops have passed me when I was doing 75 on one of these 55mph roads before without so much as a glance. For the most part, they don't do anything unless you're doing 80 or above. I just resent the fact that I have to drive what everyone on the road considers a reasonable speed in fear of getting pulled over by the random guy in blue that's having a bad day. I'd much rather the limit be bumped up to 75 and then *really* get a ticket for doing more than that. Until the laws are enforced as they're written, however, people won't complain in large enough numbers to get things changed. Maybe more stupid ideas like the one being discussed in this article will finally get people off their asses and start writing to their representatives to get things changed. And yes, before anyone asks, I have written to my representatives. But as I mentioned, unless LOTS more start doing that, nobody is going to take notice.
Because the test isn't a valid test. They didn't *just* change the CPU configuration when they ran the second test. In fact, they didn't change the configuration at all. They just increased the number of concurrent compiles. Doing this even on a single processor system would have shown an improvement simply because there's IO latency involved in compiles (and lots of it). Running more than one compile at at time allows a second or third compile to use the CPU while the first and/or second are tied up waiting for IO.
The test they ran does not indicate the benefits of dual CPU alone. It shows the benefits of dual CPUs combined with the benefits of running multiple compiles at the same time. That's why you end up with more than 100% increase.
Complete (?) list of google screen shot caches
on
The ASCII Cam
·
· Score: 1
Here's a more complete list...open these in a new browser and hit stop as soon as they come up, if possible. Some seem to have stupid auto-reload next tags in them.:-(
Dude...those weren't typos or casual mistakes. He consistently referred to himself as 'i'. Doing so once or twice I can brush off as a typo. Forgetting to capitalize the name of a month I can accept as a casual mistake. Constantly using 'i' instead of 'I', however, is just plain ignorant.
The *CEO* of TurboLinux doesn't even use proper capitalization in his written statements? Seems a little out of place to me. What's with all the lowercase references to himself? Smells a little fishy around here...
Those examples are pretty cool and I must admit, I had never heard of them when trying to solve my modem problem. However, they're still one-shot examples that solve a very specific problem (i.e., share a serial port with another machine). What I was wishing someone would address in a generic way of sharing *any* device remotely. The device driver interface is extremely simple (open, read, write, ioctl, close), so the technology needed to provide that remotely should be trivial. Loose ends would need to be tidied up (like locking devices that need to be locked and the such), but I'm *sure* it's a solveable problem. I think what this person has done is a step in the right direction towards making hardware as generic and universally accessible as anything else. But that's just my opinion.
Slashdot Mirror
If the Ford Sync system is any indication, Microsoft seems to be able to pull off something like this quite well.
You're kidding right? I have the Ford Sync system from Microsoft in my new F150. And you do, literally, have to reboot the truck sometimes to get the USB interface to sync up. I mean come to a stop, turn off the ignition, wait for a few seconds and then turn it back on and pray to the sync-gods that it works this time so you can finally be on your way.
Can we get /. to prevent the first, say 5, post replies from AC?
I like.
I cann has TLD?
Thanks! I needed the laugh this morning. That was classic.
Wow. That's bad. I mean real bad.
they could even make it so that if it's pulled out and facing the passenger seat instead of the driver, the screen unblanks and updates, so that a passenger can give directions.
Yeah, as long as they provide a simple work around like that that we can all use to hack/defeat the original implementation, then I'm all for the law. But anything that's going to blank the very screen I would find most useful on me when I most need it would be utterly retarded.
It is very confusing to have to rotate the map in your head even when you are walking, not to mention the effort for doing it real-time while you are driving a vehicle.
No it's not. It's completely disorienting to me when someone rotates a map around like that (i.e., my wife). She says it helps her keep left/right straight in her head. But for me, I'd rather have the map be a fixed reference and I'll just swap left/right in my head.
We argue about who's right and who's wrong and what each preference suggests about the person's spatial brain, but the point is...neither solution works well for everyone. I think forcing GPS displays down any single path is going to be fine for about half the population and make it totally disorienting for the other. I don't see this dramatically reducing accidents in any way.
I think he was saying that the act of holding the cellphone to one's ear was illegal in the jurisdiction in which he currently resides. Not that the person is violating federal immigration law by being in the country, dumbass.
FTFY
Someone mod the parent up... Despite the stupid initial question, there's some excellent info there.
I'll second that. Assuming she's a she.
Granted, this would probably leave only a handful of posts.
And neither yours nor mine would make the cut, of course.
Wow. I honestly never thought I'd see the day. I've been reading since forever as well and CmdTaco has ALWAYS been there. It's going to be different, no doubt about it. But it's always going to be "News for Nerds, Stuff that Matters".
(Or as my wife jokes, "News for Nerds, Stuff that Matters to People that don't")
Thomas Dorris
It's been well established that the ECUs in the '90-'94 turbo Eclipses and Talons (DSMs) were made with substandard capacitors which would leak after several years causing the exact problems outlined here. Traces on the board would be destroyed and teh things would be left useless.
The difference? Mitsubish *never* acknowledged the problem. They just fixed it under the covers in '95 and never told anyone about it. Nice, huh?
Thomas Dorris
> you can probably buy a completely tuneable ECU
:-( And I already have a completely tunable ECU.
I was going to e-mail you directly, but I can't seem to get at your e-mail address anywhere.
Anyway, I've been a member of that digest for 8 years now, not that it's actually been working in the last year or two.
http://www.dsmlink.com
FWIW, I too spent a good many months with head bowed to crankwalk. I hope your story goes better than mine. 3 engine rebuilds later and they finally realized the problem was actually a faulty clutch master cylinder. Grrrr.
Thomas Dorris
The article talks about Hondata which works on Hondas. An example of almost the exact same thing in the Mitsubishi world can be found here:
http://www.dsmlink.com
That software was derived entirely by brute force decryption of the '95 Mitsu Eclipse turbo ECU code. We actually wrote the thing before we knew anything about Hondata. Once it was released and I started looking around a bit more, I realized the Hondata guys had done something almost identical with the Hondas.
Thomas Dorris
Interesting to point out that when my partner and I started decoding the ECU in the '95 Mitsubishi Eclipse, the OBDII section was particularly useful to us. It gave us right there in the code all the conversion factors necessary to get the internal ECU variables converted to human readable form.
Thomas Dorris
> Mind you, it's far more effective to use an aftermarket ECU.
;-)
That's debateable. How's it going DG?
Check out http://www.dsmlink.com. That software and ECU work was done exclusively by my partner and me. As the NYTimes article states, it takes thousands of hours to decode the ECU programming. But man, what a bunch of fun it was. I remember taking the source code with me on vacation to the Bahamas because I was into it so much at the time.
It's a true hacker's delite to dig into raw machine code and reverse engineer the concepts that went into its writing. To be able to apply that then to make your CAR faster is pure icing on the cake. Some folks may just want to buy an aftermarket ECU and slap it on, but others truly enjoy the challenge and rewards of digging into the ECU themselvse. That's the type of person this article is describing.
Thomas Dorris
Seriously. Most folks on here think Java sucks, but that's typically because they haven't actually *used* it. I think perl sucks, simply because I haven't used it and don't know it well enough to be efficient at it. That's all too common. But take a closer look at Java... It's cross platform, multithreaded, scaleable ('cept that pesky GC thing, which can be handled reasonably enough with intelligent coding), and does all the stuff you're looking to do.
I used to code exclusively in assembly, then C, then C++, and now Java. Trust me, Java is a stable alternative that will solve MANY of these cross platform issues for you, if not all.
As an example, I have written a datalogger for my car. I coded everything under Linux using vi. It's a Swing based app that's multithreaded and uses the serial port to communicate with the car's computer. I never gave a second thought to cross platform support. I just coded to the Java APIs.
One day, a friend of mine wanted to run the thing on his laptop...which had Windows 98 on it. Sure enough, I put the files onto his laptop and it ran perfectly. This was not modified in any way and didn't even get recompiled! I just put the jar files from my Linux box onto this Windows laptop and away it went. I told him this "should" work, and sure enough, it did.
As for scaleability, I have also helped design a VERY large scale middleware Java RMI server architecture for a VERY large shipping company (it's a public company...you know them...I'm positive you've used them). This handles all user-based load from their VERY large website. We're talking millions of transactions a day here, not thousands. With proper attention to garbage collection, multithreading, and a distributed architecture, this system runs without flaw, 24/7.
So Java works in real world examples, it really does. Plus, it promotes code reuse so well, that I can't imagine suggesting any other solution for your problem.
The article says Zimmerman struggled with how to respond to that one hate e-mail for an entire day... Hell, I read just a few sentences of it and immediately knew how to respond.
F U, you short sighted moron
The only way to raise enough interest from the public to get stupid laws repealed is to make people obey them. Here in MD we have TONS of 6 lane divided highways that are posted 55mph. That's ridiculous. *Nobody* drives below 70-75 on these things. It's just another way the cops have to pull you over anytime they feel like it. Posted limits are for the most part far below the real limits of the road and modern vehicles. But nobody complains because nobody is really being forced to drive that slow. Cops have passed me when I was doing 75 on one of these 55mph roads before without so much as a glance. For the most part, they don't do anything unless you're doing 80 or above. I just resent the fact that I have to drive what everyone on the road considers a reasonable speed in fear of getting pulled over by the random guy in blue that's having a bad day. I'd much rather the limit be bumped up to 75 and then *really* get a ticket for doing more than that. Until the laws are enforced as they're written, however, people won't complain in large enough numbers to get things changed. Maybe more stupid ideas like the one being discussed in this article will finally get people off their asses and start writing to their representatives to get things changed. And yes, before anyone asks, I have written to my representatives. But as I mentioned, unless LOTS more start doing that, nobody is going to take notice.
Because the test isn't a valid test. They didn't *just* change the CPU configuration when they ran the second test. In fact, they didn't change the configuration at all. They just increased the number of concurrent compiles. Doing this even on a single processor system would have shown an improvement simply because there's IO latency involved in compiles (and lots of it). Running more than one compile at at time allows a second or third compile to use the CPU while the first and/or second are tied up waiting for IO.
The test they ran does not indicate the benefits of dual CPU alone. It shows the benefits of dual CPUs combined with the benefits of running multiple compiles at the same time. That's why you end up with more than 100% increase.
Here's a more complete list...open these in a new browser and hit stop as soon as they come up, if possible. Some seem to have stupid auto-reload next tags in them. :-(
r g/hasciicam001.html+&hl=en
r g/hasciicam002.html+&hl=en
r g/hasciicam003.html+&hl=en
r g/hasciicam004.html+&hl=en
r g/hasciicam005.html+&hl=en
r g/hasciicam006.html+&hl=en
r g/hasciicam007.html+&hl=en
r g/hasciicam008.html+&hl=en
r g/hasciicam009.html+&hl=en
r g/hasciicam010.html+&hl=en
r g/hasciicam011.html+&hl=en
r g/hasciicam012.html+&hl=en
r g/hasciicam013.html+&hl=en
http://www.google.com/search?q=cache:ascii.dyne.o
http://www.google.com/search?q=cache:ascii.dyne.o
http://www.google.com/search?q=cache:ascii.dyne.o
http://www.google.com/search?q=cache:ascii.dyne.o
http://www.google.com/search?q=cache:ascii.dyne.o
http://www.google.com/search?q=cache:ascii.dyne.o
http://www.google.com/search?q=cache:ascii.dyne.o
http://www.google.com/search?q=cache:ascii.dyne.o
http://www.google.com/search?q=cache:ascii.dyne.o
http://www.google.com/search?q=cache:ascii.dyne.o
http://www.google.com/search?q=cache:ascii.dyne.o
http://www.google.com/search?q=cache:ascii.dyne.o
http://www.google.com/search?q=cache:ascii.dyne.o
Here's a google cache link to one of the screenshots:
r g/hasciicam001.html+&hl=en
http://www.google.com/search?q=cache:ascii.dyne.o
Dude...those weren't typos or casual mistakes. He consistently referred to himself as 'i'. Doing so once or twice I can brush off as a typo. Forgetting to capitalize the name of a month I can accept as a casual mistake. Constantly using 'i' instead of 'I', however, is just plain ignorant.
The *CEO* of TurboLinux doesn't even use proper capitalization in his written statements? Seems a little out of place to me. What's with all the lowercase references to himself? Smells a little fishy around here...
Those examples are pretty cool and I must admit, I had never heard of them when trying to solve my modem problem. However, they're still one-shot examples that solve a very specific problem (i.e., share a serial port with another machine). What I was wishing someone would address in a generic way of sharing *any* device remotely. The device driver interface is extremely simple (open, read, write, ioctl, close), so the technology needed to provide that remotely should be trivial. Loose ends would need to be tidied up (like locking devices that need to be locked and the such), but I'm *sure* it's a solveable problem. I think what this person has done is a step in the right direction towards making hardware as generic and universally accessible as anything else. But that's just my opinion.