More like the gizmo will never get made unless they have money from elsewhere and are using Kickstarter only as a marketing campaign
You seem to think that's a bad thing. It's the purest form of market research there is - not only did you get people interested in your thing, but you got them to put money behind it.
I don't have a problem with market research, but then please mark it as such. This is just dishonest and it does a disservice to everyone else by giving the impression to the general public that an actual product can be made for that ridiculous budget and timeline. Then campaigns with genuine products and realistic budgets will never get financed because people take this sort of thing as standard and realistic. At least these guys have some real prototypes and aren't just selling hot air there.
Also, doing a "market research" Kickstarter as a mean to convince VCs and/or angel investors to give you funds is pretty much a suicidal gamble - now you have 20k people who have put down their money for your gizmo and you still have no real funding to produce it. And you may not be able to get it - 20k people wanting a $200 gizmo is not that much interesting from the investment point of view by itself (that's just $4million) and it is pretty much the worst project size possible when it comes to manufacturing - too big to build in a garage and not big enough to actually give you access to the manufacturing facilities you will need. Also, few projects reach that sort of size on Kickstarter, most get much less. So unless it is something really groundbreaking, truly visionary that will make the VCs go gaga and pull out the checkbooks, you will have trouble attracting investment (heck,it is a stupid touchpad like the one Apple sells already...). However, you are stuck with the commitment to build and ship those 20k units already...
I more inclined to say that these people are an idealistic startup trying to bring their first project to the market, with no real past experience doing so. The completely BS time line shows that as well - they budgeted one month only for tooling and production - just the injection molding tooling production takes several weeks for every iteration (and costs thousands of $$$ a pop) and it is pretty much granted they will not get it right the first time.
So my bet is that this will ship a year or two late, over budget and probably drive the company to bancruptcy in the process.
More like the gizmo will never get made unless they have money from elsewhere and are using Kickstarter only as a marketing campaign. The $60k they are asking for won't cover even the materials. Just the mandatory FCC/CE/UL certifications will take a third of their budget, assuming that they actually pass on the first try.
This article gives a good breakdown of how much it does actually cost to build and ship a hardware product: https://medium.com/bolt-blog/w...
Yeah, right. So it only took a decade to get serious OpenSSL bugs discovered and fixed - despite the project being open from the start. And that is most likely an order of magnitude smaller project than something like even moderately complex CPU core, written in a language that many more people are familiar with.
Yes, if it wasn't open, the bugs probably wouldn't have been found, but that's speculation - we simply will never know. If you hope to find a "backdoor" (which could be simply so subtle as intentionally weakening some crypto support instructions or random number generator if some flags are set) in a ton of Verilog/VHDL code where you need to understand both the hardware *and* the crypto, you are seriously delusional. Even the vendors themselves have only a fairly small team of people that actually understands this type of code. It is so ultra specialized niche. You will probably not see the weakness even if you were looking straight at it unless you are a specialist in exactly this domain and familiar with the implementation.
Anyhow, it is a moot point - the mainstream CPUs are never going to be "open sourced", because it is the core intellectual property of these companies.
First, these FPGAs don't quite have enough power to run a design comparable with an Intel/AMD CPU as most people know them. So this effort is pretty much irrelevant for dealing with backdoors in mainstream hardware. Their goals are quite different, mostly to do with on the fly reconfigurable computation - something that is hard or impossible to do if you cannot generate the bitstream using your tools.
Second, even if you had a fully open sourced design somehow, how many people do you think would be able to actually understand it to the degree that they would be able to verify that there is no backdoor? Or even verify that the design is complete and the backdoor part is not withheld? It is not possible to build these without the in-house tools companies like AMD or Intel use (they don't use off-the-shelf FPGA tools, those are too small/slow to handle these large CPUs). Most people wouldn't be able to understand even the Verilog/VHDL for the tiny microcontroler implemented in the article.
I am all for openness and open sourcing as much as possible but that is not a panacea and in cases such as these it would only give false sense of security.
Except it is regulated as one. In fact, most countries don't make any distinction whether the RC model is fixed wing, heli, multirotor or whatever. Once it is unmanned and falls into the "model" category, it is regulated the same.
That most owners don't know that there are *gasp* laws and rules that apply to their toys is not the problem with the laws, unfortunately.
"Drones" - aka small multirotor helis - are regulated as RC model aircraft in most countries already. Not sure where you are, but perhaps make sure that you actually know what laws are on the books already before calling for more regulation.
The problem is not lack of regulation but the fact that 99.9% of the owners of these things have no clue about the rules that actually apply to their hobbies. RC model flyers have been rarely caught doing similar stupidities before because: a) it is hard to do with a fast moving fixed wing plane, b) traditional model helis are tricky to fly and very expensive, few people would risk their toy like this after they have finally mastered it, c) few RC models were computerized to the degree that they essentially "fly themselves", including GPS waypoints and what not. RC flying was always about the flying skills, not taking videos for Youtube. d) the enforcement was caught flatfooted, the few RC model owners around have newer posed problems but now every yahoo has a gizmo that requires no skills to fly and don't give a shit about any rules (if they are even aware of them).
As I see it, unless the police is allowed to take these things out by force, then things aren't going to change. Tracking down an owner of a drone hoovering somewhere high in the air autonomously is pretty much impossible unless you are very lucky. They don't need to emit radio signal continuously, the gizmo can navigate by GPS so unless you literally run into a guy with the controller you will not find him.
And as regulation is concerned - that could actually use to be relaxed quite a bit. E.g. in most of Europe if you want to record video using an RC plane/heli/drone for commercial purposes, the rules are very draconian - you need essentially a full private pilot license as if you were flying a full sized plane, you must always have a spotter next to you, are not allowed to fly beyond line of sight, etc. And this applies regardless of whether you are recording over a crowd of people (which requires additional permits) or only some fields for a local farmer...
Considering that even an app like HTC's "Kids Zone" (a vendor preinstalled, unremovable app with activities for kids to keep them occupied) requires permissions like: "In-app purchases", "Phone calls", "Contacts", "Calendar", etc - aka everything that could run up an enormous bill or exfiltrate your monetizable personal information while your offspring are playing - it doesn't surprise me at all that someone tries to scam the advertising douchebags too...
Today's smartphone is a device for siphoning personal data and money, whether the owner's or the advertisers, nothing more. Any other functionality that it happens to have is starting to become only a side effect and coincidence (even more if the functionality is actually useful). It is starting to be so bad that soon we will use the smartphones only to access Internet on the go and have a second device to actually perform calls, text and keep any other personal info on.
It is more likely that none of them will be dominant, because when you have 2-3 players that refuse to talk to each other to even establish common APIs to handle the basic tasks like tracking or renderer integration, many game studios will just say "Meh, screw it". And they will remain sitting on the fence instead of pouring money into a niche product that requires very significant technological and content investment. And with little reasonable content beyond bite-sized demos nobody will buy the HMDs neither. That's the real issue.
And yeah, of course, the rush to claim possible walled gardens so that they can play Apple and extract toll from both developers and users - Valve with Steam, Oculus with their Market or what it that thing called, Samsung has its own, Sony for sure is preparing its own for their PS4 platform, Google with Google Play, etc.
Without at least some sort of standardization and simplifying the integration of the HMDs into graphic engines this is a nonstarter and could bury the technology before it even had a change to take off. The direction e.g. Oculus is going in is pretty terrible - every release of their SDK is more closed than the previous one, more invasive and complicated integration-vise. Guess why only is it that only Unity and Unreal have somewhat usable Rift integration - and good luck making things actually work with Unreal. It feels very much like unfinished alpha with tons of problems and issues, despite Oculus engineers actually working on it.
I have told John Carmack that they have blown a huge chance to establish a defacto API standard for interfacing to these HMDs with their SDK. And that was before it was announced that they are abandoning the non-Windows versions and taking the code completely proprietary.
None of which actually addresses any of the needs these companies have.
Even COBOL is standardized - and that is about as relevant as X3D or WebGL to supporting a Rift-like HMD or some sort of interaction device that isn't a keyboard/mouse.
I am sorry, but this is BS. This charitable idea unfortunately rests on the false premise that Internet works the same way as press does (and thus one can control and censor it using the same means).
This is not about kids being drunk and getting a photo of them sleeping in a garbage bin posted on some news website - that sort of stuff will pretty much disappear after few years by itself, because it is expensive to maintain all this crap accessible and its publicity value has been zero few hours after it was published already
The larger problem is that a lot of information that is public in common interest gets suppressed - e.g. why a crook should have the information about their crime removed only because they feel like it? E.g. here in Europe it is common that for many jobs you have to bring a copy of your criminal record showing that you haven't been convicted. Expunging something from there typically takes an act of court and many years (typically only after 10-20 years after the sentence has been completed you can ask the court to expunge it). If a kid was stupid and landed in jail, having their crime removed from Google will help them exactly zilch. Then you have people who want to have information about them suppressed for vanity or political reasons - that is straight censorship and there is little reason why that should be allowed.
The search engines shouldn't be (and cannot be) the ones shouldering the burden of whether some of these requests should or shouldn't be allowed. They don't have the resources to judge whether or not the request is valid and they have a conflict of interest as well - it is pretty much to be expected that they will simply remove stuff by default in order to reduce the hassle and avoid having to go through courts (why would they - it would be only a net loss for them either way, even if they won it). So in the most cases the public interest just flies out of the window. .
Finally, this approach of how to achieve the goals of removing the information is completely bogus - basically it is like court-mandated sticking head in the sand so that you don't see the problem. That you stick the head in the sand doesn't mean that the problem ceases to exist - the fact that Google or Bing stop listing the information doesn't mean that the original website that has actually hosted the information pulls it down as well. So nothing has been actually "forgotten" and it only takes a search on something like Yandex or some other search engine that doesn't care about these requests (e.g. BBC) to uncover it again. I am pretty sure that sensation-hungry tabloids will be using this to fish out juicy dirt in the future. So what has been achieved apart from spending millions on a bogus remedy here? Andersen's Emperor's New Clothes comes to mind here - it only takes one person to yell that the emperor is naked...
Experience writing, debugging and maintaining code.
The bucket list of having to know this and that means nothing when the programmer doesn't know how to apply it. Claiming things like the latest C++11 features (lambdas) as separating beginners from masters is just BS trying to artificially simplify the issue into something quantifiable. HR and managers love that, because it is easy to test.
I write C++ code for over 15 years now and I can't claim that I am conversant with all those new C++11 features, like lambdas or even move semantics. I didn't need or encounter them so far in production code. The first lambda I have found was only very recently in some brand new code that is explicitly written as C++11 - and had to look up what that weird syntax was about. However, I am pretty sure I will be running circles around anyone who has just drilled themselves on the C++11 specs, but never wrote anything serious in it - I have simply seen and written so much code already that I am fluent in the language, even without knowing all the obscure features. It is the same as with learning foreign languages - you can be excellent at grammar but you still won't be able to communicate until you have to speak it for a while...
And I do hope that you offer a senior developer wages as well for these sort of requirements. The OP was talking entry level job.
People requiring these sort of skills for an entry level job are the true reason for the perceived "lack of IT talent" - unreasonable expectations and entry level pay.
Arg correction. Actually the video is misleading. The "sputter" and flameout in the video just under 2 minutes of flight is normal staging, the first stage separating and the second stage igniting - you can even see the second stage continuing on. The video has nothing to do with the accident.
According to the official press release, the accident has occurred at 497 second of flight, with the third stage having an "anomaly" at 161km of altitude. The satellite and the upper stage practically completely burned up in the atmosphere.
That was obviously not 3rd stage but the 1st one which failed. The incident occurred just under 2 minutes of flight, right about the time where the first stage burns out and the second stage ignites. The article mentions that the satellite with the third stage would have crashed somewhere in Siberia, not that the 3rd stage has malfunctioned. The 3rd stage motor is the one that provides the final boost and orbital corrections and probably didn't even ignite yet in this accident.
That "90fps needed for no motion sickness" is just a big red herring. Sorry. We had VR for much longer than Oculus exists and there were ways to have usable VR even at 30fps. Sure, 90 looks better, but things can be done with less. Moreover, the motion sickness is primarily function of content, not framerate - you can have even 120fps and you will still get sick if the camera is wildy gyrating around.
And if nobody will have hardware that will be actually capable of hitting those 90fps at those resolutions that we won't have 5 minute gimmicks but only demos that companies will show off at tradeshows on hardware that mere mortals can't afford to buy. I am not sure that that is any less gimmicky...
Let's put this stupid never ending meme to rest, shall we?
The 9500 Kickstarter backers got their DK1 for their money. Including me. I was one of the first ones. They have delivered what they have promised in the campaign, nothing less, nothing more.
Or do you really think that the development beyond the DK1 and the massive hiring that included people like Abrash and Carmack that has brought Oculus from a 3 person startup to a large company acquired by Facebook was actually financed by the Kickstarter money? You need to get real, those Kickstarter 2.5 millions were long gone by then. Yes, the Kickstarter got it off the ground but everything else was paid by venture capital - and Facebook. So the Kickstarter backers really don't have any reason to not be happy about what became of their money nor does Oculus have anything to report to them anymore.
Now whether the direction in which Oculus is going meshes with the ideals about "democratization of VR", cheap VR that everyone could enjoy etc. that is another discussion. Personally, I am not happy with what they are doing, because instead of making the VR cheap and easily accessible it is going to be a toy for the rich kids only. The minimal PC requirements are actually the least of the issues, even though it is something that the lay person is most likely to deal with.
The much worse problem is that their SDK is becoming more and more proprietary, closed binary blob that requires your 3D engine to pretty much build everything around it, otherwise it is a nightmare to integrate. It is pretty telling that even Unreal Engine 4 *still* doesn't have a good DK2 integration, year after DK2 is out - it is that complex and that intrusive to do and their heavily threaded and pipelined engine is not a good fit for the expectations the SDK has. I am afraid that with these crazy requirements the adoption by actual content producers - game studios, application developers, etc. is going to be minimal.
The massive effort required to re-engineer the games (both the engines and to adapt the content) to support the Rift will not pay off when only a small niche will be able to actually use it. Heck, current games are barely able to consistently hit 60fps at 1080p, here we are asking double the resolution and, should we follow the recommendations from Oculus, we should be targeting 90-120fps. Good luck with that... Either the Oculus games will have massively reduced visual quality compared to the "normal" versions or will require insane hardware. Most likely both. I just don't see the game studios jumping on this bandwagon on a massive scale. I am afraid that what will most likely happen is that it ends up as yet another obscure and poorly supported gizmo, like the Razer Hydra, things like the Vuzix glasses, various shutter 3D glasses that were sold for PC over the years etc. A pity and a massively wasted opportunity, really.
That they have stopped the Linux and Mac support - I think it was obvious that this was only a matter of time. The writing was on the wall ever since they have released the DK2 with the two-part SDK architecture (closed source binary blob runtime and an open library to talk to it). The Linux and Mac SDKs were much delayed and when the SDK finally arrived, it wasn't full featured - e.g. the "direct" mode has never arrived to Linux (even though it is possible to make something like that work and probably with fewer bugs and glitches than the horrid driver hack they do on Windows).
The Mac SDK may eventually come back, but I am not having much hope - most Mac users have laptops and most laptops with discrete GPUs actually don't render directly to the external output but into a framebuffer of the integrated ("slow") GPU which then sends the image out. Which is the architecture that is explicitly not supported by Oculus. The Linux SDK is very likely dead for good, even though they won't say so. It just doesn't make commercial sense to go there, the market is small. So it will be likely languishing in limbo forev
Generic Javascript/PHP/Java/C# "trained monkey" coders are a dime a dozen and most likely available for less than you are asking for, especially if the work can be done by someone overseas with 1/10th of your living expenses.
On the other hand, if you are skilled in mathematics, computer graphics (algorithms, not Photoshop!), statistics or artificial intelligence, you are going to be in high demand. These are skills that are a lot harder to find and command a good price. The downside is that you have to spend a lot of time by learning. That doesn't mean you must spend years and top $$$ on a university degree (it does help, though!), but you will need to invest some significant time there.
Basically, it is pretty much the same story as basic machinists working on lathes being replaced by CNC operators and robots - you need to bring some added value to the business. The low end - the basic programming - is pretty much a commodity today, especially for large companies who can afford to offshore/outsource. You are nobody special because you know Javascript or C# today.
The other option is to work local - there will be always a market for small businesses/consultants catering to mom & pop businesses that need a website built, accounting or customer management system created, perhaps some reporting beyond what Excel can do. Those are too small fish for the big guys like SAP to go after and too small to be able to afford a team in India/Eastern Europe to manage their systems, not to mention that it would be really impractical. It is a large market - not everyone has to (and can) work for Facebook, Google or Microsoft today.
If you are able to be replaced by someone who barely knows the language, doesn't know the country, has to live out of a suitcase, well, mate, it is your fault, not theirs.
From what I can piece together, they want to replace the CNC system, which has been around for over 60 years, with a new setup. I sceptical as to why as
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
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...
The fact that this practice is widespread in the Linux world originates from the usage of insecure FTP mirrors run by volunteer admins. There it's possible for a mirror to get hacked independently of the origin web page.
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.
Slashdot Mirror
You seem to think that's a bad thing. It's the purest form of market research there is - not only did you get people interested in your thing, but you got them to put money behind it.
I don't have a problem with market research, but then please mark it as such. This is just dishonest and it does a disservice to everyone else by giving the impression to the general public that an actual product can be made for that ridiculous budget and timeline. Then campaigns with genuine products and realistic budgets will never get financed because people take this sort of thing as standard and realistic. At least these guys have some real prototypes and aren't just selling hot air there.
Also, doing a "market research" Kickstarter as a mean to convince VCs and/or angel investors to give you funds is pretty much a suicidal gamble - now you have 20k people who have put down their money for your gizmo and you still have no real funding to produce it. And you may not be able to get it - 20k people wanting a $200 gizmo is not that much interesting from the investment point of view by itself (that's just $4million) and it is pretty much the worst project size possible when it comes to manufacturing - too big to build in a garage and not big enough to actually give you access to the manufacturing facilities you will need. Also, few projects reach that sort of size on Kickstarter, most get much less. So unless it is something really groundbreaking, truly visionary that will make the VCs go gaga and pull out the checkbooks, you will have trouble attracting investment (heck,it is a stupid touchpad like the one Apple sells already ...). However, you are stuck with the commitment to build and ship those 20k units already ...
I more inclined to say that these people are an idealistic startup trying to bring their first project to the market, with no real past experience doing so. The completely BS time line shows that as well - they budgeted one month only for tooling and production - just the injection molding tooling production takes several weeks for every iteration (and costs thousands of $$$ a pop) and it is pretty much granted they will not get it right the first time.
So my bet is that this will ship a year or two late, over budget and probably drive the company to bancruptcy in the process.
More like the gizmo will never get made unless they have money from elsewhere and are using Kickstarter only as a marketing campaign. The $60k they are asking for won't cover even the materials. Just the mandatory FCC/CE/UL certifications will take a third of their budget, assuming that they actually pass on the first try.
This article gives a good breakdown of how much it does actually cost to build and ship a hardware product:
https://medium.com/bolt-blog/w...
Yeah, right. So it only took a decade to get serious OpenSSL bugs discovered and fixed - despite the project being open from the start. And that is most likely an order of magnitude smaller project than something like even moderately complex CPU core, written in a language that many more people are familiar with.
Yes, if it wasn't open, the bugs probably wouldn't have been found, but that's speculation - we simply will never know. If you hope to find a "backdoor" (which could be simply so subtle as intentionally weakening some crypto support instructions or random number generator if some flags are set) in a ton of Verilog/VHDL code where you need to understand both the hardware *and* the crypto, you are seriously delusional. Even the vendors themselves have only a fairly small team of people that actually understands this type of code. It is so ultra specialized niche. You will probably not see the weakness even if you were looking straight at it unless you are a specialist in exactly this domain and familiar with the implementation.
Anyhow, it is a moot point - the mainstream CPUs are never going to be "open sourced", because it is the core intellectual property of these companies.
Sorry, but you need to get real here.
First, these FPGAs don't quite have enough power to run a design comparable with an Intel/AMD CPU as most people know them. So this effort is pretty much irrelevant for dealing with backdoors in mainstream hardware. Their goals are quite different, mostly to do with on the fly reconfigurable computation - something that is hard or impossible to do if you cannot generate the bitstream using your tools.
Second, even if you had a fully open sourced design somehow, how many people do you think would be able to actually understand it to the degree that they would be able to verify that there is no backdoor? Or even verify that the design is complete and the backdoor part is not withheld? It is not possible to build these without the in-house tools companies like AMD or Intel use (they don't use off-the-shelf FPGA tools, those are too small/slow to handle these large CPUs). Most people wouldn't be able to understand even the Verilog/VHDL for the tiny microcontroler implemented in the article.
I am all for openness and open sourcing as much as possible but that is not a panacea and in cases such as these it would only give false sense of security.
Except it is regulated as one. In fact, most countries don't make any distinction whether the RC model is fixed wing, heli, multirotor or whatever. Once it is unmanned and falls into the "model" category, it is regulated the same.
That most owners don't know that there are *gasp* laws and rules that apply to their toys is not the problem with the laws, unfortunately.
"Drones" - aka small multirotor helis - are regulated as RC model aircraft in most countries already. Not sure where you are, but perhaps make sure that you actually know what laws are on the books already before calling for more regulation.
The problem is not lack of regulation but the fact that 99.9% of the owners of these things have no clue about the rules that actually apply to their hobbies. RC model flyers have been rarely caught doing similar stupidities before because:
a) it is hard to do with a fast moving fixed wing plane,
b) traditional model helis are tricky to fly and very expensive, few people would risk their toy like this after they have finally mastered it,
c) few RC models were computerized to the degree that they essentially "fly themselves", including GPS waypoints and what not. RC flying was always about the flying skills, not taking videos for Youtube.
d) the enforcement was caught flatfooted, the few RC model owners around have newer posed problems but now every yahoo has a gizmo that requires no skills to fly and don't give a shit about any rules (if they are even aware of them).
As I see it, unless the police is allowed to take these things out by force, then things aren't going to change. Tracking down an owner of a drone hoovering somewhere high in the air autonomously is pretty much impossible unless you are very lucky. They don't need to emit radio signal continuously, the gizmo can navigate by GPS so unless you literally run into a guy with the controller you will not find him.
And as regulation is concerned - that could actually use to be relaxed quite a bit. E.g. in most of Europe if you want to record video using an RC plane/heli/drone for commercial purposes, the rules are very draconian - you need essentially a full private pilot license as if you were flying a full sized plane, you must always have a spotter next to you, are not allowed to fly beyond line of sight, etc. And this applies regardless of whether you are recording over a crowd of people (which requires additional permits) or only some fields for a local farmer ...
Considering that even an app like HTC's "Kids Zone" (a vendor preinstalled, unremovable app with activities for kids to keep them occupied) requires permissions like: "In-app purchases", "Phone calls", "Contacts", "Calendar", etc - aka everything that could run up an enormous bill or exfiltrate your monetizable personal information while your offspring are playing - it doesn't surprise me at all that someone tries to scam the advertising douchebags too ...
Today's smartphone is a device for siphoning personal data and money, whether the owner's or the advertisers, nothing more. Any other functionality that it happens to have is starting to become only a side effect and coincidence (even more if the functionality is actually useful). It is starting to be so bad that soon we will use the smartphones only to access Internet on the go and have a second device to actually perform calls, text and keep any other personal info on.
It is more likely that none of them will be dominant, because when you have 2-3 players that refuse to talk to each other to even establish common APIs to handle the basic tasks like tracking or renderer integration, many game studios will just say "Meh, screw it". And they will remain sitting on the fence instead of pouring money into a niche product that requires very significant technological and content investment. And with little reasonable content beyond bite-sized demos nobody will buy the HMDs neither. That's the real issue.
And yeah, of course, the rush to claim possible walled gardens so that they can play Apple and extract toll from both developers and users - Valve with Steam, Oculus with their Market or what it that thing called, Samsung has its own, Sony for sure is preparing its own for their PS4 platform, Google with Google Play, etc.
Without at least some sort of standardization and simplifying the integration of the HMDs into graphic engines this is a nonstarter and could bury the technology before it even had a change to take off. The direction e.g. Oculus is going in is pretty terrible - every release of their SDK is more closed than the previous one, more invasive and complicated integration-vise. Guess why only is it that only Unity and Unreal have somewhat usable Rift integration - and good luck making things actually work with Unreal. It feels very much like unfinished alpha with tons of problems and issues, despite Oculus engineers actually working on it.
I have told John Carmack that they have blown a huge chance to establish a defacto API standard for interfacing to these HMDs with their SDK. And that was before it was announced that they are abandoning the non-Windows versions and taking the code completely proprietary.
None of which actually addresses any of the needs these companies have.
Even COBOL is standardized - and that is about as relevant as X3D or WebGL to supporting a Rift-like HMD or some sort of interaction device that isn't a keyboard/mouse.
I am sorry, but this is BS. This charitable idea unfortunately rests on the false premise that Internet works the same way as press does (and thus one can control and censor it using the same means).
This is not about kids being drunk and getting a photo of them sleeping in a garbage bin posted on some news website - that sort of stuff will pretty much disappear after few years by itself, because it is expensive to maintain all this crap accessible and its publicity value has been zero few hours after it was published already
The larger problem is that a lot of information that is public in common interest gets suppressed - e.g. why a crook should have the information about their crime removed only because they feel like it? E.g. here in Europe it is common that for many jobs you have to bring a copy of your criminal record showing that you haven't been convicted. Expunging something from there typically takes an act of court and many years (typically only after 10-20 years after the sentence has been completed you can ask the court to expunge it). If a kid was stupid and landed in jail, having their crime removed from Google will help them exactly zilch. Then you have people who want to have information about them suppressed for vanity or political reasons - that is straight censorship and there is little reason why that should be allowed.
The search engines shouldn't be (and cannot be) the ones shouldering the burden of whether some of these requests should or shouldn't be allowed. They don't have the resources to judge whether or not the request is valid and they have a conflict of interest as well - it is pretty much to be expected that they will simply remove stuff by default in order to reduce the hassle and avoid having to go through courts (why would they - it would be only a net loss for them either way, even if they won it). So in the most cases the public interest just flies out of the window. .
Finally, this approach of how to achieve the goals of removing the information is completely bogus - basically it is like court-mandated sticking head in the sand so that you don't see the problem. That you stick the head in the sand doesn't mean that the problem ceases to exist - the fact that Google or Bing stop listing the information doesn't mean that the original website that has actually hosted the information pulls it down as well. So nothing has been actually "forgotten" and it only takes a search on something like Yandex or some other search engine that doesn't care about these requests (e.g. BBC) to uncover it again. I am pretty sure that sensation-hungry tabloids will be using this to fish out juicy dirt in the future. So what has been achieved apart from spending millions on a bogus remedy here? Andersen's Emperor's New Clothes comes to mind here - it only takes one person to yell that the emperor is naked ...
Experience writing, debugging and maintaining code.
The bucket list of having to know this and that means nothing when the programmer doesn't know how to apply it. Claiming things like the latest C++11 features (lambdas) as separating beginners from masters is just BS trying to artificially simplify the issue into something quantifiable. HR and managers love that, because it is easy to test.
I write C++ code for over 15 years now and I can't claim that I am conversant with all those new C++11 features, like lambdas or even move semantics. I didn't need or encounter them so far in production code. The first lambda I have found was only very recently in some brand new code that is explicitly written as C++11 - and had to look up what that weird syntax was about. However, I am pretty sure I will be running circles around anyone who has just drilled themselves on the C++11 specs, but never wrote anything serious in it - I have simply seen and written so much code already that I am fluent in the language, even without knowing all the obscure features. It is the same as with learning foreign languages - you can be excellent at grammar but you still won't be able to communicate until you have to speak it for a while ...
Dave from EEVBLOG is on the case already: https://www.youtube.com/watch?...
If you don't know the fellow, he is a professional EE with a wee bit of background and qualifications in these things.
And I do hope that you offer a senior developer wages as well for these sort of requirements. The OP was talking entry level job.
People requiring these sort of skills for an entry level job are the true reason for the perceived "lack of IT talent" - unreasonable expectations and entry level pay.
Arg correction. Actually the video is misleading. The "sputter" and flameout in the video just under 2 minutes of flight is normal staging, the first stage separating and the second stage igniting - you can even see the second stage continuing on. The video has nothing to do with the accident.
According to the official press release, the accident has occurred at 497 second of flight, with the third stage having an "anomaly" at 161km of altitude. The satellite and the upper stage practically completely burned up in the atmosphere.
That was obviously not 3rd stage but the 1st one which failed. The incident occurred just under 2 minutes of flight, right about the time where the first stage burns out and the second stage ignites. The article mentions that the satellite with the third stage would have crashed somewhere in Siberia, not that the 3rd stage has malfunctioned. The 3rd stage motor is the one that provides the final boost and orbital corrections and probably didn't even ignite yet in this accident.
Learn to read and use common sense, folks!
That "90fps needed for no motion sickness" is just a big red herring. Sorry. We had VR for much longer than Oculus exists and there were ways to have usable VR even at 30fps. Sure, 90 looks better, but things can be done with less. Moreover, the motion sickness is primarily function of content, not framerate - you can have even 120fps and you will still get sick if the camera is wildy gyrating around.
And if nobody will have hardware that will be actually capable of hitting those 90fps at those resolutions that we won't have 5 minute gimmicks but only demos that companies will show off at tradeshows on hardware that mere mortals can't afford to buy. I am not sure that that is any less gimmicky ...
Let's put this stupid never ending meme to rest, shall we?
The 9500 Kickstarter backers got their DK1 for their money. Including me. I was one of the first ones. They have delivered what they have promised in the campaign, nothing less, nothing more.
Or do you really think that the development beyond the DK1 and the massive hiring that included people like Abrash and Carmack that has brought Oculus from a 3 person startup to a large company acquired by Facebook was actually financed by the Kickstarter money? You need to get real, those Kickstarter 2.5 millions were long gone by then. Yes, the Kickstarter got it off the ground but everything else was paid by venture capital - and Facebook. So the Kickstarter backers really don't have any reason to not be happy about what became of their money nor does Oculus have anything to report to them anymore.
Now whether the direction in which Oculus is going meshes with the ideals about "democratization of VR", cheap VR that everyone could enjoy etc. that is another discussion. Personally, I am not happy with what they are doing, because instead of making the VR cheap and easily accessible it is going to be a toy for the rich kids only. The minimal PC requirements are actually the least of the issues, even though it is something that the lay person is most likely to deal with.
The much worse problem is that their SDK is becoming more and more proprietary, closed binary blob that requires your 3D engine to pretty much build everything around it, otherwise it is a nightmare to integrate. It is pretty telling that even Unreal Engine 4 *still* doesn't have a good DK2 integration, year after DK2 is out - it is that complex and that intrusive to do and their heavily threaded and pipelined engine is not a good fit for the expectations the SDK has. I am afraid that with these crazy requirements the adoption by actual content producers - game studios, application developers, etc. is going to be minimal.
The massive effort required to re-engineer the games (both the engines and to adapt the content) to support the Rift will not pay off when only a small niche will be able to actually use it. Heck, current games are barely able to consistently hit 60fps at 1080p, here we are asking double the resolution and, should we follow the recommendations from Oculus, we should be targeting 90-120fps. Good luck with that ... Either the Oculus games will have massively reduced visual quality compared to the "normal" versions or will require insane hardware. Most likely both. I just don't see the game studios jumping on this bandwagon on a massive scale. I am afraid that what will most likely happen is that it ends up as yet another obscure and poorly supported gizmo, like the Razer Hydra, things like the Vuzix glasses, various shutter 3D glasses that were sold for PC over the years etc. A pity and a massively wasted opportunity, really.
That they have stopped the Linux and Mac support - I think it was obvious that this was only a matter of time. The writing was on the wall ever since they have released the DK2 with the two-part SDK architecture (closed source binary blob runtime and an open library to talk to it). The Linux and Mac SDKs were much delayed and when the SDK finally arrived, it wasn't full featured - e.g. the "direct" mode has never arrived to Linux (even though it is possible to make something like that work and probably with fewer bugs and glitches than the horrid driver hack they do on Windows).
The Mac SDK may eventually come back, but I am not having much hope - most Mac users have laptops and most laptops with discrete GPUs actually don't render directly to the external output but into a framebuffer of the integrated ("slow") GPU which then sends the image out. Which is the architecture that is explicitly not supported by Oculus. The Linux SDK is very likely dead for good, even though they won't say so. It just doesn't make commercial sense to go there, the market is small. So it will be likely languishing in limbo forev
Even better, specialize.
Generic Javascript/PHP/Java/C# "trained monkey" coders are a dime a dozen and most likely available for less than you are asking for, especially if the work can be done by someone overseas with 1/10th of your living expenses.
On the other hand, if you are skilled in mathematics, computer graphics (algorithms, not Photoshop!), statistics or artificial intelligence, you are going to be in high demand. These are skills that are a lot harder to find and command a good price. The downside is that you have to spend a lot of time by learning. That doesn't mean you must spend years and top $$$ on a university degree (it does help, though!), but you will need to invest some significant time there.
Basically, it is pretty much the same story as basic machinists working on lathes being replaced by CNC operators and robots - you need to bring some added value to the business. The low end - the basic programming - is pretty much a commodity today, especially for large companies who can afford to offshore/outsource. You are nobody special because you know Javascript or C# today.
The other option is to work local - there will be always a market for small businesses/consultants catering to mom & pop businesses that need a website built, accounting or customer management system created, perhaps some reporting beyond what Excel can do. Those are too small fish for the big guys like SAP to go after and too small to be able to afford a team in India/Eastern Europe to manage their systems, not to mention that it would be really impractical. It is a large market - not everyone has to (and can) work for Facebook, Google or Microsoft today.
If you are able to be replaced by someone who barely knows the language, doesn't know the country, has to live out of a suitcase, well, mate, it is your fault, not theirs.
From what I can piece together, they want to replace the CNC system, which has been around for over 60 years, with a new setup. I sceptical as to why as
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
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 ...
The fact that this practice is widespread in the Linux world originates from the usage of insecure FTP mirrors run by volunteer admins. There it's possible for a mirror to get hacked independently of the origin web page.
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.