I don't need to give an analysis. This is a comment forum, not a funded research paper. It's simply a ludicrous figure as any observer of large scale projects could tell you. Go look up what Boston's big dig cost by way of example - it's estimated cost vs its final cost.
Their product idea is to be a taxi operator but without abiding by the safeguards, and regulations that protect passengers or even the drivers themselves - police background checks, vehicle safety checks, adequate insurance, employee rights etc. Unsurprisingly this has lead to all kinds of adverse consequences for the company.
If they're still burning through money after all that then there is something seriously fucked up with their product idea and their business model. I won't miss them if they go under. More likely they'll try to do an IPO and pass the buck onto some other saps. The founds and 1st round of investors will take the money and run.
I don't really buy the argument that it would be cheaper to go to Mars from the Moon. Any manned Mars mission would likely to be assembled in stages in orbit of the Earth. Much cheaper and less risk than sending those same stages to the moon and assembling them there.
There are other detailed estimates [spaceelevatorwiki.com] for a space elevator that are around $10 billion. The people who throw around $1 trillion are trying to pick a number so big it prevents people from considering the feasibility. You definitely won't find any detailed breakdown that leads to something so insane.
And people saying $10 billion aren't being serious either. Not even remotely.
Scientists don't even know for sure they've made hydrogen metal, have no idea what its properties are, can only create a microscopic amount and can only hold it in a stable state using a diamond anvil cell at extreme pressures. So how does that herald a new age in consumer gadgets?
Are we talking about fully autonomous vehicles where the passenger has virtually no control over the car's choices? Maybe there is a stop button or similar for emergencies but little else?
Or are we talking about a semi-autonomous vehicle where the driver is expected to be alert, unimpaired, overseeing the vehicle's progress and capable of intervening for any reason?
Because for the latter it seems like there will be plenty of blame to spread around if the car does something stupid that the human overseer could have prevented had they been fulfilling their job. And if they weren't doing their job was that because they were drunk off their ass, playing on their phone or otherwise doing something that means they share blame for an accident?
Not really. They're both projecting 3d images in front of a person's face. Both require motion tracking of some kind to reorient the image as a person's head moves. It's just that VR headsets so far have used IR lights, dead reckoning and other methods to do the tracking while hololens went full head-on with image processing. It didn't need to be that expensive just because it was AR.
Regardless, it was stillborn because it was prohibitively expensve. And not very good for all the tech either.
Just like planets, species etc. It comes from a desire to categorize things even though on occasions things cannot be categorized or the criteria for doing it doesn't work.
The first version was so expensive and technically flawed that it's hard to see who it was targeted for. The Oculus Rift dev kits cost $350, the HoloLens cost $3000. Regardless of the technical complexity that accounted for that price difference, it still doomed the headset.
"Rust generates code which is no different in performance than C or C++ code written correctly. ". I hate seeing typos the split second after I hit submit.
Rust generates code which is different in performance than C or C++ code written correctly.
Most of Rust's safety is done at compile time and compiles away to nothing or is in the design of the apis that check you're not doing something dumb when you call them. So if you tried to copy a slice of a buffer in excess of a buffer it would panic but it wouldn't impact on performance any more than C code doing the same.
Obviously you can forego safety in C but that's the point Rust is trying to address - safety without penalising performance. That makes it perfect for IoT and its why the assumption that C can rest cosy because of IoT is a bad one. If I were writing any code for IoT I wouldn't choose C unless I had no choice. I might choose C++ assuming I could be sure of using only C++11/14 and nothing else. But I would choose Rust in preference to either of them.
Some straightforward and simple to back up all the personal and private data into a file that can be offloaded, factory reset the phone, walk through with the clean phone, and "unpack" it on the other side.
Samsung manage it. If you look at the firmware that Samsung puts on the premium devices vs the low end, it's virtually identical. They've managed to increase their reach with a relatively minor additional effort. I suspect Samsung are also pretty glad that they have all those sales to sustain them when they suffer a flop such as their recent battery scandal.
Surely any profit margins are good, especially if the budget handsets introduce people to your brand and allows you to spread the risk across a range of models instead of putting all the eggs in one basket.
I realise that's in theory. HTC have kind of fucked up in recent years and it's less to do with their hardware but how they've marketed them.
The firm does have leadership though. They just divvied the responsibilities of CEO out amongst the board. Perhaps it works better that way because decisions can still be made, but they're made in a collective fashion. On top of that they avoid the expense of having a CEO - salary, car, expenses etc.
I'm sure learning C is essential. It doesn't mean it's the only language and as I said if Rust were a choice I'd have to have a strong reason not to use it. And you're not paying attention to what's going on in IoT if you think everything is bare metal these days. The likes of Samsung, Google, Amazon et al are building software stacks over a kernel, so compliant devices are separated from the metal by a substantial amount of layers. And even if they weren't, Rust is available for some microcontrollers and there is no reason to think that won't grow over time.
Yeah C is there and I haven't said any different. But it's a horribly dangerous language to code IoT and I expect that will reflect in the languages people choose to develop such devices over time.
Heartbleed was a problem with C because C allowed the code to walk straight right off a buffer and send the contents to the client. If you tried that in Rust you would get a runtime panic.
That neither link actually leads to the essay. The Verge link is basically regurgitated clickbait summary of the Nature link. Utterly redundant in and of itself.
The Nature article while more informative only provides a handful of selective quotes from the essay but still no link. Instead it frames the essay in the context of Churchill's interest in science. How about an actual link to the actual essay?
Where did the "we're talking kernel level here" nonsense arise from? This is a thread about a resurgence of C for programming IoT devices. This may surprise you but IoT devices do not implement their functionality in the kernel. Either the board is a microcontroller of some sort and has no kernel, or the board ships with an SDK consisting of a kernel and the developer writes a userland process on top which to all intents and purposes behaves as you may expect with access to files, sockets, memory etc.
Either way Rust is a viable option providing the architecture is supported. Rust relies on LLVM to generate machine code so if LLVM supports an architecture then so potentially does Rust. It already supports a lot of architectures ARM, MIPs, x86 on Windows, Linux, OS X and a bunch of microcontrollers.
I'd also point out that at least one kernel HAS been written in Rust. I wouldn't seriously propose using Redox in its existing form, but it kind of pisses on the argument that even if we were talking about the kernel (and we're not) that somehow Rust is ruled out there either.
$80 to replace a $15 battery is not much of a justification for sealing a battery in. More to the point, Apple's service is expensive and contains all kinds of odious language to deter people from using it - the battery must hold less than 80% of its original charge, the phone must be backed up and unlocked before sending it in, you lose your phone for 3-5 days, you might not even get YOUR phone back at the end of all this.
There is no way this is an acceptable alternative to just buying a battery and swapping it in. Some people might even carry a spare when they're travelling.
It is a very deliberate ploy by Apple to offer a replacement service but make it so expensive and inconvenient to use that they can maximize the chances that people just buy a new phone instead. As I said originally Apple aren't the only practitioners of this scummy practice but they pioneered it.
The problem is not that C++ has some subset which is safe, but that it everything else is unsafe and neither the compiler, nor your code reviewers are necessarily going to save you. C and C++ suffer bugs that COULD and SHOULD be caught by the compiler but aren't.
You can code review this subset of C++ til you're blue in the face but the next project over to you may not. Even some of the most reviewed and widespread code in existence has suffered serious errors that were the fault of the language. Look at the Heartbleed bug as one example. And it's extremely clear that when we're talking of software that powers IoT devices, or cars, or hydraulic presses in factories, or X-Ray machines or anything else which has a critical function that even ONE screwup could have catastrophic consequences. Even if your software has less critical failure modes, it's still a pain in the ass if it crashes, leaks, suffers mysterious race conditions or is exploitable because the code has to enforce its own buffer checks.
That's why Rust makes such a good fit for systems software. It shuts down an entire swath of potential programming errors before they can even happen. In the normal course of programming there are no pointers, or null pointers, or explicit memory allocation/deallocation. Things like strings and arrays are intrinsic types and are enforced against their length. Threads that share data MUST protect them with locks or mutexes or have ownership. Things that break in C/C++ at runtime are stopped by the compiler.
C and C++ aren't going anywhere I'm sure, but neither are they defensible by saying if you know the exact subset which is safe that it absolves all the stuff which isn't in that subset.
That's great for you. It doesn't alter the point in the slightest. Even if there is a subset of modern C++ which (when used with discipline and years of knowledge) can avoid problems prevalent in C and C++ doesn't mean those problems aren't prevalent. They are.
Slashdot Mirror
I don't need to give an analysis. This is a comment forum, not a funded research paper. It's simply a ludicrous figure as any observer of large scale projects could tell you. Go look up what Boston's big dig cost by way of example - it's estimated cost vs its final cost.
If they're still burning through money after all that then there is something seriously fucked up with their product idea and their business model. I won't miss them if they go under. More likely they'll try to do an IPO and pass the buck onto some other saps. The founds and 1st round of investors will take the money and run.
Their research is not serious at all if it comes to such a laughably low figure.
I don't really buy the argument that it would be cheaper to go to Mars from the Moon. Any manned Mars mission would likely to be assembled in stages in orbit of the Earth. Much cheaper and less risk than sending those same stages to the moon and assembling them there.
There are other detailed estimates [spaceelevatorwiki.com] for a space elevator that are around $10 billion. The people who throw around $1 trillion are trying to pick a number so big it prevents people from considering the feasibility. You definitely won't find any detailed breakdown that leads to something so insane.
And people saying $10 billion aren't being serious either. Not even remotely.
Scientists don't even know for sure they've made hydrogen metal, have no idea what its properties are, can only create a microscopic amount and can only hold it in a stable state using a diamond anvil cell at extreme pressures. So how does that herald a new age in consumer gadgets?
Or are we talking about a semi-autonomous vehicle where the driver is expected to be alert, unimpaired, overseeing the vehicle's progress and capable of intervening for any reason?
Because for the latter it seems like there will be plenty of blame to spread around if the car does something stupid that the human overseer could have prevented had they been fulfilling their job. And if they weren't doing their job was that because they were drunk off their ass, playing on their phone or otherwise doing something that means they share blame for an accident?
It has been doing the rounds since at least 2012. It was news back then. It's not news now.
Regardless, it was stillborn because it was prohibitively expensve. And not very good for all the tech either.
Just like planets, species etc. It comes from a desire to categorize things even though on occasions things cannot be categorized or the criteria for doing it doesn't work.
The first version was so expensive and technically flawed that it's hard to see who it was targeted for. The Oculus Rift dev kits cost $350, the HoloLens cost $3000. Regardless of the technical complexity that accounted for that price difference, it still doomed the headset.
"Rust generates code which is no different in performance than C or C++ code written correctly. ". I hate seeing typos the split second after I hit submit.
Most of Rust's safety is done at compile time and compiles away to nothing or is in the design of the apis that check you're not doing something dumb when you call them. So if you tried to copy a slice of a buffer in excess of a buffer it would panic but it wouldn't impact on performance any more than C code doing the same.
Obviously you can forego safety in C but that's the point Rust is trying to address - safety without penalising performance. That makes it perfect for IoT and its why the assumption that C can rest cosy because of IoT is a bad one. If I were writing any code for IoT I wouldn't choose C unless I had no choice. I might choose C++ assuming I could be sure of using only C++11/14 and nothing else. But I would choose Rust in preference to either of them.
If someone finds a viable way to recycle these things, then it still only viable because there are a lot of them concentrated in a single place.
Some straightforward and simple to back up all the personal and private data into a file that can be offloaded, factory reset the phone, walk through with the clean phone, and "unpack" it on the other side.
Samsung manage it. If you look at the firmware that Samsung puts on the premium devices vs the low end, it's virtually identical. They've managed to increase their reach with a relatively minor additional effort. I suspect Samsung are also pretty glad that they have all those sales to sustain them when they suffer a flop such as their recent battery scandal.
I realise that's in theory. HTC have kind of fucked up in recent years and it's less to do with their hardware but how they've marketed them.
The firm does have leadership though. They just divvied the responsibilities of CEO out amongst the board. Perhaps it works better that way because decisions can still be made, but they're made in a collective fashion. On top of that they avoid the expense of having a CEO - salary, car, expenses etc.
Yeah C is there and I haven't said any different. But it's a horribly dangerous language to code IoT and I expect that will reflect in the languages people choose to develop such devices over time.
Heartbleed was a problem with C because C allowed the code to walk straight right off a buffer and send the contents to the client. If you tried that in Rust you would get a runtime panic.
The Nature article while more informative only provides a handful of selective quotes from the essay but still no link. Instead it frames the essay in the context of Churchill's interest in science. How about an actual link to the actual essay?
Either way Rust is a viable option providing the architecture is supported. Rust relies on LLVM to generate machine code so if LLVM supports an architecture then so potentially does Rust. It already supports a lot of architectures ARM, MIPs, x86 on Windows, Linux, OS X and a bunch of microcontrollers.
I'd also point out that at least one kernel HAS been written in Rust. I wouldn't seriously propose using Redox in its existing form, but it kind of pisses on the argument that even if we were talking about the kernel (and we're not) that somehow Rust is ruled out there either.
There is no way this is an acceptable alternative to just buying a battery and swapping it in. Some people might even carry a spare when they're travelling.
It is a very deliberate ploy by Apple to offer a replacement service but make it so expensive and inconvenient to use that they can maximize the chances that people just buy a new phone instead. As I said originally Apple aren't the only practitioners of this scummy practice but they pioneered it.
You can code review this subset of C++ til you're blue in the face but the next project over to you may not. Even some of the most reviewed and widespread code in existence has suffered serious errors that were the fault of the language. Look at the Heartbleed bug as one example. And it's extremely clear that when we're talking of software that powers IoT devices, or cars, or hydraulic presses in factories, or X-Ray machines or anything else which has a critical function that even ONE screwup could have catastrophic consequences. Even if your software has less critical failure modes, it's still a pain in the ass if it crashes, leaks, suffers mysterious race conditions or is exploitable because the code has to enforce its own buffer checks.
That's why Rust makes such a good fit for systems software. It shuts down an entire swath of potential programming errors before they can even happen. In the normal course of programming there are no pointers, or null pointers, or explicit memory allocation/deallocation. Things like strings and arrays are intrinsic types and are enforced against their length. Threads that share data MUST protect them with locks or mutexes or have ownership. Things that break in C/C++ at runtime are stopped by the compiler.
C and C++ aren't going anywhere I'm sure, but neither are they defensible by saying if you know the exact subset which is safe that it absolves all the stuff which isn't in that subset.
That's great for you. It doesn't alter the point in the slightest. Even if there is a subset of modern C++ which (when used with discipline and years of knowledge) can avoid problems prevalent in C and C++ doesn't mean those problems aren't prevalent. They are.