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

701–710 of 797 posts

Re: Hard Rust requirements from May onward

#701

Post by spacechild1 »

alserio wrote: post #672
spacechild1 wrote: post #636

Earlier quoted context omitted.

Ah, now I realize that you don't necessarily meant something like an ISO standard. I definitely agree that a programm language should have some kind of normative specification and it's not sufficient to say "the spec is the behavior of the compiler". > Again, I ask for a reference, "according to what?" I understand this is the zeitgeist. I think that at this point it is pretty well-established that the majority of se…

Can I ask what that domain is?

Audio and multimedia art.

Re: Hard Rust requirements from May onward

#702

Post by [deleted] »

jurschreuder wrote: post #667
dataflow wrote: post #648

Earlier quoted context omitted.

> 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. How is language relevant here? If someone just…

This is really a Rust specific thing, since so many C++ projects were 1-on-1 translated to Rust only changing the licence. Rust has been the tool of choice for stealing GPL3 open source projects where some people have spent all their free time on at some point in their life.

[deleted]

Re: Hard Rust requirements from May onward

#703

Post by noisem4ker »

hunterpayne wrote: post #630
tempest_ wrote: post #241

Earlier quoted context omitted.

From the outside looking in most of the push back against rust seems to be of the "I am too old, never make mistakes, and don't want to learn a new thing late in my career" variety. I have rarely seen an argument that pushes back against Rust with actual alternative solutions to the problems the rust proponents are trying to solve. It is mostly a bunch of old people letting the perfect be the enemy of the good.

I think you got your last sentence backwards. Because reading it literally, you mean what we have now is perfect. If that's the case, switching to Rust is a waste of time.

No, it makes sense to me. Perfect is not what we have now (as evident to everybody outside of the "skill issue" denialists) but how C/C++ or a new language could get up to par with Rust with some enhancement, and without the latter's idiosyncrasies.

Re: Hard Rust requirements from May onward

#704

Post by kees99 »

zahlman wrote: post #603
mike_d wrote: post #570

Earlier quoted context omitted.

> there are approximately five languages that are presumed to be acceptable for core applications in the base system: [...] Python I don't know if you've tried to get someone else's Python running recently, but it has devolved into a disaster effectively requiring containers to accurately replicate the exact environment it was written in. Core system applications should be binaries that run with absolutely minimal de…

> I don't know if you've tried to get someone else's Python running recently, but it has devolved into a disaster effectively requiring containers to accurately replicate the exact environment it was written in. Please show me a project where you believe you "effectively require containers" just to run the code, and I will do my best to refute that. > since we no longer live in a storage constrained world. I think yo…

> Please show me a project where you believe you "effectively require containers" just to run the code

I guess GP meant "containers" broadly, including things like pipx, venv, or uv. Those are, effectively, required since PEP 668:

https://stackoverflow.com/questions/75608323/how-do-i-solve-...

Re: Hard Rust requirements from May onward

#705

Post by atoav »

zahlman wrote: post #625
atoav wrote: post #207

Earlier quoted context omitted.

I program mostly Python, C, C++, Javascript and Rust. Including on embedded (that goes for C, C++ and Rust) Most people nowadays who criticize Rust do so on a cultural basis of "there are people who want this so and it changes things therefore it is bad". But never on the merits. Rust is a good language that contains in its language design some of the lessons the best C programmers have internalized. If you are a ste…

> a cultural basis of "there are people who want this so and it changes things therefore it is bad". But never on the merits. In this mindset, arguing against change is an argument on the merits. Because everything you spend time on has the opportunity cost of everything else you could spend time on.

Yes sure, but you got to engage with the arguments on the other side as well. The argument on the other side is that a rewrite is worth it because it prevents entire classes of memory leaks that are still to this day leading the exploitable CVE lists.

We could now pretend their position is: "Oh, we got this shiny new language that magically makes everything 100% safe and thus we need to rewrite everything." But that is not the position. Most of them are aware that a rewrite is always a trade-off. You could reintroduce old bugs etc.

As I said, I program languages on both sides on the divide and if I had to write and maintain secure software that my life depended on I would certainly prefer to write it in Rust. Memory safety would be just a tiny part of that. The other factors would be the strict type system (can be used to enforce certain guarantees that contributers cannot easily fuck up) and the tooling (the builtin testing is stellar).

The future of tooling is going to be written in the language people of the coming generations like to write. There was a time when C++ or even C was the new shiny thing. Why can't we just write all software in assembly like in the good old days? Because there were some actual tangible benefits to doing it in C and that's the language people with the ability of doing the job chose.

I am not saying a Rust rewrite makes sense in every case, but if you check the past decade of CVEs on a project and half of them would have been prevented by the vanilla Rust compiler maybe that's the rational thing?

Re: Hard Rust requirements from May onward

#706

Post by spacechild1 »

spacechild1 wrote: post #636
themafia wrote: post #583

Earlier quoted context omitted.

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

