MathiasPius

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].

[1] https://en.wikipedia.org/wiki/LinkedIn#Use_of_e-mail_account...

You can pull another branch without switching first:

  git switch my-test-branch
  ...
  git pull origin main:main
  git rebase main

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].

[1] https://github.com/actions/runner-container-hooks/issues/113

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.

It is, yeah, the process is the same: boot into a rescue system running in memory, and do whatever you want with the disk.

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).

Between the VMware licensing changes and this, it looks like Broadcom is making a serious play at dethroning Oracle as the most evil software vendor.

It's a shame that competition for this position has been ramping up lately.

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.

I think it is a reference to the Chernobyl mini-series, where the Dyatlov character responds to the news of the level of radioactive contamination as "Not great, not terrible", unaware that their measuring equipment is actually maxed out, hiding the true scale of the problem.

I've only used Bottlerocket in relation to EKS, and even then my interaction with it was pretty limited so I have no idea how it fares as a standalone operating system.

My one big experience with it was the recent bug which (as I recall) attempted to harden the system by marking memory pages as no-execute, which caused virtual runtime languages like Java to basically break entirely when running on a node using this version of Bottlerocket.

It was fixed pretty quickly, but it did feel like a weird thing to slip through...

I set up a Talos bare metal cluster about a year ago, and documented the whole process on my website. Feel free to reach out if you have any questions!

It is precisely the large impact on GDP that poses a threat to the host nation. When companies like Novo Nordisk are such a huge part of the economy, they can exert disproportionate influence on society itself.

Our economy is absolutely benefiting from Novo Nordisk's size right now, but if/when their demand weakens or they're out-competed, we're going to end up with a lot of unemployed biotechnicians and massive roads to Kalundborg which will need to be maintained.

I'd be very interested to know as well. Although the last time I attempted to run kanidm in a containerized fashion it left a lot to be desired.

The software is (perhaps expectedly) not really built to support semi-ephemeral lifetimes, so it took quite a few hacks to get it running in Kubernetes the last time I tried.

As I recall, the primary issue I had was with exposing the certman-provided Let's Encrypt certificates to the kanidm process inside the container in a reasonable fashion. I don't think I found an elegant way of signalling to the kanidm process that the certificates had been renewed and should be reloaded.

You can build a custom iso with a "talos.config" kernel parameter set which instructs Talos to download and apply a configuration on boot.

I haven't actually. I believe they do offer modest amounts of credit for creating useful libraries, documentation and such targeting their platform, but I never really looked into it.

As diggan said, there's usually at least one of their dedicated server offerings for which setup fees are waived, so I figure my tests would use the API to find out which one and use it :)

This is actually great. I maintain a library[1] for interacting with the Robot interface using Rust, but testing is heavily gated because of the potential costs it might incur, which is why a lot of the purchasing/cancellation APIs haven't been thoroughly tested.

With this billing, I'll be able to do thorough integration testing without breaking the bank.

And of course with hourly billing, horizontal scaling becomes much more feasible.

[1] https://github.com/MathiasPius/hrobot-rs

This got me curious (and a bit worried) so I checked, and it seems like it might have been differently licensed for commercial use around the time you mention, but that no longer appears to be the case: https://caddy.community/t/caddy-license-for-commercial-use/1...

My solution for this setup is having ingress controllers on all three nodes, and then specifying all three IPs in all DNS records. That way the end user will "load balance" based on the DNS randomization.

Of course, if a node goes down, a third of the traffic will be lost, but with low TTLs and some planning, you can minimoze the impact of this.

When it comes to load balancing, I think the hcloud-cloud-controller-manager[1] is probably your best bet, and although I haven't tested it, I'm sure it can be coerced into some kind of working configuration with the vSwitch/Cloud Network coupling, even if none of cluster nodes are actually Cloud-based.

I haven't used Sidero Omni yet, but if it's as well architected as Talos is, I'm sure it's an excellent solution. It still leaves open the question of ordering and provisioning the servers themselves. For simpler use-cases it wouldn't be too difficult to hack together a script to interact with the Hetzner Robot API to achieve this goal, but if I wanted any level of robustness, and if you'll excuse the shameless plug, I think I'd write a custom operator in Rust using my hrobot-rs[2] library :)

As far as the hard-coded IP addresses goes, I think I would simply move that one rule into a separate ClusterWideNetworkPolicy which is created per-node during onboarding and deleted again after. The hard-coded IP addresses are only used before the node is joined to the cluster, so technically the rule becomes obsoleted by the generic "remote-node" one immediately after joining the cluster.[3]

[1] https://github.com/hetznercloud/hcloud-cloud-controller-mana...

[2] https://github.com/MathiasPius/hrobot-rs

[3] https://github.com/MathiasPius/kronform/blob/main/manifests/...