Easy. They cannot control a g-code based platform because there are way too many open alternatives around already. If they build something proprietary that others will have to work with due to their market power, then they get to be a gatekeeper and collect "tax". That's all. Good old "embrace & extend" strategy again.

Now whether or not this will be successful or whether it even makes sense, I don't know. It could be a major flop with a framework/tool that essentially nobody will use, because 3D printers are far from something an average consumer needs or will buy. Even the hypothetical non-existent plug & play, "push a single button" replicator-like machine is not going to make this an ubiquitous piece of hardware on everyone's desk - most people simply don't need it and can get their trinkets and gizmos cheaper and ready-made elsewhere. However, the software could also end up becoming a defacto standard for consumer printers if they play their hand well ...

Unfortunately many people think that VR didn't exist before Oculus Rift. Which is, of course, BS. There was good quality VR available before as well but unless you have worked for a large university, the military, NASA or some large aerospace/car company, you were unlikely to encounter it due to the costs of the equipment involved. Industry-grade HMDs still cost $15000, they used to start at $40k but I guess after the cheap Oculus became available, that price point became untenable. `CAVEs and large projection setups that are commonly used for both research and training work can cost millions.

The worse part is that also quite a few people from these companies - Oculus, Valve and others that are jumping on the VR bandwagon now - tend to ignore the decades of existing research. Most people there are businessmen and (briliant) engineers, not researchers (with a few exceptions). They tend to massively reinvent the wheel and to rediscover things known for many years, because they don't know where to look for them. If they didn't, they would know that increasing framerate and decreasing input latencies is not going to fix the motion sickness. Sure, laggy, smeared image in the HMD will make people sick. However, you can and will get sick even at 120fps - it depends much more on what you are rendering than at how you are rendering it. A virtual rollercoaster will make people throw up even at 4k resolution rendered at 250fps with perfect head tracking. It would look awesome, though ...

The problem is mainly the content, not the technology - the content must work with the technology idiosyncrasies (I won't call them limitations - that implies they could be overcome, but sometimes it would require changing the laws of physics or it would cost so much that it just isn't practical), not ignore the specificities of the medium ("let's play COD with an Oculus Rift, that will be awesome!" *BARF*) or expect that the "technology will improve" and motion sickness won't be an issue, no matter what wild camera gyrations, cool fly-throughs and slow motion cut scenes the game designer has put in. It is the same thing as the film directors having to learn how to shoot in 3D - the "film language" (how you convey your message through camera work, lighting, etc) changes quite significantly when you are in 3D and not every film director was/is comfortable with going there. Even the visually stunning Avatar had some issues with stereoscopy here and there. That is why the worst 3D movies were the ones converted from the regular 2D, where the media specificities were ignored.

This is very much where we are still at the begining - virtual reality as an entertainment and story telling medium. It is not a question of technology anymore, it is more about finding sensible ways to do things in VR so that the experience is fun, pleasant and something people will actually like to return to. With careful design work and working with the medium and not against it you can render even at 30fps and nobody will get sick.

In my 15 years of working with VR (involving both large projection setups and HMDs) I have never encountered anyone getting sick because of the frame rate. It was pretty much always because of poorly made content not suitable for the technology being used, poorly implemented navigation that didn't respect the specificities of the medium ("teleporting" camera, forced/constrained camera movement, head bobbing, poorly synchronized/unsynchronized treadmills ...), poor camera work/tracking ("mouselook" in FPS really is wrong for VR - you don't have head bolted rigidly to your shoulders!) and similar issues. Then you have issues like people feeling discomfort/headaches because of eye strain due to poor focus, moire, poorly set up stereo rendering, etc. It often gets incorrectly attributed to "cyber"/motion sickness, but that has nothing to do with it at all. Finally, there are people who will get sick and dizzy even from looking at a static image projected on the wall - the issues can be psychological/psychosomatic as well.

To conclude, I think it is time that we step back from chasing latencies and framerates and look at the actual underlying causes. Higher framerates and better technology in general are not the silver bullet here.

I think that the logic is that a business professional will benefit more from what a specialized language like R can offer than from the general purpose stuff. The manager is not going to code a website or an accounting database (where the general purpose languages would be useful), however, they may need some sophisticated business analyses or reports that nobody else can do for them - and R is very good for that.

