Yeah no problem. I’d like to point out that this puts a hole in your firewall. If you have something exposed via udp, and an attacker knows about your --sport rule or figures this out, they can connect to it just by setting their source port to 5353. You can check what’s listening on udp with ss -lun or sudo ss -lunp (for process info).

Also, I have looked up what @Eideen@lemmy.world said about dig not supporting mdns and I think they are correct. With mdns, because of the multicast nature, you can get replies from multiple computers, and that’s a pretty big difference to regular dns. How could it even reliably know it has gotten all the replies or if it should wait for more? It just sort of happens to work correctly if you get a single reply.

Also, and I also looked this up, mdns lookups will to go through avahi-daemon on regular glibc distros. The libnss-mdns plugin description for glibc says this:

nss-mdns tries to contact a running avahi-daemon for resolving host names and addresses and making use of its superior record cacheing. If Avahi is not available at lookup time, the lookups will fail.

As I said, I’m not sure about that.

Still, dig won’t be listening on port 5353 for the answer, it’ll open some random port, so the firewall rule for 5353 will not apply. And the conntrack rule, is my guess, also doesn’t apply, because what I think the conntrack module does is:

• Remembers about the outgoing connection (i.e. when dig sends its udp packet out): source port, destination IP and port
• Check incoming packets against this info, and lets them through if they appear to be an answer

Since the outgoing packet is going to multicast, and the incoming packet (I suspect) is coming from the IP of the machine that answers (a different IP therefore), conntrack wouldn’t be able to figure that out. The answer doesn’t match the outgoing packet that dig sends. Since this is just a hunch, I would try to confirm this by looking at the traffic in e.g. wireshark.

My hunch on what’s going on: Dig opens up a different udp port (it has to, there would be avahi-daemon listening on 5353). So it sends out to the multicast address on 5353, but the answer comes back from the actual IP of whoever is answering, to whatever port dig is listening on, and the connection tracking is not smart enough to figure out this should be let through?

You should look at the traffic with wireshark.

Also maybe that’s fine in practice? Do applications actually run their own mDNS queries? Maybe it all goes through avahi-daemon? That uses port 5353 so that would get an answer if it did the mDNS query instead of dig. But I’m not sure how this works, so that’s just a guess.

There’s some wrong things in this article, and a thing worth mentioning.

Half-Life (and its mods like Counter-Strike) had Linux server versions, and a lot of dedicated servers ran on Linux, which I think is worth mentioning when talking about the history.

Steam wasn’t well received at first, people didn’t like that there was now this special launcher/downloader you had to use. Mind you they moved their old games onto Steam, so it’s not like you knew about this when you bought it. Also there weren’t any games on there except Half-Life and related titles, like HL mods that got their own release.

Contrary to what the article claims, MacOS does not support some outdated version of DirectX, it does not and never has supported DirectX at all. DirectX was only ever supported on Windows and XBox.

DirectX also was not well received at first. Here’s an old article from gamedev.net (2002):

What later became known as DirectX 1.0 ended up not being very widely accepted. It was buggy, slow, badly structured, and overly complex.

Of course, Microsoft wasn’t about to just give up. They kept working at it, asking the community for ways to improve it. The first truly viable version of DirectX was DirectX 3.0. A few years later, they released DirectX 5 (skipping 4 entirely), which was the first truly useful version. Incremental improvements were made with version 6. Then came DirectX 7.0.

DirectX 7 was the first one to actually be embraced by game developers. It worked well, making game programming reasonably easy, and a lot of people liked the interface.

So, the Manhattan Project started. Manhattan Project was Microsoft’s attempt at creating a set of APIs that would make the task of writing games for their platform significantly less painful. The questionable naming decision was, sadly, fully intentional: while Microsoft had most of the PC gaming on its side, the gaming industry as a whole was mostly dominated by game consoles from Japan.

WTF Microsoft.

Since you say the thing is working fine on Windows, there’s almost certainly a bug or several. I’d say probably a driver in the kernel, but could be something else. Changing distro or kernel version does sometimes help with that sort of thing, mainly because another distro may have newer or older kernels and other software, and bugs get both introduced and fixed every release.

Freezing issues can have lots reasons, including buggy apps, RAM exhaustion due to memory leaks, bugs in the graphics drivers or graphics stack more generally, various blocking I/O things taking unexpectedly long due to network issues or faulty hardware or drivers.

If you want a chance to figure this out, you probably need to run things in the terminal, like installing software updates through the apt and snap (?) cli utilities. GUIs are notoriously shit at reporting unexpected errors, whereas all sorts of programs (including GUI apps if you start them in a terminal) do regularly print warnings and error messages to stderr, which will show up in a terminal. This is because it’s easy for the programmers to do that with just single printf() (etc.) line.

For driver issues, looking at the kernel logs can sometimes show interesting things as well. I will say that, when looking at logs or terminal output, there often are warnings that are completely unrelated and/or harmless, and that’s not necessarily obvious to the user.

If this is a software issue, framework imho shouldn’t advertise their stuff being able to run Ubuntu if they cannot stay on top of issues that are happening in this configuration.

Glad you got it working.

If we assume, for a moment, that your issue was in fact related to fluidsynth, which I kinda still think it might be, because of what fuser and the logs showed, it would be a good idea to undo your module blacklist thingy and reboot.

If your slow boot issue persists, and you try to fix that tomorrow, then try looking at the bootup messages as described here:

https://askubuntu.com/questions/25022/how-to-enable-boot-messages-to-be-printed-on-screen-during-boot-up

If you reinstall pulseaudio to get back to where you were before, uninstall pipewire, those two shouldn’t be running simultaneously.

Good luck and keep me updated if you manage to fix it somehow.

Yeah I wrote that stop command wrong, it’s supposed to be systemctl --user stop pulseaudio. The relevant errors from journalctl were the “busy” errors. Are they still there? Maybe they’re old messages? You can type G to go to the end of the log.

Also, and this is probably my last suggestion, try restarting the socket with systemctl --user restart pipewire-pulse.socket. And maybe restart all the other crap as well for good measure. My theory here is that pulseaudio overwrote that socket with it’s own socket, and anything trying to play sound would be trying to connect to the nonexistent pulseaudio, and maybe restarting pipewire doesn’t actually recreate the socket, because systemd does that, but I’m not sure that’s actually how that works.

Theoretically logging out and in again should also restart all the things pipewire I think, but it’s possible that whatever is slowing down your boot is actually slowing down the login, so do at your own risk.

Yeah not sure about that. My guess is the casper-md5check is irrelevant, not sure why udev would be affected by installing/uninstalling audio stuff, and also not sure if that actually slows down your boot, my guess would be no. vboxdrv and virtualbox are probably also irrelevant.

I think I should have included systemctl --user list-units --failed previously.

Oh good. Maybe you can try restarting pipewire w/o rebooting.

First, check if pulse is running (it might be even if uninstalled), with systemctl --user list-units (search for pulse by typing /pulse) or ps -A|grep pulse and kill it with (probably) something like systemctl --user stop pulseaudio or maybe killall pulseaudio. Not sure what’s better here, but it needs to be killed if it’s running.

Then do systemctl --user restart pipewire pipewire-pulse wireplumber.

Oh, I’m sorry. Can you run systemd-analyze blame (and also systemd-analyze --user blame) and look for something, near the top, that took a long time? Also systemctl list-units --failed to see if something has failed to load properly.

I’m afraid to ask, and I should have thought of that, do you remember if uninstalling fluidsynth removed anything else?

Also maybe try uninstalling pulseaudio, it’s possible it’s fighting with pipewire over the device, but that’s just a guess.

Yeah actually looks like the same issue I had. Just uninstall fluidsynth with apt remove fluidsynth and (probably) reboot, and see if that fixes it.

This is so stupid, what’s Vietnam supposed to do? What stuff does America produce that they can export to Vietnam to offset this trade imbalance? The US is basically ruining that country, again. Because what, they stole jobs growing coffee, assembling phones and sewing T-shirts from the American workers? I’m sure the American worker would love to do that at competitive wages of like $200 per month.

