Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. ×

Comment Re:I've switched to Vivaldi (Score 1) 225

That's not true at all. Firefox extends the Chrome extensions API in various places as needed. For example, see the "New APIs" here: https://blog.mozilla.org/addon...
Another example: Firefox has implemented a "sidebar" Webextensions API, Chrome has not. https://bugs.chromium.org/p/ch... https://bugzilla.mozilla.org/s...

Comment keeping the batteries charged may not be that hard (Score 1) 382

I have seen the mess of cables necessary to support electric trolleys in Seattle and elsewhere. With batteries, you could reduce the overhead wiring to straight streets and above bus stops,where it is cheap to install and power, allowing charging during normal operation. At stops, the bus stops for a while to take on and let off passengers, and buses have stops for a few minutes at the beginning and end of routs at terminals to allow the drivers to get up and use the facilities. All are good opportunities for high rate charging.

Comment Re:What the hell is "rust"? (Score 1) 236

Swift lacks many of Rust's key features. In particular, it doesn't ensure data-race-freedom like Rust does. You're also stuck with using reference counting for all dynamic memory management, and atomic ops for your refcounts at that. Traversing a read-only dynamic structure? Enjoy atomic addref/release all the way along.

Comment Re:99.9% perfection X 14 million lines = 14,000 fl (Score 1) 236

No-one, apart from maybe Dan Bernstein, is good enough to reliably write bug-free code. The hubris that says "I am!" is the core reason why we have such enormous security problems.

> How many lines of code is in the Rust compiler & library. How much of that must be flawed? That'll get passed on to every program that uses it.

No, that's not how it works.

A bug in the compiler only matters if it was triggered during the build that produced your binary *and* the build succeeds *and* the results pass your test suite. Unless your code is quite unlike anyone else's code, you will hit this a lot less than bugs in your own code.

A bug in Rust's standard library can affect a lot of programs, but much of Rust's standard library is written in safe Rust so gets the same safety guarantees as regular Rust code. And of course the standard library gets a lot more testing and inspection than your own Rust program.

The bigger picture is that formal verification technology is advancing so that in time, we'll be able to verify that a build worked correctly (i.e. the generated code preserves the safety properties of the Rust code), and we'll be able to write proofs for most of the unsafe parts of the Rust standard library that they also preserve safety properties.

Comment Re:Assembly language is good enough for anyone... (Score 1) 236

String and vector libraries can't protect you from use-after-free bugs. To prevent those, before Rust, you needed some kind of GC, which imposes performance tradeoffs (some combination of increased memory usage, throughput overhead, and pauses). (Swift's ARC is really a form of reference-counting-based GC.) Rust offers a new approach where you can have manual memory management but the compiler can verify you don't have use-after-free bugs.

Comment Re:Assembly language is good enough for anyone... (Score 1) 236

Rust can do many things modern C++ can't do.

For example, in Rust you can give away a reference to a field of an object *safely*:
struct X { foo: Y }
impl X {
    fn foo(&self) -> &Y { &self.foo }
}
No way to do that safely in C++. Sure, you can give away a pointer or a reference to a field, but the compiler can't ensure you haven't introduced a use-after-free bug. Rust can.

Comment Re:Least effective too (Score 0) 231

I wrote about this in a followup: http://robert.ocallahan.org/20...

The problem is that, by design, AV software is ineffective at catching "new stuff", partly because malware authors can tweak new malware until it passes the classifiers of the major AV products.

So the reality is that every day new malware appears that will not be caught by even the best AV packages unless you're lucky. Real life detection rates will be significantly lower than seen in these tests. Even if the difference between Windows Defender and the others grows a bit, it may actually be less significant.

"A chance at catching them" isn't good enough. What you need are the systematic security measures deployed by modern OSes and browsers, more and better. And AV software gets in the way of that.

Slashdot Top Deals

Lead me not into temptation... I can find it myself.

Working...