TomBombadildoze

Beats Opus 4.6 at what exactly? It certainly isn't code.

I use a combination of a Claude Max subscription and local inference, including qwen3.8-27b, 4bit. I have found qwen to be absolutely useless at anything but very specific, surgical code changes. In my experience, for anything even remotely nuanced, a frontier model is required.

Buffalo also feature prominently in The West, another fantastic Ken Burns documentary.

https://www.pbs.org/kenburns/the-west/

Unpopular because it's so flagrantly ignorant. How much do you know about the "egregious" expenditures by rank-and-file federal employees just doing their jobs?

> A butler has always been a person of authority, expertise, and responsibility. Why "houseboy"? Because he's Asian?

facepalm

The author describes Marc Andreessen's Gilded Age slash Roaring 20s lifestyle and attitudes, and then suggests that a hundred years ago, this person may have been referred to as "houseboy".

Marc Andreessen is the hypothetical person from a hundred years ago. It's a scathing criticism of Marc Andreessen.

No, it is bad advice, and it is absolutely not idiomatic Python. The language specification reserves them to ensure new ones can be added in the future.

https://docs.python.org/3/reference/lexical_analysis.html#re...

This has been in the specification since, at latest, Python 2.0, and perhaps earlier.

Any you see defined outside the Python data model are entirely historical, written in contradiction to the spec. Many of them also can't be changed because there is so much code in the wild that depends on them.

*Do not define your own dunder methods!*

Cartels disrupting law enforcement, and/or vice versa.

Pulumi, cdk8s.

Until you need to update it, or apply it to multiple environments, or any number of tasks where the concepts of configuration parameters and dependencies become important.

Edit: I'm not saying Ansible is an appropriate substitute (it absolutely isn't), rather that `kubectl -f` is not a scalable solution.

The lesson is that shockingly few people have realized is that the problem space is not, nor has it ever been, served by declarative solutions. You can describe the state you want a system to be in but there will inevitably be procedures involved to do some of the work. It is unavoidable. At the point people began developing templating around their configuration, ah, templates... which themselves have imperative language constructs awkwardly (and badly, cough Golang) embedded in them, it should have been clear to everyone with a shred of talent that it wasn't a good solution.

Declarative configuration is wholly expressible by imperative languages. The converse is not true. Declarative configuration is appropriate for declaring state (i.e., values), and not for describing procedures.

Stop using half-baked YAML crap and start using real tools.

When all you have is a hammer, everything looks like a nail.

"Moving on" and recounting a story can be, and often are, entirely different things.

Ruby/RoR values form over function. Over the past few (five or so?) years, as teams went through the transition from aggressive feature development to devoting more effort to maintenance and operations, they realized that relying on conventions as a guiding principle has a substantial cost burden that you don't pay when prefer rigor and specification.

Their own internal price target, the FMV they assign to shares.

https://www.wsj.com/articles/stripe-cuts-internal-valuation-...

Please. Stripe is privately held so let's look at a market comp, SQ.

SQ 2021 Revenue: $17B

SQ 2021 cash and short term investments: $5.3B

Stripe 2021 Revenue: $12B

Similar businesses, operating in the same market, with the nearly the same number of employees (about 8000). Barring exceptional circumstances, we would expect their financial health to be roughly similar.

You said it yourself:

> the leaders have to... [deal] with investors

The economy is contracting and their share price is falling. They could afford to dip into cash and keep everyone on board but their investors are more concerned about propping up the valuation. They don't have two shits to give about the people they're letting go.

You aren't missing anything. This guy is absolutely, completely, without rival or parallel, beyond compare, unquestionably supreme, the God-King, the Emperor, the One True Big Kahuna, and the Head Motherfucker In Charge of being Full Of Shit. If this guy were the biggest fish in the ocean, he'd be stuffed to the gills with it.

Interesting concept, and plenty of good discussion and criticism in other comments.

One thing in particular from the article that I found especially objectionable:

> For now, the theory is just that—a theory.

This is a conjecture. I expect better from science journalism.

I tried to order a Solo Stove last fall. I placed the order, they accepted it, everything seemed like a normal e-commerce experience. Two days later, I received an email saying my order had been canceled for suspected fraud. I've never had that happen before, and it hasn't happened since. My experience is obviously anecdotal but their fraud detection routine clearly had major flaws.

With news of layoffs at Bolt, I wonder how many partners lost sales like mine.

There are many complaints in this discussion about inaccuracies in the post but you've actually captured the essence of the problem--type hints just don't solve the problem well.

