solatic

> There should be some balanced path in the middle somewhere, but I haven’t stumbled across a formal version of it after all these decades.

Well, there isn't a formal version of it, because the answer is not formal, it is cultural.

In enterprise software, you have an inherent tension between good software engineering culture, where you follow the Boy Scouts' principle of leaving a codebase cleaner than you found it, and SOC2 compliance requirements that expect every software change to be tracked and approved.

If every kind of clean up requires a ticket, that has to be exhaustively filled out, then wait for a prioritization meeting, then wait for the managers and the bean counters to hem and haw while they contemplate whether or not it's worth it to spend man-hours on non-functional work, then if you're lucky then decide you can spend some time on it three weeks from now and if you're unlucky they decide nope, you gotta learn to work within an imperfect system. After once or twice or trying to work By The Book, most engineers with an ounce of self-respect will decide "fuck it, clearly The System doesn't care," and those with two ounces of self-respect will look for work elsewhere.

Or, you get together with the members of your team and decide, you know what, the program managers and the bean counters, they're not reading any of the code, not doing any of the reviews, and they have no idea how any of this works anyway. So you collectively decide to treat technical debt as the internal concern that it anyway was in the first place - you take an extra half hour, an extra day, however long it takes to put in the extra cleaning or polish, and just tack it on to an existing ticket. You give a little wink and you get a little nod and you help the gears turn a little more smoothly, which is all the stakeholders actually care about anyway.

You cannot replace culture with process. All attempts to replace culture with process will fail. People are not interchangeable cogs in the machine. If you try to treat them as such, they will gum up and get stuck. Ownership and autonomy are the grease that allows the human flywheel to spin freely. That means allowing people to say, "I'm going to do this because I think that it is Right And Good For My System Which I Own", and allowing them to be responsible for the consequences. To pass SOC2, that means treating people like adults and allowing them to sometimes say, instead of "can I get this reviewed because I legit need another set of eyes to take a serious look?", to say "can I get a quick rubber-stamp on this please?"

PgBouncer introduces its own problems and strictly speaking adds additional complexity to your infrastructure. It needs to be monitored and scaled separately, not to mention the different modes of session/transaction/statement connection pooling. Adding another proxy in the middle also increases latency.

Yes, currently, putting PgBouncer in the middle helps handle massive sudden influxes of potentially short lived connections. That is indeed the correct current best practice. But I hardly fault the author for wishing that postmaster could be configured to run on multiple cores so that the additional complexity of running PgBouncer for this relatively simple use-case could be eliminated.

There are two separate concerns here: who the credentials are associated with, and where the credentials are used. IMDS's original security flaw was that it only covered "who" the credentials were issued to (the VM) and not where they were used, but aforementioned IAM conditions now ensure that they are indeed used within the same VPC. If a separate proxy is setup to inject credentials, then while this may cover the "where" concern, care must still be taken on the "who" concern, i.e. to ensure that the proxy does not fall to confused deputy attacks arising from multiple sandboxed agents attempting to use the same proxy.

AWS has a more powerful abstraction already, where you can condition permissions such that they are only granted when the request comes from a certain VPC or IP address (i.e. VPN exit). Malware thus exfiltrated real credentials, but they'll be worthless.

> Tax rates are not the same as effective taxes paid

Correct, but the tax system is nonetheless quite effective at setting behavioral incentives and disincentives. Higher income and estate tax rates incentivize capital being locked up in investments instead (for lower capital gains taxes); those investments put people to work and are subject to Labor negotiating higher compensation. Allowing donations to non-profits to deduct from other taxes allows private individuals (compared to a government bureaucracy) to more efficiently fund social welfare programs, which incidentally, also put people to work in the administration of such programs.

Funding government is not the sole goal of higher taxation rates, but rather, also how incentives in society are shaped.

Really don't understand.

Their own cherry-picked example benchmarks show that there is frequently no benefit, after enabling FSST, to query runtimes and sometimes query runtimes are actually negatively affected. Despite hard empirical evidence against FSST, they decided to enable it across-the-board? Not even "hey, we built this cool thing which may or may not improve your workloads, here's how to opt-in", but pushing straight up performance regressions for their customers with no way of opting-out?

Why would I ever trust my data to engineers who are more interested in their academically-interesting resume-driven-development than in actual customer outcomes?

> Is it just really really hard to maintain a shared dictionary when constantly adding and deleting values? Is there just no established reference algorithm for it?

Enums? Foreign key to a table with (id bigint generated always as identity, text text) ?

> I have databases I know would be reduced in size by at least half.

