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

491–500 of 508 posts

Re: APT Rust requirement raises questions

#491

Post by ahartmetz »

phicoh wrote: post #419
radlad wrote: post #360

Earlier quoted context omitted.

systemd has been the de facto standard for over a decade now and is very stable. I have found that even most people who complained about the initial transition are very welcoming of its benefits now.

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.

That's the main problem with systemd: replacing services that don't need replacing and doing a bad job of it. Its DNS resolver is particularly infamous for its problems.

Re: APT Rust requirement raises questions

#492

Post by lagniappe »

bryanlarsen wrote: post #479
lagniappe wrote: post #460

Earlier quoted context omitted.

Ah yes, the signature snark from the Rust community. This is the type of thing that repels people.

Most of the repelling is happening on the anti-Rust side. The hate and vitriol has chased away Wedson Almeida Filho, Alex Gaynor, Hector Martin and Christoph Hellwig from the Rust in Linux project. And it's happening here too. https://news.ycombinator.com/item?id=46048336 makes clear that most of the commentary here is just plain wrong, yet it's not upvoted to top.

And for each of those names there are 100 rust zealots tainting their legacy with their behavior.

Re: APT Rust requirement raises questions

#493

Post by roryirvine »

pmarin wrote: post #352
creatonez wrote: post #227

I have never seen a program segfault and crash more than apt. The status quo is extremely bad, and it desperately needs to be revamped in some way. Targeted rewrites in a memory safe & less mistake-prone language sounds like a great way to do that. If you think this is a random decision caused by hype, cargo culting, or a maintainer's/canonical's mindless whims... please, have a tour through the apt codebase some day…

20 years on Debian. Not a single crash with apt

Almost 30 years for me, both on my personal machines and at work.

I went through a period about 25 years ago where apt crashed on my (rather janky) desktop almost every other run, and sometimes left my system in a state so inconsistent that I had to fall back on 'dpkg-reconfigure --force' and the like to fix it.

Turns out that it was due to a bad interaction between a failing stick of RAM and reiserfs' tail-packing feature, which was causing frequent silent corruption in /var/lib/dpkg/status and friends.

I don't think I've seen any similar issues since, across what must be many millions of apt runs I've been responsible for.

Perhaps gp is suffering from some similar underlying problem?

Re: APT Rust requirement raises questions

#494

Post by Dagger2 »

phicoh wrote: post #482
radlad wrote: post #431

Earlier quoted context omitted.

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

Hm, but systemd-resolved mainly doesn't provide DNS services, it provides _name resolution_. Names can be resolved using more sources than just DNS, some of which do support link-locals properly, so it's normal for getaddrinfo() or the other standard name resolution functions to return addresses that aren't in DNS.

i.e. it's not inventing DNS records, because the things returned by getaddrinfo() aren't (exclusively) DNS records.

The debug tool for this is `getent ahosts`. `dig` is certainly useful, but it makes direct DNS queries rather than going via the system's name resolution setup, so it can't tell you what your programs are seeing.

Re: APT Rust requirement raises questions

#495

Post by cactusfrog »

estebank wrote: post #381
cactusfrog wrote: post #160

Earlier quoted context omitted.

Could the rust code be transpired to readable C?

> readable No, because some things that are UB in C are not in Rust, and vice versa, so any codegen has to account for that and will result in additional verbosity that you wouldn't see in "native" code.

Thank you for the explanation

Re: APT Rust requirement raises questions

#496

Post by phicoh »

Dagger2 wrote: post #494
phicoh wrote: post #482

Earlier quoted context omitted.

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…

Hm, but systemd-resolved mainly doesn't provide DNS services, it provides _name resolution_. Names can be resolved using more sources than just DNS, some of which do support link-locals properly, so it's normal for getaddrinfo() or the other standard name resolution functions to return addresses that aren't in DNS. i.e. it's not inventing DNS records, because the things returned by getaddrinfo() aren't (exclusively)…

systemd-resolved responds on port 53. It inserts itself in /etc/resolv.conf as the DNS resolver that is to be used by DNS stub resolvers.

It can do whatever it likes as longs as it follows DNS RFCs when replying to DNS requests.

Redefining recursive DNS resolution as general 'name resolution' is indeed exactly the kind of horror I expect from the systemd project. If systemd-resolved wants to do general name resolution, then just take a different transport protocol (dbus for example) and leave DNS alone.

Re: APT Rust requirement raises questions

#497

Post by nerdponx »

brobdingnagians wrote: post #264
nerdponx wrote: post #195

Earlier quoted context omitted.

As far as I understand the idea behind scrum it's not that you don't plan, it's that you significantly shorten the planning-implementation-review cycle.

Perhaps that is the ideal when it was laid out, but the reality of the common implementation is that planning is dispensed with. It gives some management a great excuse to look no further than the next jira ticket, if that. The ideal implementation of a methodology is only relevant for a small number of management who would do well with almost any methodology because they will take initiative to improve whatever they…

> the reality of the common implementation is that planning is dispensed with. It gives some management a great excuse to look no further than the next jira ticket, if that.

Maybe I'm just lucky but I've never experienced this. If anything, the companies I've worked for didn't do anything particularly agile, and were often deliberately trying to change habits and workflows to be more agile. This often came down from engineering managers who wanted to know how the whole project was going to go the day it started, so they could report upwards with a delivery timeline.

Re: APT Rust requirement raises questions

#498

Post by nerdponx »

nofunsir wrote: post #241
nerdponx wrote: post #195

Earlier quoted context omitted.

As far as I understand the idea behind scrum it's not that you don't plan, it's that you significantly shorten the planning-implementation-review cycle.

I've got a bridge to sell. It's made from watered-down concrete and comes with blueprints written on site. It was very important to get the implementation started asap to shorten the review cycle.

In a way, bridges are kind of agile. There are many stages of things like site selection, geological testing, architectural and engineering design decisions, computer simulations, traffic forecasting, etc. All of that happens in a feedback loop with the customer (eg some state DOT).

Re: APT Rust requirement raises questions

#499

Post by jcgl »

phicoh wrote: post #496
Dagger2 wrote: post #494

Earlier quoted context omitted.

Hm, but systemd-resolved mainly doesn't provide DNS services, it provides _name resolution_. Names can be resolved using more sources than just DNS, some of which do support link-locals properly, so it's normal for getaddrinfo() or the other standard name resolution functions to return addresses that aren't in DNS. i.e. it's not inventing DNS records, because the things returned by getaddrinfo() aren't (exclusively)…

systemd-resolved responds on port 53. It inserts itself in /etc/resolv.conf as the DNS resolver that is to be used by DNS stub resolvers. It can do whatever it likes as longs as it follows DNS RFCs when replying to DNS requests. Redefining recursive DNS resolution as general 'name resolution' is indeed exactly the kind of horror I expect from the systemd project. If systemd-resolved wants to do general name resolutio…

If you don't like those additional name resolution methods, then turn them off. Resolved gives you full control over that, usually on a per-interface basis.
Post reply on HN