381–390 of 797 posts
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.
Aren’t m68k computers only a few models from the 1990s and 1980s, and some more recent hobby projects? That’s squarely in the retro computing enthusiasts category. I’m not in the Debian world, but those do seem to me like the types of systems that could use their own specialized distros rather than being a burden to the mass market ones. It’s not as if you could run a stock configuration of any desktop environment on…
m68k is used in a number of embedded systems today. It is unknown (to me) how many of those run linux (as opposed to some other embedded OS), but I would guess at least some do. I also don't know how many run (or want to run) debian vs something else (a custom yacto distribution is my first guess), but that might be non-zero. It is possible someone is running a non-debian distribution and using debian packages to pro…
But I'm not sure. I think the new Rust dependencies are good. In an ideal world, the people who care about niche systems step up to help Rust target those systems.
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…
> In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages > 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. But hasn't all that foundational code been stable and wrung out already over the last 30+ years? The .tar and…
Additionally, the fact that this comes across as so abrasive and off-putting is on brand for online Rust evangelicalism.
Earlier quoted context omitted.
Ada and SPARK fulfilled the promise of a safe systems language decades ago without making most of the mistakes Rust does. Rust has its strong sides, sure, but it's far from the only shop in town. The GCC happens to include an Ada compiler as well.
The problem is they forgot about making the language approachable so it lives in its bubble for safety criticial usage (which Rust kinda starting to eat its lunch from with the certified Rust fork)
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…
Right now, there are approximately five languages that are presumed to be acceptable for core applications in the base system: C, C++, Shell (which probably means specifically bash), Perl, and Python. The most recent language to be added to that list is Python, about 20 years ago. That's not to say that everybody likes those languages (indeed, there's quite a few commenters here who I think would be surprised to lear…
I think any projects that are run by people that see themselves as "X-people" (like Python-people, Perl-people) always have a bit "ick" reaction to new languages being added to projects they might see as part of a language's community.
So say you're a C++ developer, contributed to APT over the years, see all of it linked to the C++ community which you are part of too, and someone wants to start migrating parts of it to Rust/$NewLang. I think it might sometimes affect more for these people than just the code, might even be "attacking" (strong word perhaps) their sense of identity, for better or worse.
Earlier quoted context omitted.
The Fil-C project ( https://fil-c.org/ ) seems like a more pragmatic way to deal with C security holes in old, well-loved userspace code. It effectively turns C into a managed language rather than a bare metal one, seems to remove a lot of the impetus to rewrite.
I really like the idea of Fil-C for derisking legacy code, but - It's not an option for debian core infrastructure until it supports at least the same platforms debian does (arm, riscv, etc) and it currently only supports x86_64. - It doesn't turn C into a modern language, since it looks like there's active development here getting the productivity benefits of moving away from C is likely still worth it.
Earlier quoted context omitted.
The Fil-C project ( https://fil-c.org/ ) seems like a more pragmatic way to deal with C security holes in old, well-loved userspace code. It effectively turns C into a managed language rather than a bare metal one, seems to remove a lot of the impetus to rewrite.
Making core package infrastructure 10x slower doesn't seem especially pragmatic.
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.
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…
Sadly most people don't agree with this I have been seeing hatred on this forum towards Rust since long time. Initially it didn't make any kind of sense. Only after actually trying to learn it did I understand the backlash. It actually is so difficult, that most people might never be able to be proficient in it. Even if they tried. Especially coming from the world of memory managed languages. This creates push back a…
I think this is more true of C than it is of Rust if the bar is "code of sufficient quality to be included in debian"
Earlier quoted context omitted.
What part of C package management defends against supply chain attacks? Does it audit third-party code for you?
I think it's mostly the fact that C dependencies are much rarer and much harder to add and maintain. The average C project has at most a handful of other C dependencies. The average Rust, Go or NodeJS project? A couple hundred. Ironically, because dependency management is so easy in modern languages, people started adding a lot of dependencies everywhere. Need a leftpad? Just add one line in some yaml file or an "Alt…