My team began using type hints and aggressively applied mypy to new code starting a couple years ago and it _has_ helped immensely. However, we also started doing some work in Typescript around the same time and the difference in developer experience and code quality is pretty clear. Typescript is just a better solution to the problem of adding type information to a dynamic language.

What's especially frustrating is living through the design and early life of asyncio (Guido, you should have adopted the gevent model), then getting excited about typing, only to find it is also not very good. What's _especially_ frustrating is that Typescript existed two years before PEP 484 was published, so the core developers had ample time to seek inspiration elsewhere, and they came up with a sub-standard solution.

Python needs a Typescript analogue, with a compiler that targets vanilla Python.

Good gravy, this is a lot to unpack. It's an alarming story from the very beginning, and a cautionary tale of how tempting it is to do everything with Jenkins, even though it's an appropriate tool for absolutely nothing in the Year of our Lord 2021.

> As part of our automation setup, we continuously run integrity jobs to inspect our Jenkins nodes.

Why on earth would you self-host this in Jenkins? This is a monitoring and alerting problem.

> These jobs check system configurations and properties and look to see if any node is failing those checks.

What year is it? We've solved this with immutable infrastructure or system integrity monitoring. Or both.

> The checks automatically mark Jenkins nodes as offline when any of those checks fail and notifies our Mobile Build & Release team via a Slack message.

"Mark" offline? Why not just terminate it? And why do we care if build nodes come and go? These should be cattle, not pets. If they all die at once, that's bad. If they're cycling in and out, that's business as usual.

> When our Jenkins UI stopped working, we noticed two things:

> 1. We had recently upgraded Jenkins and all its plugins to a newer version

Did they just now learn what an awful idea this is? All of this at once, really?

This isn't so much a Jenkins problem (though let's be clear, Jenkins is a problem) as it is a remedial engineering problem. The top takeaways should be "choose appropriate tools for the task at hand" and "don't make reckless decisions with brittle systems".

This isn't a batch scheduling problem. It's a monitoring and alerting problem. OP needs a monitoring and alerting solution.

Stop ~~~ engineering ~~~ things and choose the right tool for the job.

You put it better than I could. There are certainly naive examples of how to use it out in the wild but that's not SQLAlchemy's fault. It's a sophisticated tool that accurately reflects how a database works.

I caution people against using Django because the ORM makes so many weak, simplified assumptions about how a database works that don't bear out in practice. It's fine for a blog. It falls apart when you're working with Real Data.

Yes, the premium received at the time the contract was sold.

That's not what the fallacy fallacy means.

It is possible to form an coherent argument that happens to include a fallacy, where eliminating that fallacy doesn't invalidate the argument. Essentially, the argument itself is poorly constructed but the claim is still supported by evidence.

In this case, the entire premise is fallacious. You can tell because the written premise includes the fallacy.

citation needed

> The whole idea of containerization came from Google anyways, who uses it internally.

Not really. Jails and chroots are a form of containerization and have existed for a long time. Sun debuted containers (with Zones branding) as we think of them today long before Google took interest, and still years before Docker came to the forefront.

> I've seen Docker be a disaster over and over again. The fact that they have a good sales pitch only makes it worse because more people get stuck with a bad technology.

> Eliminating Docker from the equation seems to me to be an unmitigated Good Thing.

Now this I agree with, Docker is a wreck. Poor design, bad tooling, and often downright hostile to the needs of their users. Docker is the Myspace of infra tooling and the sooner they croak, the better.

Of course. However, you don't need someone to provision and monitor power, connectivity, datacenter security, and all the responsibilities AWS absolutely prices in for you. You also substantially reduce your effort and cost toward capacity planning and managing depreciation. You pay for consumption of _all the things_ required to operate compute infrastructure, plus their margin.

There are certainly companies and problems for which colocating still makes more sense than the cloud but 9 out of 10 of these articles completely gloss over most of the costs. This article is one of them.

> The nearest galaxy is 25k light years away so even at the maximum speed it would take 25 thousand years to travel here.

Given your arithmetic, I assume by "maximum speed" you mean the speed of light, in which case travel wouldn't take 25k years. It would in fact be instantaneous. At relativistic speeds, distances contract and time dilates.

Now, this is all moot because this:

> The idea that aliens would use these to propel ships is rather ludicrous, and highly unlikely.

... is absolutely correct. No amount of energy will propel a massive object to the speed of light.

edit: I realized I may have misinterpreted. From the perspective of someone watching their own kind travel that expanse, it would indeed appear to the outside observer to take 25k years to travel.

43k reactions and 1600 comments.

You know, I feel like he just might pull through and score another job.

Almost everything on computers is perceptually more rich, useful, and intuitive than it was in 1983.

^The word “mafia” is never heard in The Godfather$