I agree--grand parent's assertion of "standardized interfaces they will be slower in achieving greater emissions and fuel efficiency" is complete bullshit. Citation needed like never fucking before.

I know cars and I like modern cars. I don't do well with carburetors. Give me a fuel-injected, electronically controlled system all day long. Give me a modern ECU that will automatically adjust for barometric pressure and ambient temperature. Give me an ECU that will give me good fuel efficiency and emissions. I race my car, but I do not remove my catalytic converter.

They don't want to expose the dealer interface for reprogramming a car's mileage, VIN inside the ECU or new keys w/o having the two existing keys. That's the entire extent of the security concern with the exposure of this information.

Otherwise, if my car is malfunctioning and I want to diagnose why it's not running right, I am all too often hampered or screwed without the dealer tools.

Simple example first: my car developed a knock in a cylinder. To find out whether it's a valve or a rod bearing or piston-slap, I have only one option: disconnect the ignition connector and the fuel connector, start the car, shut it off, etc repeat for each cylinder. However, the dealer can simply go into a menu and trigger an ON_1/OFF_1 (from 1 to 4) for each cylinder, doing the same thing electronically, faster and safer.

Complex scenario: diagnosing catalytic converter failure (which is very emissions relevant!) If the car is running rough or is down on power, especially top-end power, it's possible that this might be caused by a catalytic converter. However, many other things could also be wrong to cause this. The best you gonna do as a DIYer right now (for a 2004+ Mazda, in my case) is to wait until the computer throws a check engine light complaining of cat converter inefficiency. However, your situation might be right on the threshold of the rather-generous factory allowance for catalytic converter performance. The dealer can simply pull up a page of emission stats the the car tracks, which lists catalytic converter efficiency. If it's near the bottom of the range, especially for a car with lower mileage, then you have a dying converter. You can monitor this setting over time as well (E.g. over two weeks) and see if it degrades. Having access to this information can save you non-trivial dollars in gas mileage (e.g. highway can drop from 30mpg to 24mpg easily), fouled up spark plugs and (albeit small) risk of engine damage. Since most modern cars run spark plugs capable of long term replacement intervals, such as 60K miles, you risk fouling up an expensive set of plugs.

This is the simple stuff too. Troubleshooting your ABS system? You get nothing other than an ABS light. Could it be a tear in wiring to an ABS sensor? If you are crafty, you can solder that up cleanly yourself for pennies. Could it be air in the brake lines that got into the ABS module? Bleed the air for the cost of a half liter of brake fluid ($10). If a wheel speed sensor shat the bed, that's a $75 repair. If the ABS module shat the bed, well that's much more expensive. Going to the dealer to find out what the ABS light is all about? You will get slapped with a $90 (1 hr labor) diagnostic fee. As a car enthusiast and an engineer, I don't like paying $90 for 5 minutes of diagnostics. What if you go to your local repair shop for the same problem? If they can't read the ABS code, they will have to spend time going down the list of possible things that could go wrong. E.g. all 4 wheel sensors and wiring would have to be inspected (hope the tear is not obvious or not a failed wire inside a connector, where it's not visible!), brakes bled just in case, parts possibly replaced unnecessarily (on a hunch for a common problem). The pure waste in labor that an independent shop has to do wastes the shop's time and your money.

The starter always confirms the starting car's number at the starting line. So if someone gets into the wrong grid spot, it doesn't matter because their car number would be still correct at the starting line. If someone is driving someone else's car and doesn't inform timing appropriateyl, then you would have that problem anyway.

Reruns are not an issue because they are just like regular runs, except done again for a special reason. Cars still line up at the starting line in a certain order to run a re-run.

Double-driver cars are not an issue with sequencing--with any other solution, the club needs to know which driver is at the starting line.

The order that's the same is the order of cars that have been launched from the starting line, not the order of cars lining up for that line.

It doesn't, because at that point, the car that spun is considered a "DNF." The car that spun can be instructed to not to trip the timing lights and if they do, it can be fixed.

In autocross, cars are not allowed to pas each other. If someone spins and the car behind gets too close (within 10 seconds), it gets red-flagged and gets a re-run.

I autocross and I've been thinking about the same problem. I even thought about writing my own free software and building plans for off-the-shelf/cheap-to-make transponders ($1200 for a wireless transmitter unit? jesus).

The problem is that if a car doesn't finish and misses the timing mark--the software shoudl just let you to fix it up. You should be able to say "this car didn't finish" (has a missing tick) or "ignore this tick" (some corner worker tripped the lights accidentally). Then it shoudl be able to just recalculate the times affected. It seems so simple to me, I am baffled that it hasn't been implemented.

All the cars starts in the same order, all the numbers are known at hte start time and cars never pass each other. So you have always same-sequence travel of cars. All you need to do is fix occassional lacks of ticks or extra ticks. No need to re-run the cars.

Verizon/AT&T probably do not keep historical data, even if they can pinpoint my location at law enforcement's request.

The problem is that we have traffic laws with unrealistic speed limits in this country, towns that will raise revenue through ticket writing and red light cameras, all now with access to your OnStar data without your consent or a warrant. Drivers that go with the flow of traffic are safer due to a smaller speed differential--but your insurance company may be glad to force you to do 65 on a road designed for 75mph in the 70's (MassPike) or 55 on a newly widened 3-lane widely-divided highway (rt 3 Greater Boston).

towns shorten yellow lights to get more red light tickets--increase in rear-end accidents be damned. Wouldn't it be nice to corroborate that data with the onstar gps log?

Shh, Slashdot heads might explode.

Unless the TFA is talking about SFTP (which it isn't), there is no reason to laud anything positive about FTP. Other than it was a straightforward protocol and it served us well, back in the day.

Oops, accidental A/C post

This is a plea for anyone who thinks object-orientation won't do anything for them to stop and back away from that view for a second. Give me a minute to explain.

Read this great article called Why are you still using C?. I think it explains very well what OO can do for it.

Did you know that the Linux kernel, despite NOT using C++, is actually doing bonafide object-oriented programming?

Just one example is the Linux VFS. A filesystem passes in a struct with function pointers to read, write inodes, etc. The I/O kernel code only knows about each VFS in the generic terms, but ends up calling specific implementations via the function pointers. This is called polymorphism.

That's right, the Linux kernel is doing real, meaningful object-oriented programming. In contrast, if you put a few functions together under a class (like many people do that "have to" write OO), then you ain't doing jack shit worth of object oriented programming. However, because the kernel is using C, it has to do a lot of messy things with pointers. C++ helps take care of that mess (polymorphism is supported in the compiler), so you don't have to write it by hand.

Problem is, object-oriented programming is useful when it is applied on an as-needed basis.

Design patterns? Same thing. People got a design patterns boner when the book came out (I know I did). The academic/enterprise/fancypants software architect approach was: "What if? What if?! Why not use a pattern here, just in case you ever need to do it this other way?" So, you end up seeing patterns and flexibility and layers of abstraction (variations on a theme) built everywhere, where you end up not using them.

So you end up with a ton of code that never really does you any good. Worse, when you suddenly realize that you need some kind of flexibility, you already probably sliced the code the wrong way, so now it's actually *harder* to make things flexible. All because you made them flexible ahead before you knew what you actually needed.

There's a concept of emergent design, which basically says: don't come up with any frameworks, let frameworks emerge from the code. That is, if you find yourself needing to copy/paste the code or find yourself repeating something that's awful similar to this other thing, well, *now* -- only now is the time to use a technique to eliminate the duplication. Maybe you make a little framework. Maybe you just make a class or two to help you out. Maybe you use a bit of a larger design pattern, well, 'cause you don't need to use the whole thing. And that's great! You've taken care of the duplication, so now all the code you have has purpose, has a real need.

WE have been made to feel stupid, by all these academic and UML software architect wankers that are removed from real-world coding and proclaim the need for design patterns everywhere and "careful architecture" beforehand. Turns out that we weren't stupid, we were just being practical.

I don't know whether you've gotten caught up in the UML/"design lots of patterns"/"writing code is for suckers" hoopla of the late 90's early 2000's--as if you didn't, you'll have a much easier time learning state of the art in development, while being able to apply enough experience from your younger days. (Consider everything that has to do with J2EE Enterprise Java of early 2000's as an example of what not to do.)

If you want to become current, you are going to need to learn to do:

1) Test-driven development
2) Write clean, expressive code (with much less need for comments and documentation)
3) Object-oriented design, as used to solve actual problems (not just putting functions into classes)
4) Design for what you need now or in the immediate future and refactor only as needs change
5) The Do Not Repeat Yourself principle. No duplication or copy/pasting.

The best advice I give to any starting out developer these days is to read Robert Martin's book Clean Code. It distills the wisdom of many an experienced programmer into a clear, well-explained format. It's Java-centric, but principles apply everywhere. Read it and see why separation of concerns is good, why keeping your functions at the same level of abstraction is good, why the single responsibility principle is good.

That book is the first book that explained to me properly why I should give a crap about the Law of Demeter. That law has been around since 1987 and yet I rarely came across anything but explanations with sterile, academic examples. Yet, "Clean Code" showed me why it's bad in closer-to-home terms AND, best of all, instantly provided a rewritten version that didn't violate the law and was clearly better.

One important point: it's not the languages you know, it's whether you know how to code well, design well and analyze problems well. All languages are just tools.

Modern development has finally stopped pissing over code and began respecting code. Gone are the days of trying to make UML diagrams generate Java (Model-Driven Architecture seems to have successfully passed us by without doing too much damage). In the web apps world, I think Ruby on Rails exemplifies latest thinking in software engineering, namely the thinking of "less code = better" and how to add abstraction layers without imposing code overhead in your application (e.g. convention over configuration).

Just because something is easier to use and works right without having to FK with it, doesn't mean it sucks for the advanced user.

No, if you return it, you are not obligated to the contract.

1) Standards & development:

You're right.

2) Usability:

"home screen is just an app," "keyboard is just an app" -- don't care. Don't care to install any OS version I want. Don't care to install a different home screen. That's not usability, that's just a pain in my neck.

Widgets are probably cool, but for multitasking, quoth Larry Page: "software running in the background that just sort of exhausts the battery quickly."

For me usability is not caring about anything like how many apps are open or whether anything's draining my battery. I just want to do things and care as little as possible about anything other than the thing I'm doing. With the iPhone, I don't ever think about closing any apps. My friend, who has a PocketPC phone, is always compulsively tries to close the browser on my iPhone before putting it away and I always tell her "it doesn't matter, just hit the sleep button." You don't have to exit out of anything, you don't have to close anything, there are no trojans that can stay running in the background. It's nice.

3) Upgradability:

That's nice. And you can swap multiple MicroSD cards, which, while a pain, can come in handy if use your phone in different enough sitautions.

4) Flexibility:

That's nice too. However, in general, I have been very happy with the choice of apps on the Apple app store and they do a lot of different things. I haven't felt the need to get a different browser--I quite like what comes with the phone.

The new sensor is bigger now, maintaining the same pixel size.

So you get more megapixels due to a larger sensor AND you get better sensitivity due to backside illumination.

I have a DSLR for quality pictures... for the rest, social situations and what not, 5 megapixels is plenty good and better low light performance just might make this good enough to obviate the need for a separate point & shoot camera.

I'd love to see some HTC Evo 8MP vs iPhone 4 5MP camera quality comparisons.

Bullshit back on you. False comparison. Lacking features != a crappy product. It just means a product that does less. First iPhone OS version didn't have exchange integration or copy/paste, but what was there worked well and was designed to work well. In fact, until Apple was convinced that it could do copy/paste well, it didn't release that feature. That's just not biting off more than you can chew.

There's a gulf of difference between shipping something that's limited in functionality to something that is crappy. Have you ever used the PocketPC PDAs back in the day? I've used a Palm OS-based Handspring and a PocketPC Dell Axim, and let me tell you, the Handspring, with its limited feature set and a slow CPU, did the core PDA things (calendar, todo) a lot better than the Axim. The Axim felt slow (despite a several times faster CPU) and it was harder to work with the calendar (more taps to do things, weird options I didn't need). I hated using it and wrote off PocketPC after that (which is why I never bought a Treo with Windows). That's what "shipping crap" means.