331–340 of 797 posts
What's the long-term play for Canonical here?
Earlier quoted context omitted.
Not a Rust or even a systems language guy but it’s not “for some reason”. The reason is actually incredibly clear and about removing the single largest surface area of security problems in the entire history of Linux.
> The reason is actually incredibly clear There is no guarantee that other bugs do not flurish in the rust echosystem. There are no publicly known quality code checks of rust programs except a big "trust us"(see firefox with all its CVEs, despite "rust"). And combined with the Cargo echosystem, where every malicious actor can inject malware is a big warning sign.
Firefox is not even close to 100% Rust.
This is a wildly misinformed comment.
It's about time. Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. It's not as if Rust is that much more difficult to write than C. Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. If 32-bit x86 support can be dro…
Earlier quoted context omitted.
I find Rust much easier to write than C. Its types let me be reasonably sure I’ve written appropriate code before I even get to the point of running tests, and I don’t have to memorize the flow of the whole program to have that assurance. For instance, struct Feet(i32); struct Meters(i32); fn hover(altitude: Meters) { println!("At {} meters", altitude.0); } fn main() { let altitude1 = Meters(16); hover(altitude1); le…
It would've saved the Mars Climate Orbiter: https://en.wikipedia.org/wiki/Mars_Climate_Orbiter > An investigation attributed the failure to a measurement mismatch between two measurement systems: SI units (metric) by NASA and US customary units by spacecraft builder Lockheed Martin.[3]
> ... 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 worriers and doubters "prove something was wrong," even though classic and fundamental principles of mission safety should have demanded that they themselves, in the presence of significant doubts, properly "prove all is right" with the flight
Dropping units on the NASA side also was problematic but really culture was the cause of the actual crash.
[0] https://spectrum.ieee.org/why-the-mars-probe-went-off-course
Earlier quoted context omitted.
Is it just the "retro-computing hobby"? There could still be businesses who might need support for old machines, especially in developing countries. I don't know the actual situation though, I'm open to the idea that my suggestion is insane.
It's much more common to find businesses running on very old hardware in developed countries, not in developing ones. Developing nations basically didn't use computers 20-30 years ago, there's no random remnants from that era beyond some extreme tail end. And, given how the PC & server market evolved in the 2000s and 2010s, it was cheaper to buy a then-current x86 than to import some ancient Alpha system from whereve…
There's a non-negligble amount of "handed-down" refurbished hardware from developed to developing. PCs and servers that are already 5+yo and out of market at installation.
Earlier quoted context omitted.
Yes that's true and there's synergies but keep in mind I also have a personal mind
[flagged]
> Assume good faith.
Earlier quoted context omitted.
This whole it used to be different thing is looking back with rose tinted glasses. It’s always been the case that project maintainers were able to make choices that the community didn’t necessarily agree with, corporate backed contributors or not, and it’s still a possibility to fork and try to prove out that the other stance is better. Nobody is being forced out of the community, you can fork and not adopt the chang…
The point of freedom in software is certainly that I can create my own fork. And individual projects a maintainer can certainly do what he wants. But it is still worrying if in community projects such as Debian when decisions that come with a cost to some part of the community are pushed through without full consensus. It would be certainly not the first time. systemd was similar and for similar reasons (commercial i…
You describe it that way, but that's not how the world in general works in practice. You do things based on majority.
Earlier quoted context omitted.
Ferrous Systems donated their language specification ("Ferrocene") to the Rust foundation[0] who is working on integrating it but that takes time, obviously. 0: https://rustfoundation.org/media/ferrous-systems-donates-fer...
Their spec just happens to describe whatever the compiler decided to implement, it's not a source of truth.
Earlier quoted context omitted.
> basically fine How many type confusion 0 days and memory safety issues have we had in dynamic language engines again? I've really lost count.
Are you counting ones that involve running malicious code in a sandbox and not just trusted code on untrusted input? Because then I'd agree, but that's a much harder and different problem. My impression is that for the trusted code untrusted input case it hasn't been that many, but I could be wrong.
It makes me uncomfortable that this mandate is coming from a Canonical employee. After all, if this switch was a good idea on merit alone, it would happen organically without requiring this kind of combative communication. What's the long-term play for Canonical here?
The obvious potential motivations are things like making a more reliable product, or making their employees more productive by giving them access to modern tools... I guess I could imagine preparing for some sort of compliance/legal/regulatory battle where it's important to move towards memory safe tooling but even there I rather imagine that microsoft is better placed to say that they are and any move on canonical's part would be defensive.