moregrist

> There is a (very) long tail of truly abysmal software that people are forced to use all the time.

We generally call it “enterprise software,” and it’s usually abysmal because the people buying/funding it are VP-level executives who care about compliance/reporting/visibility and who never have to actually use the software.

This actually comes up on HN pretty regularly. Or used to; like many topics it’s taken a back seat to AI.

You can be demanding without using terms like “loser thinking.”

But performance isn’t a single thing. If you prioritize features over pen testing, you’re optimizing one kind of performance and neglecting security, which is an another kind.

For a company whose whole selling point is security, it’s a bad trade-off.

The cost of manufacturing drugs is not where pharma makes it’s profits. Look at the margins for competitive generic drugs and over the counter medicine. Margins are tight.

Pharma makes bank on drugs that are patent protected. Squeezing the manufacturing cost is a small gain on top of that.

Hearing people talk about the “information superhighway” was exceptionally tedious.

The biggest difference to me is the tone. The dot-com era was brimming with optimism and enthusiasm. People were getting rich (on paper). The demand for someone who could write html/perl/java (or fake it) was high, and lots of smart or savvy people got pulled into tech.

The thing I hate about all of the HN posts on AI is the underlying doomerism. There’s always someone gleefully proclaiming that white color workers are super screwed and that we’re destined to be sad serfs to our AI overlords.

I miss feeling good about tech.

Drug design is hard because it’s a system problem not a molecule-protein interaction problem.

At one point the gold standard for generating leads was using combinatorial chemistry to experimentally screen through millions of compounds.

I’m not sure how wide-spread that is any more; it used a lot of reagents. And it ran into the real bottleneck: lead generation tells you little to nothing about the efficacy, toxicity, and side effects of a drug or biologic in actual humans.

In silicon will never do a better job at lead generation than combinatorial chemistry. It could help with the real bottleneck. But… there just isn’t a lot of high quality training data on this.

They’ve been pushing ML approaches to drug design since at least the early 2010s. The approach has evolved with the trends in ML. Overall, I think the results have been very mixed; much like the traditional pharma pipeline.

It’s marketing, but in a global good will sense of “look how much OpenAI cares about secure open source.”

This works for established profitable brands that want to build / maintain a good public image.

This isn’t the marketing needed by an unprofitable startup that wants to show hyper growth before its IPO. They need the “use our product or get pwned” kind of marketing.

I agree it’s not great, and finding an MCU that does this well is challenging. But that may just become a hardware design constraint going forward.

It’s not clear to me what else one can do to protect this kind of IP if you want or need to do the processing on-device.

One solution is to encrypt the firmware and keep the decryption keys on the hardware side, preferably in something that’s tamper resistant.

It’s not ideal. It has serious drawbacks. It makes development and updates a PITA. But it does make it much harder to decompile your firmware.

> Software engineers are getting laid off because of advancements made by AI.

This is said by a lot of CEOs trying to make layoffs look good, but I haven’t seen anything that suggests that it’s true.

> Yet I see far more of these blogs about the plight of mathematicians, not enough about the plight of software engineers.

Really?!? We’ve been living through 3 years of blog posts, LinkedIn hot takes, and podcasts talking about the plight of software engineers in the era of AI. There isn’t a week that goes by without an HN post about it.

I can feel empathy for the practitioners in a field that may have been profoundly changed, the same way I can feel empathy toward software engineers who are struggling with the changes in their own field.

In the end, we’re all trying to figure out where this leads. And how this will affect our lives and our work.

> Assume the model which initiates the worm is a high powered model.

The disconnect here is that highly powered models have billions or trillions of parameters and have compute requirements that scale with the parameter count.

If this became feasible with smaller models, we’d be in a very different world. One where you’d have your own local Fable/Opus/Astra on your desktop.

If we get there, this becomes somewhat believable. Right now it’s just too many orders of magnitude of memory and flops between the many H100s that run the current models and what smart devices have.

Your typical ESP32 chip, which is really beefy for embedded, tends to come with <1 MB of RAM and similar amounts of NVRAM. It runs two cores at a few 100s of MHz and does a bit of SIMD but it was designed for embedded IO (I2C buses, etc) not matrix multiplication. And its network speed is nothing like an Infiniband interconnect. You’re lucky getting 802.11b Wi-Fi.

> Instead of infrastructure being more easily shared with the collective, or valued enough to build a business, now companies can tailor even major infrastructure to their own needs, and avoid all that coordination.

Large companies have always done this. Tons of early 2010s open source projects came out of reimplementing white papers from closed-source Google projects.

It’s also the major downside of this kind of thing. Once someone gets acclimated to how things are done at a large company with custom tools, it’s not always easy to switch to another process, especially a simpler one. There are tons of stories about FAANG engineers joining a startup and being useless.

There’s real value in having consistent tools across an industry. It makes hiring and training easier. Even if you’re convinced that a LLM could crank out a payroll or ordering system that’s perfect for your org, you still have to train the accountants and admin assistants to use it. And you’ve now become the customer support.

The bar is lower with version control, but it’s still more friction than git + GitHub + a well-known workflow.

> I hypothesize that the kind of reader who wants a physical copy of a book is much happier to get a hardcover.

Nope. I vastly prefer paperback. I don’t like ebooks much, and hardcover books are too large, too heavy, and take up too much space on a bookshelf. For books I know I’ll re-read, I might go for one, and I’ve certainly made some impulse HC buys that I regret, but I vastly prefer paperbacks.

One of the best things about mass market paperbacks was you could fit one in a jacket pocket, and easily carry 1-2 around with you.

Most good scientists work hard to prove results to themselves before going public.

Peer review is then done _in private_ before publication as a check on quality and significance.

Retracting a paper is pretty embarrassing. And not considered science as usual.

They only withdrew it after someone pointed out that it was a flawed paper.

In one case by asking Astra to review it.

Not exactly encouraging that they did their homework before publishing results.

I think the general argument is “if you can’t bother writing a blog post, then why should I read it?

Which seems like a pretty good argument to me, given the amount of slip out there and how increasingly performative these pieces are.