Did you/your distro set up realtime ulimits correctly such that pw can acquire rt priority?

Tab groups are one of the best features to come to modern browsers the past few decades. Especially the ability to save and close them greatly aided me as a rehabilitating tab hoarder.

Haven’t tried vertical tabs yet but it’s great to see them implemented in Firefox properly now.

Great to see that PWAs finally coming back, even if it’s only on Windows now. Didn’t catch that they are working on that again!

I find the link previews to be distracting but they’re easy enough to turn off.

Great to finally be able to undload tabs manually. That would have been extremely useful back in my tab hoarding days. Tab unloading is generally quite a neat feature.

The LLM shit can go away for all I care but it’s not really that invasive IME. It’s one entry in the right click menu that’s easy enough to turn off right from said menu for me.

PDF editor upgrades are very welcome.

Right click to search for an image sounds like such an obviously good UX feature; great to see they’re thinking about such things again. Sad to see it’s Google-only for now but that makes sense given how small and non-standardised the market for reverse image search is.
@kagihq@mastodon.social could you perhaps get in contact with Mozilla so they can implement your endpoint for this too?

I get the sentiment but it does not seem appropriate in this case‽

2/14 features in the article are related to slop. The other 12 are actual, genuine improvements; some of them quite significant if you ask me.

Blame where blame is due but please don’t forget to praise where praise is due too.

Thanks for the explanation!

Though it ought to be possible to only respond with the new self-signed cert when LE does the challenge and with the previous, properly signed cert otherwise.

I found https://codeberg.org/neilpang/acme.sh/wiki/TLS-ALPN-without-downtime which demonstrates one method to achieve that but I lack practical experience judge whether that’s optimal.

Forgive my ignorance but why would that incur a downtime?

The only way I can think of for downtime to happen if you switched certs before the new one was signed (in which case …don’t) or am I missing something?

It also strikes me as weird that LE requires 80 but does allow insecure 443 after a redirect. Why not just do/allow insecure 443 in the first place?

The same that happens when you update to receive a breaking change on a rolling distro. It’s version number go up, just at a different point in time.

That’s a very odd example to choose given how trivially interchangable kernels are.

At NixOS, we ship the same set of kernels on stable and rolling; the only potential difference being the default choice.
I’m pretty sure most other stable distros optionally ship newer kernels too. There isn’t really a technical reason why they couldn’t.

To be able to predict when something you depend on breaks.

This “something” could be as “insignificant” as a UI change that breaks your workflow.
For instance, GNOME desktop threw out X11 session support with the latest release (good riddance!) but you might for example depend on GNOME’s X11 session for a workflow you’ve used for many years.

With rolling, those breaking changes happen unpredictably at any time.
It is absolutely possible for that update to come out while you’re in a stressful phase of the year where you need to finish some work to hit a deadline. Needing to re-adjust your workflow during that time would be awful and could potentially have you miss the deadline. You could simply not update but that would also make you miss out on security/bug fixes.

With stable, you accumulate all those breaking changes and have them applied at a pre-determined time, while still receiving security/bug fixes in the mean time.
In our example that could mean that the update might even be in a newer point release immediately but, because your point release is still supported for some time, you can hold on on changing any workflows and focus on hitting your deadline.

You need to adjust your workflow in either case (change is inevitable) but with stable/point releases, you have more options to choose when you need to do that and not every point in time is equally convenient as any other.

Rolling vs. point release is not about whether a breaking change happens or not but when.

With rolling, breaking changes could happen at any time (even when inconvenient) but are smaller and spread out.
With point release, you get a big chunk of breaking changes all at once but at predictable points in time, usually with migration windows.

Waiting some weeks for uncaught bugs to be ironed out might be advisable if you still have limited debugging capabilities.

Otherwise, you can always nixos-rebuild build-vm using the new release channel and see whether it breaks anything you depend on.
My experience is that it probably won’t. My past few years of updating my server from one stable release to the next were, in one word, boring. Some renames, deprecations etc. with clear errors/warnings to fix at eval time but nothing that actually broke once it was built and deployed.

https://blog.kagi.com/small-web is the closest I’ve seen but it is indeed quite small and often not useful.

Kagi is generally a tool that can be made to clean your search results of poorly incentivised content. It already categorises “top 10” click farms as such OOTB and lets you disable them entirely.

The ability to block websites from appearing in your results is the most useful though IME. If I stumble upon a poorly incentivised website, I can simply block it and it will never appear again.

It’s not all you’re asking for but it gets you the closest that I know of.

Sources claim an up to 100% mortality rate!

That is indeed a nice tool.

The default configuration of 13/16T also provides quite even spacing though. The more significant difference is that the 12T in the back require a 44T chainring for similar development as 13T + 50T and that extends the lowest gear from 2.65 to 2.49.

This is all nice and all but my problem is that it doesn’t tell me how significant that difference actually is in the real world; I don’t know how the 0.25 delta would actually manifest itself in a way where you’d feel an appreciable improvement in climbing hills.