On the other hand, learning R without learning (and understanding) statistics is pretty much pointless and that is *much* harder task than learning the language. Lot of people buy SPSS (a tool similar to R, just with a nice UI) for a lot of money, then load random data and start pressing buttons following some sort of cookbook/cheatsheet. Random numbers come out and then they wonder why their "analysis" doesn't match the reality. Then they go and hire expensive business consultants - who do the same thing while spouting jargon, only charge for it a lot more.

R is a very powerful tool, but without a solid background in statistics and data analysis it is like giving a scalpel to hospital nurse and declaring her a brain surgeon ...

"... and provide an experience very much like the desktop"

Which is exactly what people don't want.

Microsoft should finally pull their collective head out of their backside and stop making everything into a PC with Windows. A phone isn't a PC, it isn't used in the same way, so a "desktop experience" is very counterproductive on a phone.

One would think that they have learned something already ...

Sorry, but that isn't how it works. The role of the MD5/SHA1 hash on the website is not security but the ability to quickly check whether or not the download was corrupted in transfer so that you don't waste time burning a corrupted ISO image, for example.

The real security feature are the cryptographic signatures inside the packages themselves. Both RPM and DEB formats allow the use of these and most Linux distros use them. There is both a hash and a crypto signature to check that the package comes from who it claims to be coming from and that it wasn't tampered with.

As this, by definition, requires that the encryption key is present in the clear on the machine where the decryption is happening in order to make it possible to decrypt the instructions (CPU cannot execute encrypted code), then it can be trivially circumvented. Finding where the key is stashed is going to be only a matter of time and then the encrypted code can be conveniently decrypted off-line, repackaged without the stupid performance-impeding encryption (caching will suffer badly with it) and released on a torrent somewhere, as always ...

Fundamentally this is not different from doing ROT13 on your code - code obfuscation.

Having cars reflashed at a dealership is something different - the mechanic will usually do at least some basic sanity tests that everything works before handing it over to the client.

Anyway, my point wasn't that reflashing firmware is bad - it may be even required and I am fine with that. It needs to be done safely and securely, though!

And yes, Toyota had a big software problem too, even though it wasn't why they have lost that accelerator pedal lawsuit:

http://www.edn.com/design/auto...

In particular, BMW has a history of similar cockups - just search youtube for various "iDrive problems", "Check engine reset" issues, "Engine stalling" issues, etc. Those software problems go back years. The first iDrive implementation from 2002 using Windows CE was a legendary lemon.

It isn't just BMW, though - http://www.edn.com/design/auto...

I had a Renault Clio and Renault's unreliable electronics is legendary too, even though there it was more a poor design than necessarily bad code. But you will never know - nobody has seen the source code of the firmware in many of the control units. Often not even the manufacturer has it - it is outsourced and subcontracted, even for critical systems like ABS or ECU.

And I am pretty sure that this is industry-wide problem - the same control units are in many cars, especially today with all those shared platforms and alliances between manufacturers.

