Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hard Rust requirements from May onward

lists.debian.org

Post reply on HN
Print view View original

571–580 of 797 posts

Re: Hard Rust requirements from May onward

#571

Post by richard_todd »

jeffparsons wrote: post #556
richard_todd wrote: post #550

I'm not sure if it's an insecurity thing or an immaturity thing, but when all these stories pop up, I always wonder why rust enthusiasts don't just prove their point by making their own "modern" and non-"retro" tech. If you can make something better, just do it already, and people will switch to it when they see the benefits. This parasitic "you must accept rust in your long-standing project" model is so off-putting,…

This email is from a Debian maintainer, about Debian introducing a new hard dependency on Rust. It's not some random Rust advocate telling Debian folks that they should use Rust against their will. Yes there are absolutely some obnoxious "you should rewrite this in Rust" folks out there, but this is not a case of that.

There are like 1000 Debian maintainers, right? This person doesn't speak for the project as a whole, and as far as I can tell he is telling Debian folks they will be accepting rust whether they want it or not, and whether their preferred architecture is supported or not. Maybe there was some organizational vote on this, but if so it isn't referenced in the thread. It says "I plan", not "Debian decided to".

And regardless, my point is it would be more sensible to say "I'm going to introduce an oxidized fork of apt and a method to use it as your system apt if you prefer" and then over the next year or so he could say "look at all these great benefits!" (if there are any). At that point, the community could decide that the rust version should become the default because it is so much better/safer/"modern"/whatever.

Re: Hard Rust requirements from May onward

#572

Post by aragilar »

viraptor wrote: post #115
aragilar wrote: post #103

Earlier 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…

Owasp deals with web security only. That whole area is biased towards php/ruby/js/python/beam where those issues don't exist outside of native modules. https://www.cvedetails.com/vulnerabilities-by-types.php is a bit more clear. It's xss, SQL, then memory. The first two are not possible to enforce a fix on - you can always make a decision to do something bad with no visible annotation. Even then, rich types like in r…

But how many breaches get CVEs (or are caused by them)? Given how much users (and their data) interact via the web vs any other platform, reducing the breaches of services is going to improve users lives more than reducing the number of CVEs (does mongodb defaulting to not have username/password to access have a CVE).

As for preventing XSS and SQL injections, that's what good web frameworks do. If your framework encourages you to write raw unescaped SQL, or doesn't provide sensible defaults around content policies, then no matter what language it's in, there are going to be issues (and maybe if we called these frameworks "unsafe" then we'd get somewhere with fixing them).

Re: Hard Rust requirements from May onward

#573

Post by ATMLOTTOBEER »

cmm11 wrote: post #54

If anyone has a problem with the language used in the email, I would remind you that this is the same person who is maintainer for debian's keepassxc packages. Here's a thread of them insulting upstream developers & users of the Debian packages. https://github.com/keepassxreboot/keepassxc/issues/10725

You’re right this guy is a dick, as soon as I read this email I went to check who it was and laughed because I remembered that keepers thread.

Re: Hard Rust requirements from May onward

#574

Post by zahlman »

> It's important for the project as whole to be able to move forward and rely on modern tools and technologies and not be held back by trying to shoehorn modern software on retro computing devices.

... This is Debian we're talking about here?

... What distros are recommended for those who intend to continue trying to squeeze utility out of "retro computing devices"?

... And what sort of minimum specifications are we talking about, here?

Re: Hard Rust requirements from May onward

#575

Post by zahlman »

embedding-shape wrote: post #386
jcranmer wrote: post #316

Earlier quoted context omitted.

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…

> Interestingly, I wonder if the debates over the addition of C++, Python, and Perl to the base system language set were this acrimonious. 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…

> 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.

I would say that Pythonistas are quite accustomed to "(other) languages being added" to the Python ecosystem. After all, NumPy relies on Fortran, as well as C.

