That's a really good point. I'm sure they've said something like that in a interview/PR type setting, and I'm sure they wont follow through. So from a technical/legal standpoint, there's probably not much you can do.

However, I'm sure this will lead to tons of activation cracking to keep things going. Heck, I still use XP for my main OS (I know, lazy). I'm fairly certain I don't want to upgrade to Win 7, but I've been very hesitant to switch to linux. When the "can't activate, servers offline" day comes for XP, I'll just crack activation and keep going. That is if I haven't migrated to linux by then.

I forget what the countdown date is. I would download the widget to check (out of morbid curiosity), but I can't run it since I use XP...

I was referring to what they're buying, not why. But yes, TDI's are great.

True, cost / complexity is an issue. But if the reliability is there, people are often willing to pay an extra for a very fuel-efficient vehicle. Like hybrids.

Yeah, good points. Although...

> Until the electronic system is at least no larger than a typical DOHC head it will receive the same reception as Rover's fully-variable heads.

I dont think the size is that important here. If an electronic system were twice as heavy, and required a much bigger alternator, but also increased fuel efficiency by 15-20%, someone would do it...

I've always wondered why more solenoids aren't used, as in @grishnakh's example.

I suppose it's like power steering - they're just finally starting to get fully-electric power steering in cars, and it's been how long? The capability has been there, but it's taken something special (the need for a very light/efficient car) to drive that kind of change.

I'm guessing when car manufacturer's are trying to optimize their fuel efficient cars, they look at the top X factors that reduce efficiency, and find the most cost-effective fixes. So at one point "Variable valve timing" will come up, and the cost of developing a highly reliable system will be justified, and they'll do it.

Then again, they have fully electronically controlled suspensions out there, yet I have never seen/driven a car with one. Unless valve timing is such an important issue *and* current variable valve timing methods fail miserably, they probably wont be able to justify such a new, complicated, and completely neat idea like computer-controlled solenoid-activated valve timing.

But oh man, how cool would *that* be??

Oh man, I remember reading about that engine. Really innovative idea, especially since gas efficiency was a concern and this was a neat way to get good efficiency out of a carbed card.

