__turbobrew__

Most hardware vendors don’t make operating systems, so they are not incentivized to limit what software can run on the hardware.

For example, intel and AMD contribute a lot of code and engineering hours to open source projects because they WANT people to be able to run that software on their hardware.

Apple could change the platform/firmware to break Asahi if they wanted to. They could lock down the hardware to make it nearly impossible to install another OS like they do with iphone.

Protecting the secret from the host is a superset of protecting the secret from a workload.

Why would any group want to take on a project which could be instantly killed by an external for profit entity? For now Asahi is left alone by Apple but that could change in a single day and the entire project is dead. It doesn’t seem like a productive way to direct the limited energy that distribution foundations have on hand.

How does this compare with TPUs? Can you not have secrets in the TPU which cannot be accessed directly by apps, solving this threat vector? I get that you want compatibility with popular libraries, but I wonder if the actual solution is to use hardware support to enforce the secret boundaries.

It seems like they shifted heavily to prioritizing enterprise users. Starting in the last day or two I started getting much faster responses on an enterprise plan.

Microsoft expects less from their engineers, and it shows in the large pay differential from Meta.

I hit a panic in btrfs using an ubuntu 24 LTS kernel. The trauma is still well and alive.

Google is doing great still. One of the few FAANG I am bullish on over the long timescale.

No, infrastructure engineers. The one who scale the system up so you don’t have to rate limit.

All of the smart people I know went to work at OpenAI and none at Anthropic. In addition to financial capital, OpenAI has a massive advantage in human capital over Anthropic.

As long as OpenAI can sustain compute and paying SWE $1million/year they will end up with the better product.

The feeling I get with jj is it is almost like people are trying to convince others why jj is superior instead of just sharing that jj exists and let others decide themselves. It seems like every few months there is a jj post on HN which devolves into the narratives of “git works for me” and “but jj is better at X”.

I can see that gold settled in London is worth more than gold settled in NYC given trust in both nations right now.

I have seen that too. People on the way out trying to get access to production systems. Layoffs suck, but the business needs to protect itself from those who are departing. The company used to have more lax separation procedures but after that incident everything got locked down.

Runs fine on my iphone

I wonder if visibility was good enough that looking both ways before crossing the runway would have prevented this.

That is a poor choice of naming. Sounds like JewNote.

Yes, I have worked with the strong but arrogant/snarky engineers. Luckily most of them got canned or forced out because the environment they create around themselves more than negates the positive impact they have. The strongest engineers I have worked with are all humble and kind.

It is their loss, I cannot imagine letting a minor work quarrel live rent free in my head for over a decade. I feel bad enough when something is stuck in my mind for a week.

Yea I knew meta was toxic, but publicly beefing over something over a decade ago is a whole other matter. I can’t even remember what I was working on 10 years ago, and even if I did I wouldn’t be bringing people down that much later.

I work on infrastructure at bigco and we landed on a 5 second default timeout for our RPC framework which is interesting.

Sometimes I think there should be a list of sane and tested production configs: default rpc timeout, default backoff exponent, default initial backoff, default max backoff, health check frequency, health check timeout, process restart delay, process restart backoff, etc…

I get lots of AI companies in my inbox, not much else. Surprisingly I got a bite recently because my linkedin says I have worked with eBPF.

If Jeff Dean still codes, so can I.

> What I am going to be most interested in is what happens in the SRE/Sysadmin world over the next few years as more AI-generated code hits prod in organizations that don't have adequate review & oversight functions.

You kindof answered the question yourself. Humans write the tests and then go tell the AI to write the solution which passes the test.

You can download the entirety of wikipedia and store it in your own offline immutable backup.

There are standards but actually designing a sane network architecture, buying all of the correct network hardware, and configuring all of the software to properly use that hardware is hard. At my company we have a team of about 20 people whose job it is to just design, install, and run the network.

I recently had a performance review at a FAANG. One engineer on my team has spent the past 3 years working on a complex infrastructure migration which involved about 20 engineers. The migration was completed last year and saved the company some opex costs.

I on the other hand spent 3 weeks optimizing our core service and reduced 2x the opex costs of the large complex 3 year migration.

In my yearly review my manager acknowledged my impact, but said I need to solve more complex problems to get to Staff Engineer. I protested saying that my 3 weeks of work had a larger impact than 20 engineers over 3 years, but he told me that is just how it works.

Modern AMD processors are basically a bunch of smaller processors (chiplets) glued together with an interconnect. So yes single chip nodes can have many numa zones.

BGP based routing is a major pain in the ass to do on-prem. If you want true HA in the datacenter you are going to need to utilize BGP.

I am Canadian, so no I wouldn’t be going to Nam.

Work/school days should just be shorter in the winter. We can easily leave work/school an hour earlier in the winter and nothing bad would happen.