hnjst

Farage cage maybe?

Leslie didn't steal his Turing award ;)

On the contrary, I'd start without any remote.

https://discord.gg/dwXDHMGY for example.

I'd ask myself another set of questions: - can they extract information from conversations and exfiltrate it in a stealthy or obfuscated enough way so that they won't be noticed or have plausible deniability - do they have incentives to do so (assuming the absence of liability described above) - do they have a track record on related topics that makes you confident in the fact that they wouldn't act that way

My answers being yes - yes - no, the question of 'do they listen to target the ads they try to make me display' is pretty irrelevant to me. I can't trust them not to nor check reliably if they do.

If you try to address a different question such as 'do they really encrypt reliably to protect your conversations from being snooped on without their authorization', the threat analysis may differ. In that case they have incentives aligned with yours and are probably faithfully trying to effectively protect your/their data.

At the end, I'd estimate the probability of the scenario and how I value the consequent loss of privacy. Then accept/mitigate/refuse the risk accordingly.

Don't forget checking for the evil bit too! https://www.rfc-editor.org/rfc/rfc3514

I'm still completely baffled that we nowadays almost all have in our pocket a device able to run something like https://f-droid.org/en/packages/jp.yhonda/.

Currently in a large private bank: Keepass, hardware tokens in physical safes accessed supervised by another team, Hashicorp Vault, a few HSMs and managed key vaults for the cloud workloads.

Paranoid levels of security are relevant in some cases but unnecessary in others. Physical security and organisational processes are also an important complement to technological solutions.

I recently tried https://github.com/yewstack/yews that looks very much like "React in Rust". It is web oriented through WASM compilation and integration with web technologies, Tauri can be used to bridge the gap and use it for desktop apps but it is probably an excessively complex and impure assembly for that goal.

For theoretical foundations, I'd recommend reading about the FLP result (https://dl.acm.org/doi/pdf/10.1145/3149.214121), the reduction of the state machine replication problem to consensus (https://dl.acm.org/doi/pdf/10.1145/78969.78972) and the different consistency criteria.

To climb on the shoulders of giants you can dive into the work of (incomplete list, irrelevant order but these have been eye openers to me) :

- Leslie Lamport

- Maurice Herlihy

- Eli Gafni

- Rachid Guerraoui

- Michel Raynal

- Petr Kuznetsov

- Hagit Attiya

- Sergio Rajsbaum

- Nancy Lynch

WET -> Write Everything Twice (before premature factorization).

I've been exploring this exact possibility a few days ago. The support for Suricata's rules in AWS Firewall is pretty limited though (https://docs.aws.amazon.com/network-firewall/latest/develope...).

There is a generalization allowing asymptotically optimal entropy extraction from Markov chains traces that doesn't require transition weights knowledge (like Von Neumann trick doesn't require bias knowledge).

https://ieeexplore.ieee.org/document/1684974

Shameless plug of a paper on related topics: https://link.springer.com/article/10.1007/s00446-017-0311-5

> I Learned French in 12 Months

That's not so difficult I guess, here even babies do so.

I love "smart" programming languages and gladly write in Rust when it makes sense. However Go wins the bulk of my language picks these days, marginally thanks to the efficient tooling and complete standard library but essentially because of how easy it is to read / review / integrate / patch external code without the need to rediscover authors' specific styles and ways of doing things.

Understanding low level architecture of that time (and early memory management) and first steps of the boot process is definitely something that has been useful to me since then. DOS batch files scripting no so much...

My childhood story too. We ended pretty knowledgable, effective and borderline dangerous when the watered down systems arrived later.

I'd put in the same category the edition of saved games to change your amount of money to FFFFFF or the epic shenanigans required to setup a LAN party.

I'll take an intermediary position. Commits on a WiP branch don't need to let the repo in a working state, however I like when said branch has its history rewritten so that each commit is mostly a working unit change before submitting the branch for merging.

You definitely shouldn't restrain from committing often during development, however having a cherrypickable branch history when merging instead of "let's squash this mess and forget about it" has value to me.

I also would have loved discovering electricity or information theory. Somehow it's convenient that people stacked on the shoulders of each other across a few generations made processors from that but it sadly put the bar pretty high to go further nowadays.

Thankfully I can use these cool processors to build the next CandyCrush and shine in our modern and innovative society.

You can actually renew/upgrade your whole cluster with no downtime if you care enough to tackle the annoying bits that cost a few minutes in YOLO mode.

In my book DevOps is a set of practices that aims at improving the collaboration between Devs and Ops. I know that the term is now often used to label a role (or even a job description), but I think something important is lost in the switch.

