Hacker Newsnew | past | comments | ask | show | jobs | submit | binarin's commentslogin

There is also a middle ground - it's possible to sign SSH certificate using yubikey as CA. By controlling expiration and set of principals, the cert you get on your machine is scope restricted, and quickly expires. Or you can load it into an ssh-agent and drop it immediately.

Yeah, we already saw what "within limit" means e.g. in the case of "make me a C compiler" with kinda unlimited compute.


I renew it automatically via DNS. But as I use Cloudflare for DNS, and it doesn't allow to precisely control access to subdomains, I use a separate locked down VM that is only responsible for issuance and makes the resulting certs available for download.


NixOS?


I'm mostly consume proton via proton-bridge, which is running in a dedicated VM. Then all my IMAP clients connect to that single instance.

Also, for email sending I use smtp2go free tier - primarily because I use random emails on my own domains to see who's leaking, and I don't want to set them up separately proton-side.

In that setup, proton itself is kinda unnecessary - I keep that path mostly as an insurance, just in case of acatastrophic homelab failure.


There are still some places that operate that way, as outlined in this Jane Street talk https://www.youtube.com/watch?v=zR9PpXWsKFQ (Production Engineering When Trading Billions of Dollars a Day).

> capacity to reason about it (during critical downtime) and communicate it

That's one of the things that's put into limelight in that talk.

I personally think that most of "Web Scale" software is inconsequential (inconsequential for its creators, not for users) - as there are no consequences for bugs and outages at all. A data breach -> slap on a wrist. Reputational damage because on an outage/data loss amidst general public? - almost impossible (clownstrike, anyone?)

The funny thing is that web scale software that's consequential is often in an ethically grey zone - but at least you won't be surrounded by colleagues who don't give a shit.


It's the Python guys whom I totally don't understand - it's all fun and dandy until you try to maintain and cleanup a legacy codebase of tens of millions lines of code in any dynamic language :)

With or without AI - doesn't matter. Only at that point you gain understanding of the limitations both of LLMs and of dynamic languages.

edit: Forgot about "Nightmare" difficulty - try enjoying dynamic languages and LLMs when your legacy codebase is earning tens of thousands $ per second.


Unless you're doing something really dynamic, I don't really understand this position and would like to learn more. for most cases gradual typing is a great option that can be done incrementally in Python (two things even cheap agents are really good at).


You can't forbid people doing something "really dynamic". And in a sufficiently big system, over long period of time, this stuff will accumulate - 100%. Then you'll get to a point where answering questions like "is this piece of code still alive" with enough confidence is almost impossible.

The question is where the "enough confidence" border lies - and in the worse case the only way to do some reliable investigatios would be printf debugging or its alikes.


It sounds like your app is using a lot of dynamic techniques like meta-programming? If so, that makes a lot of sense. Most of the apps I've seen use very little use of meta-programming and friends and incremental typing worked rather well.


> your legacy codebase is earning tens of thousands $ per second.

Your legacy codebase generates ~300 billion a year?


Okay - not earning, but processing. Adjust the figure a bit for varying traffic patterns during week and seasonality, and it'll be kinda like that.


I've learned the most from LFS long time ago, when I had no internet. I had a mismatching set of Slackware and redhat source CDs, and LFS itself didn't match the versions on CDs too. Since then I can build anything and anywhere, even if it's not cooperating :)


With some workarounds, I've put chrome and slack into the same RAM-limited cgroup - no more whole system freezes. From my anecdotal evidence, this also answers the question "who should you kill" :)


Yeah, exactly, it's not stealing, it's just ignoring the terms of license. The same thing in spirit as e.g. different corps shitting on GPL. And should be enforced with the same eagerness (lol).


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: