Tesla have a range calculator to show expected range based on speed, temperature, whether air con is on etc. Various factors will reduce your range from the optimum so you'll almost never get the full range quoted.

As other posters have said, there are enough features in Oracle (some of which are added cost options) to keep it (or DB2, Sybase etc) mandatory in some cases because Postgres & MySQL simply aren't up to the job.

Once you have that in play, companies will tend to standardise on one DB platform for most deployments because (a) you don't want to have to keep multiple skillsets up to date and (b) you never know when that new application will suddenly evolve into requiring feature X which MySQL doesn't support properly, possibly simply by organic data growth.

Also, in some cases, it's probably more expensive proving you can run on MySQL than it is to simply open your wallet to start the deposit for Larry's next yacht...

I'm not involved as I'm in Scotland....

1) The state legislature is run by people. People are (a) greedy and (b) want to stay in power. When car company lobby groups see potential competition, it's cheaper for them to bribe, sorry, "provide campaign funds" to a pet politician than to actually compete. Those people take the money and decry the horrible, horrible Tesla company for daring to defile the hard working people who they've been speaking to (read - taking wodges of cash from).

2)There are some reasons, e.g. here and various Google searches would give you differing opinions. Perhaps it's simply that, because of their current low sales volumes, dealerships just can't provide the right environment to sell Teslas.

I'd have thought that OpenOffice or LibreOffice have probably over taken it on functionality on a modern OS, so there's likely little real value in it. As for running on DOSBOX or similar, why bother?

This will be the next global pandemic that will devastate the human population. Just like Swine flu. Just like Avian flu. Frankly, I've got less fear from these horror stories as time goes by.

And before someone points it out, yes, I'm aware the mortality rate from Ebola isn't comparable to the flu, but the overblown hype about it stands.

The negotiation point is moot. There is the option for you to negotiate the terms with the ticket seller, but there is no onus on the seller to alter the terms if they don't want to.

In specifics - the advertisement to sell the ticket is an "invitation to treat". Proferring money to the seller is the "offer" and it's implicit that the offer is on the terms of sale advertised in the invitation to treat (including terms regarding prohibition of cameras/filming) and the seller accepts the offer. The buyer could place an offer whereby they offer to buy the ticket buy allowing filming. The seller can then reject the offer and/or present a counter-offer (e.g. you can film if you pay some fee to allow filming).

IANAL, but I've studied contract law for Scotland. A contract is an offer and an acceptance, that's all it takes.

You're right, it has nothing to do with copyright, it's contract law (essentially) and laws covering permission to take pictures on private land (the football stadium).

The argument from the premier league is around videoing clips off the TV and posting online which is pretty clear copyright infringement.

Submarine crews generally experience surface pressures, ~1 bar. 18 metres down will be ~2.8 bar with attendant risks of decompression sickness (aka the bends) on the way up unless he comes up very slowly. This kind of thing is known as "Saturation diving and is done all the time e.g. in the North Sea for oil, often for weeks and at greater depths than Fabien is planning.

The 30 days "record" does seem to imply he's doing more than others have done which is rather misleading; it's certainly different from submarines, though.

*facepalm*

No, you don't use main memory as a write cache, that would be idiotic. You use it for read cache. Any updates will be written to disk (and memory) before acknowledging to the client.

In any case, it doesn't matter how good your batteries/UPS are if your server or DB software crashes for any reason and you have uncommitted writes in memory, hence why caching writes on a database is a Bad Idea (TM).

"Veteran network admin trait No. 2: If we don't know it's down, it's probably not down"

Bullshit. Well, either that or our network admins are numpties. We had a switch go down in a data hall. We knew the switch was fubar as we'd lost connectivity to a number of devices at the same time. Networks wouldn't admit a fault. We eventually got moved to new switch ports and lo, everything started working.

The usual approach to any network fault in our place is "replace your NIC". That has, in my memory, fixed maybe two faults.

The issue about ignoring future proofing is that you can invest a lot of time & effort integrating the tool into your environment, writing scripts etc. If that tool gets obsoleted for any reason, it can be a lot of work to switch to an alternative (this goes for FOSS & commercial software equally). You can get locked in to FOSS just as easily as with commercial, you just have a few more options available with FOSS. Some tools can be swapped in & out at a moment's notice, but if you integrate something into your way of working very closely, it can be a nightmare to unpick later.

As for modifying code yourself, that requires a whole set of skills & disciplines many admin teams don't have - I know our team/organisation would struggle with that. There are, of course, 100s of companies who are quite happy downloading source & patching/maintaining it themselves.

Other than that, there's some good advice in there. Version control & release/test cycles are key for any software product.

V1280s are sun4u and don't support LDOMs.