3 ms·

Depends on what its for. I wouldn't mind any unsafe non network connected device, if they really want to hack my programmable thermometer with no network access

Depends on what its for. I wouldn't mind any unsafe non network connected device, if they really want to hack my programmable thermometer with no network access, or my wired keyboard, they can be my guest! If my server is on intranet, I don't have any fears either, without memory safety hacks can happen, but spectre and meltdown haven't been seen in the wild. For OS and browsers though, I agree completely if infrastructure as long as its not always connected to the open internet, it doesn't seem to be much of a threat, and even though I don't care about memory safety, the performance of rust tools impresses me! I wish people talked about performance of rust more than its memory safety, I don't care as much about that, but everything being faster? Who wouldn't want that? I made this thread a few days ago. https://news.ycombinator.com/item?id=29456115 https://news.ycombinator.com/item?id=29456115

eru 5y ago
I remember quite a few posts on the Firefox blog about how Rust allowed them to write faster programs. See eg https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-rust/ https://hacks.mozilla.org/2019/02/rewriting-a-browser-compon...
- GhettoComputers 5y ago
  They could write better performing programs, as well as do it faster than C, the thread I linked to has GNU coreutils in rust for instance, it has excellent performance and every CLI tool I used is very fast, much faster. This is another example if you are interested. https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep
roca 5y ago
The thing is, code tends to be reused across projects. If you write a library or a utility program and it's full of holes, that's only OK if you're sure it will always be used in a "safe" context with no untrusted input. Who really wants to commit to that?
- eru 5y ago
  Also, if you have a large enough corpus of random enough input, you are bound to hit similar bad cases as if you had some malicious input. More pithy: Hanlon's razor says 'never attribute to malice that which is adequately explained by stupidity.', but the reverse is also true: enough stupidity or just randomness can look like malice.
- GhettoComputers 5y ago
  Any non networked devices would be easy to commit to. Nobody will force you to use such a library if you are worried about holes. I think internet connected software like OS and browser matters, but I not only don't care if its in these devices, I WANT it to be easy to hack to run custom software. I am glad that the PSP had holes, I am happy camera firmware had holes, and I am also glad that android had holes, I never been hacked on it once, but I sure did hack it myself! The threat of most security issues is vastly overblown, spectre and meltdown don't exist in the wild, but they crippled all CPUs just in case. Security at what cost? I disabled it, I have no need to make my computer slower for a virus that will never affect me, I "wear" an updated browser. ;)
zionic 5y ago
I disagree because that still drives demand for C/C++ developers and tool chains. Nothing new should be written in these unsafe languages.
- GhettoComputers 5y ago
  I'd rather have choice rather than a draconian ban.

eru 5y ago

I remember quite a few posts on the Firefox blog about how Rust allowed them to write faster programs. See eg https://hacks.mozilla.org/2019/02/rewriting-a-browser-component-in-rust/ https://hacks.mozilla.org/2019/02/rewriting-a-browser-compon...

GhettoComputers 5y ago
They could write better performing programs, as well as do it faster than C, the thread I linked to has GNU coreutils in rust for instance, it has excellent performance and every CLI tool I used is very fast, much faster. This is another example if you are interested. https://github.com/BurntSushi/ripgrep https://github.com/BurntSushi/ripgrep

roca 5y ago

The thing is, code tends to be reused across projects. If you write a library or a utility program and it's full of holes, that's only OK if you're sure it will always be used in a "safe" context with no untrusted input. Who really wants to commit to that?

eru 5y ago
Also, if you have a large enough corpus of random enough input, you are bound to hit similar bad cases as if you had some malicious input. More pithy: Hanlon's razor says 'never attribute to malice that which is adequately explained by stupidity.', but the reverse is also true: enough stupidity or just randomness can look like malice.
GhettoComputers 5y ago
Any non networked devices would be easy to commit to. Nobody will force you to use such a library if you are worried about holes. I think internet connected software like OS and browser matters, but I not only don't care if its in these devices, I WANT it to be easy to hack to run custom software. I am glad that the PSP had holes, I am happy camera firmware had holes, and I am also glad that android had holes, I never been hacked on it once, but I sure did hack it myself! The threat of most security issues is vastly overblown, spectre and meltdown don't exist in the wild, but they crippled all CPUs just in case. Security at what cost? I disabled it, I have no need to make my computer slower for a virus that will never affect me, I "wear" an updated browser. ;)

zionic 5y ago

I disagree because that still drives demand for C/C++ developers and tool chains. Nothing new should be written in these unsafe languages.

GhettoComputers 5y ago
I'd rather have choice rather than a draconian ban.