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

721–730 of 797 posts

Re: Hard Rust requirements from May onward

#721

Post by dvtkrlbs »

aragilar wrote: post #584
dvtkrlbs wrote: post #271

Earlier quoted context omitted.

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

I don't agree with openssh take but yeah we don't need to migrate everything to rust and yeah a migration not always goes smoothly I am using sudo-rs on my arch install for over a year havent had any issues yet.

Re: Hard Rust requirements from May onward

#722

Post by thiht »

egorfine wrote: post #183

I'm happy for all developers programming in their favorite programming languages. Programming for over 30 years I have seen entire ecosystems come and go. What I don't get is the burning need for Rust developers to insult others. Kind of the same vibes that we get from systemd folks and LP. Does it mean they have psychological issues and deep down in their heart they know they need to compensate? I remember C vs Pasc…

> What I don't get is the burning need for Rust developers to insult others

... where?

Re: Hard Rust requirements from May onward

#723

Post by burntsushi »

larusso wrote: post #694
9dev wrote: post #489

Earlier quoted context omitted.

> why not simply write something new. Because of backwards compatibility. You don’t rewrite Linux from scratch to fix old mistakes, that’s making a new system altogether. And I’m pretty sure there are some people doing just that. But still, there’s value in rewriting the things we have now in a future-proof language, so we have a better but working system until the new one is ready.

Sorry. I will answer on this because I feel people got a bit hung up on the “new” thing. Might be a language barrier. I really understand the reasons why with backwards compatibility etc. The point I tried to make is that we really spend tons of time either to maintain software that where written or “born” 50 or so years ago or rewrite things in the same spirit. I mixed my comments wit the the security aspect which m…

Writing tools that are POSIX compatible doesn't mean one puts it on the pedestal of the "holy grail of OS design." I've certainly used POSIX to guide design aspects of things I build. Not because I think POSIX is the best. In fact, I think it's fucking awful and I very much dislike how some people use it as a hammer to whinge about portability. But POSIX is ubiquitous. So if you want your users to have less friction, you can't really ignore it.

And by the way, Rust didn't invent this "rewrite old software" idea. GNU did it long before Rust programmers did.

Re: Hard Rust requirements from May onward

#724

Post by steveklabnik »

_kidlike wrote: post #689
steveklabnik wrote: post #464

Earlier quoted context omitted.

It’s been ten years since Rust 1.0, if that were to happen, we’d be seeing it now. But we don’t.

but we do... 4 years after Rust, we got a first glimpse at Zig. Even today, there's a lot of people that believe that Zig would have been a better choice for the Linux kernel than Rust. And the answer to "why now" is quite simple - Because of the whole Rust in kernel debate, people started scrutinizing the situation.

Then Zig people should be the focus of “this kids and their new shiny” criticism, not Rust.

People who become aware of something only when it’s being used by something huge also aren’t early adopters either. Rust has already been in the Windows kernel for years at this point, with none of this consternation.

Re: Hard Rust requirements from May onward

#725

Post by bfkwlfkjf »

noir_lord wrote: post #212
bfkwlfkjf wrote: post #145

Earlier quoted context omitted.

[flagged]

I think that's unkind absent any proof otherwise which you haven't posted. In reality a lot of the heavily used parts of Linux (and open source generally) are going to have some commercial involvement or are we suggesting that no one should be paid by any of the companies backing Linux who use Linux because to me that sounds worse . Whether you like it or not, Linux/Open Source hasn't been entirely the preserve of un…

My whole point, which you've missed, is that the _interest_ is what we should be looking at. I don't care if he says he does or doesn't act on it. He has the interest.

Re: Hard Rust requirements from May onward

#726

Post by steveklabnik »

mgh95 wrote: post #379
cmrdporcupine wrote: post #327

Earlier quoted context omitted.

You can absolutely use rustc without Cargo and there's frankly plenty of arguments for doing so in the context of embedded.

Large parts of tooling dependent on cargo; for examples, lsp, analyzer, etc. Once you take out cargo, rusts development environment becomes quite poor.

This is also just a matter of work, for example, the Buck folks have put in the work so that rust-analyzer works well with projects based on it.

Re: Hard Rust requirements from May onward

#727

Post by jstimpfle »

paulf38 wrote: post #663
zenxyzzy wrote: post #501

