Earlier quoted context omitted.
You’re the one that said ten years.
You're the one who said "ten years since Rust 1.0 "
The person who they replied to stated a decade. This whole thing is pretty clear cut and dry.
Hard Rust requirements from May onward
581–590 of 797 posts
Re: Hard Rust requirements from May onward
#582Re: Hard Rust requirements from May onward
#583Earlier quoted context omitted.
> It's not as if Rust is that much more difficult to write than C According to what? > Rust is explicitly designed There is no standard. It's accidentally designed. > knowing what we know now about language design and code safety. You've solved one class of bugs outside of "unsafe {}". The rest are still present.
> There is no standard. It's accidentally designed. Are you really claiming that you can't design a language without an official standard? Not to mention that C itself has been designed long before its first ISO standard. Finally, the idea that a standard committee is a preconditionfor good language design is rather bold, I have to say. The phrase "design by committee" isn't typically used as a compliment... > You've…
> that you can't design a language without an official standard?
No, just that it's not 1968 anymore, and if you want to claim your language has learned lessons from the past, then this is one that clearly got missed.
> The phrase "design by committee" isn't typically used as a compliment...
While the phrase "emergent incompatibilities" is only known as a detriment.
> It's "only" the single most important class of bugs for system safety.
Again, I ask for a reference, "according to what?" I understand this is the zeitgeist. Is it actually true? It seems to me this great experiment is actually proving it probably isn't.
> This kind of deflection and denialism isn't helping.
Once again, I asked for proof that the claim was true, you've brought nothing, and instead have projected your shortcomings onto my argument.
> And I'm saying this as someone who really likes C++.
Have you ever pushed for C++ to replace C programs because you assume they would be "better" according to some ill defined and never measured metrics?
Re: Hard Rust requirements from May onward
#584Earlier quoted context omitted.
Is it the largest though? Based on https://owasp.org/www-project-top-ten/ , it would be part of #6 or #8. While one can always walk and chew gum at the same time (and those rewriting system software are likely not the same people who need to design systems with less flawed access control), replacing stable software is not without risk (e.g. https://lwn.net/Articles/1043103/ , which is an instance of #6 caused by rust…
Pretty consistently [1] [2] [3] [4] it comes out that nearly %80 of security vulnerabilities come from memory safety vulnerabilities. I would consider that largest. Especially Microsoft's doc is pretty telling that this ratio was pretty consistent since 2006 so no amount of external tooling and training solves this. [1] https://langui.sh/2019/07/23/apple-memory-safety/ (albeit apple solving this with an another langu…
In which code though? What counts as a security vulnerability (does the design of the play store such that searching for an app and the top result not being that app count)? I like everyone else want a secure browser, but my secure browser isn't going to prevent my email (or passwords) from appearing on https://haveibeenpwned.com/. I like rust, and want to write more rust, but if I were to port openssh to rust, I guarantee my rust code would have more CVEs than openssh.
My feeling is in the specific instance of using rust in apt, this is most likely a good thing (though I hope existing well tested rust libraries are used rather than NIHing them and introducing new bugs), but so far Ubuntu's rustification has not gone smoothly, so I'm more wary of the changes that e.g. improvements to Firefox via rust.
Re: Hard Rust requirements from May onward
#585Earlier quoted context omitted.
The author's benchmarks suggest 10× would be a pathological case! But even so - what price correct & secure software? We all lost a tonne of performance overnight when we applied the first Meltdown and Spectre workarounds. This doesn't seem much different.
We have an alternative that isn't 10x slower, and comes with many other benefits (Rust). The only cost is losing hardware support for some very obsolete and very unpopular platforms. (Nevermind that Fil-C's hardware support is narrower than Rust's.)
Rust doesn't automatically add memory safety to all existing C code, which will need to be maintained for decades, Fil-C nearly does and its still early days.
> We have an alternative that isn't 10x slower, and comes with many other benefits
Anyone involved with development around a fruity company would say Swift ;)
Re: Hard Rust requirements from May onward
#586Earlier quoted context omitted.
> are pushed through without full consensus You describe it that way, but that's not how the world in general works in practice. You do things based on majority.
No, this is not how you do things in a functioning community. You do things based on societal contracts that also protect the interests of minorities.
I cannot fathom using the rest of my Saturday attempting to break down the level of spin you’re trying to play at here.
Re: Hard Rust requirements from May onward
#587Earlier quoted context omitted.
That was only the proximate cause, the ultimate cause was cultural. As complex systems and efforts run into problems, it is trivial to blame the unit conversion when they had been ignoring people for months who had concerns [0] > ... ground controllers ignored a string of indications that something was seriously wrong with the craft's trajectory, over a period of weeks if not months. But managers demanded that worrie…
That's technically true, but if NASA's API accepted arguments in Meters instead of int32_t (or whatever the equivalent was in the language they used), then it would've been instantly obvious that the controller code that Lockheed Martin wrote was using the wrong datatype.
Do we know how the code was called, was it linked in or was it via IPC (the latter seems most likely to me, and then the question is does the IPC framework support a rich type system)?
Re: Hard Rust requirements from May onward
#588Earlier quoted context omitted.
The actual Intel 80386 processor was discontinued in 2007, but the i386 architecture -- ia32, 32-bit x86 -- lived on for longer in the semi-mainstream (there were 32-bit Intel Atoms introduced to the market as late as 2012, AMD Geodes were sold until at least 2019, and I believe some VIA C3/C7 derivatives made it into the 2010s as well) and is in fact still in production to this day for the embedded and industrial ma…
All of those are i586 or i686 though right? AMD Geode LX is the only i586 CPU produced in the last 15 years. Everything else is at least i686 and Rust has perfectly adequate i686 support. Is there any major distro left with pre i686 support?
Debian's i386 is actually i686 I believe.
Re: Hard Rust requirements from May onward
#589Earlier quoted context omitted.
I meant, that email literally ask the fellow developer to either finish the Rust port or sunset the debian port in 6 months. I am asking if the former option is a practical one
I believe m68k already has a working Rust compiler of sorts, though it's not part of the default Rust chain. I think shaping that fork into something that will let it run and compile like normal is feasible. For other architectures currently unsupported by Rust, I doubt it'll happen. The CPU architectures themselves are long dead and often only used for industrial applications, so the probability of hobbyists getting…
In that case, the "6 months" deadline for non-m64k is just a false option.
I would consider that a passive-aggressive or an insult
Re: Hard Rust requirements from May onward
#590Earlier quoted context omitted.
Anyone capable of programming and willing to invest enough time will be able to learn Rust, in my opinion. It might take some people months rather than days, but I think that is a desirable outcome. Important low level software should be written by competent developers willing to invest the effort.
The effort should rather be invested into learning how underlying hardware works and introducing redundancy and observability into the system.
That's non-sequitur.
The problem here is that C is too basic, dated, with inadequate higher-level abstractions, which makes writing robust and secure software extra difficult and laborious. "Learning underlying hardware" doesn't solve that at all.
Debian supports dozens of architectures, so it needs to abstract away architecture-specific details.
Rust gives you as much control as C for optimizing software, but at the same time neither Rust nor C really expose actual underlying hardware (on purpose). They target an abstract machine with Undefined Behaviors that don't behave like the hardware. Their optimisers will stab you in the back if you assume you can just do what the hardware does. And even if you could write directly for every logic gate in your hardware, that still wouldn't help with the fragility and tedium of writing secure parsers and correct package validation logic.