According to what I put behind the concept, implicating Devs is at the core. You built it, you run it!

Completely aligned with my parent, day-to-day operations are often slightly more complex than making sure your server run your app properly, I'd argue that our services are increasingly dependent on others (in both directions, dependencies multiply and are more and more critical). That's also by interacting more with external entities that they bring more value.

> The best solution I can come up with is a synchronously-replicated append-only log store which is utilized in a primary/sync-witness/async-witness/... configuration. The first tier of resilience would be synchronous and provided by a set of witness nodes which must ack as a majority to progress primary. These nodes would ideally be within 1-2ms of the primary. The async witnesses could be in orbit and/or on mars. These are more about extreme geological disaster recovery. The witness nodes would also use a separate consensus protocol to decide when the primary needs to be taken down and replaced with a sync (or god forbid async) witness. They would be able to elect an emergency leader separate from the primary who would be authorized to stop the bad primary in the hypervisor, and edit any relevant DNS records to ensure traffic stops hitting the bad system.

This part was what I felt deserved a counter-point though. Consensus is indeed at the core of the issue once you want distributed fault tolerance. However, I think you'll quickly hit two things with your approach: 1-2ms of latency, I fear that it may come with highly correlated failures on the "first tier of resilience". Moreover, the "second tier" being much farther, keeping them in consensus will imply harsh trade-offs. If you use synchronous consensus protocols, you'll slow down drastically the "first tier" (assuming you want consistency), if you go for the asynchronous replication (not consensus, this matters...) then the second tier can't really intervene on leader election or failover without risking a partition on a false positive (and if you try to be conservative there your RPO will suffer).

If you're into these (fundamental) issues, I'd recommend Leslie Lamport's work (i.e. https://www.college-de-france.fr/site/en-martin-abadi/semina... or http://www.lamport.org/), the paper pointing a disappointing impossibility: https://dl.acm.org/doi/abs/10.1145/3149.214121 and its generalization (https://dl.acm.org/doi/abs/10.1145/167088.167119).

I'm pretty biased since I gave k8s trainings and operate several kubes for my company and clients.

I'll take two pretty different contexts to illustrate why for me k8s makes sense.

1- I'm part of the cloud infrastructure team (99% AWS, a bit of Azure) for a pretty large private bank. We are in charge of security and conformity of the whole platform while trying to let teams be as autonomous as possible. The core services we provide are a self-hosted Gitlab along with ~100 CI runners (Atlantis and Gitlab-CI, that many for segregation), SSO infrastructure and a few other little things. Team of 5, I don't really see a better way to run this kind of workload with the required SLA. The whole thing is fully provisioned and configured via Terraform along with it's dependencies and we have a staging env that is identical (and the ability to pop another at will or to recreate this one). Plenty of benefits like almost 0 downtime upgrades (workloads and cluster), on-the-shelf charts for plenty of apps, observability, resources optimization (~100 runners mostly idle on a few nodes), etc.

2- Single VM projects (my small company infrastructure and home server) for which I'm using k3s. Same benefits in terms of observability, robustness (at least while the host stays up...), IaC, resources usage. Stable minimalists hardened host OS with the ability to run whatever makes sense inside k3s. I had to setup similarly small infrastructures for other projects recently with the constraint of relying on more classic tools so that it's easier for the next ops to take over, I end up rebuilding a fraction of k8s/k3s features with much more efforts (did that with docker and directly on the host OS for several projects).

Maybe that's because I know my hammer well enough for screws to look like nails but from my perspective once the tool is not an obstacle k8s standardized and made available a pretty impressive and useful set of features, at large scale but arguably also for smaller setups.

Or with https://csvkit.readthedocs.io/en/latest/

> #2 SSH keys are configured in cloud-init, there's no reason they can't be read from SecretsManger and rotated out of the box.

If you didn't know it, you may be interested by ec2-instance-connect (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-inst...). It's sadly officially only supported on Amazon Linux / Ubuntu but ephemeral ssh key authorization based on IAM has nice properties in terms of security / auditability / access control / revocation etc.

Using something similar, but it doesn't handle well cluster deletion.

I can confirm, we're using a similar approach at it mostly works.

There are still issues though, if you try to remove your cluster the k8s provider can't be configured (no module.my_cluster.cluster_id anymore) and the refresh phase of plan will fail. You can find workarounds but those I know are quite manual / ugly.

My father started his self-hosting journey with a similar need. He went with Piwigo (https://piwigo.org/) that seems to fit his requirements.

Not sure I would personally pick that (PHP, documentation misaligned with my concerns...), but it may match others' criteria.