Rust evangelists are tiresome. It's not gonna fix the tech debt problem, No matter how much rust crack you smoke. Disciplined use of c, with modern tools like valgrind, will give you safe code without having to lobotomize yourself into fighting the borrow checker for everything, even manifestly simple code.

It would be nice (speaking as a Valgrind developer) if Valgrind could guarantee safe code. Unfortunately it doesn’t. Firstly, it does not detect all kinds of errors (and indeed no tool does). Secondly, it is unlikely that the test coverage is perfect. Delusional overconfidence that developer “skill” is all that is needed to overcome the many shortcomings of C is not a solution to the problem of guaranteeing security…

I find it surprising hearing statements like this from a developer of a tool for, well, C programmers mostly I guess? "Skill is all that is needed to prevent bugs and produce bug-free software" is a phrase I've never heard from an actual C programmer, but have heard plenty of times from detractors.

The C programmers I know are certainly not deluded or overconfident. They don't even think "their" language is a perfect one, or even a very good one. They just avoid black-and-white thinking. They take a practical approach about memory issues, seeing them more like any other kind of bug. It's a different aesthetics than you would maybe see from many Rust folks. They want to be productive and want to be in control and want to understand what their code does. In turn, they accept that in some cases, bugs (possibly memory bugs) creep in, some of which could go unnoticed for some time. They tend to not see that as a huge issue, at least in general, because an issue that has gone unnoticed (or didn't manifest) is often less of a problem than one that is immediately obvious. (In case of data corruption, it _can_ be a huge issue, and you have to add safeguards to prevent it, and have to be accepting some residual risk).

They understand that everything is a trade off and that with experience and practice, good architecture, good tooling etc. you can prevent many bugs early, and detect them early. They have tried many approaches to prevent bugs, including fancy languages and constructs, and have concluded that in many cases, perfect safety is not possible, in particular it's not possible without seriously hurting other requirements, such as productivity.

As to valgrind, I can say that it was a bit of a mixed bag for me. It did help me finding bugs a number of times, but I also had to configure it a bit because it was producing a lot of noise for some external libraries (such as libc). I don't really understand the underlying issues.

Re: Hard Rust requirements from May onward

#728

Post by jodrellblank »

dokyun wrote: post #695
jodrellblank wrote: post #453

Earlier quoted context omitted.

> Rust isn't 'delivering value' Citation needed. Or, what can be asserted without evidence can be dismissed by pointing to ripgrep.

Oh wow a replacement for a tool I already have. It's slightly faster, even if I seldom ever worry about its speed. Who cares?

57000 people who have starred its repository on Github care.

More evidence than you have provided for your claim "Rust isn't delivering value", what did you use to come to that conclusion?

Re: Hard Rust requirements from May onward

#729

Post by krautburglar »

doubletwoyou wrote: post #560
krautburglar wrote: post #81

I think polyglot causes more problems than it solves. It is gross how many different toolchains and package managers it now takes to build a distro. One person wants python, another wants node, another wants go, and now this. with node we traded buffer overflows for supply chain attacks. If they don’t want C, it would be better to start fresh. Robert Morris re-wrote enough of Linux in golang to be usable, and the ove…

Unfortunately, the world is a complicated place and each one of these languages have their own benefits and tradeoffs that suit themselves to one particular language or another (ask an ML scientist to switch to raw C), leading to all of these languages having a valid place in the pantheon of softwares (except maybe for js). Since debian is a pragmatic OS, it needs to adapt to solve for the real problem of being gener…

Applications vs Infrastructure: When stand-alone applications are in completely different languages, that is normal and reasonable and fine. When it takes 5-10 different programming languages just to build and manage the base system, that is an engineering failure and a mess.

Re: Hard Rust requirements from May onward

#730

Post by throwaway7356 »

remexre wrote: post #547
cbmuser wrote: post #438

Earlier quoted context omitted.

> Who is still using these machines? Genuine question, not trolling. Well, there are so many things were you could argue about the relevance of a userbase. If the size of a userbase would be the only argument, Valve could just drop support for the Linux userbase which is just 2-3% of their overall userbase.

Are there even close to 2% of Debian users using a DEC Alpha?

popcon.debian.org reports 3 alpha installations and 261750 amd64 installations. Assuming comparable opt-in rates there are less than 0.002% of the users using alpha.

The other mentioned architectures hppa, m68k and sh4 are at a similar level.

Post reply on HN