Haven’t seen the video, I’m only commenting based on the summary in the comments.

It’s good that flatpak is switching to OCI containers. Hopefully that will end the flatpak’s dependency hell. This week I was looking at flatpak as a way to publish my app and found the user experience (user is the app publisher in this context) quite bad. Could be skill issue obviously.

I thought I could just look into a database of flatpak runtimes, pick the one with the software I need, add additional packages and be done with it. Unfortunately it is not that simple. First of all as far as I know, there is no “database” like archlinux.org/packages. You have to download the runtime and then search /usr/include/ or /usr/bin/ to check if particular piece of software exists in it. Adding additional packages is also quite difficult. There are these runtime extensions which are like “baby runtimes” for special software like ffmpeg, java, etc. They kinda suffer from issues similar to the issues of the runtimes. And unlike in regular distros where you can get a package for almost anything, here you don’t have the luxury and have to bundle that not so popular dependency.

I hope that with OCI I will be able to just provide the binary, a link to the base image and a list of dependencies to install and be done with it.

As I said there are many alternative coreutils (BSD utils, toybox) for the embrace extend extinguish. I just don’t see a model situation because that seems to me like embracing, extending and extinguishing a programming language. Nobody does that because it is not financially viable.

It’s not required to do work, if you want to use GPL licensed software for commercial applications. You need to share your source code, if you modified the GPLed code. But most people don’t modify the coreutils’ code. Are coreutils getting so much work done on them? To me it does not seem like it when this new uutils project managed to dwarf them in performance in some benchmarks.

Anyways I think I’ve read somewhere that the project author is open to change the license, if the contributors want to. I guess someone could open a discussion about it. The issue is that it cannot be people from this comment section because they cannot engage in an adult discussion. I do think it’s worth considering the advantages of changing the license to GPL, mainly that users will be forced to share their potential bug fixes. But people have to cut their Canonical conspiracy crap, which just does not make any sense and only makes it harder to convince the uutils author.

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

-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

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

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.