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

You are missing out the entire point. In a justice system, a single innocent in prison is a thousand times worse than a free criminal. This is where most people draw the line if they think about it. Because when you put innocents under arrest, suddenly you are no better than dictatorships and terrorist state.

The real justice is investing in a security system that tracks, investigates, and condemn actual criminals, in a targetted way, so that honest people can live securely and free. Believe it or not, plenty of countries manage to do that pretty well.


There are companies I wouldn't candidate for, even with kids I think, although it's hard to say, I don't have kids, and apparently there is a mind-shift happening when you get one. Oracle, Palantir come to mind. But maybe not Microsoft, I don't know about that one. It's probably bad, but maybe not "I prefer to watch my kids starving" kind of bad.

Maybe not, there are plenty of hard things to do at Microsoft scale, hypervisors (which I guess could count as "OS" but maybe not "Windows" in the consumer-product line sense), compilers, languages, hardware since Microsoft is doing that too, browsers (although the hard part is chrome-based, probably they contribute to it), databases, distributed systems for cloud products, etc. Plenty of hard things to do.

Depends on everybody needs obviously, but say you have your dev machine that is remote, and you want to connect to it from a laptop (for real-estate reason or just for working from everywhere you want), maybe you want everything on the same (remote) machine like browser, db, IDE, etc and access to it as a remote "desktop" not just an ssh session.

Of course cli tools would be enough for somebody who likes a full TUI dev environment (and for my own use cases that would be enough) but for some people I understand the need, and I feel it is a regression for them to not have it.


Maybe not a shit company but a trash company indeed.


I completely agree and went by the proverb "everything worth doing is worth doing poorly" about a year ago now, it took some time for it to sink in but now I'm actually productive. My main blocker was waiting for other's approval, now I feel a lot more free.


Most devs can't do SRE, in fact the best devs I've met know they can't do SRE (and vice versa). If I may get a bit philosophical, SRE must be conservative by nature and I feel that devs are often innovative by nature. Another argument is that they simply focus on different problems. One sets up an IDE and clicks play, has some ephemeral devcontainer environment that "just works", and the hard part is to craft the software. The other has the software ready and sometimes very few instructions on how to run it, + your typical production issues, security, scaling, etc. The brain of each gets wired differently over time to solve those very different issues effectively.


I don’t understand this take - if all engineers go on call, they learn real quick what happens when their coworkers are too innovative. It is a good feedback loop that teaches them not to make unreliable software.

SREs are great when the problem is “the network is down” or “kubernetes won’t run my pods”, but expecting a random engineer to know all the failure modes of software they didn’t build and don’t have context on never seems to work out well.


It's possible to do both, you just need to be cognizant of what you're doing in both positions.

A tricky part becomes when you don't have both roles for something, like SRE-developed tools that are maintained by the ones writing them, and you need to strike the balance yourselves until/unless you wind up with that split. If you're not aware of both hats and juggling wearing them intentionally, in that case, you can wind up with tools out of SRE that are worse than any SWE-only tool might ever be, because the SREs sometimes think they won't make the same mistakes, but all the same feature-focused things apply for SRE-written tools too...


My take (I'm an SRE) is that SRE should work pre-emptively to provide reproducible prod-like environments so that QA can test DEV code closer to real-life conditions. Most prod platforms I've seen are nowhere near that level of automation, which makes it really hard to detect or even reproduce production issues.

And no, as an SRE I won't read DEV code, but I can help my team test it.


>And no, as an SRE I won't read DEV code, but I can help my team test it.

that doesn't sound like my definition of an SRE. How is what you're doing different than Ops?


> And no, as an SRE I won't read DEV code, but I can help my team test it.

I mean to each their own. Sometimes if I catch a page and the rabbit hole leads to the devs code, I look under the covers.

And sometimes it's a bug I can identify and fix pretty quickly. Sometimes faster than the dev team because I just saw another dev team make the same mistake a month prior.

You gotta know when to cut your losses and stop searching the rabbit hole though, that's true.


I agree with your nuance, but that's not my default mode, unless I know the language and the domain well I am not going to write an MR. I'm going to read the stack trace to see it it's a conf issue though.


Maybe he meant boot environments ?


That’s what I meant. My bad. Got confused.


I've said it before too, it is exemplary in terms of what documentation should be ; just read through it with a VM on, type the things, and everything just works, no googling or LLMing around. I heard it is the same for other BSDs as well, will try those some day. Also a testimony of how coherent this system is.

As a seasonned SRE it is a breathe of fresh air in this world where everything else seems to change from one version to another and nothing seems to work at first try, ever.


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

Search: