That’s an interesting report but it’s possible to “work” at different latencies. And unless you have specialized audio capture/playback hardware and have done some tuning and testing to determine the lowest stable latency that your system is capable of achieving… “works” for you is likely to mean something very different than it does to someone who does a lot of music production.

It remains an interesting question to some users whether Wayland changes the minimum stable latency relative to X and if so whether it does so for better or worse.

I’d consider asking in a Linux audio or music production community (I’m not aware of any on Lemmy that are big enough to have a likely answer though). If music production is a primary use case and audio latency matters to you, almost no general users are going to be able to comment on the difference between X and Wayland from a latency perspective. There may not be a difference, but there might and you won’t be likely to learn about it outside of an audio-focused discussion.

Tell me more about why I care that snap is setting up loop devices and not that docker is setting up virtual ethernet devices and nftables chains. System tools do system things, news at 11.

I say again, this impacts my life not at all and there is nothing easier to ignore than snap.

… those “pending update, close the app to avoid disruptions” popups are kind of disrupting.

I don’t exactly disagree that it’s slightly irritating but:

1. No one declares war on an operating system the way snap haters have over a “restart to update” message. It’s an irritation, but it’s not an irritation proportional to the response snap gets out of people.
2. Restarting to enable an update or complete an update is not something unique to snap. Except for a tiny number of very advanced live-patching systems like the one some kernel updaters use, every updater either nags you to shutdown to do the update, nags you to restart to finish the update, or doesn’t nag you and the update just doesn’t take effect till you restart (apt falls in this category and it’s not unambiguously better than nagging because you’re silently vulnerable when security patches are shipped until you restart). So again, this is just an extremely unremarkable thing that tons of updaters deal with similarly.

I do nothing.

• I use the Firefox snap. It takes like 800 extra milliseconds to start up on my 10y old laptop and it moves my profile dir. It otherwise impacts my life not at all and is just fine. If it ever bothers me, there PPAs, flatpak, or a dozen other ways to install Firefox that are all perfectly simple.
• I install other stuff from flatpaks or PPAs or using docker.

The angst around snap is inscrutable to me. There are 30 million easy ways to install software and they all work on Ubuntu. There is nothing in my life that’s easier to ignore than snap.

Really happy to see the image-zoom fix in there. Limited zoom was pretty irritating recently and it’s totally addressed here.

I haven’t used Tuxedo, but on apt-based distros it’s pretty common for an auto-update daemon of some kind to run in the background on startup to either download updates, or at least download package metadata so some UI component can start nagging you to install the updates that are available.

If you wait a few minutes, the download should complete and you can do what you want. You can probably get away with killing it, especially if you use a gentle signal like HUP. I wouldn’t risk it though… if you corrupt your package metadata or worse… and actual important package… it can be a significant hassle to clean up the mess. And the cost of waiting 30s-5m and trying again is so low it’s hard to beat that as an approach.

If its happening a ton you can probably find and disable the auto-update thing but I don’t know what it would be on Tuxedo.

All fair enough. I’m not real convinced about this though:

My guess is: A popular app will implement this feature and it will become mandatory for everyone else who wants downloads.

I suspect some app does do this already, some definitely have ways to interact with specific instances while logged out of them. I have 6 lemmy apps or PWAs installed just to keep up with new developments there… but I couldn’t tell you the differences in community discovery between them because the federation and instance discovery problems make it unrelentingly terrible on all of them when compared to lemmyverse.net, which already supports browsing communities by instance.

While I would love for in-app discovery to be good, the journey from where we are to where lemmyverse.net is is long enough that I don’t really see any intermediate hacks as being app-defining.

The idiomatic way to query communities in Lemmy is to interrogate your instance, not to interrogate the instance hosting the community. I think there are some sensible reasons for this:

• Large instances hosting lots of communities want to delegate read workload to the many instances out there hosting users. They don’t WANT everyone coming to query the communities instance directly. That’s rather the whole point of federation. Now, will one app doing direct community-hosting queries bring down the threadiverse? No, it won’t. But it’s not how community discovery is envisioned to work, and Jerboa being developed by the lemmy devs means that it’s unlikely to employ non-federated community discovery hacks.
• If you offer community discovery by directly querying the instance, you create another discovery problem which is equally hard to solve… which is instance discovery. OP may have a particular instance in mind already that they want to query, but as soon as querying communities by instance becomes a commonly used feature… people WILL immediately begin asking how to search instances to put into that list… which again is generally a problem that is supposed to be addressed through federation. Also if you don’t build instance discovery, you’ll have tons of reports from people who mistype instance names and can’t figure out why it’s not working.

All of which is to say that while there is an approach that involves directly querying a specific instance… it’s a partial solution that doesn’t build toward a comprehensive one. I don’t expect the devs to move this direction, but rather to focus on fixing the community browser in lemmy and exposing those capabilities through jerboa. This is the larger job I was referring to, and although there is a shorter path to OP’s specific request, I don’t think it’s a likely one to be followed in Jerboa.

Fwiw, it’s straightforward to do this on lemmyverse.net, which works well on mobile. The way federation of new communities works means that it’s a relatively big job to create a usable community browser within Lemmy right now. I wouldn’t expect rapid progress in this area, and would consider adapting your community browsing habits to rely on lemmyverse rather than in-app browsing.

I’ve used a combination of

• Managing ZFS snapshots with pyznap
• Plain old rsync to copy important files that happen not to be on ZFS filesystems to ZFS.

If I were doing this over today, I’d probably consider https://zrepl.github.io/ instead of pyznap, as pyznap is no longer receiving real active development.

In the past I’ve used rdiff-backup, which is great but it’s hard to beat copy-on-write snapshots for speed and being lightweight.