Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Trust the World's Fastest VPN with Your Internet Security & Freedom - A Lifetime Subscription of PureVPN at 88% off. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×

Comment Re:If Apple built a Hololens we'd never hear about (Score 1) 102

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.

Comment Re:Until (Score 1) 374

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.

Comment Re:Higher profit margins? (Score 2) 40

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.

Comment Higher profit margins? (Score 1) 40

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.

Comment Re: Learn C for advanced security, not for basics (Score 1) 374

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.

Comment Re:Until (Score 1) 374

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.

Comment And yet no link to the actual essay (Score 3, Insightful) 186

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?

Comment Re: Learn C for advanced security, not for basics (Score 1) 374

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.

Comment Re:The usual bollocks (Score 1) 309

$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.

Comment Re:Until (Score 1) 374

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.

Slashdot Top Deals

We are not a loved organization, but we are a respected one. -- John Fisher