I’m a flutter dev, and I’ve seen testimonies from a former Windows 98 dev about limiting the number of redraws in the shell.

There’s deffo extra overhead, but it’s not linear - 4k being 4 times as many pixels as 1080p doesn’t mean 4k the work to render after the first frame, as the browser/framework will cache certain layout elements.

The initial layout is still expensive, though, so big tables will take longer, but that big table at high Res will probably be less chuggy when scrolling once loaded.

np! o7

I guess it’s more niche.

Sure SUSE may not “need” a fork, but most forks of Debian and Ubuntu aren’t changing much beyond a few superficial settings - If you need your “own” distro you’re more likely to pick the bigger distros to fork and slap your own badge on á la TuxedoOS, PopOS, GnomeOS, KDE-Neon, etc.

rarbg mirrors are simply rehosting the database. You were even able to download and self host it for a while. Not sure if the tracker is able to accept new torrents though, I’m not really knowledgeable on how trackers work

We need colour! light themes aren’t meant to blind us!

yeah figma is GPU accelerated for all the vector graphics it handles

Figma is great for designers, there are sadly very few applications that support collaborative UI-UX design. We badly need a FOSS alternative!

Some distros allow this. Nix for example allows you to save config files that describe your entire system (apps, settings, etc) and then load them in one go. Other distros are following suit with their own tailored solutions too (I think Ubuntu might have something? Manjaro?).

That might save a bit of power, but your dedicated GPU is usually in an idle/powered down state until your compositor gives it specific applications to accelerate. for Nvidia laptops this is what the PRIME/Optimus feature does.

Your GPU doesn’t need to re-render your entire screen every frame. Your compositor will only send regions of the screen that change for rendering, and most application stacks are very efficient with laying out elements to limit the work needed.

At higher resolutions those regions will obviously be larger, but they’ll still take up roughly the same % of the screen space.

Unless you’re running games or 3D intensive apps no. Resolution is cheap on power under normal circumstances.

Fedora, Ubuntu etc. use up to date packages if you’re using flatpaks and snaps. Nix I suppose fits the bill better but it’s a harder distro to “learn” than arch imo

How about Rhino? Rolling release of Debian Sid iirc

I like the approach here, but the requirements are a little vague and prone to bikeshedding. Stuff like “could this be used by multiple clients” might mean a protocol is held in limbo whilst it’s given extra scope for example.

It’ll need some strong moderation which might rub people the wrong way, but if this keeps Wayland’s cutting edge moving whilst the official solutions are found, I’m all for it.

Wayland’s approach has always been to make 3rd party protocols easier to opt in and out of. Sway and Hyprland both used custom protocols whilst official solutions were being designed iirc. Nothing stopping anyone from switching from one protocol to another if they implement the same thing down the line.

At least this way, compositors may be able to use something like frog as a shared “experimental branch” which can be enabled for users who need them, but otherwise disabled whilst Wayland core isn’t pressured to work faster.

It’s up to Wayland to make these projects obsolete if it causes them or users a problem.

Spotube uses the Spotify API for playlists but YouTube PipeAPI and other sources for music streaming.

Size isn’t an issue imo. Applications are bulky for many more reasons than their packaging formats.

Interesting, didn’t know it was feasible to make the distribution open.

That doesn’t give me much to complain about in theory, but canonical has lost way too much good faith to give people a reason to keep open snap distribution going for free. They should definitely consider hosting an open store just to get people on board again.

Nothing in theory makes that an issue of flatpaks and snap, just that both rely on different means to interact with the host system that have been woefully slow to implement. If enough protocols are developed a flatpak or snap should be as capable as a native app with the safety benefits for free.

Honestly if not for the convoluted Linux FS layout, debs would be pretty serviceable and aren’t really different to the Windows solution. The fs layout makes installations way too fickle to clashing with other applications.

That and dependency hell, which distros should have never been allowed to touch beyond the core dependencies required to get your desktop running.

Nothing necessarily at the tech level. They’re more capable than Appimages or flatpaks to the point that you can use it to build a reproducible system hardened against tampering or defective updates.

The downside is that it’s controlled entirely by canonical, has limited abilities (if any?) for hosting storefronts/packages outside of their ecosystem, and said ecosystem is insecure and has already allowed multiple waves of malicious apps to reach end users because of poor moderation of listings masquerading as legitimate versions.

Canonical has also been increasingly hostile to flatpaks - removing it from Ubuntu and derivatives by default to push users towards snap.

The whole loopfs thing is just an annoyance, but the aggressive posturing by canonical as well as the closed nature of the storefront that has led to malicious attacks on end users is enough to give it more than a few haters.