Okay, there's the misunderstanding - I hadn't understood you were talking about automated pre-checkin testing. I still am not seeing the need for "multiple compilers, multiple OSes, and multiple binary architectures" mentioned by the original poster for a product that is intended for a single platform. I frankly don't care whether my code builds and how it runs under Clang when we're a Visual Studio shop. Of course it's different for an open-source organization or a library vendor that needs to support multiple build/run environments, but those are rare exceptions. For most, we're talking about adding a lot of complexity, time, and maintenance costs to get a common code base for a number of different build environments that will never be used in production, particularly when there's a full-time QA department available.

And the benefit of this extra step is...?

On the flip side, we usually get bitched at if there are no unit tests for new code.

Developers may build with the IDE’s own compiler during development, but must ensure the code successfully builds with the centralized build system before committing.

Which is fine if you have the good fortune to have a mirror of the build system on your own machine, but in a lot of situations that isn't the case. Where I work we of course have the raw build scripts that we're expected to run locally before committing, but the CB system we use (Jenkins) occasionally just doesn't behave the same way because it has to do additional processing that we can't do locally, and sometimes will flag spurious errors that can only be fixed by clearing the workspace. Yay for incremental builds.

Multiple compilers, multiple OSes and multiple binary architectures should all be used and they should all be available to every developer on the network.

That's fine for something that's intended to run cross-platform, but not so much for something targeted to a specific operating system - code that's hooking Windows drivers isn't going to fare too well under Linux, for instance. As regards the unit tests, it's trivially easy to have code that runs fine in the unit tests but won't build for production because the test project contains the needed dependencies, but the coder forgot to put those dependencies into the production project. That's not an excuse for broken builds, but it does happen.

Your QA/Build process is seriously broken if you don't have one person or one team in charge of the build at all times.

We do have someone that owns the responsibility for the build system, but we also largely subscribe to the "you break it, you fix it" philosophy, and all of the devs have the tools to see when something breaks on the CB system right then and there. Social pressure among the devs ("Awesome job breaking the build, Bob. Did you even compile it before checking it in?") tends to help keep the builds clean, although there still are a couple of guys on the team that can be counted on to break the build a few times a week. 9 times out of 10 our busted builds are because someone didn't take the time to build all of the required configurations on their own machine before checking something in.

Rework the code so that it doesn't warn.

The problem is that sometimes that's not an option. For instance, a few weeks ago I was working with some code in VS 2010 that used named enums. Even though Intellisense was smart enough to recognize the enum without the explicit name ("enum" instead of "name::enum"), the compiler kept throwing "unknown symbol" errors if the enum was left as-is, and it would throw a warning indicating that the syntax given was only valid under C++11 if I explicitly scoped the enum, which failed the build because we compile with warnings equating to errors. Changing the enum itself to be enclosed in a class or at least a namespace probably was the right way to do it, but it would end up affecting a lot of other code, which in turn meant an extra regression pass for the QA guys. So, the only practical solution at the time was to disable the warning for that block of code, and re-enable it afterwards with a comment explaining the reason.

With a few rare medical exceptions, people who can take responsibility for their own actions generally don't get fat in the first place. If they do at all, it's only a little, then they say "oh guess I need to correct this" and it never becomes a real problem.

It's a truly weak and spineless person who cannot take charge of their own life, including identifying and effectively working to change one's own weaknesses and shortcomings. Excuses and explanations for why something's not your fault (as though fault and blame had anything to do with what needs to be done) are so much less effort. This childish preoccupation with blame and how to escape it prevents people from realizing how much an individual can change.

This is one of those things the older generations generally understood that the younger ones generally do not. This represents a devolution of the society. And yes, I have personally made major changes in my life. I did this more than once precisely because I didn't give a shit about blame and fault. What I cared about is what actions I could take to manifest real change. I was proud to call something "my fault" because that meant I had the power to change it. What I can do, I can also learn not to do. I didn't have this infantile desire to escape blame and garner sympathy from others to make myself feel better. I felt better by fucking doing something about it.

It's called growing up and being a man or being a woman, taking responsibility like actual adult people do. Why, this might even include the foresight to take a hint and embrace a healthier lifestyle when you're only a little overweight, instead of waiting until you're morbidly obese to conclude that what you are doing isn't working. This kind of adulthood is an increasingly rare sight. This does not bode well. You now have an entire culture that rejects this idea rather than viewing it like a best friend and an ally. The culture can feel however they want; no one escapes the actual cause-and-effect. There is no way a morbidly obese person feels better day-to-day than a healthy person. All of the "fat acceptance" in the world won't change that reality. But you can work with reality instead of demanding that people make you feel good about denying it just for the sake of inoffensiveness and phony blamelessness.

Of course they're afraid of that. Heaven forbid we actually allow the accused to exercise their right to a fair trial.

MIT is already working on something similar.

Oh yeah, and if you get an efficient diesel generator you're looking at using 14 gallons for that 455 miles of range, giving you 32.5 mpg, which while it isn't great, isn't bad either.

The shipping weight on the first generator you gave was over 400 pounds, so we'll be conservative and call it 350. Fuel is another 7 pounds per gallon, which adds another 100 or so pounds (or more with a bigger tank, although this will go down as the fuel is consumed), and the trailer will likely weigh in the neighborhood of 150 pounds, with the hitch adding another 30 pounds or so. The upshot of this is that with the extra weight the car will be pulling (600+ pounds or so, plus whatever the passengers weigh), you're not likely to get the advertised 265 miles of range, plus if the generator is running at 85-90% of capacity to charge the car it's going to burn fuel at close to twice the advertised rate (which usually assumes a 50% load), both of which will substantially reduce the effective MPG.

It's doable, but not practical. To me it seems kind of silly to spend thousands of dollars in addition to the rather steep cost of the car itself just to turn it into an expensive, jury-rigged hybrid when any $30,000 ICE sedan will give roughly equivalent if not better range, and you have to buy a LOT of fuel to make up that $40,000 price difference (minus whatever tax credits, etc. come into play). And yes, if you happen to have any charging stations along the way you can mitigate the financial cost, but the charge time is far from trivial, even for the Superchargers. For an ICE car that gets 30mpg, it takes about a minute to fill it with enough energy to go 300 miles. For a Tesla on a Supercharger, it takes an hour or so to load not quite 90% of that much energy, and far longer at most other stations.

But you never know if you could have gotten the better deal even when you do agree. You may indeed get a price that you agree on but you never know how low the dealer might have gone.

You're absolutely right, of course, but in my case, I placed a non-trivial value on my free time, and given that what I was offering was a couple thousand dollars under the researched "invoice price" (which of course is bogus, given the nebulous value of the dealer's holdback and other potential dealer incentives) and *many* thousands under the MSRP, I felt that it was at the very least a fair price and that it represented a case of diminishing returns to pursue anything lower.

If it helps any, I hate the car. It's what my ex wanted to get, not me.

Who here has actually had a 'good' experience when buying a car from a dealer?

The last car I bought was pretty much trouble-free. I researched the vehicle, determined what I was willing to pay for it, and called the dealerships with my out-the-door price. Three of them balked, the fourth faxed me a quote with my price, and I picked the car up later that day for exactly that amount. They weren't real pleased to find out I already had financing in place through my bank, but that wasn't my problem. :-)

Haggling means that the person with the most experience at it wins

No, haggling means the person that's least willing to walk away loses. It's not hard, you just have to say, "okay, no deal then", get in your car, and drive away if they won't sell for what you're willing to pay. Plus you get the bonus of knowing the salesman is going to be sweating as he explains to the sales manager why he lost the sale.