And it’s also client-side. Kagi filters them server-side AFAICT, so from your POV it’s instant and without client-side filtering jank.

There’s also the option of just leaving an offline disk at someone’s and visiting them regularly to update the backup.

Having an entirely offline copy also protects you/mitigates against a few additional hazards.

If you don’t process any user data beyond what is technologically required to make the website work, you don’t need to inform the user about it.

He

I hate to be that guy but OP gave no indication of their gender. English has the luxury of having a “natural” neutral pronoun; please just use that.

which these suggested Fedora Spins are designed to integrate with as tightly as possible

Could you explain what exactly this “tight integration” pertains? AFAIK these are just regular old global-state distros but with read-only snapshotting for said global state (RPM-ostree, “immutable”).
Read-only global system configuration state in pretty much requires usage of Flatpak and the like for user-level package application management because you aren’t supposed to modify the global system state to do so but that’s about the extent that I know such distros interact with Flatpak etc.

Bazzite is completely the opposite of an OS designed to run one app at once, which means you haven’t tried it before rubbishing it as a suggestion.

That is their one and only stated goal: Run games.

I don’t know about you but I typically only run one game at a time and have a hard time imagining how any gaming-focused distro would do it any other way besides running basic utilities in the background (i.e. comms software.).

Obviously you can use it to do non-gaming stuff too but at that point it’s just a regular old distro with read-only system state. You can install Flatpak, distrobox etc. on distros that have mutable system state too for that matter.

Could you point out the specific concrete things Bazzite does to improve separation between applications beyond the sandboxing tools that are available to any distribution?

It’s true that I haven’t used Bazzite; I have no use for imperative global state distributions and am capable of applying modifications useful for gaming on my own. It’s not like I haven’t done my research though.

There is no distribution that does what you’re looking for. All the ones recommended by others in this thread are just generic distributions that do nothing special to separate user applications and I have no idea why they saw fit to mention them at all.

The best recommendation here is Qubes but that’s arguably not a distro but rather its own operating system that can then run some instances of distros inside of it with strong separation between those units.

The only thing that somewhat goes the direction you want is Flatpak but it’s not anywhere close to Androids really quite solid app separation scheme.

The reality of it is that most Linux desktop apps are made with the assumption that they are permitted to access every resource the user has access to with no differentiation; your SSH or GPG private keys are in the same category as the app’s config file.

Standard APIs to manage permissions in a more fine-grained manner are slowly being worked on (primarily by the flatpak community IME) but it’s slow and mostly focused on container stuff which I’m not convinced is the way forward. There does not appear to be any strong effort towards creating a resource access control design that’s anywhere near as good as Android’s in any case though.

The closest thing we have is systemd hardening for system components but that’s obviously not relevant for desktop apps. It’s also (IMHO) inherently flawed due to using a blocklist approach rather than an allow-list one. It’s also quite rigid in what resources it controls.

I’m not convinced any of the existing technologies we have right now is fit for a modern user-facing system.

Here’s what I think we ought to have:

• A method to identify applications at runtime (e.g. to tell apart your browser from your terminal and your editor at runtime)
• A generic extensible way to declare resources to which access should be controlled within a single user context (i.e. some partition of your home filesystem or some device that your user generally has access to such as your camera)
• A user-configurable mapping between resources and applications; enforced by kernel-level generic mechanisms

No need for any containers here for any of this; they’re a crutch for poor legacy distro design that relies on global state. I don’t see a need for breaking the entire UNIX process model by unsharing all resources and then passing in some of them through by overly complex methods either.

Eventhough they’re quite simple and effective, I’m not convinced UNIX users are a good primitive to use for application identification like Android does it because that implies user data file ownership needs to be managed by some separate component rather than the standard IO operations that any Linux apps ever uses for everything.
I think this should instead be achieved using cgroups instead which are the single most important invention in operating systems that you can actually use today since UNIX IMHO.

The missing parts are therefore a standard for resource declaration and a standard and mechanism to assign them to applications (identified via cgroup).
I haven’t done much research into whether these exist or how they could me made to exist.

That is not relevant here in any way. That’s a distro made to easily run one app at a time without really caring about data security w.r.t. that app.

Note that even with this it’ll be quite likely that games don’t work. WineD3D is much less compatible than DXVK.

You need a device that can do Vulkan properly. The best for that are AMDGPUs and Nvidia ones but I wouldn’t recommend the latter. Newer Xe Intel GPUs should also work but they’re quite a bit behind anything AMD has to offer in terms of performance.

The newer of your GPUs meanwhile is a design from ~2015. Vulkan released in 2016. Just to get you an idea.

The issue here is not Linux, it’s that neither of your GPUs was made for modern gaming. On windows that might sometimes work, especially with games targetting older graphics APIs that your GPUs were made with in mind but on Linux everything is Vulkan (a very modern graphics API), even games that only use older APIs.
A modern Vulkan-capable card is a requirement for painless gaming on Linux.