In the case of if you could bring your own missile-defence-network, then you probably don't need co-location anyway. (There is nothing "co", it's just location you build & operate, with your Patriot or whatever)

As a DevOps, I have seen the quote about "premature optimisation's root of all evil" in real life quite often. In fact, optimising one bottleneck quickly yields another one -moving the goalpost further-, potentially increasing business-impact if the flow is not contained properly.

Especially during incidents, _rushing_ to fix often yields more problems. I've seen people isolating/shutting-down mildly misbehaving instances. Causing excessive load to the remaining and starting the cascading failure like dominos falling one after another.

Which reminds me a scene from "The Office", where Dwight goes rogue and conducts a "Fire-Drill" by locking doors and deliberately causing smoke. Everyone panics and hell breaks loose. This is at the beginning of the episode, maybe 5-minutes tops. I show this at the incident-management training, this is how people behave in real life. No joke.

To give more concrete aspect on the moving goalpost: SWEs improve transaction processing with multi-threading, but that causes more connections/transactions to the database. Even though theoretical gains are Nx (n-times depending on threads/cores), real life gains are 1.2x-1.3x, because database connections are getting occupied. As the next step, increasing number of DB connections helps, maybe add another master node (risk of having deadlocks increase, but ignore for now for the sake of argument). But then the disk IO becomes the bottleneck due to write-heavy (payments domain). Then we add Redis to reduce load, and maybe some asynchronous processing. At this point complexity increases and we need to solve rare occurrences of duplicate data or race-conditions because it is not single-threaded process anymore...

Not to mention manuals/instructions. Regulation discussed here is about these too.

Also as consumer, I would argue the marketing done by apple is just scammy. They keep praising how much carbon saved or sustainable new machines are. But in fact, a minor issue becomes a massive electronic dump.

I also like Macs, I own several of them. Repaired a few. Mostly replacing batteries and keyboards. For example 2014 Macbook Air had a normal battery, no sticky business. Meanwhile 2020-2025 MacBook Air has sticky stuff, making repairs harder.

The best part is, 2014 macbook air has 54 Watt/hr battery, 2020-2025 models are 53 watts/hour. The lasting battery gains are coming from Apple silicon efficiency as well as modern BMS.

Simply put, regulation is the answer. Apple makes it difficult because they can, and also because it creates revenue. Of repairability was the source of income, you would see 10/10 repairable macbooks with no (significant) tradeoffs. (ie. it could be a few grams heavier for added screws)

Comments URL: https://news.ycombinator.com/item?id=47553755

Points: 1

# Comments: 1

Unless there is a CI that fails immediately when these checks fail, and it is not possible to bypass/override, then of course quality in the codebase improves significantly.

But that is very hard to give business results, in terms of ROI, 99.9% of the PMs will sweep these under the rug, because of unclear ROI.

Another remark I have to make is that, these things should be in a cloud/container (isolated environment) somewhere. Because I know several people who has their git commit aliased with no-precommit-hooks, because well, otherwise they complain that it is too slow. (Slowness is another issue that can be improved, but again, less visible ROI than just adding the command-line switch)

https://9to5mac.com/2025/10/16/no-the-eu-didnt-ban-apple-fro...

It is interesting to see how mass-propaganda is playing out right before our eyes...

Also adding better "context" into the discussion, than the usual claims/punchlines of marketing-speak.

Maybe it's not exactly the grammar itself but also overall structuring of the idea/thought into the process. The regular output sounds much more like marketing-piece or news-coverage than an individual anyway. I think, people wanna discuss things with people, not with a news-editor.

This applies not only work-stuff itself also to the job-applications/cv/resume and cover-letters.

I've been to Seattle once, (ex-Amazon here) where the DevCon was held in the town while my team was located in Bellevue. I took initiative to rent a bike for a day (60$ for drop-bar gravel bike) I must say although I did not beat the time between Day-1 (Office across spheres) and Bingo (Bellevue office), it was not far off. Even comparing the "Shuttles" Amazon operated, shuttle took about 1h while ride takes around 1h15m. (Plus sweat)

> P.S: I would say I am in a "fair" shape as I ride quite a lot throughout the year.

Comments URL: https://news.ycombinator.com/item?id=47135215

Points: 1

# Comments: 2

The content (that shows up in HN) is also good. Since I am on mobile device, I cannot tell the exact font used, but seems like Georgia to me. While https://github.com/susam/susam.net hosts the actual source code of the website.

Another remark: Would be really nice to have a same theme adaptation for BearBlog and similar places.

The response might've been different if the author had already given a patch, in somewhat backward-compatible way. This doesn't even have to be a functional patch, could be a simple `@warning: usage of default IV will cause insecure storage` similar annotations on the affected functions.

Another thing to remark (and which might've been off-putting for the authors of these libraries) that the author had used term mistakes in various places. Of course in an ideal world, ego should not or would not matter, but these libraries both seem to be quite stale and possibly the authors are having other $DAYJOB responsibilities. Making it difficult to fix things that they just receive complaints about. (I am also guessing these are quite many...)

Again in relation to the points above, it might've been better to say: Cryptography evolves over time, last years' best-practices get outdated, vulnerabilities being found, replaced with newer best-practices of this year. Same will happen next year too. It's not a deliberate mistake or any type of incompetency issue, this is a matter of ever-evolving field that we know and understand better...