Ah, now I realize that you don't necessarily meant something like an ISO standard. I definitely agree that a programm language should have some kind of normative specification and it's not sufficient to say "the spec is the behavior of the compiler". > Again, I ask for a reference, "according to what?" I understand this is the zeitgeist. I think that at this point it is pretty well-established that the majority of se…

To be clear: I definitely don't think that all C or C++ code should be rewritten in Rust. But for components that are exposed to the public internet or accept untrusted user input it totally makes sense.

Re: Hard Rust requirements from May onward

#707

Post by bonzini »

bgwalter wrote: post #499
jeroenhd wrote: post #437

Earlier quoted context omitted.

If only more people were willing to let their opinions be changed over time like that, rather than clinging onto them.

If only a reason were given. This is the original: > Rust is a security nightmare. We'd need to add over 130 packages to main for sequoia, and then we'd need to rebuild them all each time one of them needs a security update. What has changed? Why is 130 packages for a crypto application acceptable?

Probably because 120 (*) have been added in the intervening 4 years.

(*) random number

Re: Hard Rust requirements from May onward

#708

Post by t43562 »

gspr wrote: post #699
t43562 wrote: post #690

Earlier quoted context omitted.

When the primary documentation is of no use one looks for anything else that can possibly help and a lot of that is out of date.

What's wrong with the primary documentation?

I was doing this months ago and have forgotten every twisty road I went down but I wanted to produce a binary package for a particular version of Ubuntu (and or Debian) and put it in a PPA so that people could use my code easily. It seemed like the rules file could be anything and I wouldn't have to implement a lot of targets that are either irrelevant or hard to understand the purpose of. So I used a script. Mistake - makefiles now seem to be the thing.

I struggled over how to layout the directories in my GIT repo. The fact that I want to build from the git repo is another layer of confusion - as opposed to building from a tarfile. I'm making something unstable for other developers right now, rather than a stable releasable item.

The next bit of extreme confusion is .... where should my package's install target put the binary plugins I built. I'm not going to try to go back and check over this in detail but as far as I remember the docs were very unspecific about that as if it could be anywhere and different user docs on the net seemed to show different things.

I got to the point where I could appear to build the thing on my machine but that's not good enough - the PPA has to be able to do it and then you've got to upload, wait and hope the log explains what's wrong well enough.

I tried looking at other packages - I'm building plugins for GNU make so I tried that - but it was using the build from tar approach (IIRC) and was way overcomplicated for my very simple package which is just a few .so files in a directory.

It took me a couple of weeks of messing around with every possible option to get this far and I just ran out of energy and time. I am not a beginner at programming - only at packaging - so IMO there is a great deal that could be done for the user experience. Don't get me wrong - I'm not picking on .deb. RPM is another incredibly horrible packaging system where every tiny mistake can force a long long long rebuild.

They're obviously complicated because they're trying to offer a lot and e.g. Artix doesn't use selinux so there's one misery avoided straight away but it has a consequence.

IMO the core docs just don't prevent any of this confusion. They seem like a reference for people who already know what they're doing and enough tutorial for a very specific simple case that wasn't mine. People wouldn't bother to write their own tutorials if the docs filled the need.

Re: Hard Rust requirements from May onward

#709

Post by illuminator83 »

uecker wrote: post #682
physicsguy wrote: post #666

Earlier quoted context omitted.

pkg-config isn’t the hard bit though, is it? Usually the hard bit with C libraries is having dependencies with dependencies all of which use their own complex build systems, a mix of Make, CMake, Autotools, Ninja, etc. Then within that for e.g. a mix of using normal standard names for build parameters and not e.g. PROJECTNAME_COMPILER instead of CMAKE_C_COMPILER

The package manager takes care of the dependencies. And one does not need to compile the libraries one uses, so how complicated this is does not matter. I install the -dev package and I am done. This works beautifully and where it does not the right move would be to fix this.

I think in most of my projects, many of the C++ packages I used for work (lots of computer vision, video codecs etc) I had to compile and host myself. The latest and greatest of OpenCV, dlib or e.g. gstreamer weren't available on the distros I was using (Ubuntu, Fedora, Centos). They'd lag a year or more behind sometimes. Some stuff was outright not available at all via package manager - in any version.

So, yes, you do have to figure out how to build and package these things by yourself very often. There are also no "leftpad" or similar packages in C. If you don't want to write something yourself.

In constrast - virtually every software package of any version is available to you in cargo or npm.

Re: Hard Rust requirements from May onward

#710

Post by bhaak »

jrmg wrote: post #580
cbmuser wrote: post #442

Earlier quoted context omitted.

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

Here is a recent blog post where somebody tried to install Debian on an Amiga 4000 with an 68040 running at 25 MHz.

https://sandervanderburg.blogspot.com/2025/01/running-linux-...

I didn't find what Debian version they tried but I think it's implied it's a recent version. They ran into memory issues. They had only 48MB while the recommendations are to use 64MB. It did boot though until it threw errors because of memory constraints.

They got a working system by trying Debian 3.1 though.

Post reply on HN