If someone is thinking about drive-by-wire cars (Nissan, uses a safety clutch to be legal atm, but they have publicly announced a push to go fully by wire http://www.caranddriver.com/fe...) or the recent idea about the OTA updates in this sort of cesspit of horrid and unaccountable code, they must be insane.

I am not against the ability to perform an OTA update in principle, but considering how abysmal record with firmware (and software in general) these companies have, this is a major disaster waiting to happen.

When Microsoft, Apple or Google botch an update, there will be a few dead computers or phones at worst. If someone like e.g. Toyota or BMW (both with a "proven" record of poor quality firmware - think "stuck" accelerators or the famous BMW video of stalling car spitting out its key at the driver) push an automatic OTA update and something unexpected fails, there will be *dead people* in addition to dead computers. And something *will* fail sooner or later - we are far far from the ability to write provably correct code as a matter of course. And embedded code is often one of the worst examples of both software engineering (non-)methods and quality, mainly because it costs money and time to do things properly instead of outsourcing the firmware to the lowest bidder somewhere in a sweatshop. Nobody will ever see that code anyway, right?

The only way this can work safely is with previous user's authorization - i.e. *never* automatically and unattended. In that way I can make sure that I am safely stopped and not going 130 kph on a motorway when my engine or brakes decide to go bust on me. That is, AFAIK, what Tesla is doing (a message pops up and the driver needs to accept the update). However, unless this mode of operation is made mandatory, some dickhead will for sure push an automatic update at some point. It is just too tempting to not to and I would be surprised if Tesla didn't have an option to push a "silent" update too already ...

The other point that nobody reacted on so far - do you really want an always-on, always phoning home wireless connection in your car? That's a wet dream come true for anyone who wants to track your car for whatever reason. Tesla is doing it for (ostensibly) performance tracking (and, conveniently, busting lying journalists), your insurance may start to require access to that data if you want to keep your premiums low and finally police and spooks will rejoice, because they don't even have to bug your car or bother with license plate cameras anymore ...

People are getting all excited about this, but they are forgetting that this is *not* going to be a full featured Windows able to run their Office and what not. First of all, it is an ARM architecture, so regular Windows apps won't work unless they have an ARM version (extremely rare). The OS is most likely going to be the cut-down WindowsRT and running on an underpowered hardware - the new Raspberry Pi 2 is still much slower and has less RAM than even the first Microsoft Surface RT, which wasn't exactly known to be a speed demon ...

Microsoft is pushing this as "Internet-of-Things" platform, but I honestly don't see how WindowsRT presents any advantages there over a dedicated OS without the unneeded GUI bloat. And for education? Yes, there will be perhaps Office RT and few Microsoft's apps available, but that's all. What are the kids going to run on this? Visual Studio?

That this isn't going to come back to them in the form of another smouldering crater, except with paying passengers this time.

Delays and problems notwithstanding, dumping a company that has essentially designed and developed the entire thing and handing the project to someone else who doesn't have the know-how about this particular system sounds really unwise, especially after the enormous amount of resources that were spent already. Probably the wealthy investors started to push on Branson and Rutan didn't want to compromise on something, so they decided to bypass them. Or Scaled isn't trusted to not mess something up again as it wasn't a first serious safety-related incident there.

One way or another, this isn't really a confidence inspiring move from an engineering point of view - I cannot imagine the motivation and morale of the people building the craft after being told that no, they won't be allowed to be involved in the testing, except as consultants.

This fellow has obviously no clue about Python and likely not much about programming in general when he can spout such nonsense about Python being "C-based" and "unable to do more complex things".

I read this more as - "I know Visual Basic so I will do everything in VB to save time". If he has said that, he could have avoided presenting himself as an ignoramus spouting techy mumbo-jumbo to get that parent off his back that doesn't really know much about the subject he is supposed to be teaching. I had colleagues who were teaching object oriented programming at a university using Max/MSP and dragging/connecting boxes - "These are objects in Max, so it is an object oriented programming!". But that is what you get when you have a music composer assigned to teach computer science (not kidding ...).

I am really sorry for those kids, because Visual Basic is a pretty terrible language to start from - it is very limited in what it can do and then anything more complex is directly linked to the Microsoft Windows idiosyncrasies, with little abstraction. They would have been much better off with something like Python & Pygame combination (I did teach a first semester programming class like that). Or even better some language actually specifically made for this purpose - like Logo. Or even start with Scratch, Alice or Lego Mindstorms kits for complete novices that have really no clue yet and then move on to Logo or Python once the basic concepts are settled.

People that are advocating C here have obviously never tried to actually teach it to complete novices (we are talking high school kids here!) - there you need to get the kids to first understand the abstractions like code, execution flow, the correspondence between real world objects and their modelling in a computer (variables, types, use of arithmetic etc.) Having to battle compiler errors, strict typing and stuff like pointers required even for printing a simple "Hello world!" message is really distracting and not helpful in that context. They will have plenty of time to learn about that later.

Disclaimer: I did teach undergraduate programming courses, both in Python and C/C++, including using those Lego Mindstorms kits.

The Windows installer has a similar issue and apparently it is not even considered as a problem (red box):

https://support.steampowered.c...

This reeks of serious incompetence or negligence, in my opinion - writing installers that blindly mass-erase files instead of tracking which files did the software actually install and erase only those on uninstall/move is not acceptable in my book. Whether or not it is documented in some disclaimer that nobody reads or not is irrelevant. This really is asking for a lawsuit if someone gets seriously bitten by it.

I really wonder what the devs at Valve were smoking when they consider this as acceptable.

Are you too ashamed to post this antisemitic and islamophobic screed under your own name that you have to post as an anonymous coward?

How fitting, mate.