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.

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.

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.

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.

Since you are already using Libreboot, you already have (proprietary) microcode updates installed. So I think it shouldn’t be a security disaster with Linux-libre (that assumes that you keep your Libreboot updated). Worst thing that would happen is that your hardware won’t work. That’s also the best thing that will happen. The blobs are just firmware that gets loaded on a device that needs it. If you have the device, it won’t work without blobs. If you don’t have it, the firmware is not loaded so the outcome is not that different from regular linux. And also reading from comments there are some blobs for enabling DRM content. I guess that’s not mandatory.

Though imo Linux-libre is pointless. For noobs it’s a potential security disaster and skilled users would be better off compiling their own kernel with just the features they need to reduce attack surface.

It sounded like you got annoyed that I was guessing and it sounded like you tried to make it clear to me that the guess was not helpful to you with the use of sarcasm. I guess I misunderstood, sorry.

Regarding the actual questions: You asked how does it compare to Coreboot. Canoeboot is actually coreboot, just slightly modified to work with Free Software Foundation’s rules but these rules are kind of absurd. See [1]. Libreboot is also modified Coreboot but one that’s actually good. The difference between them is that Libreboot should be a bit easier to install and that they support different hardware.

In terms of battery life the same laptop with or without Coreboot should perform the same. Coreboot really only handles the booting. Battery life should depend on the “EC firmware”, which is like a second chip on your motherboard that handles stuff like blinking LEDs or checking if your lid is opened or closed. It also depends on the OS itself so Linux vs Windows will make a difference. Canoeboot is an exception because it does not include “microcode updates” for ideological reasons. Microcode is code that runs on a “CPU inside of your CPU”. Not updating it will A) make your CPU buggy and vulnerable to attacks like Spectre [2] and B) maybe even have worse battery life because Microcode can control the voltage your CPU runs at. More voltage -> more power (P ~ V^2)

[1] https://libreboot.org/news/policy.html

[2] https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)

Well if it were closed source, it would be harder to repackage proprietary apps because you would not know how the snap “root filesystem” translates to $DISTRO root filesystem.

Because some apps are only packaged as snaps so if you want them to be accessible to users, you have to install snapd. Flatpak can still be the default which on non-Canonical distros already is. Which why I don’t even worry about snap becoming the standard.

You simply use a different packaging format as I said in the previous comment.

I’m not arguing whether snap or flatpak is better. Flatpak is better.

But your arguments are going against each other. You disagree that FSF should tell you what software you can use but then you want to tell other users what software they can use. If you use flatpak despite of FSF’s opinions, you should let people use snap despite of your opinion.

You are confused and mean. You cannot compare 2 different laptops and say that one has worse battery management because of coreboot. You would need to have the same laptop with and without coreboot to do any comparison.

I don’t really get what you are trying to say in the second paragraph but Canoeboot is not a good daily driver because it’s basically a “drug substitute” for GNU dummies. The author of it does not recommend using it. Use Libreboot instead as it does not break your CPU.

My guess: Generally it should not be that different since most of it is handled by the EC firmware. (Proprietary is OK in FSF’s eyes if it’s baked into the hardware) But Canoeboot does not include microcode updates which could affect the CPU’s power management. (Clocks speed, Vcore, etc.)

Ok but KDE has official Snap packages so they already are “legitimizing it”. Also snap won’t be able to entshittify anything. Snapd is still open source, so you can just repackage the software for different package system.

This is a stupid argument. In FSF’s eyes even having nonfree repository (ie. for drivers) is bad so this is completely irrelevant for anyone considering flatpak or snap. Both have nonfree stuff in there.