I really enjoy when it when someone injects a dose of "wacky" into something that is taken more or less for granted (Raft) to challenge the standard way of thinking about it.
This article flipped my understanding of split-brain or network partitions on its head: You don't actually have to have a majority to ensure progress, you just have to design your quorum selection criteria in such a way that no other partition believes they are authoritative, and these finite projection planes are an interesting way of proving that (with caveats).
All illegal or unethical means can be explained, but not justified, by their ends.
I'm quite sure having unfettered insight into the browser environments of your users makes enforcing your Terms of Service much easier, but held against the (even minute) risk of exposing one of users' political, religious or sexual preferences, any of which might carry with it massive risk of bodily injury or death in many parts of the globe? I'm sorry but ToS enforcement does not even begin to clear that bar.
If you don't want your users to scrape large parts your website, have you considered just blocking users with outsized traffic usage and not violating their privacy in the process?
Justifying this invasion of privacy as a means of defending LinkedIn against the apparently existential threat posed by something as pedestrian as scraping is especially ridiculous when considering how LinkedIn managed to even get off the ground in the first place: By invading the privacy of its unwitting users by scraping their contacts and impersonating them via email[1].
In 2023 I quoted a customer some 30 hours to deploy a Kubernetes cluster to Hetzner specifically to run self-hosted GitHub Actions Runners.
After 10-ish hours the cluster was operational. The remaining 18 (plus 30-something unbillable to satisfy my conscience) were spent trying and failing to diagnose an issue which is still unsolved to this day[1].
It sometimes blows my mind how questions which essentially boil down to "How do I best manipulate you for personal gain?" can be asked in such an unabashed fashion.
Introducing a separate charge specifically targeting those of your customers who choose to self-host your hilariously fragile infrastructure is certainly a choice.. And one I assume is in no way tied to adoption/usage-based KPIs.
Of course, if you can just fence in your competition and charge admission, it'd be silly to invest time in building a superior product.
You can always upload your own, it's pretty simple doing so in a reproducible manner using something like Packer, but even without it you can just boot a VM into a rescue system, write your OS of choice to the VM disk and reboot.
Technically there are two clients: The camera and whatever device is used to access the feed.
I can absolutely imagine an architecture where video can be streamed in an encrypted manner, or stored in encrypted time-stamped blobs, allowing the server to provide rough searching, and then the client can perform fine-grained scanning.
This obviously doesn't enable any kind of processing of the video data on the server side, and doing it on the receiving client would require the feed to be active This means that any kind of processing would almost necessarily have to happen on the sending device, which would probably increase the power and compute requirements by a lot.
Doing a self-audit like this is actually an amazing idea. I consider and re-consider my choices every once in a while, but sitting down and doing an end-to-end write-up would put me a lot more at ease.
Like you, I also considered the implications of mixing TOTP into KeePass, but eventually landed on going all-in on the one database. It does mean raising the bar for keeping it secure, but it was already very high to begin with.
One thing I have considered is combining this all-in-one approach with an additional keyfile, which I could then share OOB to devices, effectively adding a second factor. I like the idea of using Yubikey or similar, but the fear of locking myself out is too great.
Oh don't get me wrong, my claim is that they are not even clearing the absolute lowest bar when it comes to their stewardship of the Bitnami repositories: Do no harm.
Others have already provided good answers. I wouldn't classify it as evil if all they did was to stop maintaining the images & charts, I recognise how much time, effort and money that takes. Companies and open source developers alike are free to say "We can no longer work on this".
The evil part is in outright breaking people's systems, in violation of the implicit agreement established by having something be public in the first place.
I know Broadcom inherited Bitnami as part of an acquisition and legally have no obligation to do anything, but ethically (which is why they are evil, not necessarily criminal) they absolutely have a duty to minimise the damage, which is 100% within their power & budget as others have pointed out.
And this is before you even consider all the work unpaid contributors have put into Bitnami over the years (myself included).
I suspect this might be helpful for minor integration challenges or library upgrades like others have mentioned, but in my experience, the vast majority of Rust compilation issues fall into one of two buckets:
1. Typos, oversights (like when adding new enum variants), etc. All things which in most cases are solved with a single keystroke using non-LLM LSPs.
2. Wrong assumptions (on my part) about lifetimes, ownership, or overall architecture. All problems which I very much doubt an LLM will be able to reason about, because the problems usually lie in my understanding or modelling of the problem domain, not anything to do with the code itself.
Thanks for writing all this down! I've written a lot of Rust, which was why I was drawn to RMK initially, but ran into a lot of the same headaches as the author, but without the perseverance to resolve any of them.
I did manage to get QMK working eventually, but without VIA/L the prospect of having to flash the two parts of my Ferris Sweep every single time I wanted to fine tune it, and having already spent a lot of time just getting that far, completely burned me out on the project.
I tried the same about a month ago and was unable to get anywhere, probably due to being very new to the custom keyboard scene and having only a very vague understanding of how qmk/rmk/vial/keymaps fit together. Thanks for writing this up, I might give it another go now!
I think impact can have a big influence on mechanical hard drive longevity, so it could be that the way the ServerPartDeals drives were sourced, handled or shipped compromised them.
Postgres upgrades were actually annoying the last time I did, where I had to explicitly import data from a previous version into the new one, instead of the software just automatically detecting that the data was a version behind and doing whatever to upgrade the format.
This would probably not have been as big of a headache, if it wasn't because it was running in a container, and was deployed as part of a separate project, meaning CloudNativePG (which probably handles this for you) was not an option.
https://github.com/MathiasPius/