Most people don't employ these strategies because storage is cheap and compute time is expensive.

You are correct, but only insofar as destroying paper value. If investors have a firesale because the market would prefer to realize whatever value might be rescued, even at a loss, but the proceeds of the sale stay inside the US, then that capital is more likely to be reinvested in the US once investor confidence returns. This is the underlying reason why most long-investors should continue to hold their positions despite short-term losses. The fact that NVDA has a $4.6T market cap, as a product of about 24 billion shares multiplied by about a $190/share price, does not mean that the market believes that all 24 billion shares could be sold for that $190/share price. That is a convenient fiction that falls apart when investor confidence bursts, but that does not in and of itself truly represent value destruction (Nvidia employees will still wake up the next day and go to work), at least not until second-order-effects kick in (e.g. Nvidia employees leave because their RSU packages are no longer competitive compensation). People who stay long in the stock market can wait for investor confidence to return, in which cash is reinjected into the stock market, and the losses in diversified portfolios are not realized. If the S&P 500 investor takes a 50% hit in a crash, decides to hold, then the S&P 500 rises by 140% in the next two years, then the investor who held will still realize a nice return.

The way in which that narrative does not happen is if the capital leaves entirely to be locked up in other investments; in the context of index funds which would anyway rebalance to rise with those other investments, if the capital leaves for other countries, to investments that are not covered by the index funds.

> “There were pictures of huge mountains of ‘earth apples’,” she recalled, using the word Erdäpfel, an affectionate term for the potato sometimes used by Berliners

Fun fact: the Hebrew translation of potato, תפוח אדמה, is the portmanteau of "earth" (אדמה) and "apple" (תפוח).

If you should ever be so fortunate as to have too many potatoes, see if you can shred them with a food processor and combine with onion, egg, salt, and pepper to make potato kugel, which freezes exceptionally well.

AWS China is a completely separate partition under separate Chinese management, with no dependencies on us-east-1. It also greatly lags in feature deployments as a result.

US stock market index funds will crash when the US stock market crashes. That will require very large sums of capital to decide to move away from US capital markets. To give an idea of how much money would need to move - VTSAX alone is about $2.1 trillion, with hundreds of billions of dollars of shares of each Mag7 stock.

You basically need the world to decide that EMEA/JAP markets are collectively stronger than the US stock market, and to collectively move their capital outside the US to be deployed in EMEA/JAP. Moves away from Mag7 to US value stocks will be captured by the US stock market index funds; moves into commodities will be seen as opportunities to buy the dip before a market rebound. You can view attempts by US private equity to purchase real estate as attempts to hedge against overvaluation in US markets, but if the US has another Great Depression, those real estate purchases won't be able to fetch high rents or prices anyway.

In short, just follow the normal advice, which is not to put all your money into US domestic stocks, but to also purchase foreign stock market index funds, which help to hedge against the risk of the entire US stock market crashing. In the long run, US index funds are still a good investment - US courts still are quite powerful to settle contract disputes, the US does not have capital flight controls, and American business culture is still one of the hardest working, greediest forces on the planet - a Great Depression v2 would not change that.

Well, all kinds. Alerting is a really great way to track things that need to change, tell people about that thing along established channels, and also tell them when it's been addressed satisfactorily. Alertmanager will already be configured with credentials and network access to PagerDuty, Slack, Jira, email, etc., and you can use something like Karma to give people interfaces to the different Alertmanagers and manage silences.

If you're deploying alerts, then yeah you want a progressive rollout just like anything else, or you run the risk of alert fatigue from false positives, which is Really Bad because it undermines faith in the alerting system.

For example, say you want to start to track, per team, how many code quality issues they have, and set thresholds above which they will get alerted. The alert will make a Jira ticket - getting code quality under control can be afforded to be scheduled into a sprint. You probably need different alert thresholds for different teams, and you want to test the waters before you start having Alertmanager make real Jira issues. So, yeah, progressive rollout.

> real-time usage -> billing

This is one of the things that excites me about TigerBeetle; the reason why so much billing by cloud providers is reported only on an hourly granularity at best is because the underlying systems are running batch jobs to calculate final billed sums. Having a billing database that is efficient enough to keep up with real-time is a game-changer and we've barely scratched the surface of what it makes possible.

I think there's two kinds of software-producing-organizations:

There's the small shops where you're running some kind of monolith generally open to the Internet, maybe you have a database hooked up to it. These shops do not need dedicated DevOps/SRE. Throw it into a container platform (e.g. AWS ECS/Fargate, GCP Cloud Run, fly.io, the market is broad enough that it's basically getting commoditized), hook up observability/alerting, maybe pay a consultant to review it and make sure you didn't do anything stupid. Then just pay the bill every month, and don't over-think it.

Then you have large shops: the ones where you're running at the scale where the cost premium of container platforms is higher than the salary of an engineer to move you off it, the ones where you have to figure out how to get the systems from different companies pre-M&A to talk to each other, where you have N development teams organizationally far away from the sales and legal teams signing SLAs yet need to be constrained by said SLAs, where you have some system that was architected to handle X scale and the business has now sold 100X and you have to figure out what band-aids to throw at the failing system while telling the devs they need to re-architect, where you need to build your Alertmanager routing tree configuration dynamically because YAML is garbage and the routing rules change based on whether or not SRE decided to return the pager, plus ensuring that devs have the ability to self-service create new services, plus progressive rollout of new alerts across the organization, etc., so even Alertmanager config needs to be owned by an engineer.

I really can't imagine LLMs replacing SREs in large shops. SREs debugging production outages to find a proximate "root" technical cause is a small fraction of the SRE function.

Headline is wrong. I/O wasn't the bottleneck, syscalls were the bottleneck.

Stupid question: why can't we get a syscall to load an entire directory into an array of file descriptors (minus an array of paths to ignore), instead of calling open() on every individual file in that directory? Seems like the simplest solution, no?

Yeah but that's kinda my point. OK you can write policy to control the Kubernetes configuration with CUE. What about policy to control the Dockerfile, let alone the policy to control the cloud infrastructure? No? So the Security folk writing policy need to learn two languages - one for general-purpose policy, plus CUE specifically for Kubernetes manifests? Why not write the policy for Kubernetes manifests in the general-purpose language they're using for the rest of the policy? And so on and so forth, which make CUE's value proposition dubious in the enterprise.

> Kubernetes

So cue cmd also built the image, authenticated to a private registry, pushed the image, authenticated to the private Kubernetes cluster, and ran kubectl apply?

Like I said, if SROs are legal, you will get better and worse examples. Certainly a lot of people lived in university dormitories which are not, of course, filled with the dregs of society. Is there a market for an SRO hall filled with young Congressional staffers in Washington DC? Or one on Wall Street for young entry-level folk working in investment banks pulling 16 hour days in their first couple of years? Almost certainly. You keep out the dregs of society the same as anywhere else: you charge more than the cheapest places and ask people to sign a strict behavioral code where violations result in quick eviction.

And you share a toilet with a hundred other people in your workplace. So what? SRO rent pays for cleaning staff for common areas.

Devs need to write the 1% of automated tests needed just to prove that what they wrote works in the ideal case. QA is valuable for writing the 99% of automated tests that prove that the software works in the edge cases, with DevOps occasionally dropping in to make sure that the test suite runs quickly.

The way you solve Product and QA being at odds is very simple: QA loses, until they don't. When trying to find product-market-fit, it doesn't make sense to delay delivery to prove that an experiment works in exceptional circumstances. Eventually you do have product-market-fit, and you want to harden the features you already shipped, which is where QA comes in - better internal QA finds the bugs rather than your (future) customers. Eventually you start launching features to a massive audience on day 1, and you need QA to reduce reputational risk before you ship. The right time for QA to intercede and get a veto on delivery changes over the lifetime of the product, and part of whether or not QA is a net-add is whether your organization (leadership) is flexible enough to accept and implement that flexibility.

Is there anyone out there that has actually, in the real world, realized CUE's promise of bundling type safety + data/configuration + task running in such a way that does not require wrapping it in shell scripts? Can you set up your CI/CD pipelines so that it's literally just invoking some cue cmd, and have that cmd invocation be reasonably portable?

The problem is, once you have to wrap CUE, the loss of flexibility within a special-purpose language like CUE is enough for people to ask why not just bother writing the scripts in a general purpose language with better ecosystem support. And that's a hard sell in corporate environments, even ones that find benefit in type safe languages in general, because they can just pick a general purpose language with a static type checker.

Oh we definitely had diverse and vibrant characters, and that was part of what made living there fun. I also find it strange that in a page about solutions to loneliness, you reject one that, by your own admission, would introduce someone lonely to a wide variety of new people.

But if you're trying to use it as a euphemism for drug addicts, I think you'll often find that they end up homeless, despite there being SROs, because they spend their SRO rent on drugs instead, and they get evicted. If you're trying to use a euphemism for sex workers, the successful SROs usually had strict rules around the Single Resident part.

Basically it's just like hotels, in the sense that there are both seedy, run-down, crummy hotels and there are upscale hotels. That there are some crummy hotels is not an indictment of hotels in general. If you make the category legal, you will find worse and better examples, and lonely people would have their choice of establishment that would help put them back into close proximity with others.

I lived on a kibbutz for nearly three years after university and had similar levels of personal space. While I definitely would not want to live on a kibbutz for my whole life, there were very significant downsides (internal politics), I made some lifelong friends there and overall consider that experience to have been very positive, in particular for my social life.

Make Single Room Occupancy (SRO) housing legal again.

Having barely room for little more than a bed forces you to get out during the day. Stuff happens when your default for where to spend your time is not at "home". SRO halls also usually had more room for common spaces to meet and socialize with other people in a similar position in life, and of course, SRO is a very cheap housing option.

Your competitors are not necessarily targeting the same users, and their internal strengths and weaknesses are different from yours. All comparisons to competitors are superficial and distract you from building what your users want and improving upon your internal strengths and weaknesses.

I'll agree with you that the author tried to put in a sound bite and it failed to clarify the author's point.

The author is trying to argue for hiring early engineers who have exhibited ownership values and who want to take ownership for their work. These are the people for whom you establish "extreme transparency" (see: late in the post), a Google Doc for them to help align with others on high-level plans, a kitchen for people to informally talk in, and then get out of their way. That kind of environment is indeed in and of itself quite motivating for a certain kind of engineer.

Of course, it doesn't scale to BigCorp-size. Eventually you have too many cooks in the kitchen. The truth is that the vast majority of engineers really do want someone to tell them exactly what to do, so that they can come in to a highly structured 9-5 job and earn a paycheck that pays their mortgage and feeds their family. Author's prescriptions do not apply to large companies or to most engineers, and Author makes it clear as such.

Renting is actually a better deal, financially, in Israel compared to purchasing. Rent is cheaper than the mortgage payment, by hundreds and sometimes thousands of dollars a month, in a society where the average price of housing is more than 14x the average annual salary but most people are highly emotionally compelled to purchase housing as a symbol of stability and wealth creation - an emotional decision instead of a financial one.

As always, local circumstances matter.

People should look at the actual guidelines, not the flashy website: https://cdn.realfood.gov/Daily%20Serving%20Sizes.pdf

In a 2000 calorie diet, 7-9 servings summed over fruits, vegetables, and grains vs. 6-7 servings summed over protein and dairy. 3-4 servings of protein where a serving is 1 egg or 3 ounces of meat means eating a meatless 2-egg breakfast and maybe a single hamburger patty at lunch and that's pretty much your daily protein.

Hardly some carnivorous revolution.

Merge with Crystal meaning, recognize that both projects have more in common from a language and culture perspective than they are different, get the committers and steering folk to talk together, collaborate together, combine the work. Think for example how Python has a great C FFI, you have a highly dynamic Python layer that can sit on top of C code for optimized hotpath code. Now imagine you instead have a highly dynamic Ruby layer with great integration with a Crystal layer for optimized hotpath code, where because the Ruby and Crystal folks are working together, everything is a first class citizen, all the code is in the same language family, using the same build toolchain, packaging toolchain, etc. Write standard Crystal libraries for compiling to native mobile platforms and write Rails-style views in Ruby for mobile app views, for example.

I see what you're saying, and I recognize that a coding agent will spit out something usable, but it still feels wrong. When a service provider puts out an SDK, they are responsible for it and are incentivized to update it when their API updates. If I ask an LLM to generate an SDK for me, then I am responsible for the SDK code despite the fact that I am not responsible for the API itself. This is not good Conway's Law alignment; it's the kind of thing you do when you have no other choice but to accept the debt that comes with it.

> third party ecosystem is smaller... less and less relevant as coding agents get better

I disagree. The problem isn't with getting an implementation for some favored sort algorithm, it's about integrating with external systems. That's a million times easier when you're not crafting the equivalent of an untyped curl call dealing with raw JSON bodies and can instead use official SDKs provided by the external system provider.

Not even GCP offers a client SDK in Dart, let alone AWS or Azure. Sure, there's a Postgres package for Dart, but you're working with raw arrays on the result rows - no Dart support in sqlc. What about a payment provider like Stripe? Nope. Or an email provider like SendGrid? Also no.

I mean... this is one of the reasons why Go is so popular. You're practically guaranteed to find an SDK for the service you need to connect to. And that's not because the Go team at Google had some special marketing magic that the Dart team at Google didn't have access to, that's just organic growth. Do you really think services are going to wake up across the industry and start offering Dart SDKs??