As I remember, one of the problems of igniting an air-fuel mixture is getting a complete burn. A large part of pollutants are due to incomplete burn (meaning you're sending gas/chemicals straight through the engine w/o burning or using them). The spark from a sparkplug is very small, and takes time to spread. The sparkplug is also mounted to the wall/ceiling of the cylinder, which is inconvenient.

So the idea here was to pre-ignite a small amount of air/fuel in a small pre-cylinder area, then let that flame spread out into the main cylinder. Created a more complete burn, which (pretty much by definition) creates more power ie. more efficiency.

It's almost sad that this happened at the end of the carburetor-era - it was quickly replaced by fuel injectors, which were more efficient. It was a really neat solution to the carb/fuel problem.

No!

This reminds me of when I was young. I used to listen to classical music in high school while doing homework. My dad would always tell me to "turn off that music" because I couldn't possibly be concentrating with it on. I would explain that it helped, but he would never believe me. It really wouldn't matter what I told him, he had his mind made up; he could not concentrate with music on, so no one could concentrate with music on.

The reasoning the boss has... "he thinks it distracts us from our jobs and causes us to make mistakes". It seems likely that he sees something he doesn't agree with (headphones in the workplace... unprofessional), makes an assumption (this must be a source of distraction), and then makes up an arbitrary justification for changing it (it causes errors). It would make sense if he had followed it from the bottom up; the company is experiencing too many programmer errors, which can be traced back to distractions, which can be shown to be caused by too much personal music. Then there's a justification.

But that's a far cry from looking over a see of headphones and deciding in your head, "I think this is wrong. I'm going to 'fix' it by changing something." It's not clear what the boss' exact reasoning is, but it looks like a poor and shortsighted decision that can only harm things.

Personally, I know sometimes I need music to keep me going. Classical for when I'm cruising along, some high-energy for when I'm really plugging along and getting a ton done, and then complete silence when I have to figure out something complex. Then once I get through that complex segment, it's back on the music. Going without music would be like having an uncomfortable chair for the day, or going w/o my favorite mechanical keyboard, or not having enough light. Not a show stopper, but just a bit more miserable and less productive.

Thinking back on it, whenever I'm working with programmers, it's just about universal that they'll all have their own headphones and use them to tune each other out (concentrate) while working. The headphones come off to discuss programming problems, games, lunch (take out)... then back on to get back to work. I haven't seen another office position where headphones are so ubiquitous.

Just one thought; for dimdim, you have to install a browser plugin to share your screen. This is not a huge deal, but it's not the one-click program that some of us are looking for where dealing with tech support issues. I'd say this is a better solution than some others, esp. compared to installing a whole program. But you'd still have to get your (possibly technophobe) relative/client to do this over the phone:
-go to the dimdim website (pain starts here... what's a browser?)
-sign up for an account, entering all the right info & choosing a password.
-log into the website and start creating a "meeting" to host
-install the browser plugin & restart browser
-go back to that hosted meeting, find the link and send it to you
-now you can see their screen. I'm not sure what additional steps you have to take to control their screen, but I think there might be more.

I like dimdim. I love that they're open source, and I definitely want to try them for my next screen-sharing meeting, esp. with their cool browser-sync tech. But for tech support, I think this still is not an ideal solution. I'd rather try out something like teamviewer.com or ultravnc SC (reverse VNC) instead.

*NOTE: I could be wrong about the above steps. I've tried hosting a meeting a while ago, but I may have remembered things incorrectly.

Logmein is great, and I use it for all my own computers. However, it requires an install on client-side, and for some situations (over the phone support with an ignorant user), trying to get them to install is a long, painful process.

I also use reverse VNC, which is nice. You have to open up a port on our own router, have the VNC viewer listening on the right port, and then setup the reverse VNC binary to connect to your computer (ultravnc has easy programs for this), but it's reliable and pretty simple for end-users... one download, one click, done.

I haven't found a web-based, no-install remote desktop sharing program yet that's free. Would be nice to have.

I think the golden rule applies here; do unto your code what you wish your predecessor's had done to their code. If you write your own code, maintain it yourself, and never have anyone else work on it, then do whatever you want. Heck, use no punctuation, indentation*, or even carriage returns if you can help it.

However, there seem to be two camps; those who see the value in comments, and those who don't. Comments wont detract from those who don't like them (besides more trivial annoyances like wasted screen space), while the lack of comments may significantly hamper those who would appreciate it. It seems safer & more efficient to comment and make understandable code accessible to all, instead of saying that "good programmers" shouldn't need it, and raise the requirements unnecessarily for the maintainability of your code.

Used properly, comments can help. So just find a helpful way to do it. My mindset is that I write for the next guy, assuming that someone's going to hand him the code with an explanation of what he should be doing, and the comments will help guide him. They help the same way as chapter titles. Chapter titles are unnecessary and often can be completely removed without altering the story. But try to skim through a book and find what you're looking for w/o titles, and it's a pain.

I just jumped into an existing project that a genius (really) friend of mine started. He's very smart, but not as experienced a programmer. And the #1 pain point right now is lack of comments. Some of the code is plain spaghetti. That's fine, I'll just refactor it. But since there's no comments describing *why* it's doing what it's doing, I can't yet refactor.

Other things work just fine. But again, lack of comments prevents me from understanding what it's doing without understanding the entire context of the entire system. This is bad design, but that's the point - perfect code may not need comments, but none of us need worry about that (since we wont be working on perfect code anytime soon). It's not a crime to have rough code because the system is still organically growing. It is to have tons of uncommented stuff jumbled together.

Help me to help you. Help your successors maintain your crap. Comment your code. Make things easier on people (I'll put a 1 liner describing this section, since it's a little tricky), rather than harder (Really smart people will understand this, and I don't care about the others).

* Python users: find another way to obfuscate.

nahdude's system sounds great... automate all the day-to-day sys admin into a GUI that devs can use.

I use something simpler, a homegrown remote-scripting system like capistrano but in python. I think a web based complex system would be much better, but it's hard to justify for smaller projects (or budgets). However, it's very nice to setup remote scripting. You can do pretty much anything remotely that you can do locally (ie. on each server), but the benefit of having it all centralized makes things easier.

I have a script on my dev machine that updates my dev server with the latest code, migrates the DB, and restarts apache. I have similar scripts for the testing and production servers. I also have a script that exports the DB from the production server and imports it into my dev machine for me to play with. Having these tasks automated is very nice, since all these utilities can be kept in source control for each developer to be able to use. They speed up simple tasks and lower the barrier of entry. When updating the dev server or getting a copy of the live DB is a single-click deal, you're more likely to use it.

For more in-depth server admin, a more complex solution should be considered. But in the OP's post, it seems like the target is simplifying daily server-admin tasks for web dev's, and a remote scripting solution might be a low-effort improvement.

Or do the same thing but add a web gui and get a neat system like nahdude's. I wouldn't mind having that... but it wouldn't really gain me much over my current command-line system.