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

APT Rust requirement raises questions

lwn.net

Post reply on HN
Print view View original

481–490 of 508 posts

Re: APT Rust requirement raises questions

#481

Post by gaanbal »

ActorNightly wrote: post #380
WD-42 wrote: post #116

Earlier quoted context omitted.

I’ve been writing python professionally for over 10 years. In the last year I’ve been writing more and most Rust. At first I thought the same as you. It’s a fugly language, there’s no denying it. But once I started to learn what all the weird syntax was for, it began to ruin Python for me. Now I begrudge any time I have to go back to python. It feels like its beauty is only skin deep, but the ugly details are right t…

>Now I begrudge any time I have to go back to python. It feels like its beauty is only skin deep, but the ugly details are right there beneath the surface: prolific duck typing, exceptions as control flow, dynamic attributes. All these now make me uneasy, like I can’t be sure what my code will really do at runtime. I feel like this sentiment is from people who haven't really took the time to fully see what the Python…

it's faster to prototype in rust. this may seem counterintuitive, but when a rust program compiles, it generally works. not saying 100% and free from logic bugs, but a lot of the error handling, locks required, and checks for nulls have already been worked out by default.

Re: APT Rust requirement raises questions

#482

Post by phicoh »

radlad wrote: post #431
phicoh wrote: post #419

Earlier quoted context omitted.

Depends a bit on how you define systemd. Just found out that the systemd developers don't understand DNS (or IPv6). Interesting problems result from that.

> Just found out that the systemd developers don't understand DNS (or IPv6). Just according to Github, systemd has over 2,300 contributors. Which ones are you referring to? And more to the point, what is this supposed to mean? Did you encounter a bug or something? DNS on Linux is sort of famously a tire fire, see for example https://tailscale.com/blog/sisyphean-dns-client-linux ... IPv6 networking is also famously di…

Systemd-resolved invents DNS records (not really something you would like to see, makes debugging DNS issues a nightmare). But worse, it populates those DNS records with IPv6 link local addresses, which really have no place in DNS.

Then, when after a nice debugging session why your application behaves so strangely, all the data in DNS is correct, why doesn't it work, you find that this issue has been reported before and was rejected as won't fix, works as intended.

Re: APT Rust requirement raises questions

#483

Post by uecker »

antonvs wrote: post #452
uecker wrote: post #361

Earlier quoted context omitted.

But it is nonsense. Every time some rewrote something (in Rust or anything else), I instead worry about what breaks again, what important feature is lost for the next decade, how much working knowledge is lost, what muscle memory is now useless, what documentation is outdated, etc. I also doubt Rust brings as many advantages in terms of stability that people claim. The C code I rely on in my daily work basically neve…

You want the computing infrastructure to remain essentially as it was in the 1970s. I don't.

Me neither, I just do not want to make steps backwards because people rewriting stuff for stupid reasons. But your argument is just the old "you do not want to adapt" shaming attempt which I think has no intellectual substance anyway.

Re: APT Rust requirement raises questions

#484

Post by az09mugen »

stouset wrote: post #423
influx wrote: post #282

Earlier quoted context omitted.

It really makes me upset that we are throwing away decades of battle tested code just because some people are excited about the language du jour. Between the systemd folks and the rust folks, it may be time for me to move to *BSD instead of Linux. Unfortunately, I'm very tied to Docker.

That “battle-tested code” is often still an enduring and ongoing source of bugs. Maintainers have to deal with the burden of working in a 20+ year-old code base with design and architecture choices that probably weren’t even a great idea back then. Very few people are forcing “rewrite in rust” down anyone’s throats. Sometimes it’s the maintainers themselves who are trying to be forward-thinking and undertake a rewrit…

As long as LLVM (C++ but still) is not rewritten is rust [0] , I don't buy it. C is like JavaScript, it's not perfect, is everywhere and you cannot replace it without a lot of effort and bugfix/regression tests.

If I take for example sqlite (25 years old [3]) there are already 2 rewrites in rust [1] and [2], and each one has its bugs.

And as an end user I'm more enclined to trust the battle-tested original for my prod than its copies. As long as I don't have the proof the rewrite is at least as good as the original, I'll stay with the original. Simple equals more maintainable. That's also why sqlite maintainers won't rewrite it in any other language [4].

The trade of rust is "you can lose features and have unexpected bugs like any other language, but don't worry they will be memory safe bugs".

I'm not saying rust is bad and you should not rewrite anything in it, but IMHO rust programmers tend to overestimate the quality of the features they deliver [5] or something along these lines.

Memory safe != good product

[0] https://rustc-dev-guide.rust-lang.org/overview.html [1] https://github.com/epilys/rsqlite3 [2] https://github.com/tursodatabase/turso/ [3] https://sqlite.org/chronology.html [4] https://www.sqlite.org/whyc.html [5] https://www.phoronix.com/news/Ubuntu-25.10-Broken-Upgrade

Re: APT Rust requirement raises questions

#485

Post by NoGravitas »

bicarbonato wrote: post #146
dv35z wrote: post #31

Every time I consider learning Rust, I am thrown back by how... "janky" the syntax is. It seems to me that we ought to have a system-level language which builds upon the learnings of the past 20+ years. Can someone help me understand this? Why are we pushing forward with a language that has a Perl-esque unreadability...? Comparison: I often program in Python (and teach it) - and while it has its own syntax warts & fr…

What do people actually mean when they say "the syntax is janky"? I often see comparisons to languages like Python and Kotlin, but both encode far less information on their syntax because they don't have the same features as Rust, so there's no way for them to express the same semantics as rust. Sure, you can make Rust look simpler by removing information, but at that point you're not just changing syntax, you're cha…

I don't know if there is, but there certainly needs to be. All of Rust's syntax seems to be needed to support its semantics, but it also undeniably crosses a threshold of "too much syntax". Though I do agree with the person above who said that every language that's not Lisp has too much syntax.

Re: APT Rust requirement raises questions

#486

Post by NoGravitas »

ben-schaaf wrote: post #416
thousand_nights wrote: post #86

Earlier quoted context omitted.

nta you're replying to, but as someone who doesn't know rust, on first glance it seems like it's littered with too many special symbols and very verbose. as i understand it this is required because of the very granular low level control rust offers maybe unreadable is too strong of a word, but there is a valid point of it looking unapproachable to someone new

> littered with too many special symbols and very verbose This seems kinda self-contracticting. Special symbols are there to make the syntax terse, not verbose. Perhaps your issue is not with how things are written, but that there's a lot of information for something that seems simpler. In other words a lot of semantic complexity, rather than an issue with syntax.

I think it's also that Rust needs you to be very explicit about things that are very incidental to the intent of your code. In a sense that's true of C, but in C worrying about those things isn't embedded in the syntax, it's in lines of code that are readable (but can also go unwritten or be written wrong). In the GCed languages Rust actually competes with (outside the kernel) — think more like C# or Kotlin, less like Python — you do not have to manage that incidental complexity, which makes Rust look 'janky'.

Re: APT Rust requirement raises questions

#487

Post by Muromec »

SAI_Peregrinus wrote: post #201
Muromec wrote: post #88

Earlier quoted context omitted.

It is possible the deb package is parsed to extract some metadata before being installed and before verifying signature. Also there is aspect of defence in depth. Maybe you can compromise one package that itself can't do much, but installer runs with higher priviledges and has network access. Another angle -- installed package may compromise one container, while a bug in apt can compromise the environment which provi…

> It is possible the deb package is parsed to extract some metadata before being installed and before verifying signature. Yes, .deb violates the cryptographic doom principle[1] (if you have to perform any cryptographic operation before verifying the message authentication code (or signature) on a message you’ve received, it will somehow inevitably lead to doom). Their signed package formats (there are two) add extra…

It's not cryptographic doom principle, as they don't decrypt before verifying signature, they just parse. It's still kinda sorta bad, but in a different way.

Re: APT Rust requirement raises questions

#488

Post by kzrdude »

stonemetal12 wrote: post #42
fn-mote wrote: post #20

The most interesting criticism / idea in the article was that the parts that are intended for Rust-ification should actually be removed from core apt. > it would be better to remove the code that is used to parse the .deb, .ar, and .tar formats [...] from APT entirely. It is only needed for two tools, apt-ftparchive and apt-extracttemplates [...] Another interesting, although perhaps tangential, criticism was that th…

Given that Cargo is written in Rust, you would think there would be at least one battle tested solver that could be used. Perhaps it was harder to extract and make generic than write a new one?

Uv uses pugrub and maybe APT could too.

Re: APT Rust requirement raises questions

#489

Post by pornel »

grayhatter wrote: post #463
pornel wrote: post #461

Earlier quoted context omitted.

The situation today is very different than what it used to be when people actually used 386 or Amigas because they had no other options (BTW, Rust supports m68k, just not AmigaOS specifically). Today even crappiest old PCs that you can fish out of a dumpster are already new enough to have Rust/LLVM support. We have mountains of Rust-compatible e-waste that you can save from landfill. Take whatever is cheapest on eBay…

> but let's not pretend it's a situation that people are in due to economic hardship. I'd encourage you to not strawman my response. Because I already said myself that it appears to me it's only hobbyists who are losing support. My objection isn't to the argument that it's dropping support, my objection is that it's dropping support without cause. Other than, the assumed this would be more comfortable for me. Maintai…

By alluding the switch to Rust was "without cause", and bringing up concerns of floppy users and retro-hobby hardware, you seem to be seeing the change only from a very narrow perspective of interests of very specific group of users.

There are lots of other users, and lots of other ways to care about them. Making software less likely to have vulnerabilities is caring about its users too. Making software work better and faster on contemporary hardware is caring about users too, just a different group (and a way larger one, and including users who really can't afford faster hardware).

Sometimes it's just not possible to make everyone happy, and even just keeping the status quo is not always a free option. Hypothetically, keeping working support for some weird floppy drive may be increasing overall system complexity, and cost dev and testing effort that might have been spent on something else that benefitted a larger number of users more.

Switching to a language with a friendlier compiler, fewer gotchas, less legacy cruft, and less picky dependency management can also be a way of caring about users - lowering the barriers to contributing productively can help get more contributions, fewer bugs, improve the software overall, and empower more users to modify their tools.

It'd be fine to argue which trade-offs are better, and which groups users should be prioritized, but it's disingenuous to frame not accommodating the retro/hobby usecases in particular a sign of lack of compassion in general. It could be quite the opposite - focusing only on the status quo and past problems shows lack of care about all the other users and the future of the software.

Re: APT Rust requirement raises questions

#490

Post by pepa65 »

freedomben wrote: post #163
raincole wrote: post #136

Earlier quoted context omitted.

> Cargo is a terrifying nightmare Really? Why? I'm not a Rust guru, but Cargo is the only part of Rust that gave me a great first impression.

GP mostly answered that in the comment already: > If you could install regular rust dependencies with "apt install" in debian stable, that would be a different story! But no. They want the version churn: continuously adding and removing bugs, like particle/anti-particle pairs at the boundary of a black hole.

Depending on the particular apt repo to be ready and have what you need would be so much more of a nightmare!
Post reply on HN