Bitwarden seems to be pretty clearly on the path of enshittification. They've been going towards closing off the self-hosted versions for a while, and moving their app out of repos that check licenses, with the likely aim of taking it closed source.The usualy will surely follow.
Not sure how soon, but I definitely wouldn't newly go to them at this point.
Hm, that's a harsh price then.Even ignoring having to figure out how to send letters, I noticed they seem to have fees for having an account, and the lowest I noticed with a visa debit card was over 10€/month, while the lowest with EC was technically 3€/ but charged for transactions, so the lowest sane one was 7€/.
So if I can't move my account entirely and would use those as a second account, which it looks like I'd have to, I'd basically pay a significant monthly subscription fee for mobile payment.
How much light is a photon, anyway? Does is take thousands or trillions of photons interacting with the eye to register as light?
Others mentioned there is a atudy showing it could be a single photon in an extreme controlled environment.
But in normal conditions, eyes chemically adjust to a reasonable sensitivity, our dynamic range is not limitless.Eyes actually have the very quick contraction and expansion of the iris, and then that chemical tuning on top, which is why it can take some minutes to see well in strong darkness.
So taking something more realistic you would see in different cases: In a darkened hall you can make out a faint led at 40m distance, faint being about a μW, which is unusually dim for most leds you encounter. A μW might yield you 100μl (micro lumens).
xkcd puts a firefly as 600μl lumen, which is about a millionth of a dim light-bulb. That comes to the same brightness at 100m distance, which is reasonable for seeing fireflys well.
Both of these shine that light output on a sphere, which your eyes capture a small circle of, whose size is your maximally expanded pupil. Looking at wikipedia "the size of the pupil [varies] between 1.5 mm and 8 mm", which having to look at wikipedias source (thanks for nothing) tells me it is the diameter, so radius 4mm.That equates to 2.5ppb of the total area for the 40m distant led, so 2.5 billionths. So of those 100μl, the eye receives 250fl (femto lumens).
Assuming the color averages to green, specifically 555nm green, that has 1/683 W/l. A photon has energy in Ws of c•h/555nm, which works out to 2.8 quintillion (555nm) photons per second per lumen.
250fl is 250000 quintillionths of a lumen, so we are talking 7000 photons a second.Now in the dark you might notice your vision is quite blurry, and takes a while to pin stuff down, analogous to a longer exposure time. So to detect say blinking, you might need to wait 100 or 200ms. So maybe we can say you can comfortably see units 700 to 1400 photons in a sufficiently dark environment.
That's actually very promising. It's europe, I should just go and see if I can open an account with them even without german residence.Do they have decent online-banking and savings accounts?
I'm unaware of anyone but curve, and curve seem to shadow-ban you for having rooted or weird phones and then claim kyc failure. In general they are quite shady and have poor customer service.
You know any other ones? Would be very useful since I think anyone in the eurozone could then use those.
since im not sure where in the boot process linux recognizes my raid and when the decryption happens
Usually raid and decryption happen in the initram. This is because these are too complex to sit purely in the kernel, requiring userspace tools like cryptsetup, but you want to be able to boot off of them so they have to be handled before the disk is mounted.
Usually that initram is dracut. Why dracut only partially completes the process here, likely figuring out the raid but not decryption, is anyones guess. In my experience dracut is quite hard to debug and configure.
The simplest approach is probably to just eat it and write a startup service that does it. Basically a startup command. No need to worry about timing, as when the initram finishes the raid should already be up.There might be a prebuilt systemd service for it too iirc...
If you really wanns go for it, there are other initram systems like ugrd, which are easier to configure and might figure your setup out properly. But you'll probably have to manually install and update them. That would definitely be a very involved approach.
There are some guesses I made here on your boot timeline. If you show your dmesg I can confirm if the raid really comes up at initramfs time. But it should be s solid bet.
Your demo instance seems unable to open any other subs.Also it redirects to an archive path which is not how redlib works and makes me question how the sesmless response regardless of state is supposed to work.Once it dumps me in the archive for whatever reason, don't I have to go back manually? (Not that even seems possible right now)
Is "Enterprise Applications" like shooting datacenters into space, or copilot business edition?I think the "Space-Enabled Solutions" part sounds more like designing satellites than the space-launch business.
Kilpatrick then brought up something especially awkward. He reminded Lendacky of a comment that the engineer had made back in 2020, confirming that a Ryzen 3700X, a consumer CPU, “should support TSME.” In a later 2025 comment in the same discussion, Lendacky again recommended using TSME, while noting that the motherboard BIOS provider had to expose the option. So there it was, AMD's own engineer, years earlier, acknowledging the feature working on exactly the kind of lower-end chip now stripped of it, proving that Ryzen support was not some fantasy users invented.
So this engineer is openly recommending it.
is an email response stating that TSME "is a security feature only applied to PRO CPUs as part of AMD PRO Technologies," notably the first time the company has publicly stated such a restriction
amd itself never stated anything at all, one way or another.
where two AMD engineers eventually responded: Tom Lendacky, an AMD fellow software engineer, and Mario Limonciello, an AMD senior principal software engineer.
Interestingly, neither engineer appeared to have a clear answer for why the feature had disappeared.
This sort of implies both knew of it and didn't know of the specifics of the removal. But it isn't clear.
Reading it again I may havw over-remembered though, to be fair. Not as high level as I thought.This does also mention that amd didn't "advertise rhe feature only for pro cpus". They never specified it at all, so all there was to go on was the actual cpu behavior, which did support it on all lineups. With a feature mentioned and not stated to only be present on some lineups, it's also reasonable to expect it present on all cpus.
Earlier article mentioned it was acknowledged by high ranking amd officials multiple times over the years.So they definitely knew.
It might have been that it wasn't documented internally and someone else removed it not knowing it was in use.But at the latest with the initial bug report this was clear, at that point it did reach people who knew. So not undoing it, especially given the severity of the impact of silently disabling a security feature, is absolutely on amd with no excuse.
What's the point over keepass with syncthing?