Also, imagine this perfectly balanced trade scenario: Vietnam sells coffee to the US, gets dollars, uses these dollars to buy oil from the UAE, and the UAE then uses these dollars to buy American weapons or something. As per the braindead Trump administration, this would be a problem, because it involves a third country.

I mean it’s definitely weird that wireplumber and pulseaudio are running simultanously, that is probably not great (or maybe it’s harmless, idk), but it’s normal when using pipewire to have wireplumber on control0.

Anyway you should try running fuser before you apply your fix.

Also I deleted my original post, because I wasn’t super happy about it, and made new one, so now there are two versions of this post. Sorry.

I mean something must have changed three days ago, kernel update maybe? You could try running a different kernel and see if this fixes it automagically.

I recently also had an issue where I could only see a dummy device, and that got me wondering. It was caused by fluidsynth hogging the audio device. So maybe could you check something? Look at the log file for pipewire (journalctl --user -u pipewire here) and do fuser -fv /dev/snd/* when it’s still in its broken state to see if (maybe) you’re misdiagnosing the problem. Because I could possibly sort of imagine that doing the force-reload and start pulseaudio dance might actually have seemingly fixed my fluidsynth issue by inadvertently making it so that pulseaudio got a hold of the audio device.

I had an issue like this recently on Debian testing and it turns out fluidsynth was hogging the sound device and so pipewire couldn’t open it. IDK why it was doing that all of a sudden. The symptom was also just having the dummy device.

I think what I did to figure this out was look at the pipewire logs and it said something to the effect that it couldn’t open the sound device because it was busy, and according to my bash history I did fuser -fv /dev/snd/* and figured out it was fluidsynth that was using it, which I then disabled or maybe uninstalled because wtf do I need midi for anyway.

Your problem may be different, but I can imagine, theoretically, that all the stuff you’re doing makes it so pulseaudio gets first dibs on the (otherwise busy) sound device and so maybe you have misdiagnosed the problem.

It’s option caps:escape_shifted_capslock I think.

You can look through /usr/share/X11/xkb/rules/base.lst for all the options.

Edit: Just looked up when this was added, this is a new option from 2024:

https://gitlab.freedesktop.org/xkeyboard-config/xkeyboard-config/-/commit/6bf17ba73bd94dd02e036a8c99c4a684a83f13fb

We knew about this stuff, but I guess it’s really only official once the NYT writes it down.

Apparently the way to write about one nuclear power being heavily involved in strikes on another nuclear power, except for actually pushing the button, which they strongly advise their proxy to do, is to make it kinda cool and daring and not terrifying. This reads like some character drama. Note how the Ukrainian characters seem a lot more flawed.

That they used euphemisms, like “point of interest” instead of “target”, to obfuscate what they’re doing isn’t that surprising, but seriously fuck these guys. Learn this one weird trick on how to avoid WW3: just call it something else. I wonder how insane someone has to be to be a general.

Also makes me wonder what they’re leaving out of that story. The Ukrainians did that one on their own, trust us. Sink Russian flagship? No US involved. Invade Kursk? US didn’t know about it. Attack Russian oil infra? Yeah not cool Ukraine, not cool. Also no word about who blew up that dam or Nordstream.

Everywhere else though? Yeah basically the US did all that. Total involvement.

We’re told it only went south when the Ukrainians stopped following orders. Not doing exactly what the US says is bad apparently. It’s either reckless or stupid, and it actually for real doomed their 2023 offensive. For sure that one would have succeeded if the stupid Ukrainians listened.

Great partnership guys, why oh why would anyone be wary if the US actually has their best interests in mind, let alone the best interest of the their soldiers or population? No, you see, you need to charge up that hill now! Don’t look at it first! Don’t shell it first! We swear it’s just a small number of Russians. And no, we don’t trust you enough to tell you how we know that. So risk averse these Ukrainians! And btw, I see a lot 18-25 year olds running around in Kiev, what’s up with that? Looks like you are not taking this very seriously Mr. Zelensky! Looks like you don’t want to win!

The file autostart.sh file needs to be executable. This might be why it’s not working.