this puts a hole in your firewall

Indeed, thanks, I realized that shortly after posting it.

dig not supporting mdns

Yep you both are correct. Looking at it now, the result does actually warn me that I'm trying to send a regular DNS request to mDNS multicast address.

It just sort of happens to work correctly if you get a single reply

Yeah I guess it's a hack. To me it does not really matter because I'm just using it for wireguard, so the worst thing that could happen is that I would try to connect to a wrong host and the key exchange would fail.

libnss-mdns

The reason for why I'm doing this whole hack is that nss-mdns package is only available on glibc version of Void but I'm using musl, so it's really just hacks on top of hacks. I found a final solution though so that's nice (see final edit of post). Thanks for all your replies!

It's solved now. Basically what's happening is that I ask a multicast address on UDP port 5353 and get a response from different IP because the original IP was multicast. So my firewall blocks the reply, because it really isn't a reply like downloading a webpage. I solved it by filtering based on the source port. Meaning the reply has source port 5353 but on my machine it arrives at some random UDP port so I cannot really filter based on the destination port.

solution

 undefined

    
-A OUTPUT -p udp -m udp --sport 5353 -j ACCEPT


  

Thanks for your help!

Well the musl C library does not have nss-mdns available. But it does not matter, I solved it now. Thanks anyways!

Edit 2: Actually dig picks a random port to send the mDNS request from and sends it to 224.0.0.251:5353 (multicast IP). The correct host then replies from port 5353 to the previously picked random port from dig. But I found that you can specify the port with dig -b IP#port so I think that should help. I kinda don't have the time to try it out currently though.

end of edit2.

well I randomly solved it by adding

 undefined

    
-A OUTPUT -p udp -m udp --sport 5353 -j ACCEPT


  

Which basically means you are right. The destination port is just some randomly picked number (checked wireshark), so I have to filter based on source port, which is 5353.

Edit: Also thanks for your help!

It just times out so my thought was that it just blocks the reply.

Actually I don't have avahi installed. I only have some avahi-libs. I thought it's only needed on the computer who's IP I'm trying to get.

Huh weird. For me the first one works but the second one fails and returns an empty string.

I guess I should have specified that I'm on Void-musl. The reason why I'm doing this is because there is no NSS library on musl, so as far as I know you cannot automagically query hostnames on the network.

It's also likely that most of these signatures aren't even from graphic designers, just some people from Linux related forums.

Well the dev said that he does not care about the license. He wanted to create a coreutils alternative with better concurency using Rust as a pet project. He had even stated that he was not interested in the MIT vs GPL drama, yet people here were acting like children over it.

People think it's some kind of Canonical evil master plan, yet it's just some random dude slapping a license on his cool new code, without really thinking about it. Also this conspiracy does not make sense at so many levels. For one Canonical would shoot themselves into their foot if they created their own proprietary coreutils, because admins would not want to deal with non-portable scripts. Also there are already the BSD utils, so if they wanted to create their own fork, they would have already done that by now. They won't because they prefer free labor from FOSS devs.

If you link to GPL library, your software has to be GPL. You are confusing it with LGPL. Though you can bypass this by making the library its own standalone app. Like let's say FFmpeg which is just a frontend for libAV libraries. (ignore that these libraries are actually LGPL, so you can link to them.)

The author explicitly states that this is not the reason.

https://github.com/uutils/coreutils/discussions/4358#discussioncomment-8027681

Bruh instead of all this speculation, you guys could have just looked it up.

https://github.com/uutils/coreutils/discussions/4358#discussioncomment-8027681

I will give you one. You want to embed the coreutils in some other projects ie. a browser. But at that point it's cheaper for you to submit your modification upstream because you are making money selling the browser not by selling modified coreutils. Maintaining your own fork is not worth it once you make meaningful changes.

I think this is the reason why uutils are being funded by Big Tech and why they chose this license. (to get funded) correction: I only found that they are funded by the Sovereign Tech Fund and apparently the author is open to changing the license, they don't care (see video/presentation).

But yes, I agree this whole comment section is deranged. The reason why Ubuntu chose uutils is because of Rust's safety and because of speed. In some workloads (I think it's sorting) they totally smash the GNU counterparts.

For Ubuntu it does not make any sense to make a proprietary fork. You don't choose your OS based on its coreutils. If they added a new convenience flag for their proprietary grep, it would just make them look bad. Also skilled users would hate it because now their scripts would not be portable. Or if it were really that big of a gamechanger, the feature would get added to the other coreutils and Ubuntu would end up with nothing but bad reputation. Unless they made change to the underlying code for performance. Then it would be harder to implement in the other coreutils but as I said before, nobody would care. Faster and safer coreutils are a nice to have, not something people base their OS choice on.

Edit: added source to author's stance on license

It's not recommended because there are better options ie. Arch, not that it would be impossible to learn linux using Void. Arch simply has better documentation than Void. Which is important when you want to learn fast. My previous comments provided examples why the documentation is worse.

Btw arch wiki does provide documentation for runit but only on its runit page, not on every page that mentions managing a service.

Not talking about the quality of the software. I mean that some guide on Arch wiki will not work because some software expects systemd or the guide is just more difficult to follow with a system using runit. My point is that a new user does not have "the context", so for a new user Void is a worse way to learn linux quickly than Arch or honestly even Gentoo. Even Gentoo has its own wiki so it's likely that if an Arch wiki guide does not work for you, you will likely find the Gentoo specific detail on their wiki. You don't have such luxury with Void.

Ubuntu pro provides support after 5 years of standard LTS support. Linux Mint does not provide any support (paid nor free) after the first 5 years so the comparison does not really make sense.

People want to switch from baguettes to bread. So they get flour, water, yeast and salt and are asked to bake their own bread. "I never saw what was so hard about baking bread, the seller says." Well the issue is not the difficulty of baking bread. They simply don't want to spend time baking bread. They are used to going to the store to buy an already baked baguette.

I'd argue the demographic that writes posts about switching their OS is more likely to be happy switching to Arch than most of the people who switch. The way I imagine the average Linux noob is a university student who installed Ubuntu for their coding class.

For novices Void is worse because it does not have the Arch wiki. The Void Docs are brief and you will inevitably end up reading the Arch wiki anyways, except you will run into Runit specific bs.

It makes sense because if you are a veteran, you probably already have your workflow streamlined, so you don't need new software in the repositories.