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

791–797 of 797 posts

Re: Hard Rust requirements from May onward

#791

Post by larusso »

larusso wrote: post #790
burntsushi wrote: post #763

Earlier quoted context omitted.

So then your original comment should be amended to say, "and this is actually all fine when the authors use a license I personally like." So it's not actually the rewriting you don't like, but the licensing choices. Which you completely left out of your commentary. You also didn't respond to my other rebuttal, which points out a number of counter-examples to your claim. From my view, your argument seems very weak. Yo…

Sorry I didn’t response by intention. The thing with the license I actually didn’t bring up because I totally forgot about this part of the discussion. I saw comments a few weeks back going into the fact that it’s not just a rust rewrite but also a relicense with maybe shady intend. I don’t know. I don’t know much about this. To your comment. I don’t know when I actually did any claims? Nor did I claim that a rewrite…

Damn I wanted to write “not with intention”.

Re: Hard Rust requirements from May onward

#792

Post by pornel »

curt15 wrote: post #130
zozbot234 wrote: post #42

Earlier quoted context omitted.

m68k has a LLVM port already, so Rust can be implemented for that platform.[0] It would be nice to have LLVM backends for alpha, hppa and sh4 - these older architectures tend to be quite simple so a working LLVM has plenty of value as a reference and for educational use. (LLVM even used to have an in-tree DEC Alpha backend, though that was back in 2011 and not relevant to any version of Rust.) [0] Looks like there is…

Shouldn't the codegen_gcc project[1] theoretically allow Rust to target backends that only GCC supports? [1] https://github.com/rust-lang/rustc_codegen_gcc

The GCC backend makes Rust for Dreamcast work: https://www.dreamcast.rs/

(not relevant to Debian, but cool that it's already possible)

Re: Hard Rust requirements from May onward

#793

Post by pornel »

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?

Debian's tooling for packaging Cargo probably got better, so this isn't as daunting as it used to be.

Another likely thing is understanding that the unit of "package" is different in Rust/Cargo than traditionally in C and Debian, so 130 crates aren't as much code as 130 Debian packages would have been.

The same amount of code, from the same number of authors, will end up split into more smaller packages (crates) in Rust. Where a C project would split itself into components internally in a way that's invisible outside (multiple `.h` files, in subdirectories or sub-makefiles), Rust/Cargo projects split themselves into crates (in a Cargo workspace and/or a monorepo), which happen to be visible externally as equal to a package. These typically aren't full-size dependencies, just a separate compilation unit. It's like cutting a pizza into 4 or 16 slices. You get more slices, but that doesn't make the pizza bigger.

From security perspective, I've found that splitting large projects into smaller packages actually helps review the code. Each sub-package is more focused on one goal, with a smaller public API, so it's easier to see if it's doing what it claims to than if it was a part of a monolith with a larger internal API and more state.

Re: Hard Rust requirements from May onward

#794

Post by burntsushi »

larusso wrote: post #790
burntsushi wrote: post #763

Earlier quoted context omitted.

So then your original comment should be amended to say, "and this is actually all fine when the authors use a license I personally like." So it's not actually the rewriting you don't like, but the licensing choices. Which you completely left out of your commentary. You also didn't respond to my other rebuttal, which points out a number of counter-examples to your claim. From my view, your argument seems very weak. Yo…

Sorry I didn’t response by intention. The thing with the license I actually didn’t bring up because I totally forgot about this part of the discussion. I saw comments a few weeks back going into the fact that it’s not just a rust rewrite but also a relicense with maybe shady intend. I don’t know. I don’t know much about this. To your comment. I don’t know when I actually did any claims? Nor did I claim that a rewrite…

> And yes my argument is weak because I’m actually not an expert on core utility development.

Yes, and I'm trying to point out why your argument is weak. You said things like this:

> But I wonder if the core utils which have been rewritten got rewritten by the original maintainers? And again the question why not simply write something new. With a modern architecture etc rather than drop in replacements.

And it honestly just comes across as rather rude. People do write things that are new. People also write things that re-implement older interfaces. Sometimes those people are even the same people.

Like, why are you even questioning this? What does it matter to you? People have been re-implementing older tools for decades. This isn't a new thing.

> Nor did I claim that a rewrite is fine when it’s changing to a license I like.

When I pointed it out, your response was, "oh yeah but they did this other thing that made it all okay."

Re: Hard Rust requirements from May onward

#795

Post by torstenvl »

estebank wrote: post #320
torstenvl wrote: post #283

Earlier quoted context omitted.

[flagged]

The disagreement is the difference between "there's an group [the Rust community] going around pushing/bullying projects to use Rust" and "project maintainers want to start using Rust". Those two things get conflated a ton , particularly in this forum by people who have an axe to grind against Rust.

That seems unrelated. Did you mean to respond to someone else?

Re: Hard Rust requirements from May onward

#796

Post by lambdaone »

im3w1l wrote: post #673
zahlman wrote: post #633

Earlier quoted context omitted.

> the essential system Python should be in /usr/sbin There's still quite a bit you can do with the "system Python". Mine includes NumPy, bindings for GTK, QT5 and QT6, Freetype, PIL.... > insofar Python allows that with its __pycache__ spam This is, to my understanding, precisely why the standard library is pre-compiled during installation (when the process already has sudo rights, and can therefore create the `__pyc…

> All they have to do is make a virtual environment Okay so to create a five line script I have to make a virtual environment. Then I have to activate and deactivate it whenever using it. And I have to remember to update the dependenceis regularly. For my five line script. Seems to me the companies managing mloc-codebases pushed their tradeoffs on everyone else.

I found the whole 'activation' model deeply confusing and annoying. The underlying mechanism of venv is simple and elegant, but the original interface is terrible piece of design.

Re: Hard Rust requirements from May onward

#797

Post by kortilla »

pezezin wrote: post #644
kortilla wrote: post #578

Earlier quoted context omitted.

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…

My experience is in big scientific experiments like particle accelerators, I guess other fields are different. Still, my experience is that: 1) The control network is air gapped, any kind of direct Internet connection is very much forbidden. 2) Embedded real-time stuff usually runs on VxWorks or RTEMS, not Linux. If it is Linux, it is an specialized distro like NI Linux. 3) Anything designed in the last 15 years uses…

Yes, you are out of touch with what has happened with embedded. Companies love internet connected things, especially big industrial things.

It’s absolutely terrible for security but remote visibility into how your 100 ton haul truck is operating via some cloud API is what people like and keep buying.

No air gap, just hooked up to a cell phone network with maybe a VPN if you’re lucky. Either way, the kernel is handling packets directly from the Internet and keeping the kernel up to date is critical.

Post reply on HN