Slashdot Mirror

← Back to Stories (view on slashdot.org)

Mozilla Will Ship Its First Rust Component In Firefox 48 (softpedia.com)

Posted by BeauHD on from the unseasoned-cast-iron dept.

An anonymous reader quotes a report from Softpedia: Mozilla announced today plans to ship its first ever Rust code with the production releases of Firefox. The first ever Rust components will arrive in Firefox 48, scheduled for release on August 2, 2016. After teasing Rust features last year, the Mozilla Foundation announced today that Firefox 48 would contain a new media stack component that's entirely coded in Rust. The first Firefox component to feature Rust code was not chosen at random because media components often execute malicious code when parsing multimedia files. "This makes a memory-safe programming language like Rust a compelling addition to Mozilla's tool-chest for protecting against potentially malicious media content on the Web," says Dave Herman, Director of Strategy at Mozilla Research. During tests of this Rust-based media component in Firefox's unstable builds, Mozilla says that after one billion uses they have yet to see a crash or issue in the Rust media component. Last month, Mozilla released the first versions of Servo, a minimal browser created in Rust code alone. At around the same time, Microsoft open-sourced Checked C, an extension to the C programming language that brings new features to address a series of security-related issues.

167 comments

  1. Only as safe as the sandbox by Anonymous Coward · · Score: 2, Interesting

    Java isn't supposed to be able to get out of its sandbox without permission, yet it's the source of many vulnerabilities. Why would we trust Rust to be any safer?

    1. Re:Only as safe as the sandbox by mandolin · · Score: 3, Informative

      Java isn't supposed to be able to get out of its sandbox without permission, yet it's the source of many vulnerabilities. Why would we trust Rust to be any safer?

      Good question.

      My guess is that running untrusted Java code in a trusted Java sandbox has a much larger attack surface than playing untrusted media in a (more or less) trusted Rust app.

      The Rust code should still be an improvement, safety-wise, over the current C/C++ solution.
      That does not mean the Rust solution will be perfect, and it *definitely* doesn't mean you should download and run untrusted Rust apps!

    2. Re:Only as safe as the sandbox by Anonymous Coward · · Score: 5, Informative

      Rust does not derive its safety from a runtime sandbox, but from static guarantees enforced by its type system. This prevents memory errors that often lead to arbitrary code execution vulnerabilities, but it does not attempt to enforce higher-level semantic security properties, e.g. if you blindly use an untrusted string as a filename, you can still be tricked into opening /etc/passwd. Rust does not inherently protect you there, nor is it advertised as doing such.

    3. Re:Only as safe as the sandbox by Anonymous Coward · · Score: 5, Informative

      Rust isn't run in a sandbox. It's like C++. It simply has some assurances that the code it compiles should be free of some classical problems that plague software development in systems languages, without it also sacrificing the close-to-bare-metal aspects of languages like C++, and with much more of the costs involved being pushed to the compilation phase than the runtime phase. That's much more than the likes of Java have tried to offer, and it's also why so many people love to bash on it: it's hard to buy into the assurances without enough time passing, and it's made by a relatively small company that's popular to bash on right now.

    4. Re:Only as safe as the sandbox by Cyberax · · Score: 3, Interesting

      Java bytecode confinement is fairly safe. But the security model for the sandbox was a disaster, basically full of "become root" classes because it relied on poorly thought-out "code access security". Rust's security model is much simpler - it was not designed to contain untrusted code, but to make sure that trusted code is not going to blow up.

    5. Re:Only as safe as the sandbox by Tough+Love · · Score: 1

      Java isn't supposed to be able to get out of its sandbox without permission, yet it's the source of many vulnerabilities. Why would we trust Rust to be any safer?

      Maybe because Graydon Hoare designed it, the same guy who did Monotone, the ancestor of Git. Something about the Sun/Gosling attitude to systems design, seems like a lot of lather and little substance.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    6. Re:Only as safe as the sandbox by Anonymous Coward · · Score: 0

      Rust is supposed to help you write secure code, not let you run intentionally insecure code. Generally running Java from trusted sources hasn't been a big issue, the problem is with running java code from untrusted sources (which was supposed to be safe, but generally wasn't). That is not something rust is trying to do here: its replacing C++ code in this case.

      This is the case of people experienced with security work trying to write secure code in a language designed for security. This is likely to work well, and is an improvement over the C++ case where the language is designed for legacy compatibility with C and security is a tertiary concern at best (after compatibility and performance).

      The classic Java case is a hacker trying to write an exploit in a language designed for sandboxing. This is likely to end in the hackers favor because is a far harder problem to solve and people try to optimize java too much or let it interact with the OS so it keeps breaking.

    7. Re:Only as safe as the sandbox by whh3 · · Score: 2

      I wish I had mod points to recommend this. Thank you for writing so succinctly about how the "safety" of Rust is not based on a runtime sandbox but rather on compile-time analysis that determines which operations are inherently unsafe and which are safe. While Rust advocates compare their safety constructs with those that Java attempts to provide, they are achieved completely differently. Thanks again for pointing this out.

      --
      remove nospam. to email!
    8. Re:Only as safe as the sandbox by serviscope_minor · · Score: 5, Informative

      That does not mean the Rust solution will be perfect, and it *definitely* doesn't mean you should download and run untrusted Rust apps!

      Yes. Rust isn't a sandbox, it's a programming language with memory safety built into the type system. A rust program can do whatever it wants to your system if you don't sandbox it yourself. On the other hand, whole nasty classes of bugs related to buffer overflows, stack smashing and data races cannot happen, which makes it harder to attack from the outside than C.

      It says nothing about whether you should trust a particular rust program to not be malicious.

      --
      SJW n. One who posts facts.
    9. Re: Only as safe as the sandbox by Anonymous Coward · · Score: 0

      Exactly. This means that careless or less than expertly skilled programmers can write software that has less holes than if they used a lower level language.

    10. Re:Only as safe as the sandbox by gweihir · · Score: 0

      There is no reason to assume that Rust would be any better. But the egos of the Rust-people are much bigger, so they make bolder claims.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    11. Re:Only as safe as the sandbox by gweihir · · Score: 1, Interesting

      On the other hand, whole nasty classes of bugs related to buffer overflows, stack smashing and data races cannot happen, which makes it harder to attack from the outside than C.

      That so only true if the compiler and run-time system do not have bugs. How well that assumption holds up in practice can be seen in other languages. And, because they are "safer", languages with safe memory usually come with less competent coders, which often nicely eliminates any advantage gained.

      My prediction is that Rust will do nothing security-wise as soon as attackers actually start to attack it. Initially, it will of course seem to improve things, because attackers will not invest the time to find out how to deal with a new technology that may not even be around for a longer time.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    12. Re:Only as safe as the sandbox by dmpot · · Score: 1

      Rust does not aim to provide you a sandbox to run untrusted code. Its goal is to provide type safety. It means that code written in Rust is as safe as written in Python or in another high-level language, but it runs as fast as if it were written C++.

      Obviously, it could be bugs in the Rust compiler or an unsafe library that you use, but the attack surface is much smaller in this way. Take a look at programs written in high-level languages, you do not hear about buffer overflow and other low-level attacks against them very often, though they also rely on some unsafe code and may have implementation bugs.

      Most attacks against applications written in high-level languages focus on the application logic. For example, attackers may try to force the application to overwrite some configuration file, which enables them a remote access, or create an executable file, which can be then run remotely, etc.

      So for most practical purposes, Rust eliminates certain classes of attacks. This does not mean that applications written in Rust are truly safe, but they are likely to be much safer than written in C/C++.

    13. Re:Only as safe as the sandbox by garethjrowlands · · Score: 1

      Java isn't supposed to be able to get out of its sandbox without permission, yet it's the source of many vulnerabilities. Why would we trust Rust to be any safer?

      This isn't even wrong. The media component needs to be free of bugs/vulnerabilities, not execute untrusted code.

      The better comparison is with C because if the media component wasn't written in Rust, it would be written in C. Memory safety is the safety-critical attribute that Rust and Java have that C lacks. This is not the same as a sandbox. Sandboxes are indeed important in browsers - Chrome and Edge/IE have them and Firefox's sandbox (Electrolysis) is under active development. Rust is a low level language comparable to C, which has an advanced type system that ensures memory safety and other important invariants. Java, by contrast, does not have an advanced type system but does have an advanced runtime system. There have been many vulnerabilities in Java's runtime and libraries, which are large and involve a significant amount of C code.

      Think of Rust code as C code that's proven not have suffer certain classes of bug.

    14. Re:Only as safe as the sandbox by garethjrowlands · · Score: 5, Insightful

      > That so only true if the compiler and run-time system do not have bugs.

      We can be certain there are no bugs in Rusts run-time system because it doesn't have one.

      It's true that the compiler needs to be correct but that's true of all compilers. Rust is a clean, modern design and the critical parts of the compiler are fairly small, so the Rust compiler's chances of generating correct code are pretty good, even compared with much more mature C compilers.

    15. Re:Only as safe as the sandbox by dos1 · · Score: 2, Insightful

      Rust doesn't do anything magical to the security of programs written in it. Rust simply won't allow you to compile quite a lot of vulnerable programs that would be happily compiled by a C compiler, because the language is a lot stricter in terms of memory and thread safety.

      Also, "safety" of Rust actually requires you to be rather more than less competent. There's a rather steep learning curve, less competent coders will struggle (and learn a lot in the process) just by trying to come up with a code that will be finally accepted by the compiler. Rust doesn't provide safety by holding your hand and doing stuff for you - it's more like a strict parent that sets up boundaries of how you can play, so you won't hurt yourself, but otherwise leaves you alone.

      Of course it doesn't mean that you can't write vulnerable code in Rust. It's just a bit harder to do it by accident for some class of potential issues.

    16. Re:Only as safe as the sandbox by serviscope_minor · · Score: 2

      That so only true if the compiler and run-time system do not have bugs

      Well the Rust runtime is provably bug free. The proof is pretty trivial: it doesn't have a runtime.

      How well that assumption holds up in practice can be seen in other languages.

      How many other languages out there get the safety through the type system rather than other mechanisms like sandboxing? A sandbox for a complete and growing system is a much larger attack surface than the relatively small surface of the compiler.

      For the language to be insecure, there are basically 3 classes of bug:
      1. There's a bug in the type system.
      2. The compiler has a bug and allows invalid programs from (1) to compile.
      3. It generates incorrect code in a way that's exploitable

      The thing is, a C compiler is just as likely to have those bugs, especially the largest, 3, and doubly so since the Rust backend shares an optimizer with a popular C compiler.

      And, because they are "safer", languages with safe memory usually come with less competent coders, which often nicely eliminates any advantage gained.

      There's two things wrong with that. First you're comparing an average based on social factors to whether a specific program with a specific team will have bugs, which is a false comparison.

      Secondly, Rust does not relieve you of the burden of thinking about memory (like say, Javam C#), it forces you to think very hard about it and won't compile if you think about it wrong.

      My prediction is that Rust will do nothing security-wise as soon as attackers actually start to attack it.

      Compared to C? I think that's unlikely because Rust is basically like C and C++ in machine model, but with several rich sources of bugs more or less removed.

      --
      SJW n. One who posts facts.
    17. Re:Only as safe as the sandbox by lucm · · Score: 1

      I don't know, man. I googled a picture like I always do when I come across the name of someone who's supposed to be big, and that guy looks like a dentist that had a psychotic break and turned into a serial killer. Based on that I don't trust him, or rust.

      --
      lucm, indeed.
    18. Re:Only as safe as the sandbox by Anonymous Coward · · Score: 0

      And, because they are "safer", languages with safe memory usually come with less competent coders,

      So the language comes with staff?

      Oh, you mean your project is stupid and uses incompetent coders. Well, no cure for that.

    19. Re:Only as safe as the sandbox by Sloppy · · Score: 1

      And, because they are "safer", languages with safe memory usually come with less competent coders, which often nicely eliminates any advantage gained.

      Ah, the nobody can make things better argument, because if you improve things, someone will (should!) use up the extra slack they're given. You're basically arguing that software needs to have a certain amount of bugs, because if it has too few, the programmer market is being inefficient by not cranking out shittier code faster/cheaper.

      I don't buy it. I think it's possible for things to be better, that net gains are possible.

      I cite the entirety of humanity's technological progress as my evidence. Someone said, "You can't improve on gathering! If your 'farming' idea takes off, people will just fuck up the food supply some other way, in order to stay incompetent." That person was wrong.

      My prediction is that Rust will do nothing security-wise as soon as attackers actually start to attack it.

      Okee dokee. I'm betting on the other side. I guess we'll revisit this in a few years, then.

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
    20. Re:Only as safe as the sandbox by mvdwege · · Score: 1

      How many other languages out there get the safety through the type system rather than other mechanisms like sandboxing?

      I know of one: Ada. And it has a well-deserved reputation for safety.

      --
      "I know I will be modded down for this": where's the option '-1, Asking for it'?
    21. Re:Only as safe as the sandbox by K.+S.+Kyosuke · · Score: 1

      It's technically equivalent to a sandbox, but sandboxes work, which is why Rust works. Just because X can also be done badly doesn't mean that X can't be done well, too.

      --
      Ezekiel 23:20
    22. Re:Only as safe as the sandbox by K.+S.+Kyosuke · · Score: 1

      We can be certain there are no bugs in Rusts run-time system because it doesn't have one.

      All languages these days have *some* kind of runtime system. Even if it's just a set of low-level trusted primitives. But the important thing is that it has to be small and not try to do everything.

      --
      Ezekiel 23:20
    23. Re:Only as safe as the sandbox by K.+S.+Kyosuke · · Score: 1

      Rust doesn't do anything magical to the security of programs written in it.

      Isn't it the case that Rust allows for implementations with language-enforced isolation of code domains? Because if it is, I'd definitely say it's big for security of highly performant programs, because you should be able to run foreign code (mobile code, for example?) in the same memory space, including cross-module optimizations, with (a part of) the language spec serving as your security kernel.

      --
      Ezekiel 23:20
    24. Re:Only as safe as the sandbox by K.+S.+Kyosuke · · Score: 1

      Well the Rust runtime is provably bug free. The proof is pretty trivial: it doesn't have a runtime.

      Judging from this, it actually *does* have a runtime, in two forms: partly in form of some routines (used by some programs), partly in form of compiler transforms/IR operations (used by *all* programs) that securely inline some sensitive tasks into the program in a way that a library can't. Just like, for example, some Lisp implementations inline low-level memory operations even into higher-level programs to speed them up without sacrificing safety. So the problem is effectively the same: a finite set of primitive operations has to be securely implemented. But that is feasible, certainly more so than telling C programers not to make a mistake whenever they're using pointers.

      --
      Ezekiel 23:20
    25. Re:Only as safe as the sandbox by serviscope_minor · · Score: 1

      I know of one: Ada. And it has a well-deserved reputation for safety.

      Indeed! Typesystem based safety is much better than unsafe + sandbox.

      --
      SJW n. One who posts facts.
    26. Re:Only as safe as the sandbox by phantomfive · · Score: 1

      Java isn't supposed to be able to get out of its sandbox without permission, yet it's the source of many vulnerabilities. Why would we trust Rust to be any safer?

      You don't know what you are talking about. Rust is built to make avoid memory leaks and buffer overflows. It does a good job at that.

      Java doesn't have a problem with memory overflows, either, but you got confused between the plugin and the language. The Java language was fine, the plugin (with its sandbox) had problems.

      --
      "First they came for the slanderers and i said nothing."
    27. Re:Only as safe as the sandbox by Anonymous Coward · · Score: 0

      I think that's pushing the definition of runtime system just a little bit too far.

    28. Re:Only as safe as the sandbox by Raenex · · Score: 1

      On the other hand, whole nasty classes of bugs related to buffer overflows, stack smashing and data races cannot happen, which makes it harder to attack from the outside than C.

      That's not true because of the unsafe escape hatch and raw pointers. It's an improvement over C/C++ by having a safe default, but you can still shoot yourself in the foot.

    29. Re:Only as safe as the sandbox by Anonymous Coward · · Score: 0

      You can trust Rust to be safer than the C/C++ code it's replacing. Comparison to Java is irrelevant here.

    30. Re:Only as safe as the sandbox by Anonymous Coward · · Score: 0

      > That so only true if the compiler and run-time system do not have bugs.

      We can be certain there are no bugs in Rusts run-time system because it doesn't have one.

      It's true that the compiler needs to be correct but that's true of all compilers. Rust is a clean, modern design and the critical parts of the compiler are fairly small, so the Rust compiler's chances of generating correct code are pretty good, even compared with much more mature C compilers.

      So... Rust has NO standard libraries at all, and doesn't even link to standard C libraries... At run time?

      Unless everything your application needs to run is statically linked in, you have a run-time environment.

    31. Re:Only as safe as the sandbox by Tough+Love · · Score: 1

      You come across as a bit on the psycho stalker side yourself.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    32. Re:Only as safe as the sandbox by Anonymous Coward · · Score: 0

      Yeah, yeah. libc is a horrible runtime so don't use C.

      You're too much of a fucking idiot to know what you're talking about. Writing something in C doesn't make it more "authentic." Where the fuck would you be without a libc and a cc? You think that C code just magically compiles itself into binary form?

      Haskell, Rust, and C all can produce a system kernel up that runs on hardware. You go to C because that's what everything is written in. Your system already comes with a bootstrapped cc. There's no reason a system couldn't come with a bootstrapped Rust or Haskell compiler. There's no reason it wouldn't be necessary on that system to bootstrap the cc from components written in Rust or Haskell if you wanted a cc.

      You're confused by C# and Java because both of those languages compile to a form meant to run on an architecture that's made up and was never intended to exist in hardware form. Their runtimes are more like emulators, no different than if you wanted to run some code written in C and compiled for say ARM on an x86.

      I believe it's one of the goals of the folks behind Rust to eventually have a kernel and entire OS written completely in Rust. Assuming they deliver on that and it becomes a popular platform, you're going to see instructions to build a cc for it begin with downloading an already compiled binary cc.

      So tell me, what makes C special other than being frist?

    33. Re:Only as safe as the sandbox by K.+S.+Kyosuke · · Score: 1

      It depends. Features like Rust's "unsafe" or Oberon's imports of the SYSTEM module can at least be watched for (and banned in a project) since their use is blindingly obvious. The raw pointer stuff seems kind of more worrisome. I find its very presence peculiar.

      --
      Ezekiel 23:20
    34. Re:Only as safe as the sandbox by K.+S.+Kyosuke · · Score: 1

      That depends. For me, the runtime is the thing (whatever it is) that allows the language to do certain types of actual work on a physical machine, like communicating with the OS or hardware, or managing memory, for example, especially in relation to the required semantics of the language.

      --
      Ezekiel 23:20
    35. Re:Only as safe as the sandbox by gweihir · · Score: 1

      And here we see the cluelessness of the Rust-proponents in all is glory: Unless you do bare-metal assembly, you do have a run-time system. This does not mean an interpreter or a the like, the standard libraries already form a runtime system. And yes, Rust does have one.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    36. Re:Only as safe as the sandbox by gweihir · · Score: 1

      For security and safety purposes, a runtime system is everything that was not directly coded by the programmer. Bootstrap code, function dispatch, libraries, etc. all are part of the runtime system.

      But I am not surprised that the Rust-fanatics try to define the runtime system away: They actually have nothing to suggest that the Rust runtime is so massively better than others, so Rust must obviously not have a runtime.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    37. Re:Only as safe as the sandbox by gweihir · · Score: 0

      To actual language experts, Ada counts as a failure.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    38. Re:Only as safe as the sandbox by Raenex · · Score: 1

      The raw pointer stuff seems kind of more worrisome. I find its very presence peculiar.

      Raw pointers can only be used in code labeled "unsafe".

    39. Re:Only as safe as the sandbox by lucm · · Score: 1

      You come across as a bit on the psycho stalker side yourself.

      Totally uncalled for. I haven't received a single restraining order in July so far, there was just this tiny incident with the 7-11 guy and the cops said it wasn't really stalking.

      --
      lucm, indeed.
    40. Re:Only as safe as the sandbox by erapert · · Score: 1

      Considering that C, C++, and Rust all compile to machine code I think you should say "bare-metal" not "close-to-bare-metal".

    41. Re:Only as safe as the sandbox by gweihir · · Score: 1

      My guess is that all the other proofs showing Rusts superiority are of similar quality: Simple, elegant and wrong. Reality is messy, and ignoring that will not make the messiness go away.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    42. Re:Only as safe as the sandbox by gweihir · · Score: 1

      You are missing one critical effect here that happens to basically all technologies: At some point they have realized their full practical potential and any more "evolution" makes them less beneficial. Examples: Flying cars, tablets as replacement for pen&paper, video-telephony, the hypeloop, electronic locks, etc. The list is really endless and the proponents of these things always display the same amount of fanaticism, faulty thinking and lack of insight into the problem being targeted.

      But really, that you do not even begin to understand what I am saying is no surprise. From your SlashID you should be old enough to have seen a number of "magic" new languages, tools and coding techniques only to have them all fall flat on their faces. Some people learn from that, others stay suckers their entire life.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    43. Re:Only as safe as the sandbox by mvdwege · · Score: 2

      <citation needed>

      Self-proclaimed expertise does not correlate well with actual expertise, and Ada seems to be doing quite well in its domains of highly-secure and embbeded software. In fact, it's having a bit of resurgence.

      Those who do vocally hate on it seem to be the kind of cowboys that run after every new fad, the sort of programmers you wouldn't trust to code the right way to implement an automatic toilet seat.

      (Side note: let's see who spots the reference in that last paragraph.)

      --
      "I know I will be modded down for this": where's the option '-1, Asking for it'?
    44. Re:Only as safe as the sandbox by Sloppy · · Score: 1

      you should be old enough to have seen a number of "magic" new languages, tools and coding techniques only to have them all fall flat on their faces.

      Of course I've seen plenty of failures and stupid ideas! I don't see that (or your cherry-picked list) as important, though. In any human endeavor if you're around long enough, you'll see that happening. I'm sure in 4999 BC some numbnuts or con-artist had a really stupid idea about how to make farming work better. I don't care about him. Lots of people try things, and there are plenty of crackpots and real-but-nevertheless-mistaken geniuses. It doesn't mean things aren't getting better, though. I've also seen successes.

      How about "higher level" languages with memory-safety and/or garbage collection? There was a time when these things were new kids on the block, too, and even looked down upon. I can get some things finished far sooner in Python than in C, because I'm not having to think about some details far below the abstraction of my problem. Had I dismissed Python out-of-hand because it didn't have pointers, I'd be worse off today.

      How about tools like git? (You wouldn't believe the amount of my time as a human I sometimes spent in the 1980s merging someone's changes into a "main" version.)

      You don't think these things are letting people get more stuff done, in less time? We don't call them magic, we call them technological progress.

      One of the things that many programmers know would help them, even if they disagree on all the details, would be to communicate with the compiler just a little better, so that certain theoretically-automate-able things can get actually automated (e.g. generate warnings to catch certain types of bugs sooner, "automagically" parallelize some types of loops, etc). It's just a matter of time and creativity, until someone really gets this done well (e.g. so procedural programmers don't have to think like functional ones).

      I don't think we have reached the full practical potential for programming languages. I'm not saying Rust is the next thing, but there will be a next thing. If we're all joking about Rust and Go and Swift in 20 years (like how we joke about Ruby now), fine! But it's reasonably likely that something will have happened in that period, making a 2036 programmer more productive than a 2016 one. It'll happen because programmers have real, and increasingly well-understood, meta-problem that repeat themselves over and over again. People are aware of it and trying all kinds of things to address them.

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
  2. So... by Anonymous Coward · · Score: 0

    It'll bring the bug reporter down with crash reports in the first 24 hours of full release then?

  3. rust community by Anonymous Coward · · Score: 1, Offtopic

    Too bad the Rust community is so toxic. Can't call a process a slave, it has to be a "follower".

    1. Re: rust community by Anonymous Coward · · Score: 1

      People at my work went through the same discussions. Wtf. We aren't talking about humans here, these are machines. Should we rename the kill command too?

    2. Re:rust community by guruevi · · Score: 0

      Rust has multicore capabilities now? I thought that proper multi threading didn't fit into their "safety" models and requires ugly hacks.

      --
      Custom electronics and digital signage for your business: www.evcircuits.com
    3. Re: rust community by Anonymous Coward · · Score: 1

      The first politically correct programming language. I hope there are more. However, I believe it should also reference more African American history and use African nomenclature. It will be much better than that racist Perl language.

    4. Re:rust community by Anonymous Coward · · Score: 0

      The Rust standard library provides both message-passing and shared-memory concurrency primitives with static guarantees against data races. Rust threads are ordinary operating system threads.

    5. Re:rust community by Anonymous Coward · · Score: 0

      Since when? Of all the criticisms I've seen leveled at Rust, I've never actually heard this one. Are you thinking about SIMD, instead of threading?

    6. Re:rust community by Anonymous Coward · · Score: 0

      You're confusing Rust-lang with something else.
      rust-lang.org

    7. Re: rust community by Anonymous Coward · · Score: 1

      Got me thinking of the IDE days of master and slave drives. Oddly enough never once thought of slavery in the process of using that terminology, just automatically associated it with the technological meaning.

    8. Re: rust community by Laconique · · Score: 1

      You genuinely cannot see that this language is actually not neutral either. Of course the machine doesn't care but keeping politically saturated terms puts them on life support too. I am not necessarily in favor of this move but it has merit.

    9. Re:rust community by NotInHere · · Score: 4, Interesting

      Nope, in fact its the opposite. Thanks to its ownership model, Rust eliminates most of the ugly access bugs that you might run into if you do multithreading. It puts the information whether something needs to be locked before being accessed, or whether its totally threadsafe into the type system, so that the compiler can verify everything is working as you intended it.

      Of course, its not perfect, but rust is one of the languages you might want to start your multithreaded program in. It doesn't save you from thinking about the problems, but if you got it wrong, it won't compile. There are still bugs, but none that fall into the category C++ would describe as "undefined behaviour" (and those are many times the reasons for the most evil security bugs AND the hardest to debug).

    10. Re: rust community by Anonymous Coward · · Score: 0

      Oddly enough never once thought of

      That's because you're a racist. Just like you are a sexist for using male and female terms for plugs. Not quite sure sexist against whom, but it's sexist nevertheless. I'm glad I bailed on the industry I grew up with.

      captcha: accuracy

    11. Re:rust community by Anonymous Coward · · Score: 0

      Their strong ownership semantics makes sending references to other threads safe (you can transfer the unique ownership to allow another thread to mutate and know no one else can access it while you do for example); this means you can do performant sharing (references not sending copies) and keep safety. Rust actually provides one of the best multi-threading environments I've seen. This was one of the main reasons rust was created, and it solves the problem quite well.

      In addition built in stuff, you can implement new and novel synchronization tricks using unsafe rust if necessary, and use their ownership rules to guarantee your nicely encapsulated unsafe logic is used correctly. I believe the standard library ships an implementation of protecting an object by a lock (generic reusable implementation) implemented this way for example. This guarantees no references to the object escape making it impossible to access it without acquiring the lock: trying to save a reference to it somewhere so you can violate this (either on purpose, or maybe because you intended to deep copy but forgot) will fail to compile! Its impressively robust while still being usable and performant.

      If you try to send some object that is not threadsafe off to another thread (ex: it has references to thing that might be modified by the first thread) it will fail (not compile), but in cases where wrapping it in a lock is sufficient to protect it (ex: it owns all things it references, but you might be sending it to multiple threads), you can wrap it in such a lock and the send will now compile. However, if you don't have exclusive ownership (ex: your calling function will use if after you return) this unsafe attempt to wrap in a lock will also fail compile. Its really robust!

      And since rust can compile libraries that can interop with existing C and C++ code bases (and anything that can call C code) its easy to ship a single rust component as part of a larger project: the rest of the code base doesn't even have to know the implementation language has changed.

      Disclaimer: I really suck at coding in rust and have spend very little time on it. The language interests me and I have learned a lot about it and its implementation, but I haven't done a real project in it yet.

    12. Re:rust community by KermodeBear · · Score: 3, Insightful

      You're kidding me, right?

      Please tell me that you're joking.

      If this is true, I really have zero desire to learn the language. Anything swamped by the disaster of political correctness is, quite frankly, just not worth the trouble. If I'm going to use standard computer science terminology and get whined at because the same word means something not-warm-and-fuzzy in a totally different context, then I'm out.

      --
      Love sees no species.
    13. Re: rust community by ctrl-alt-canc · · Score: 1

      To have a politically correct programming language, we should also take care of replacing the "do" loop controlling statement with something less imperative, like "could you", "please compute", and so on.

    14. Re: rust community by Anonymous Coward · · Score: 1, Funny

      Yes, "kill -9" should be replaced by "kill --muslim"

    15. Re: rust community by smallfries · · Score: 1

      You could go the whole hog and just the British version of the language. It is far more refined.

      --
      Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
    16. Re:rust community by gweihir · · Score: 1, Insightful

      It is a special class of idiots that focus on irrelevant side-issues while solving a hard technological problem. A "follower" and a "slave" are also different concepts, so they are mangling technological terminology with their Newspeak. Better stay away from these people, they are not engineers at heart.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    17. Re:rust community by gweihir · · Score: 1, Flamebait

      Indeed. A tech-community that allows SJWs to dictate terminology to them is weak and not worth being part of in the first place. At least they signal to anybody with a clue that they are broken in the head early on.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    18. Re: rust community by Anonymous Coward · · Score: 0

      > Should we rename the kill command too?

      Some project (Swift? I only remember it was hipster-filled) actually renamed "suicide".

    19. Re: rust community by Anonymous Coward · · Score: 0

      Systemd already takes care of these problems automatically.

    20. Re:rust community by Mokki · · Score: 1

      If we define what untrusted code to mean random binary/library from internet that your program downloads at runtime and then executes.

      Rust/C++ have no support for limiting what harm that random binary code does. It can do anything and any Rust/C++ compile time protections are moot because the downloaded binary/library is not compiled or checked against the expectations.
      Java sandbox (mostly used by applets) is an attempt to allow downloading binary (compiled java classes) from external source and limiting what it can do.

      Trusted code is your own source and downloaded external libraries (depending on language the external libraries might be in source or binary format) one compiles into binary.
      While building trusted code the type checking of the Rust/C++/Java compilers is applied. Here Rust has the most multithread/data sharing checks.

      When handling untrusted input processed by your trusted code the question becomes can it cause untrusted code execution. Java (and other languages running in virtual machines or interpreters) provides the most protections. Generally only cases where safe code is calling to existing buggy C library for the data processing (for example image handling) can it untrusted input become a problem.

    21. Re:rust community by NotInHere · · Score: 1

      Java (and other languages running in virtual machines or interpreters) provides the most protections

      Yes, java provides lots of protections, but those protections come with a cost, that's paid by java at runtime. Rust provides the same level of protection, but it offers it at native speed (well, not 100% the same as C++, e.g. array access is always checked, so you should use iterators, they do O(1) many checks).

      Generally only cases where safe code is calling to existing buggy C library for the data processing (for example image handling) can it untrusted input become a problem.

      Same goes for Rust. The difference is though that you can actually write performant image decoders in Rust, while you have a hard time with Java (its entirely possible to write them, they just wont be as performant).

    22. Re: rust community by dunkelfalke · · Score: 1

      Ever heard of INTERCAL?

      --
      "It's such a fine line between stupid and clever" -- David St. Hubbins, Spinal Tap
    23. Re: rust community by Anonymous Coward · · Score: 0

      Master and slave were an incredibly dumb names though. The master and slave drive don't have a "master" vs "slave" relationship in any way, they're just the first and second device in the address range.

    24. Re: rust community by Anonymous Coward · · Score: 0

      Actually I remember reading some article about some american politician making an issue out of it
      he demanded all the documentation was changed to get rid of master and slave terminilogy

    25. Re:rust community by Anonymous Coward · · Score: 0

      Your loss. Nobody is stopping you from jumping the shark and be just as stupid and self-defeating as the people you're rallying against. At this point the "anti-SJW" crowd is at least as toxic as the SJW crowd, and their opinions here on Slashdot are a fine example of why both communities need a good head-upside-smackin'.

    26. Re:rust community by guruevi · · Score: 1

      From what I understand the latest benchmarks show that Rust and Java are quite even when it comes to performance. You can't just spend CPU cycles on checks and bounds without sacrificing speed.

      --
      Custom electronics and digital signage for your business: www.evcircuits.com
    27. Re: rust community by Anonymous Coward · · Score: 0

      "Slave" is a word that describes the relationship. Changing the word because you don't like what it means in another context makes you a moron.

    28. Re:rust community by gweihir · · Score: 1

      Well said.

      In my experience, a better language can help competent people produce good code more easily, but it can never make incompetent people produce reasonable code in the first place. And for competent people, "better" here typically means "stands in my way less often".

      Their "safe space" approach reminds me of a thing most religions do: They give you a more-or-less arbitrary set of rules, and if you just follow them to the letter, you suddenly become a "good" person. (In actual reality, that does not work, of course.) Come to think of it, this fallacy may be at the core of the design of Rust. And it would also explain the toxic community that cannot deal with any kind of criticism rationally, and is so dead set on pushing their thing as the only one true thing.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    29. Re: rust community by Anonymous Coward · · Score: 0

      Allahu --ackbar

    30. Re:rust community by erapert · · Score: 1

      Citation?
      The programming language shootout seems to show that Rust is a cut above Java's performance.

  4. Terrible!! by EzInKy · · Score: 1

    I really hate seeing Mozilla getting "rusty"!!!

    --
    Time is what keeps everything from happening all at once.
    1. Re:Terrible!! by Anonymous Coward · · Score: 0

      i'll take a "rusty" old firefox over the "ooh shiny" chrome clone it's turned into.

    2. Re:Terrible!! by Anonymous Coward · · Score: 0

      You're perfectly free to do so. Mozilla isn't hiding its insecure, obsolete old versions. Last I heard there are also some people who still believe that Pale Moon is worth using. The rest of us can easily see past the "Chrome clone" nonsense argument, and haven't lost our ability to configure the browser so that it doesn't offend our fragile, melodramatic minds.

    3. Re:Terrible!! by EzInKy · · Score: 1

      The problem is Mozilla has become as money hungry as all the master's that they serve. When was the last time you saw an argument for keeping firefox FOSS?

      --
      Time is what keeps everything from happening all at once.
    4. Re:Terrible!! by TangoMargarine · · Score: 1

      Except for the part where Rust itself is the "new and shiny."

      --
      Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
    5. Re:Terrible!! by TangoMargarine · · Score: 1

      Last I heard there are also some people who still believe that Pale Moon is worth using.

      It is. Are you just another person who doesn't undestand how forks work and therefore dislike them, or do you have an actual reason?

      and haven't lost our ability to configure the browser so that it doesn't offend our fragile, melodramatic minds.

      Except for the things that have actually been removed from even about:config. Mozilla, how far you've fallen.

      --
      Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
    6. Re:Terrible!! by Anonymous Coward · · Score: 0

      My actual reason is that once you strip away the supporter's flimsy PR-campaign arguments, Pale Moon is nothing more than a parasitic fork - it only exists because it has Mozilla's work to use. That may be hard work for one person to do, but it's not something special. It's simply taking old and new parts of Firefox and mashing them together, disabling the test suite, and hoping that a tiny community's "testing" will make up for it. It doesn't have expert security researchers vetting it. It even includes questionable additions that Mozilla hasn't deemed ready yet, all for the sake of differentiation. That's not even counting the many improvements that it cannot cherry-pick back without re-forking (and almost certainly breaking everything it stands for to its supporters).

      None of this makes it "superior" to Firefox, or a savior. It's just a fork for a few people stubbornly clinging to the past, desperately trying to paint that past as "better", and not wanting to recognize the many, many problems with the product compared to Firefox. MoonChild's efforts notwithstanding, it's a product that is past its prime just as the Firefoxes that it is based on. No amount of backporting Firefox features is going to change that. Maybe Pale Moon will be a serious contender if they ever get truly serious about testing, security vetting, and they pull in some more talent. Until then, we only have your word that it's not the ticking time-bomb that you don't want to acknowledge it is.

    7. Re:Terrible!! by TangoMargarine · · Score: 1

      It's just a fork for a few people stubbornly clinging to the past, desperately trying to paint that past as "better"

      Well what do you expect, when you make it nearly impossible for them to keep their comfortable browsing experience? (I assume you're involved with Mozilla somehow.)

      Maybe Pale Moon will be a serious contender if they ever get truly serious about testing, security vetting, and they pull in some more talent.

      This just comes off as sour grapes. "Those bastards stole our code, but at least they'll never be successful."

      Man, this is the first time I've seen something that's so clearly FUD that the term actually popped into my head unbidden.

      --
      Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
    8. Re:Terrible!! by Anonymous Coward · · Score: 0

      None of this makes it "superior" to Firefox, or a savior. It's just a fork for a few people stubbornly clinging to the past, desperately trying to paint that past as "better", and not wanting to recognize the many, many problems with the product compared to Firefox.

      I use Linx, you insensitive clod.

  5. Re:Oh, that's just jolly by Anonymous Coward · · Score: 0

    It looks like I have to stop using Firefox. I only use it for nostalgic reasons and that I'm familiar with it. However, I should have dumped it long ago.

  6. Who but Mozilla? by EzInKy · · Score: 1, Troll

    Who but Mozilla can we trust to protect our privacy? Everyone else seems to want to profit in one way or another.

    --
    Time is what keeps everything from happening all at once.
    1. Re:Who but Mozilla? by Rexdude · · Score: 2, Informative

      Mozilla is no longer what it used to be - one that placed users first. All they've been doing is dicking around with the UI, and getting rid of all the customizability that attracted people to it in the first place(XUL and XPCOM support is going away - so many popular extensions that modify the interface and add features are going to go away), to make it a pale copy of Chrome. The only browser today that follows the charter of the original Mozilla is Pale Moon, which was forked off Firefox 24 and will continue to support XUL and proper extensions, and provide a full blown desktop UI instead of a dumbed down touchscreen/mobile friendly one.

      --
      "..One hosts to look them up, one DNS to find them, and in the darkness BIND them."
    2. Re:Who but Mozilla? by Anonymous Coward · · Score: 0

      Mozilla has you in their pocket

    3. Re:Who but Mozilla? by Anonymous Coward · · Score: 2, Insightful

      More bullshit.
      Always the trolling on Mozilla posts. IT is so old and frankly untrue.

    4. Re:Who but Mozilla? by Anonymous Coward · · Score: 5, Informative

      Pale Moon is only worth it if you want to keep using obsolete tech. It's otherwise no better than Firefox, and has not improved significantly since its inception. It has already broken compatibility with more addons than Firefox did. It will either break compatibility with the obsolete tech you list in your post, or it will continue its slow downward spiral into irrelevance. It simply doesn't have the development community to be its own browser, and once Mozilla (rightly) stops supporting those outdated legacy things, you'll be SOL. Unless of course Pale Moon's community starts to actually pitch in beyond silly PR campaigns that overrate Pale Moon and poo-poo Firefox for "leaving them behind".

    5. Re:Who but Mozilla? by Anonymous Coward · · Score: 1

      Pale Moon is obsolete. Already it struggles with Javascript-heavy sites like Google Maps and it has hacks to get around sites that (correctly) detect it as out of date. It's only a matter of time until it becomes unusable on the modern Web.

    6. Re:Who but Mozilla? by EzInKy · · Score: 1

      As Microsoft and Ubuntu have yours?

      --
      Time is what keeps everything from happening all at once.
    7. Re:Who but Mozilla? by thegarbz · · Score: 1

      What bullshit? Care to provide and cite counter examples?

    8. Re:Who but Mozilla? by TangoMargarine · · Score: 1, Interesting

      It's otherwise no better than Firefox, and has not improved significantly since its inception.

      Don't fix what ain't broke. Pale Moon has unfucked the Firefox interface, which is a big improvement in my book.

      It has already broken compatibility with more addons than Firefox did.

      A) They've got a whole library of fixed extension for ones that are broken.
      B) Firefox is jettisoning their entire extension system anyway in the near future so it's not like they'll be any better.

      or it will continue its slow downward spiral into irrelevance

      Are we talking about PM or FF? Have you looked at your user figures recently?

      and once Mozilla (rightly) stops supporting those outdated legacy things

      You mean the things you're ripping PM for not supporting in this very same post?

      It's rather interesting that all these posts are by (presumably the same) Anonymous Coward, too.

      --
      Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
    9. Re:Who but Mozilla? by Anonymous Coward · · Score: 0

      Pale Moon is only worth it if you want to keep using obsolete tech. [etc]

      Mozilla employee detected.

    10. Re:Who but Mozilla? by Anonymous Coward · · Score: 0

      Ah, the deflector shields are up at full power, huh?

      >Don't fix what ain't broke.

      Just because it still kinda works doesn't mean it ain't broke. Not wanting to accept that changes nothing. Pale Moon keeping the old UI around hasn't made it any less broken. Keeping XUL/XPCOM around all this time in Firefox did little to improve it or fix its problems, it just made it more difficult for Firefox devs to actually fix the rest of the browser.

      >A) They've got a whole library of fixed extension for ones that are broken.

      And so does Firefox. How is this a point in PM's favor?

      >B) Firefox is jettisoning their entire extension system anyway in the near future so it's not like they'll be any better.

      This also changes nothing about Pale Moon being just as bad.

      >Have you looked at your user figures recently?

      And how are Pale Moon's figures doing lately? If that's your supposed to be an argument for Pale Moon, then you're really shitting the bed. Based on where it gets the bulk of its code from and basic software history, if Firefox falls then Pale Moon won't last very long. At best it will be a year or two before it's completely useless for modern browsing, much like Opera 12 or any other abandoned web browser.

      >You mean the things you're ripping PM for not supporting in this very same post?

      I'm not the one trying to upsell PM or deflect arguments pointed at it back to Firefox. I never said "use Firefox instead". You're making this too easy.

      >It's rather interesting that all these posts are by (presumably the same) Anonymous Coward, too.

      I'm sure it's comforting to think that your side outnumbers mine or whatever, or that anonymity is a factor in trying to disprove my assertions about PM. Neither of those things is true, however. You'll have to do a lot better than "well, I like the UI more" to prove that Pale Moon isn't a crumbling house of cards. Whether or not Firefox is also a crumbling house of cards is irrelevant to this conversation, aside from PM being wholly dependent on it.

    11. Re:Who but Mozilla? by Anonymous Coward · · Score: 0

      Pale Moon uses the single process model, so yes it is obsolete tech (separate flash process doesn't count, I'm talking tabs). Though currently Firefox isn't any better, but they're at least working toward a multi-threaded browser, unlike pale moon. So maybe if we give Mozilla another 100 years they'll release a version of the multi-process Firefox that actually works.

    12. Re:Who but Mozilla? by TangoMargarine · · Score: 1

      Just because it still kinda works doesn't mean it ain't broke. Not wanting to accept that changes nothing. Pale Moon keeping the old UI around hasn't made it any less broken.

      For somebody who's whining about my "deflector shields", you're making similar assumptions, just in the opposite direction from my opinion. Just because you like Firefox's interface doesn't mean everybody else does. Again, look at the user figures for how many people are still on Firefox.

      Keeping XUL/XPCOM around all this time in Firefox did little to improve it or fix its problems, it just made it more difficult for Firefox devs to actually fix the rest of the browser.

      Lumping together mangling the UI and replacing the extension system muddies the argument. You could have replaced the extension system without turning the UI into Chrome.

      And how are Pale Moon's figures doing lately? If that's your supposed to be an argument for Pale Moon

      I'm not the one trying to upsell PM

      Nope, not even what I'm saying.

      You're admitting that all the things you're complaining about Pale Moon doing, Firefox is comparably bad at, so I guess I fail to see what point you're trying to make. That we should use Chrome? If you want to use Chrome, go ahead; I would prefer Firefox not try to become Chrome, but keep being Firefox. But that ship has long since sailed.

      Whether or not Firefox is also a crumbling house of cards is irrelevant to this conversation

      Wow, that's sure convenient. Have you ever heard that expression about stones and glass houses?

      --
      Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
    13. Re:Who but Mozilla? by TangoMargarine · · Score: 1

      For somebody trying to argue that Pale Moon is worse than Firefox, you're doing a terrible job of it.

      --
      Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
    14. Re:Who but Mozilla? by Anonymous Coward · · Score: 0

      Go away Stuart.

    15. Re:Who but Mozilla? by Blaskowicz · · Score: 1

      For somebody who's whining about my "deflector shields", you're making similar assumptions, just in the opposite direction from my opinion. Just because you like Firefox's interface doesn't mean everybody else does. Again, look at the user figures for how many people are still on Firefox.

      What would be the absolute number of desktop web browser users who use Firefox?
      I don't know what such numbers are (total number of desktop web users, year by year) but for the sake of the argument, 30% of 500 million desktops or 14% of one billion desktops is about the same fuck ton of users.
      Or take that figure of 7% market share and apply it to 1.2+ billion users.

    16. Re:Who but Mozilla? by TangoMargarine · · Score: 1

      On the other hand, Mozilla has lost more users that most web browsers will ever have.

      --
      Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
    17. Re:Who but Mozilla? by TangoMargarine · · Score: 2

      For anyone interested in numbers, I threw together a rough timeline:

      47.9% July 2009 3.5 - peak Firefox usage
      46.4% July 2010 4
      42.0% July 2011 9
              FF12 - final release to support Windows 2000 and Windows XP RTM & SP1
              FF15 - automatic silent updates
      33.7% July 2012 17
              FF19 - built-in PDF viewer
              FF20 - replacement download manager
              FF21 - Social API "multiple providers"
              FF23 - no more <blink>, new logo, JavaScript permanently enabled, can't keyword-search in URL bar
      28.9% July 2013 26
              FF27 - more Social API
              FF29 - Australis, no add-on bar
              FF30 - disable most plugins by default
              FF31 - first Australis ESR; previous ESR automatically updated to this version Oct 2014
      24.9% July 2014 34
              FF38 - Pocket integration
      21.3% July 2015 39
              FF40 - touchscreen/Australis improvements, extension signing mandatory in future
              FF45 - Tab Groups removed
      16.9% May 2016

      So by now the lost percentage points have probably crossed the 2/3rds point.

      http://www.w3schools.com/brows...

      --
      Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
    18. Re:Who but Mozilla? by Anonymous Coward · · Score: 1

      Market share percentages means nothing when you don't include how the market changes. There has been a massive increase in mobile browser usage and Firefox doesn't do well there. Is Firefox usage actually going down or is it just not increasing as fast as other browsers? Since you left that info out, your post is effectively useless and very misleading.

      Though the timeline is nicely formatted.

    19. Re:Who but Mozilla? by TangoMargarine · · Score: 1

      I'm sure all the shenanigans the Mozilla team has gotten up to over the last several years had nothing to do with their user numbers. Nope. Not at all. Couldn't be.

      your post is effectively useless and very misleading.

      Hey, at least I tried giving any numbers at all.

      --
      Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
    20. Re:Who but Mozilla? by Waccoon · · Score: 1

      What's wrong with having Pale Moon and Firefox installed side-by-side? Yes, it's a pain, but it's what I deal with to prevent the likes of Google and friends from reading over my shoulder in ways they refuse to disclose.

      I use Pale Moon as my main browser, and Firefox for development. The only extensions I need for my main browser are my ad blocker and script blocker, and I'm pretty sure those will work well with Pale Moon for many years to come. Since I don't have to restart Pale Moon every 10 minutes due to memory hogging, like I do with Firefox, I don't even need Session Manager anymore.

      Hate on it all you like, but I for one am very glad that Pale Moon exists, and not everyone is willing to jump on the latest shiny (and generally untested) technology. I'll use it as long as it works for me. If Mozilla is more interested in adding yet more features to enhance my experience and force me to use social tie-ins I don't need, then I don't consider it to be more secure at all.

    21. Re:Who but Mozilla? by Anonymous Coward · · Score: 0

      The point is both of them are horrible.

  7. leaks by nten · · Score: 1

    I think part of Mozilla's motivation to use rust is that it prevents leaks and they know they have many.

    --
    refactor the law, its bloated, confusing and unmaintainable.
    1. Re:leaks by Anonymous Coward · · Score: 0

      Rust makes leaks less likely, but it does not prevent them.

    2. Re:leaks by Anonymous Coward · · Score: 0

      It does, unless its assurances to the contrary prove to be bunk. You have to explicitly opt into using leaky/"unsafe" code. As such, your own code won't be leaking, but lower-level non-Rust code that it relies on can still leak away.

    3. Re:leaks by TangoMargarine · · Score: 0

      Even if it does, the odds that somewhere in the Firefox codebase they'll have to drop into unsafe mode to get something to work approaches 100%.

      --
      Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
    4. Re:leaks by Anonymous Coward · · Score: 0

      It doesn't prevent leaks, not even in safe code. this function can and will happily leak anything your heart desires. Why not mark this unsafe? Because you can always implement forget by constructing a self-referencing reference-counted pointer. Memory leaks are not considered unsafe in Rust.

  8. Re:Here we go again by secretsquirel · · Score: 1

    Not me, I want a pony.

  9. Re:Here we go again by Anonymous Coward · · Score: 0

    Here we go again. Assholes always dissing Mozilla no matter what.

  10. Re:Oh, that's just jolly by arglebargle_xiv · · Score: 4, Funny

    It really depends on where the rust occurs. If it's just on the panelling or in the chrome then you can sand it down and repaint, but if it's structural rust you're pretty much hosed. Time to switch to Pale Moon, which hasn't started rusting yet.

  11. Re:Oh, that's just jolly by ChunderDownunder · · Score: 3, Informative
    Well if Slashdot had linked the Mozilla blog post instead of some random softpedia clickbait, you might have read where they are working with distros to incorporate the rust toolchain.

    We have active discussions from the Rust side on getting the rust compiler into all of the major Linux distributions. There's definitely some complexity there, but the Rust community is working hard on doing it before Firefox would require Rust to build by default.

  12. 48? by Anonymous Coward · · Score: 0

    I call BS. Everyone knows Firefox died version 41.

    1. Re:48? by Gavagai80 · · Score: 1

      41? It died for me at version 3.6.

      --
      This space intentionally left blank
  13. Re:I dumped Firefox, and I feel fine by Anonymous Coward · · Score: 0

    Torbrowser works well, the included addons in Tails Linux OS work fine, nothing breaks and no complaints!

  14. Re:Oh, that's just jolly by Anonymous Coward · · Score: 0

    While that reasoning makes perfect sense, there is no alternative that is not at least equally broken.

  15. Re:I dumped Firefox, and I feel fine by Anonymous Coward · · Score: 0

    You run back to your privacy hating ad-broker little boy. Empower those guys, like a complete idiot. Chrome users are the AOL users of yesteryear.

  16. Re:Oh, that's just jolly by NotInHere · · Score: 1

    In fact there is already a debian package of rust: https://packages.debian.org/st...

    And debian means ubuntu and lots of other distros.

  17. I am going back to FF by Anonymous Coward · · Score: 0

    because I closely observe rust and it will make a great product. As for MS "safe" C, it lacks namespaces, and therefore I prefer classical C. If I want "Safe" C, I would write Go.

  18. just because it can't happen doesn't mean it won't by Anonymous Coward · · Score: 2, Informative

    I think the most valuable point to make is that by abstracting buffers in a meaningful way, when hackers eventually figure out how to get past the protection mechanisms... probably by stepping through the rust compiler to find loopholes, a single patch should fix all instances of the vulnerability.

    Also, it should protect against code injection attacks, but it doesn't mean it's a silver bullet. It should still be possible to cause browser crashes due to I handled memory exceptions. Consider an H.264 decoder which makes a large number of branch decisions. Intentionally malicious H.264 data can still cause crashes due to OOM because of long frame sequences that could require the decoder buffers 500 seconds of frames for prediction.

    Also, even when coding in Rust, optimization will be an issue. For application code, no problems. But for decoding images and video, decisions will be made to optimize code which can be performance lethal. If buffer checks are performed every time bits are decoded from the entropy coding mechanism, it could take a LONG time to decode all the bits of a frame. So, programmers will start using C or Assembler (as they always do) to optimize this code.

    Consider that modern browsers also require encoders and performance of a heavily memory checked language will kill it. Even today x264 can't handle real-time with any quality for 4K video on most CPUs and Intel's hardware encoders are extremely poorly optimized for I and P only encoding as required for conferencing.

    The language is certainly not a silver bullet. It's a piece of the solution. What worries me is the crazy thought process people will have about "I'm using Rust, I don't have to think about memory anymore".

  19. Re:just because it can't happen doesn't mean it wo by Anonymous Coward · · Score: 1

    The choice to use Rust for the media stack may indicate that the performance concerns you mention aren't a problem in practice, or at least that the cases where it's a problem can be nested inside an unsafe{} block without significant concern.

    Most of rust's sanity checking happens at compile time, so the performance cost should be 0 in those cases. There's no runtime. It does bounds checking on arrays by default, but those are optimized out if you use iterators or if the compiler can prove that the index is never out of bounds. You can also use the previously mentioned unsafe keyword to skip bounds checking, if you're convinced that you're smarter than the compiler and the checks are causing a noticeable performance impact, though branch prediction on modern processors can alleviate much of the overhead for that.

    There's no shortage of things to criticize about the language, but by all indications I've seen, speed/optimization is not on the list.

  20. Keep it from being rusted by malware by Anonymous Coward · · Score: 0

    See subject: & faster too via APK Hosts File Engine 9.0++ SR-4 32/64-bit http://www.bing.com/search?q=%...

    Ads rob bandwidth/speed, security (malvertising), privacy (tracking) + anonymity.

    Hosts add speed (hardcodes/adblocks), security (bad sites/poisoned dns), reliability (dns down), & anonymity (dns requestlogs/trackers) natively. Hosts != ClarityRay blockable (vs. inferior wasteful redundant slow usermode addons)

    Works vs. caps & HTTP PUSH ads w/ firewalls.

    Avg. webpage = big as Doom http://www.theregister.co.uk/2... & ads = 40% of the size.

    Less power/cpu/ram + IO use vs. DNS/routers/addons/antivirus (slows you) + less security issues/complexity. Compliments firewalls (w/ layered drivers blocking less used IP addys vs. hosts blocking more used domains) & DNS (lightens dns load).

    Gets data via 10 security sites.

    APK

    P.S. - Safe https://www.virustotal.com/en/... (Verified by Malwarebytes' S. Burn "I've seen the code & it's safe" http://forum.hosts-file.net/vi... )

  21. This ignores the rotting elephant in the room.. by hairyfeet · · Score: 1, Insightful

    Which is that JavaScript is toxic and MUST be replaced. You remove JavaScript from the equation? Suddenly all the nasties just disappear.

    So I really don't care what language they write their video player or whatever in because until we deal with the rotting elephant carcass that is JavaScript I just don't see this change doing jack squat in the long run.

    --
    ACs don't waste your time replying, your posts are never seen by me.
    1. Re:This ignores the rotting elephant in the room.. by dremon · · Score: 1

      Javascript can be used simply as a middleware language (or a 'bytecode'), and an application written in strongly-typed language can be simply compiled into it. And most likely that's what will happen.

    2. Re:This ignores the rotting elephant in the room.. by gweihir · · Score: 1

      While I agree that JavaScript is a horrible abomination, so much "enterprise" code these days depends on it that it will take a very long time to go away.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  22. Re:just because it can't happen doesn't mean it wo by garethjrowlands · · Score: 1

    ... "I'm using Rust, I don't have to think about memory anymore".

    Rust is a low level language that forces you to think about memory. It's like a modern C. You can see for yourself how much of the Rust manual deals with memory management. In particular this page shows how the Rust stack and heap are the same as in C: https://doc.rust-lang.org/book... . The thing Rust has over C is a type system that eliminates common classes of bug.
     

  23. Is Rust mature enough to adopt in place of C++? by Anonymous Coward · · Score: 0

    I do a lot of security-oriented C++ programming, and haven't heard of or explored Rust before - is it mature enough, to be used in place of C++, while still allowing the flexibility of C++? Or is it something that should be used only in very specific circumstances? (and on that note - can it be made to bind/intermesh with C++, fairly easily?)

    1. Re:Is Rust mature enough to adopt in place of C++? by Anonymous Coward · · Score: 1

      Start a small project and then grow larger. Do not try to put it into a critical path of your project plan.

      Then I am quite sure it will work as advertised. "Rusting" an existing system is possible, but that is certainly the hardest way to get accustomed to this language.

      Go for a small tools or independent processes, communicating via TCP/IP.

      What you cannot do is the dirty hacks of C and C++. Rust forces common sense practices, something many people find offensive, because they have accustomed themselves with shitty stuff such as pointers into arrays, void*, insane type casts and so on.

      Rust is about robust engineering and requires the fitting mindset.

    2. Re:Is Rust mature enough to adopt in place of C++? by T.E.D. · · Score: 1

      If you want a mature language with all the same design goals as Rust, look at Ada.

  24. Erosion of meaning by thegarbz · · Score: 0

    To be a slave and a follower have two very different meanings. A slave has no choice in his master, a follower chooses who to follow. Which leads me to one of two conclusions:

    Rust handles this relationship differently from other languages and people are having a hissyfit about it without understanding its technological implications.
    or
    Rust is so overcome with political correctness that they are describing a relationship which doesn't exist because someone feels words in the english language should be abolished out of fear that they may offend.

    If it's the latter then Rust should be boycotted in an attempt to prevent stupidity from spreading.

    1. Re:Erosion of meaning by Merk42 · · Score: 1

      If it's the latter then Rust should be boycotted in an attempt to prevent stupidity from spreading.

      Fight fire with fire. Join the Rust community and complain that nearly every command is "triggering". It'll have to go through so many changes to the point of making the entire language unusable.

  25. Re:only an idiot by lucm · · Score: 1

    The real lesson in Star Wars is not the attack surface, it's the fact that when you know about a weak spot you don't have your squadrons of fighters and bombers start at the other end of the ennemy base to make their way under heavy fire and defense and have them mowed down as they approach the target.

    --
    lucm, indeed.
  26. Re:Here we go again by Anonymous Coward · · Score: 0

    http://vignette4.wikia.nocooki...

  27. Re:Here we go again by secretsquirel · · Score: 1

    :D

  28. Re:just because it can't happen doesn't mean it wo by serviscope_minor · · Score: 1

    What worries me is the crazy thought process people will have about "I'm using Rust, I don't have to think about memory anymore".

    I can't imagine anyone who's used rust actually saying that. If you don't think about memory hard enough, the Rust compiler will whine horribly and won't compile your program. That's one of the biggest complaints about it AFAICT!

    --
    SJW n. One who posts facts.
  29. Rust? by QuietLagoon · · Score: 2

    Unwanted iron oxide that is usually scraped away?

  30. Re:Here we go again by TheRaven64 · · Score: 1

    Not me, I want a pony.

    Here you go. I'd also prefer it to Rust.

    --
    I am TheRaven on Soylent News
  31. That's nice by Anonymous Coward · · Score: 0

    I'm still on Firefox 30 to avoid Mozilla's shenanigans, and judging from the browser stats more than 2/3rds of Firefox users intentionally avoid upgrading.

  32. Sure Mr Bell Labs by Anonymous Coward · · Score: 0

    We know you want to keep the world using your Portable Assembler. It makes the work of some of your big brothers easier.

  33. More Precisely by Anonymous Coward · · Score: 0

    99,9% of software engineers labor in some sort of Agile Hamster Wheel, with management trying to speed up the wheel all the time.

    That is why even the experienced guys create boatloads of exploitable bugs when they use C and C++.

    It is a myth that "you can produce error free C code, if you only were diligent enough". In 99.9% of projects there is simply no funding for the diligence required.

    I always find it funny how Magic Things like "high quality" are attached to "agile". The opposite is true - it is the good old Forced Engineering, as in Forced March.

    This world is all about Cheap Engineering, country castles for banksters and five SUVs per M.D.

    1. Re:More Precisely by umghhh · · Score: 1

      Magic thinking is a problem not only in SW development but in any project. In SW projects however the problem usually is that because there is no material cost you can redo things (possibly better) at no cost which of course is not true. Then there are some agile nonsense that have not much to do with the way Toyota did its first 'remove the walls' and use stickers experiment - successful projects are successful because they have luck, good crew and good leaders. How this all is arranged around is not important as long as the way fits the purpose. Doing agile for agile sake is as silly as doing water fall (or whatever other combination of words) for its sake - ideology does not work well in engineering.

  34. Yeah by Anonymous Coward · · Score: 0

    Thanks for spreading Fear, Uncertainty, Doubt here.

    How much does the MIC pay you for protecting C ?

  35. Nice Assassination by Anonymous Coward · · Score: 0

    So the beneficiaries of crap languages now want to paint Rust and Swift "marxist" ?

    Try harder and be notified that you will get back everything, with interest.

  36. So is this one by rossdee · · Score: 1

    version of FF that we should skip?

  37. Oh Boy by Anonymous Coward · · Score: 0

    "Rust" was used because the semi-anon originator of the ideas behind Rust had used different classes of cars in order to try out the type system of the predecessor language of Rust and Swift. Also, the semi-anon guy then lived in the region where cars were invented.

    That's why Mozilla chose the name "Rust", as this is often used in a derogatory way to describe cars.

    Hope this helps you

    the semi anon guy

    1. Re:Oh Boy by mandolin · · Score: 1

      Ummm ... here's better info about why the name was chosen:
      https://www.reddit.com/r/rust/...

  38. Re:only an idiot by Blaskowicz · · Score: 1

    Also when you spend $100 trillion on building some huge moving military base made with a billion tons of steel etc., you'd better defend it with 1000+ Tie fighters not 20 or so.

  39. Re:only an idiot by K.+S.+Kyosuke · · Score: 1

    If only computer systems could be built from a small set of basic elements and a small set of provably-correct rules to build larger structures on top of those. ...oh wait, they can!

    --
    Ezekiel 23:20
  40. I would be excited about this but, by Grand+Facade · · Score: 1

    Firefox routinely crashes on my OSx so much so I have abandoned it.

    --
    Rick B.
  41. Re:I dumped Firefox, and I feel fine by Blaskowicz · · Score: 1

    If you had such special needs and hated the version churn why not use the medium-term support version? (ESR 31.x, 38.x, 45.x)

  42. Re:I dumped Firefox, and I feel fine by Anonymous Coward · · Score: 0

    FYI, firefox will still nag you to update to the latest ESR version (45.02), and you're still vulnerable to any security holes they fix in the latest version.

  43. Nice. What's next? by Anonymous Coward · · Score: 0

    A browser called "The" using the engine "and"

    dicks stuck on stupid.

  44. Rust by jez9999 · · Score: 1

    The only language whose name admits that it's out of date the day it's released.

    --
    == Jez ==
    Do you miss Firefox? Try Pale Moon.