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...
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).
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.
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.
I've done Unix admin for years. I still find it quicker and easier to manage clusters with a GUI because frankly, they're too bloody complicated to manage effectively without one. Yes, you can automate with the CLI (I've written scripts to automate service group creation in VCS), but for a quick dive in to check the cluster status & configuration, it's usually quicker with a GUI to drill down to the setting you need.
Facebook & Google have networks/systems designed to work around failure and data loss is a minor inconvenience. They expect to lose a data centre at various times and continue to Just Work. In those environments, cheap grey boxes are fine provided you design appropriately. If you are designing a critical 24x7 system which cannot spread around in the same way (e.g. financial institutions) may have different requirements.
Now, while I'm not saying that Alcatel is less reliable than Cisco, Cisco generally has the reputation of reliability (warranted or otherwise) and so commands the premium.
I have, albeit with Veritas. Took about a month of restriping 20TB to change the stripe widths. Just because you don't do it, doesn't mean that others don't.
The ruling was upheld on September 9, 2005 by a three judge panel of the U.S. Court of Appeals for the Federal Circuit under the doctrine of laches, citing "unreasonably long delays in prosecution"
So, it seems there's a chance that waiting too long can invalidate your claims.
Compare with trademark law where you have to defend it whenever it may be seen to be infringed (see the case where Hoover corp lost the right to have the exclusive rights to the term "hoover"); the same doctrine should apply for patents. Of course, the whole patent system is a mess these days as it was designed in a different age with different industries. Scrapping patents isn't the solution as they provide valuable protection to inventors who put effort into designing something, but they're horribly abused by various parties.
The issue seems to be fundamentally down to someone with DBA rights on a database issuing "ALTER DATABASE BEGIN BACKUP" which then causes an "interlinked" database to also increment its SCN; anyone know what the "interlinking" is? I'm guessing DB links but it's a bit vague on details and high on the scaremongering... FWIW, the ALTER DATABASE command will require DBA rights to implement, so I'm not seeing the apocalypse that Infoworld is punting; if you've got DBA rights, you can do lots of stuff like drop user, drop table etc, etc, etc...
Wrong - if it was in userspace, it would be tied to the permissions granted the logged on user. I'm not 100% sure, but even as admin, UAC should still have blocked the worst of the behaviour. Once you're running code in the kernel, you can pretty much do whatever you want and the user's permissions and UAC become irrelevant.
If they've released the code under GPL and you still have a copy of it, you're entitled to do what you want with it, up to and including rebranding it and maintaining it as a GPL product for the future. The GPL granted you permissions to do certain things (copy, change, distribute the code) under certain conditions (you had to provide source code if requested). As far as I'm aware, they can't revoke those rights unless you break the other conditions; see Open Office/Libre Office for a similar situation.
One of your key system daemons has just crashed (SEGFAULT). Restarting it causes yet another crash; what do you do? If you know C coding, you start doing stack traces. If you have a support contract, you call them up. If you have neither C skills or a support contract, you hope like hell that Google can help you. If not, you're reliant on someone on a webforum/mailing list helping you out, possibly including handholding on "how to run a debugger on a core file".
I don't care whether it's 1993 or 2011, the fact is if something goes wrong, you need someone who can investigate, find root cause and recommend a fix. That pretty much has to be a skilled internal admin with C skills or a 3rd party support contract.
It's easy to maintain an OS (Linux, Windows, Solaris, AIX, whatever) when things are working, the problem is what you do when things go wrong. That's when you need the support.
This very much depends on the organisation and the risk appetite.
If you have a technically skilled support team who are willing and able to get into a bit of C coding, the "free" linux distros are viable. If your support staff are pure admins and don't do C coding much/at all, they'll struggle to maintain Linux without someone like Redhat backing them up.
Also, it depends on the app - if it can fall over for 2 days at a time without much of an issue, who cares about support? If an hour of downtime is a big issue, you need someone who is able to fix it Right Now (TM). If your local team is good enough, that's fine, but mailing list/forum support of free software is down to the goodwill of the community. They don't care if your app is down, they have day jobs and social lives as well. With Redhat, you can get someone on the end of the phone 24x7.
Slashdot Mirror
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.
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...
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?
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.
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.
The argument from the premier league is around videoing clips off the TV and posting online which is pretty clear copyright infringement.
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.
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).
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.
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.
I've done Unix admin for years. I still find it quicker and easier to manage clusters with a GUI because frankly, they're too bloody complicated to manage effectively without one. Yes, you can automate with the CLI (I've written scripts to automate service group creation in VCS), but for a quick dive in to check the cluster status & configuration, it's usually quicker with a GUI to drill down to the setting you need.
Now, while I'm not saying that Alcatel is less reliable than Cisco, Cisco generally has the reputation of reliability (warranted or otherwise) and so commands the premium.
And they didn't tend to sue people about it as much as Oracle does.
I have, albeit with Veritas. Took about a month of restriping 20TB to change the stripe widths. Just because you don't do it, doesn't mean that others don't.
Can't be perl. It's far too readable, for a start.
Site was slow for me (not quite slashdotted), but got through OK.
So, it seems there's a chance that waiting too long can invalidate your claims.
Compare with trademark law where you have to defend it whenever it may be seen to be infringed (see the case where Hoover corp lost the right to have the exclusive rights to the term "hoover"); the same doctrine should apply for patents. Of course, the whole patent system is a mess these days as it was designed in a different age with different industries. Scrapping patents isn't the solution as they provide valuable protection to inventors who put effort into designing something, but they're horribly abused by various parties.
The issue seems to be fundamentally down to someone with DBA rights on a database issuing "ALTER DATABASE BEGIN BACKUP" which then causes an "interlinked" database to also increment its SCN; anyone know what the "interlinking" is? I'm guessing DB links but it's a bit vague on details and high on the scaremongering... FWIW, the ALTER DATABASE command will require DBA rights to implement, so I'm not seeing the apocalypse that Infoworld is punting; if you've got DBA rights, you can do lots of stuff like drop user, drop table etc, etc, etc...
Wrong - if it was in userspace, it would be tied to the permissions granted the logged on user. I'm not 100% sure, but even as admin, UAC should still have blocked the worst of the behaviour. Once you're running code in the kernel, you can pretty much do whatever you want and the user's permissions and UAC become irrelevant.
If they've released the code under GPL and you still have a copy of it, you're entitled to do what you want with it, up to and including rebranding it and maintaining it as a GPL product for the future. The GPL granted you permissions to do certain things (copy, change, distribute the code) under certain conditions (you had to provide source code if requested). As far as I'm aware, they can't revoke those rights unless you break the other conditions; see Open Office/Libre Office for a similar situation.
One of your key system daemons has just crashed (SEGFAULT). Restarting it causes yet another crash; what do you do? If you know C coding, you start doing stack traces. If you have a support contract, you call them up. If you have neither C skills or a support contract, you hope like hell that Google can help you. If not, you're reliant on someone on a webforum/mailing list helping you out, possibly including handholding on "how to run a debugger on a core file".
I don't care whether it's 1993 or 2011, the fact is if something goes wrong, you need someone who can investigate, find root cause and recommend a fix. That pretty much has to be a skilled internal admin with C skills or a 3rd party support contract.
It's easy to maintain an OS (Linux, Windows, Solaris, AIX, whatever) when things are working, the problem is what you do when things go wrong. That's when you need the support.
If you have a technically skilled support team who are willing and able to get into a bit of C coding, the "free" linux distros are viable. If your support staff are pure admins and don't do C coding much/at all, they'll struggle to maintain Linux without someone like Redhat backing them up.
Also, it depends on the app - if it can fall over for 2 days at a time without much of an issue, who cares about support? If an hour of downtime is a big issue, you need someone who is able to fix it Right Now (TM). If your local team is good enough, that's fine, but mailing list/forum support of free software is down to the goodwill of the community. They don't care if your app is down, they have day jobs and social lives as well. With Redhat, you can get someone on the end of the phone 24x7.