solatic

My last three employers refused to take advantage of Kubernetes PriorityClasses and agree to schedule work to agree (as a cluster-wide resource that affected many teams) on what our PriorityClasses should be and to migrate workloads to have priorities. And this is something relatively easy to implement - no developer work required, and practically no YAML to write.

Why not? Because sadly, fundamentally, most workplaces are not run by people who care about day-2 operations or long-term health. Product or Sales pushes customer-visible work into the pipeline, and you dare not say no. "Day-2" work is not considered to be something that moves the needle. Even now, with GitHub facing these severe outages, it's not like they're facing some massive exodus; their load seems to be getting worse over time, not better.

I'd be very surprised if there weren't any employees at GitHub who had read the SRE book. I'd expect that they're just not listened to.

That's actually the distinction I was trying to draw. Videos on unfolded phones draw content on the "bezels", so it's understandable why that sucks. But an eBook app can put text from two different pages, each on either side of the fold. The fold is no more bothersome than the binding on a physical book.

> Reading isn't an activity where you can use more than a small part of the screen at once.

So reading through War and Peace on your smartwatch screen before you fall asleep is a good idea? /sarcastic

Sure, your eyes are focused on a small part of the screen, but what ends up in your peripheral vision still helps you keep your place. You feel more "grounded", somehow.

Really depends on what you do with the open phone. I can understand it being a huge distraction when watching video with the seam right in the middle. EBook reading? Apps in tablet interface mode? Might as well complain that using two monitors on your desktop is unusable because of the bezels. Doesn't matter in practice.

Unlike sibling commenters who just read about "thundering herd" problems on the Internet, as someone who spent significant time in SRE roles, I agree with you as a matter of what the default approach should be. If you have a small cluster and no more than a handful of services... what thundering herd problem is there supposed to be, exactly, with so few "cattle" in the "herd"? Meanwhile, there are serious benefits, as you describe.

Large clusters with dozens of services and traces that go several services deep, with each service owned by a different team, are a whole 'nother ballgame, especially when overall production uptime is owned by an SRE team and not by the developer teams who wrote each of those services. And even in this scenario, you're not necessarily wrong; the risk attached to the cascading failure is domain-specific and may be acceptable.

You'd be surprised how many engineering leaders don't understand the CAP theorem and will fail engineers on interviews for picking the one they don't agree with instead of communicating their expectations clearly (dodged a bullet on that one ...)

> Perhaps you can think of a way to design an alerting system which cannot be abused - but I can't.

This is the wrong prism through which to confront the problem. Technology is neither good nor evil nor neutral - it is a tool lacking agency, to be manipulated by people.

