By the time Tesla manage to make a $35,000 Model 3, other manufacturers may well have beaten them to it.
Some are already close. The electric Hyundai IONIQ is less than $30,000 and if the range improves by 60 miles or so (50%) it will be competitive with the Model 3 - which doesn't seem like a huge leap.
And this is just one model. There is already the 180+ mile range Renault Zoe available in Europe, and the new LEAF has around 170 miles.
Those mileage figures need to be taken with a huge pinch of salt. Based on my own experience with my 70D (my real world range estimate = 200 miles) I estimate a 100D would have a range of around 285 miles. Which is still excellent.
I think 381 miles will only be possible driving 30mph on a flat road with no wind.
How can you be so sure? This scenario could have been coded for. Software could have handled it better.
In this TED talk it's demonstrated how the software controlling a quadcopters could figure out an innovative new way to fly even with two of its propellers removed.
There should be a simple fix for the specific IE version issue. It's possible to run multiple IE browser engines on the same OS as there's an app that does this already (IETester).
It should be possible to create a piece of software - if one doesn't already exist - a web browser that is designed for enterprise use and allows the IT department to specify different browser engines for different sites.
That outdated internal application could be configured to use the IE6 engine - other newer applications and external websites could use newer IE engines or another engine entirely such as WebKit.
It could be rolled out by replacing 'iexplore.exe' and assuming the interface was very close to Internet Explorer it could even be transparent to users and thus very easy to roll out.
I think I agree with that. Google are probably worried that initial sales would be hampered by the preconceived notion that it would be used for major eyespam.
In my view these are both examples of the bad practice I mentioned in my post.
Your first example requires a continually maintained list of phone browser user agents. The second example, a list of search engine user agents. There are a vast number of devices and browsers and you're unlikely to stay on top of this list.
Creating a unique table row for every visitor to your site isn't the best application design for the reason you point out - a browser without cookies is going to add a new row with each access. My approach would be to generate a session key but store that in a cookie only, with session related data stored only as necessary (e.g. basket rows). Search engines are unlikely to POST so you won't get any basket rows from them (if you're adding to a basket via GET then you will have other issues).
I've been developing web applications full time since 1996 and I've never once had to resort to browser detection via user agent strings. It's just bad practice.
The fact that some people have been doing this has led to the very convoluted user agent strings we see today, rather than a simple description of the browser / rendering engine and version.
It's perfectly possible to write code that works cross-browser without having to detect browsers via user agent strings. The closest I've come to any sort of browser specific code is occasionally including IE specific CSS to work around IE bugs, but this included in an IE specific way and is ignored by other browsers.
A browser vendor should be able to put whatever they like in the user agent string, and if that breaks a web site or application, then so be it. It's the fault of the developer for making assumptions.
Do you really need 3D support for 3D product visualisation? Object rotation videos (like QTVR's Object VRs) have been around for ages. I company I used to work for was creating these back in 1998. It's a series of photos of the actual product, so you can rotate and see the product from different angles. A non-plugin JS version would be trivial to build.
Safari for iOS and Chrome for Android don't support browser plug-ins.
...which is a problem with the native code route. Java applets weren't a bad solution to this problem, but of some reason they fell out of favour. There were a lot of terrible applets, but there was nothing wrong with the technology in my view. 3D acceleration support via OpenGL / Direct3D is there.
I don't see why we would need pages of information to incorporate 3D elements. The only two uses I can think of are games and gimmicky UI / animations. The former would be better served via native code with a browser plugin (e.g. Unity3D) or a virtual machine (e.g. Java applets). The latter - gimmicky animations - we could probably do without.
A better use of 3D might be to use XML/HTML/HTTP type technologies to model virtual worlds that can be linked together in the same way we link pages together with anchors. We already had this with VRML and it didn't take off. It might have been ahead of its time, as bandwidth was much lower back then and hardware 3D acceleration was less common. I'm not convinced, though.
GPL: the whole of a derived work, even new components, must remain under the GPL MPL: only the code files licensed under the MPL must remain under the MPL
Slashdot Mirror
By the time Tesla manage to make a $35,000 Model 3, other manufacturers may well have beaten them to it.
Some are already close. The electric Hyundai IONIQ is less than $30,000 and if the range improves by 60 miles or so (50%) it will be competitive with the Model 3 - which doesn't seem like a huge leap.
And this is just one model. There is already the 180+ mile range Renault Zoe available in Europe, and the new LEAF has around 170 miles.
If you go back to the Tesla Model 3 reveal, the current setup not how it was sold.
I'm pretty sure it was along the lines of "Available from $35,000 - place your reservation today".
So the argument here is that those reservations were miss-sold, not that the business model is a surprise.
> Microsoft has described Google's announcements of unpatched Windows bugs as "disappointing".
I would describe Microsoft's ability to patch these bugs within a reasonable timeframe as "disappointing".
...and they'll want to move out of London in style, right?
Accidentally? Seems really unlikely. I'd like to see the code to see how that was possible.
Those mileage figures need to be taken with a huge pinch of salt. Based on my own experience with my 70D (my real world range estimate = 200 miles) I estimate a 100D would have a range of around 285 miles. Which is still excellent.
I think 381 miles will only be possible driving 30mph on a flat road with no wind.
"manipulated social media to create false waves of enthusiasm and derision"
Trump hired people to cheer at his rallies. Doesn't seem too much of a stretch to assume he does the same thing online too.
We must be looking at a different Wiktionary.
Small and mid-sized business
Wiktionary says it's the simple past tense and past participle of impulse. Impulse means a sudden urge requiring action.
Rephrasing then... "This new type of self-promoting campaigns that Google felt the urge to action..."
Has it improved much since 2006? When I used it back then it was awful. Slow, terrible UI, over engineered.
Well said. And it only takes one mistake by one person to introduce a vulnerability. In hundreds of thousands of lines of code.
How can you be so sure? This scenario could have been coded for. Software could have handled it better.
In this TED talk it's demonstrated how the software controlling a quadcopters could figure out an innovative new way to fly even with two of its propellers removed.
http://www.ted.com/talks/raffa...
I'm not sure a human operator could have done that.
If you want the plans for something it's not necessarily because you want to recreate it. Have you not seen Star Wars?
There should be a simple fix for the specific IE version issue. It's possible to run multiple IE browser engines on the same OS as there's an app that does this already (IETester).
It should be possible to create a piece of software - if one doesn't already exist - a web browser that is designed for enterprise use and allows the IT department to specify different browser engines for different sites.
That outdated internal application could be configured to use the IE6 engine - other newer applications and external websites could use newer IE engines or another engine entirely such as WebKit.
It could be rolled out by replacing 'iexplore.exe' and assuming the interface was very close to Internet Explorer it could even be transparent to users and thus very easy to roll out.
I think I agree with that. Google are probably worried that initial sales would be hampered by the preconceived notion that it would be used for major eyespam.
In my view these are both examples of the bad practice I mentioned in my post.
Your first example requires a continually maintained list of phone browser user agents. The second example, a list of search engine user agents. There are a vast number of devices and browsers and you're unlikely to stay on top of this list.
Creating a unique table row for every visitor to your site isn't the best application design for the reason you point out - a browser without cookies is going to add a new row with each access. My approach would be to generate a session key but store that in a cookie only, with session related data stored only as necessary (e.g. basket rows). Search engines are unlikely to POST so you won't get any basket rows from them (if you're adding to a basket via GET then you will have other issues).
I've been developing web applications full time since 1996 and I've never once had to resort to browser detection via user agent strings. It's just bad practice.
The fact that some people have been doing this has led to the very convoluted user agent strings we see today, rather than a simple description of the browser / rendering engine and version.
It's perfectly possible to write code that works cross-browser without having to detect browsers via user agent strings. The closest I've come to any sort of browser specific code is occasionally including IE specific CSS to work around IE bugs, but this included in an IE specific way and is ignored by other browsers.
A browser vendor should be able to put whatever they like in the user agent string, and if that breaks a web site or application, then so be it. It's the fault of the developer for making assumptions.
I think it was a joke.
This is free for home and business use also. The non-commercial restriction applies to the operators of the software, not the users of it.
Google docs on the other hand is completely closed source.
Do you really need 3D support for 3D product visualisation? Object rotation videos (like QTVR's Object VRs) have been around for ages. I company I used to work for was creating these back in 1998. It's a series of photos of the actual product, so you can rotate and see the product from different angles. A non-plugin JS version would be trivial to build.
Safari for iOS and Chrome for Android don't support browser plug-ins.
...which is a problem with the native code route. Java applets weren't a bad solution to this problem, but of some reason they fell out of favour. There were a lot of terrible applets, but there was nothing wrong with the technology in my view. 3D acceleration support via OpenGL / Direct3D is there.
I don't see why we would need pages of information to incorporate 3D elements. The only two uses I can think of are games and gimmicky UI / animations. The former would be better served via native code with a browser plugin (e.g. Unity3D) or a virtual machine (e.g. Java applets). The latter - gimmicky animations - we could probably do without.
A better use of 3D might be to use XML/HTML/HTTP type technologies to model virtual worlds that can be linked together in the same way we link pages together with anchors. We already had this with VRML and it didn't take off. It might have been ahead of its time, as bandwidth was much lower back then and hardware 3D acceleration was less common. I'm not convinced, though.
And for completion:
BSD/MIT: all derived works can be relicensed as proprietary
GPL: the whole of a derived work, even new components, must remain under the GPL
MPL: only the code files licensed under the MPL must remain under the MPL