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

501–508 of 508 posts

Re: APT Rust requirement raises questions

#501

Post by brobdingnagians »

nerdponx wrote: post #497
brobdingnagians wrote: post #264

Earlier quoted context omitted.

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…

I hear you. I feel like my personal experience has definitely influenced my view. I've seen management who want to have a timeline and a deadline from day 1, but don't want to put any effort into thinking out how they could allocate resources to make that happen or what was required of them. So they just ask someone else for a calendar and ask if someone's already made a ticket.

Re: APT Rust requirement raises questions

#502

Post by phicoh »

jcgl wrote: post #499
phicoh wrote: post #496

Earlier quoted context omitted.

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.

If you don't like that systemd is broken, then you can turn it off. Yes, that's why people are avoiding systemd. Not so much that the software has bugs, but the attitude of the community.

Re: APT Rust requirement raises questions

#503

Post by radlad »

phicoh wrote: post #502
jcgl wrote: post #499

Earlier quoted context omitted.

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.

If you don't like that systemd is broken, then you can turn it off. Yes, that's why people are avoiding systemd. Not so much that the software has bugs, but the attitude of the community.

It's not broken - it's a tradeoff. systemd-resolved is an optional component of systemd. It's not a part of the core. If you don't like the choices it took, you can use another resolver - there are plenty.

I don't think many people are avoiding systemd now - but those who do tend to do it because it non-optionally replaces so much of the system. OP is pointing out that's not the case of systemd-resolved.

Re: APT Rust requirement raises questions

#504

Post by Dagger2 »

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…

It's not from systemd though. glibc's NSS stuff has been around since... 1996?, and it had support for lookups over NIS in the same year, so getaddrinfo() (or rather gethostbyname(), since this predates getaddrinfo()!) have never just been DNS.

systemd-resolved normally does use a separate protocol, specifically an NSS plugin (see /etc/nsswitch.conf). The DNS server part is mostly only there as a fallback/compatibility hack for software that tries to implement its own name resolution by reading /etc/hosts and /etc/resolv.conf and doing DNS queries.

I suppose "the DNS compatibility hack should follow DNS RFCs" is a reasonable argument... but applications normally go via the NSS plugin anyway, not via that fallback, so it probably wouldn't have helped you much.

Re: APT Rust requirement raises questions

#505

Post by phicoh »

radlad wrote: post #503
phicoh wrote: post #502

Earlier quoted context omitted.

If you don't like that systemd is broken, then you can turn it off. Yes, that's why people are avoiding systemd. Not so much that the software has bugs, but the attitude of the community.

It's not broken - it's a tradeoff. systemd-resolved is an optional component of systemd. It's not a part of the core. If you don't like the choices it took, you can use another resolver - there are plenty. I don't think many people are avoiding systemd now - but those who do tend to do it because it non-optionally replaces so much of the system. OP is pointing out that's not the case of systemd-resolved.

It's not a trade-off. Use of /etc/resolv.conf and port 53 is defined by historical use and by a large number of IETF RFC.

When you violate those, it is broken.

That's why systemd has such a bad reputation. Systemd almost always breaks existing use in unexpected ways. And in the case of DNS, it is a clearly defined protocol, which systemd-resolved breaks. Which you claim is a 'tradeoff'.

When a project ships an optional component that is broken, it is still a broken component.

The sad thing about systemd (including systemd-resolved) is that it is default on Linux distributions. So if you write software then you are forced to deal with it, because quite a few users will have it without being aware of the issues.

Re: APT Rust requirement raises questions

#506

Post by baranul »

teunispeters wrote: post #444
maximilianburke wrote: post #103

Earlier quoted context omitted.

In your opinion how does Rust compare to C++ for readability?

Honestly, rust is slightly more readable than obfuscated perl. I think I prefer K&R C, and I don't like K&R C. In terms of readability, maybe equivalent to early Win32 API? [3000 lines to set up API, then call to activate]. With C++ you have a range of readable from - easy and very approachable - to 2000s era Microsoft STL. (where not only is it close to unreadable, many many hidden bugs are ... somewhere. And behavi…

> Honestly, rust is slightly more readable than obfuscated perl.

> Rust is the kind of language that would push me to write a new language that isn't rust.

It's wild how draconian and forced the use of Rust has become. It's one thing to be caught up in corporate induced hype, yet another level to force one's preferences or ideology on everybody else.

Many people don't like Rust, for various acceptable reasons, and their right to choose should be respected. Sticking with C, is an equally acceptable option. In addition to there being various other newer C alternatives languages; with greater readability, memory-safety, and ease of use. There is also Fil-C[1][2], that can provide memory-safety, with no to minimum changes to the code.

[1]: fil-c.org/

[2]: github.com/pizlonator/fil-c

Re: APT Rust requirement raises questions

#507

Post by phicoh »

Dagger2 wrote: post #504
phicoh wrote: post #496

Earlier quoted context omitted.

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…

It's not from systemd though. glibc's NSS stuff has been around since... 1996?, and it had support for lookups over NIS in the same year, so getaddrinfo() (or rather gethostbyname(), since this predates getaddrinfo()!) have never just been DNS. systemd-resolved normally does use a separate protocol, specifically an NSS plugin (see /etc/nsswitch.conf). The DNS server part is mostly only there as a fallback/compatibili…

I'm not sure what you are talking about. Our software has a stub resolver that is not the one in glibc. It directly issues DNS requests without going through /etc/nsswitch.conf.

It would have been fine if it was getaddrinfo (and it was done properly) because getaddrinfo gives back a socket and that can add the scope ID to the IPv6 link local address. In DNS there is no scope ID, so it will never work in Linux (it would work on Windows, but that's a different story).

Re: APT Rust requirement raises questions

#508

Post by radlad »

phicoh wrote: post #505
radlad wrote: post #503

Earlier quoted context omitted.

It's not broken - it's a tradeoff. systemd-resolved is an optional component of systemd. It's not a part of the core. If you don't like the choices it took, you can use another resolver - there are plenty. I don't think many people are avoiding systemd now - but those who do tend to do it because it non-optionally replaces so much of the system. OP is pointing out that's not the case of systemd-resolved.

It's not a trade-off. Use of /etc/resolv.conf and port 53 is defined by historical use and by a large number of IETF RFC. When you violate those, it is broken. That's why systemd has such a bad reputation. Systemd almost always breaks existing use in unexpected ways. And in the case of DNS, it is a clearly defined protocol, which systemd-resolved breaks. Which you claim is a 'tradeoff'. When a project ships an option…

Yes, violating historical precedent is part of the tradeoff - I see no contradiction. Are you able to identify the positive benefits offered by this approach? If not, we're not really "engineering" so to speak. Just picking favorites.

> The sad thing about systemd (including systemd-resolved) is that it is default on Linux distributions. So if you write software then you are forced to deal with it, because quite a few users will have it without being aware of the issues.

I'm well aware - my day job is writing networking software.

Post reply on HN