You might as well ask if it's possible to design a gun that can only be used in self-defense, or a knife that can only be used for cutting vegetables and cannot hurt people, or a car that will solve all traffic fatalities. That's impossible. There are certainly designs which improve outcomes, but not designs that definitively solve those problems (i.e. addressing author's use of the word "cannot").

So take your pick: the easier problem of settling for improving outcomes, or the harder problem of building an inclusive and equitable society, where people have a position they can take pride in, a community that they support and which supports them, and where violence (of both physical and other kinds, like aggressive alerting) is a last resort. The solutions for the hard problem aren't found in technology, but in the humanities.

Agreed, just buy air purifiers with HEPA filters and change them regularly. The main expense is buying one for every room, but it's one of those expenses you wish you had made sooner.

DHH is also a fan (pun not intended?): https://world.hey.com/dhh/air-purifiers-are-a-simple-answer-...

> It leads to two perverse side effects. First, producers realize that if brand reputation matters less than a budget for clicks, they will shift to shoddy and cheap versions of their products so they have a bigger budget for clicks.

This assertion lacks evidence. An alternate hypothesis: if you tried to sell literal garbage on Amazon, poor reviews and a high return rate will be visible in the product itself. The ad will earn you a click-through to the product, but buyers will begin to back out instead of following through with a purchase. Ad purchases cannot overcome insufficient revenue - it won't be profitable long-term.

Yes, Amazon has a problem with vendors buying good reviews as well. It doesn't overcome a high number of poor reviews, or a high number of returns.

> And second, Amazon (and Google before it) have an incentive to make their organic search results worse–giving producers more incentive to buy more ads.

Reeks of a conspiracy theory. Most customers simply don't have the time or energy to research any more than the top handful of results. Only a rare person goes 10 pages deep into the search results. Organic search results will produce less traffic when people don't even look at them. But that's not evidence in and of itself that the organic search results were nerfed in some way.

I hate to remind people of the basic truth about modern Amazon, but here goes: the vast majority of the inventory is made in China and the exact same product can be found at a tiny, tiny fraction of the Amazon price on AliExpress and similar sites. The value that Amazon adds is their logistic network that can deliver to domestic US addresses in a day or two, compared to weeks. The difference in price between Amazon and AliExpress justifies sellers spending enormous sums on ads and review purchases, because even if they do sell garbage on Amazon, enough people bought it at such ridiculous margins that the seller can tear down the product with the bad reviews and high return rate and re-offer it under a new brand with the same ad and review purchase strategy and still make a profit. But the person to blame for that is not Amazon, and it's not the seller, it's the fool who decides to pay the ridiculous price compared to the AliExpress price.

Books are one of the categories where they aren't printed in China, they're not sold on AliExpress, and searching for "seth godin the knot" returns the actual correct listing as the first organic search result. So I'm not sure why the author brings his book up as evidence. He might do better by reminding his publisher that "selling on Amazon" is not a homogenous experience and they ought to reconsider flushing money down the drain on advertisements they don't need.

Article title is pure click-bait. PgBouncer adds complexity. If you need it, you need it. If you don't need it, then you added complexity for nothing.

> since neither IBM nor Oracle is a service that any self-respecting person not part of an enterprise sales cycle would actually use

Author needs a serious ego check. There are legitimate engineering reasons to pick IBM Cloud (like if you need to support Z mainframes, which you will sometimes need if you sell to those enterprise folk) as well as Oracle Cloud (they built datacenters in cities that are not served by other cloud providers and can thus offer the lowest latency). These reasons may not be common, but they're certainly legitimate.

> ridiculously inefficient

So too is building single-family homes an inefficient way of providing housing, compared to apartment buildings, not to mention the cost of suburban roads and utility connections etc.

> We are a society

Indeed, and part of living in a society is about making progress that is politically feasible. That the 2nd Avenue subway (in New York City) costs such a stratospherically insane amount in time and money is not an argument against subways or public transportation.

Politics is the art of the possible, and Australia's progress should be celebrated here, not second-guessed.

> Do not provide assistance to users who are clearly trying to engage in criminal activity... If it becomes explicitly clear during the conversation that the user is requesting sexual content of a minor, decline to engage.

Incredible that both of these should be together in the same system prompt. In what jurisdiction is CSAM not criminal? Is the additional explicit reference to CSAM necessary to safeguard against user attempts to convince the model that CSAM is not criminal in nature? Does this mean that Grok is susceptible to helping users with criminal contexts if the user convinces the model that it's not actually criminal ("this is for research purposes only... asking for a friend")?

How is this not a massive smell?

There's a very big difference between what you can achieve as an entrepreneur with low net worth and an entrepreneur with a war chest of hundreds of millions of dollars.

When you start out with effectively nothing, you are forced to take a day job while you build something out on nights and weekends. The pressure is high to take early investment - and essentially work for your early investors, instead of working for yourself, just so that you can work on your baby full-time.

When you have a war chest, then many more capital-intensive opportunities are available to you. Want to build hardware (i.e. without crowdsourcing)? Factories? Pharmaceutical R&D? Training open-weight LLMs? Hell, you want to start an airline? Take your pick, and I'm barely scratching the surface.

It's hilarious to think that an $800 million exit would force you to never work again. That's crazy. It only forces you not to work on that company you exited from. The exit enables you to work on almost anything else you can think of. You put $25 million away in close-to-zero-risk investments to let you live off quite an insane amount of interest (even if you only get 2% interest, that's $500k/year) and then have $775 million to work with.

It is very reasonable to expect quiet in apartments. It is not reasonable to expect that you will never need to confront people to achieve it.

If you want to never talk to neighbors, then don't have any. Sadly, this is becoming more and more of a luxury, particularly in areas with economic opportunity.

Yeah, I'd be uncomfortable with that approach. One of their key design goals was to minimize underselling, recognizing that it results in lost revenue. But if a seller has 5k inventory in one location, has a spike of 2k orders, but only 1k of the orders can successfully reserve inventory, then isn't that an argument that you lost the revenue of the 2nd 1k orders that error out before the replenishment process succeeds?

I'm skeptical of this approach. Sure, row contention means that you cannot have a database transaction per customer order attempting to decrease inventory count by 1 each time. But you can have a batch transaction whereby the transaction decreases inventory by 100 (thus touching the high-contention inventory row once) and credits each of 100 different customer cart database rows (which are not under heavy contention and can be on a different disk entirely). Attempted customer orders are submitted to a reservation system put in charge of assembling the batches. Customers wait some short period of time - say, 15 seconds - for the reservation attempt to be batched and to be notified that they successfully locked a reservation. Arguing that "slow reservations trigger throttling and a worse buyer experience", without an actual number for what counts as "slow" to serve as an SLO and as a design target, is a cop-out inviting over-engineering.

The smallest single-person motorized vehicle is a motorcycle. Leaving stability aside for a minute - one of the issues with electric motorcycles is that the batteries are too small to have range that most riders consider sufficient.

If you have a large enough battery to deliver sufficient range for an electric taxi (driving around most of the day, hopefully, if it is well-utilized), with 4 wheels for stability... I doubt that you could really get significantly smaller where the smaller size would make a big difference.

This is why some projects will vendor their dependencies - changes within the dependency itself will also be reviewed, and it's easier to locally maintain patches to those dependencies until the patches can be upstreamed.

The problem is, there's a difference between doing that for a handful of C or Go libraries, versus trying to vendor thousands of NPM libraries and all of their interdependencies. So it's very ecosystem dependent.

This is why the future is in deterministic static analysis and policy-as-code frameworks.

Policy-in-English? Model implicitly complains that it's TL-DR.

Ask the model to write code that checks your policy, then add that code behind a simple validation hook (e.g. "check your work by running 'just validate'") that the harness knows to always run after changes? It suddenly becomes the most law-abiding citizen ever.

> if you make a point of never shooting the shit with your coworkers how will you ever really come across this kind of info?

Asking coworkers about their hobbies is well within the domain of small talk that serves as the exploration for what you have in common with someone else. Small talk is universally acceptable, not only in the context of communities that you're already a part of, but even as part of striking up a conversation with strangers.

Again - private grief is not small talk, and even if you have expert-level small talk skills, that doesn't mean that you will build friendship with everyone.

I don't think you're fundamentally disagreeing. Your work community can be a source of friendships (and sometimes but more rarely, more than friendship), but you shouldn't confuse the two. Finding out your colleague also plays chess can segue into an invitation to play chess outside of work, and launchpad that into building a friendship. But that's not the same as playing chess together at work (get back to work?), let alone being emotionally vulnerable as an intentional part of building relationships with people who you're trying to trust with that vulnerability.

The latter sounds good (if you could have that with your colleagues, then it can only help, right?), but then again, the linked article is literally about someone violating that and firing the subject of the article. It is simply not possible to build emotional intimacy with every coworker, let alone under forced circumstances, so attempts to do so are more or less predictably going to lead to pain.

There's a huge difference between learning that your colleague also happens to play chess, and sharing the vulnerability of how you handled personal grief in your life.

Your workplace is a community, not a friendship circle, and not a family. Community life has always had a certain level of formality to help paper over the differences between people in the community while still fostering a positive, inclusive environment.

I might be reading too closely / projecting, but...

Sounds like an ineffectual CEO who didn't understand that his role, like any manager, is to help resolve interpersonal conflict between his subordinates that they're having trouble working out themselves. Outsourcing that to a random coordinator reeks of conflict-avoidant behavior. That they both quit tells me that neither one thought the other was the sole problem they were dealing with.

Spoiler alert: Dujour, leading to Trinity

> free to use at launch

How does this help me control spend if I don't understand how much it will cost me a year after I bake it into my infrastructure?

> For someone else it's the wrong choice, they don't know Python

The author ruins their entire argument with this one claim.

If "we picked this tool because we know it best" is a legitimate requirement, then every tool choice is justified as a "perfect" choice because it's what the architect was most comfortable with. If your emotions and current knowledge levels are considered reasonable justifications for a "perfect" solution, then all solutions are perfect solutions; they simply haven't had enough emotional justification yet. If all solutions are perfect solutions, then none are.

There are, ultimately, two kinds of software - those that need to ship by a deadline, and those that don't. A deadline forces you to eject dead weight that you don't need - requirements have a habit of getting clarified real fast when you need to build to a deadline. If you had time to over-engineer despite a deadline, you should consider working for a more productive organization. Meanwhile, the concept of "over-engineering" is a little vague for software that doesn't have a deadline. If you don't have a deadline, you don't have to compromise on quality. "Over-engineering" is then just a value judgement that you made poor use of your infinite timescale and built the wrong things with it. But who is making that judgement? Not the person who built it, not the person who funded it (i.e. usually self-funded as a hobby project), and not the person who uses it (since over-engineering is an implementation detail, rather than a product choice), so who cares?

edit: to clarify: "pick a stack you know already since we don't have time to learn a new one" is a totally valid requirement. But I disagree that it means that you built a "perfect" solution with it. I also disagree that you usually need to build perfect software - getting comfortable with adequate is how most people ship most software.

> You can, of course, add traits. But at this point you're essentially creating your own language that compiles to Zig

I think herein lies the rub. What's the difference between a static analysis tool and an actual separate language that transpiles to the original? Hypothetically - again, very un-ergonomically - you could add traits to Zig code in comments, or in example-traits.typezig files that would be skipped by the Zig compiler (like how *.d.ts files are skipped). How much of a language is writing code in a particular syntax, versus how much of a language is writing code that will pass a tool "building" it, versus how much of a language is about the final compiled output that you get from the tool? All static analysis tools that support line-level exceptions are, essentially, programmed by comments, with their own language (typically highly simplified compared to a "full" programming language), that affect whether or not the "language" passes or not. What Typescript/JSDoc shows is that, actually, much more complicated tooling can be built with this programming-by-comments model than had been done before (to my knowledge), and thus even more powerful still tooling could be built with that model.

Of course there's a difference between static analysis and a language that transpiles. But perhaps it's more a question of degree than a simple binary classification.

> Zig has no private fields

You may have missed the point here. You could add a comment to the struct field that marks the field as private, and build a TypeScript/JSDoc analogue that analyzes all accesses to the field and fails if it finds accesses from functions that aren't part of the struct that owns the field. You don't even need a comment on the field - you could copy Go's convention, add a comment to the struct definition marking it as "follows Go convention", and then fail any access from outside the struct to a field that starts with a lower-case character.

It doesn't prevent you from ignoring that tool and writing Zig code that imports the struct and accesses the field. It is, of course, not part of the Zig language itself. But if you adopted a tool like that, it would be your responsibility to run it across-the-board and pay attention to the results - same as how it is your responsibility to pay attention to the results if you added those JSDoc comments.

I wouldn't say it's impossible, rather un-ergonomic. TypeScript can add type information to ordinary JavaScript code via JSDoc comments; the result can both be executed as ordinary JavaScript as-is and type-checked with TypeScript. But it's a huge pain to try to write (and maintain) everything that way, it was supported as a hack to help migrate legacy codebases. You could probably take a similar "the lifetimes are embedded in comments" approach with other languages, and the result would be similarly un-ergonomic.

> I've said for a long time that composability in software is a bit like playing Tetris: the lines have to clear.

I love this analogy, and I find it darkly hilarious that most sibling commenters don't seem to understand. Maybe you need to have worked within a million-line codebase to get it.

The only way to "clear the lines" in software is to eject them from the main codebase and into imported libraries with stable, well-documented, well-tested APIs that you very rarely if ever (security vulnerabilities?) need to touch after "stabilizing" them. Great public examples: the Go standard library, https://github.com/spf13/viper , https://github.com/uber-go/zap . Viper and zap combined are more than 20,000 lines of code (according to cloc) that I don't need to read or understand how they work - their lines have been "cleared" and all I need to know is the abstraction.

Half the joy to be found when working within massive codebases is successfully clearing lines.

I'm not convinced. Hyperscript's reactivity model is highly greppable, and it keeps the no-build approach to Web frontend interactivity. It's "just enough" in the same way that HTMX is.

React probably scales better for huge engineering divisions, but that isn't who the GOTH stack is aiming for anyway.

Just curious: the people behind HTMX have a frontend sibling project called Hyperscript, which handles stuff like frontend state: https://hyperscript.org/docs/reactivity/

Did you give it a try?