Asserting that kind of "ownership" over code seems rather distasteful to me. Maybe there would be less acrimony if developers got paid for it somehow.

Re: Hard Rust requirements from May onward

#576

Post by richard_todd »

Seattle3503 wrote: post #569
richard_todd wrote: post #550

I'm not sure if it's an insecurity thing or an immaturity thing, but when all these stories pop up, I always wonder why rust enthusiasts don't just prove their point by making their own "modern" and non-"retro" tech. If you can make something better, just do it already, and people will switch to it when they see the benefits. This parasitic "you must accept rust in your long-standing project" model is so off-putting,…

Thats exactly what happed with ripgrep. People seem to like it.

Exactly! People love ripgrep because of its clear advantages, and had the developers been interested in making posix mode for it, I'm certain at least some distros would have made it the default by now.

Re: Hard Rust requirements from May onward

#577

Post by mkl »

julian-klode wrote: post #514
Defletter wrote: post #184

Earlier quoted context omitted.

The level of knee-jerk reaction to anything Rust into traditionally C projects borders on the pathological. That email is about as polite as it gets without being coddling.

Do keep in mind that a lot of the people involved in these sorts of things are neurodiverse in some ways, and may have significant trouble dealing with change. As teh64 helpfully pointed out in https://news.ycombinator.com/item?id=45784445 some hours ago, 4ish years ago my position on this was a total 360 and I'd have had the same reaction to now-me's proposal.

*180, for other people confused by this.

Re: Hard Rust requirements from May onward

#578

Post by kortilla »

pezezin wrote: post #566
kortilla wrote: post #472

Earlier quoted context omitted.

You would be wrong. People want new software

If we are talking about embedded control systems no, you don't want new software, you want your machine to do what is supposed to do. At my workplace we have some old VME crates running VxWorks, and nobody is gonna update those to the latest Linux distro.

This is incorrect. Internet connections and 3rd party integrations have changed this view of “the software doesn’t need to change once it leaves the factory”.

John Deere, Caterpillar, etc are leaning heavily into the “connected industrial equipment” world. GE engines on airplanes have updatable software and relay telemetry back to GE from flights.

The embedded world changed. You just might have missed it if your view is what shipped out before 2010.

Re: Hard Rust requirements from May onward

#579

Post by jenadine »

embedding-shape wrote: post #386
jcranmer wrote: post #316

Earlier quoted context omitted.

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…

> Interestingly, I wonder if the debates over the addition of C++, Python, and Perl to the base system language set were this acrimonious. 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…

I was (and am still) a C++ person. But I somehow became also a Rust person. I am sure some people felt attacked, but imho Rust has most of the characteristics that made C++ a good language and that's why I "embraced" Rust rather than felt attacked.

Re: Hard Rust requirements from May onward

#580

Post by jrmg »

cbmuser wrote: post #442
jrmg wrote: post #133

Earlier quoted context omitted.

Here’s Debian’s “Supported Architectures”: https://wiki.debian.org/SupportedArchitectures . These platforms are all in ‘unofficial’ status (like, they work, but are not officially supported by the core Debian project). Who is actually _running_ Debian Trixie on these platforms now? It is counter-intuitive to me that these platforms are still unofficially supported, but 32-bit x86 [edit: and all MIPS architectures!] a…

They’re not going to fall to the wayside, we’re eventually getting Rust support on these. It’s just a bit annoying that Rust proponents are being so pushy in some cases as if Rust was the solution to everything.

Can you actually install Debian on an Amiga - or other 68k system - now? I’ve been searching around the web and I haven’t found much evidence that you can.

This is not intended to bash you or anyone else who’s working on it - I think it’s a cool project (I have in the recent past got an 86duino ZERO to run Gentoo, just to see if an obscure old-ish piece of hardware can be useful with modern Linux on it - and it can). I do understand the reason a project like Debian might not want to have to spend resources even just to make it easier to do though.

Post reply on HN