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.

Right I can see where you’re coming from but that incentivises using Kagi less which IMV is a really bad incentive for all parties involved.

What if they made it so that a single search per month was fine too? You’d be back complaining that it’d be $5 if you only made 2 searches that month.

It’s really hard to set a cut-off here.

On the one hand yes but on the other hand this would also kind of set wrong incentives: to use Kagi search less because you’d need to pay more.
That’s not an incentive they or you would want.

I think what I’d like is how my mobile carrier handles their data limits: It’s not an entirely fair comparison because in that case, contrary to Kagi, there is no real cost associated with my degree of usage of the service, making them entirely arbitrary and unnecessary but besides that the unused data rolls over to the next month and that’s something Kagi could mirror.

I hover around 600-1000 searches per month but sometimes exceed 1000. If I could pay for 1000/month and accumulate a little buffer in the months where I search less, that would work for me. Though perhaps I’d still want to just simply pay for unlimited usage for peace of mind.

This sounds like FUD. Do you have a source for that?

As a paying member, I know that they started charging (and presumably transferring) VAT last year.

Before that, they claimed they were simply too insignificant to even be eligible for VAT.
I looked it up and there appears to be an exception for such cases where VAT is charged in the company’s jurisdiction rather that the customer’s (it’s usually the other way around) until you reach 10000€ annual turnover. Information on this is extremely intransparent however, so this might be wrong.

They do. The $10/month search plan is unlimited.

The only LLM stuff in their search product is the quick answers which can be turned off and page summaries which you have to explicitly click on in a submenu in any case.

As someone aware of how limited LLMs are, I’ve actually found both of these features to be useful for gauging whether a site is worth visiting or not at times which is part of the core feature set of a search engine IMHO.

A good while back they claimed that Google search index fees make up the vast majority of their costs, so I doubt any of your money is going towards LLM BS unless you actually pay for their assistant product.
I doubt Google has given them any discounts since then.

I’d expect the development of all of their product to be mostly funded by VC. If they can get VC idiots who fell for the “”“AI”“” hype to subsidise building an actually useful thing (the search product), that’s a win in my book, even if they also have to build the AI crap on the side to keep said VC idiots happy.

Even with root it’s not anywhere near trivial.

You can’t, for instance, make a backup of the userdata partition block device and expect to be able to restore it because it must be decrypted by a key in the phone’s security module that gets wiped when you boot a new ROM.

Should have just been a reply.

Someone started working on a Vulkan driver for TeraScale GPUs a few years ago:

https://gitlab.freedesktop.org/Triang3l/mesa/-/tree/Terakan

I believe it can run some demos add even works on windows.

While velocity is certainly the larger contributor, it’s not like mass is insignificant either. Especially for the cargo bike case where even unloaded the mass difference requires a ~5km/h change in velocity for equal kinetic energy.

When you get to very high absolute velocities, mass becomes less and less significant but we’re very much at the low end here in that regard.

With E-bikes it’s not just the “unnaturally” fast speed but also weight and that’s doubly important for powered cargo bikes.

Speed limits don’t really make sense here though. What determines the amount of damage inflicted in a collision or how easy it is to avoid a collision by breaking is kinetic energy; that’s what needs to be limited.

I’d just base this around what a “normal” human on a “normal” bicycle can do on flat ground with reasonable human power alone: e.g. 70kg human on a 10kg bicycle doing 25km/h. That’s 80 kilogram × (25 kilometre / hour)² = 3858.02 J of kinetic energy.

Now we can assume e.g. a 20kg e-bike and calculate backwards: sqrt(3858.02 joule / (70 kilogram + 20 kilogram)) = 23.5702 km/h
Or with a 50kg cargo e-bike: sqrt(3858.02 joule / (70 kilogram + 50 kilogram)) = 20.4124 km/h.

Ideally cargo bikes would also factor measured load into them. If you carried an additional 50kg, it should only power up to 17.1498 km/h for instance.

What conditions would be “safe” under “normal” circumstances and how heavy you assume people to be are debatable and dependent on where you are (welcome to NA, +10kg avg. weight) but the mechanism should be the same.
We need to define some limit of kinetic energy that is reasonably safe for pedestrian and bicycle collisions and in line with what typical human on an unpowered bicycle would net you. Powered bicycles (or any other powered vehicle for that matter) then need to enforce that limit by way of cutting off power once the maximum kinetic energy is reached.

Oracle ZFS is so obscure by now that it’s irrelevant.

As usual with Oracle products, it’s just a means to squeeze poorly led companies.

I tried to relate the limited niche where having closer together gearing makes a noticeable difference

You appear to be misunderstanding. This isn’t about making gearing be closer together, this is about increasing the range of the gearing by making the low end lower and only reducing the high end by a little.

If anything, the configurations I wrote about would make gear spacing less even as the default is quite nicely spaced.

What I need to know is whether the change in the low end is actually noticeable in an uphill scenario and by how much.

So I prefer to have as wide as my drivetrain supports. If I have any choice, I prefer a tighter set of low gears and a bailout final cassette cog.

It’s the same for me I think. I’d prefer some variety of low gears for uphills and some variety for relatively flat ground. I don’t very much care what’s in between as long as it’s not too far apart.

When I start riding, I usually use one of the lower gears for half a turn and then immediately switch the hub from 64% to 100% (skipping the gear in between) which is a jump from 2.64m to 4.14m or 3.25m to 5.10m and then usually up to 5th gear (6.49m) for a bit and then the 6th gear when conditions allow.

I wouldn’t worry about the total, and would start with the widest cassette that will work with your current setup. Then I would only change the front chainring if you still feel a lack of top speed.

This again appears to be a misunderstanding: This is a 6-speed Brompton.

6-speed here means 6 gears total, including the hub.

The gearing is as follows:

• Hub with 3 fixed ratios (64%, 100%, 157%)
• Derailleur between two sprockets that can be equipped with a maximum of 17 teeth due to size constraints
• One chainring (no derailleur)

I get to choose the two sprockets and the chainring. That’s it; there is no wider cassette that physically fits this frame.

The reason for changing the chainring is merely to shift the gearing down which isn’t possible by changing the sprockets because a sprocket larger than about 17T will physically not fit. Again, this is a Brompton with tiny 16" wheels that folds down to suitcase size.