If there are two version of Bitwarden backend (closed and FOSS), and the closed one changes its API, and the closed Bitwarden apps also switch to the closed API, then what value does the FOSS API have anymore?

Both backend and frontend revolve around the API, and Bitwarden owns that not Vaultwarden.

If Bitwarden decides to modify the API so that only their closed-source backend has the full spec, and only gives that spec to their own apps, everything else (Vaultwarden and 3rd-party apps) will fall behind or become unusable.

To counter that, Vaultwarden and the 3rd-party apps need to declare their own API and prepare to fly solo completely independently from Bitwarden.

Such a move would force Bitwarden to show their true colors. If they really mean to stay true to the open version they will keep cooperating and keeping their API in sync with the Vaultwarden API.

The current FOSS backend used to be the center of the ecosystem. Going forward that may change. If it stops being that center and it becomes merely a token offering so Bitwarden can claim “we’re still doing FOSS” then it will become pointless.

Simply forking the backend is meaningless without the work to also drag along the entire ecosystem, or establish a new one. Forking a project takes time, effort, vision, persistence, determination.

Everybody can still fork/rename/publish the FOSS version

Yeah, but there’s no guarantee the FOSS version will be the same as the closed one.

Vaultwarden (and all the client apps) depend on Bitwarden for the API spec. If Bitwarden introduces closed features in the API that Vaultwarden can’t/won’t implement, but the client apps do, it will split the spec. They can also introduce API license keys, which would render Vaultwarden mostly irrelevant.

The only way for Vaultwarden to remain relevant going forward is to own it and split ways from Bitwarden. This would in turn mean that the FOSS client apps have to decide which to support. But I think the ecosystem is going to fragment eventually anyway, so the sooner every app decides which way they want to go, the better.

I just wish Syncthing didn’t have such a convoluted port usage, and also that its Android usage didn’t revolve around an unofficial app.

So I’ll stick to apps that do sync over SSH (using FolderSync atm).

Yeah but if you want to use something different, or may need to use different web servers or proxies from time to time, it’s better to have the cert renewal stuff separated.

Also, for any provider that’s off the beaten path you have to build caddy yourself to include the right plugin and that’s just meh.

Caddy’s fine if you only use one provider and only Caddy all the time but other than that no.

makes the manual checkout even faster since at the same time the cashier is doing the checkout you’re doing the bagging

There’s nothing stopping people at self-checkouts from putting items in bags as soon as they’ve scanned them. But lots of morons will first scan everything, then proceeed to take another stretch of time to leisurely find their bags and figure out how to pack things.

That’s not the self-checkout’s fault, that’s plain human stupidity.

In my experience, stores with that kind of ratio are miserable to shop at. At high demand hour the most you can get away it is 2 register with 1 employee, maybe 3 if the self-checkouts are very good (good UI, not error-prone).

The ones that need to match the weight of the product are absolutely horrible and full of errors.

The ones that only need to scan barcodes are ok-ish. Sometimes you can run into weird situations, like I managed to find a product that had two barcodes for some reason, and I scanned the “wrong” one and it confused the machines. Or there was a product that printed their barcode so tiny that the machine couldn’t scan it. But those are rare.

The fun part is when you try to buy any alcohol because over here they need to call a human to confirm you’re an adult.

if you need someone there is a phone to a callcenter.

Yeah. Like if you want to leave without buying anything.

They can accept cash but those that do work like ass, and also attract less tech-savvy customers. So they need to keep them separated from card-only self-checkouts, otherwise it bogs down everybody. And yes, at that point they might as well convert them back to manned checkouts, because more often than not they require a person to stand by and help the customers with the cash.

That’s the tricky part about self-hosting and it doesn’t get addressed enough. There are virtually zero apps designed with user privacy in mind.

What kind of library scan did you do? “Scan for new and updated files”, “Search for missing metadata” or “Replace all metadata”? The release notes don’t mention what exactly they mean by “full library scan”.

And GUI feels like black magic too if the person doesn’t know what’s going on.

LFS is actually a pretty good learning experience. But that depends on whether you’re interested in topics like kernel configuration, filesystem organization, the boot components and boot sequence, init system, common app resources, compiling apps, and generally how a Linux system comes together. It gives you a solid grounding that’s applicable to any Linux distro (not super-specific like Arch/Gentoo/Nix tend to be). But it’s pretty dry stuff and you have to be really fascinated by Linux to dig into it.

On the cool side once you get through LFS you should be able to put together your own mini Linux distro and see how small you can make it and still boot and do something useful.

Was probably introduced or re-introduced recently.

Has anybody upgraded from 10.11.11 directly to 12.2?

Yeah if you put it behind a reverse proxy you have lots of options. Basic auth would be the most straightforward but you can also do mTLS with a custom self-generated CA fairly easily. Then there’s OAuth but the setup is usually more involved than either of the above.

Whatever you use you gotta have HTTPS working, that’s very important to keep it secured.