I do use the Feynman Technique if I come across something interesting and try to explain it on paper. So if I was using it just for work, I'd probably do that. Something like "Spec driven development (Github Spec Kit and similar toolkits) is essentially a bunch of md files that provide more context for agents. There are some scripts that provide scaffolding, having agents write the md uses a lot of tokens so writing them manually after the scaffold is generated makes more sense. Try with a small project."

Love the movie, got a spray can and sprayed my whole keyboard army green after watching it then realized I can't 10 finger type. What a golden age of interesting young people in computer security. Roughly one year later (iirc), I read "Smashing the Stack for Fun and Profit" which might have been my most influential IT related read. It's probably tied with "Man-Computer Symbiosis" :)

1) Uptime (though this could be partially alleviated by retries)

and most of all:

2) "Trust"/"Spam score"

It's the main reason to use Sendgrid, AWS, Google, etc. Their "value" is not the email service, it's that their SMTP servers are trusted.

If tomorrow I can just send from localhost instead of going through Google it's fine for me, but in reality, my emails won't arrive due to these filters.

See jwz's struggles with hosting his own email. (Not linking to his blog here with HN as the referrer...)

With email, the 800 lb gorillas won, and in the end it didn't even solve the spam problem.

So a 20 pound monkey can also throw around some weight. To be fair I only use it for personal stuff its probably different if you need enterprise scale l.

I have a 15+ year old Gmail account that I've used everywhere. Spam has been a non issue since 15+ years ago.

The only Gmail accounts that are "overrun by spam" are those of people subscribing to lots of spammy newsletters and then not knowing how to unsubscribe from them (or figuring they'd stay subscribed in case the next newsletter is the Magical One™). But that's 100% self inflicted and you can't save those people with any technical solution.

Email spam isn't a day to day problem for Gmail (at least) since Bayesian email filtering was first implemented.

But yes, the “trust / spam score” is a legit challenge. If only device manufacturers were held liable for security flaws, but we sadly don’t live in that timeline.

Even if your "self hosting" is renting a $5/month VPS, some spam lists (e.g. UCEPROTECT) proactively mark any IP ranges owned by consumer ISPs and VPS hosting as potential spam. I figured paying fastmail $30/yr was worth never having to worry about it.

I had quite a bit of success with it and of course, DKIM and the other measures you can take some years back.

For personal emails, I don't think I had any which fed straight into spam.

e.g. you spend a lot of money to show that you are a legitimate entity or you pay less money to rent something that shows you are connected to said entity.

Maintenance is probably my number one reason for giving up on projects where I'm responsible for feeding the pet.

Without some kind of federation or centralization, it seems hard to distinguish a hobbyist from a spammer if both of them are using a plug-and-go. Forcing that responsibility into the hands of Google, Zoho, and Microsoft seems like the best compromise, unfortunately.

(Back then email still worked from residential IP addresses, and wasn't blocked by default)

No amount of LLM usage is going to change them into full stack vibe coders who moonlight as sysadmins. I just don't see it happening.

Not until, that is, a new generation, that has grown accustomed to the tech, takes over.

Until then the current SMBs will for the most part fulfill their IT needs from SaaS businesses (of which I think there will be more due to LLMs lowering the barrier for those of us who feel confident in our coding and sysadmin skills already).

These are real risks to these companies.

Your in-house teams can build replacements, it's just a matter of headcount. With Claude, you can build it and staff it and have time left over. Then your investment pays dividends instead of being a subscription straight jacket you have to keep renting.

I think there's an even faster middle ground: open source AI-assisted replacements for SaaS are probably coming. Some of these companies might offer managed versions, which will speed up adoption.

Lets take Figma as an example, Imagine you have 1000 employees, 300 of them need Figma, so you are paying 120k per year in Figma licenses. You can afford 1 employee working on your own internal Figma. you are paying the same but getting 100x worst experience, unless your 1 employee with CC can somehow find and copy important parts of Figma on his own, deploy and keep it running through the year without issues, which sounds ludicrous.

If you have less than 1000 employees it wouldnt even make sense to have 1 employee doing Figma

I mean in an example that almost happened... "you are paying 120k per year in Figma licenses, Adobe buys it, you are paying 500k per year in Figma licenses"

At least up until the point of vibe coding it was still worth the SaaS provider charging at least as much if not slightly more than you doing it yourself because most businesses weren't going to anyway.

So you end up spending the money elsewhere? with exploratory design you can easily spend 10k a month on these models as a company of 1000, thus completely losing any monetary savings. Anyway you look at it, Saas worked because costs were spread out and low enough to not optimize it too much.

I mean if we want recent examples just look at tailwindui since it's technically a SaaS.

This is a terrible example. Show me someone ripping out their SAP ERP or SalesForce CRM system where they're paying $100k+ for a vibe coded alternative and I'll believe this overall sentiment.

Just because it cannot be done today, doesn't mean there is not a real appetite in large enterprises to do exactly this.

Without naming names, I know of at least one public company with a real hunger for exactly this eventuality.

They are just hearing the promise that AI will allow them to build custom software that perfectly melds to their needs in no time at all, and think it sounds great.

I suspect the early adopters who go this route are going to be in for a rude awakening that AI hasn’t actually solved a lot of hard problems in custom software development.

Of course, once AGI is available (if it is ever) everything changes. But for now someone needs to have the deep expertise.

Hunger or actually putting real investment against it? I'll wait.

I cannot imagine an SMB or fortune 500 ripping out Salesforce or SAP. However, I can see a point-tool going away (e.g., those $50/mo contracts which do something tiny like connect one tool to another.)

That means to keep making money they need keep selling new people. According to them, their only marketing channel was the Tailwind docs, AI made it so not nearly as many people needed to visit the tailwind docs.

If they had gone with the subscription SaaS model, they'd probably be a little better off, as they would have still had revenue coming in from their existing users.

How is it in any way B2B? At most B2C + freelancers / individuals / really small SME.

It didn't have any clues a med/large B2B would look for e.g. SSO, SOC2 and other security measures. It doesn't target reusability that I as a B would want. The provided blocks never work together. There aren't reusable components.

Tailwind UI or now Tailwind Plus is more like vibe coding pre-AI.

Now attempt the same with Zoom, I suspect vibe coding will fall down on a project that complex to fit the mental model of a single engineer maintained a widely used tool

It used to be that your new b2b product has to try and displace a spreadsheet. Now it has to displace an agent.

I’ve talked to many non engineering managers that love Jira, love the reports, the way they can see work flows, do intake etc.

Engineers and even alot of engineering managers loathe it, largely, but I think we’re the collective afterthought

Also, FWIW, a lot of pain people have with Jira is self inflicted by the people who setup the instance and how it works, vs vanilla Jira

I only mean this all to be fair to Atlassian, that not all issues with Jira derive from anything they’re doing specifically

(this is even granting that AI is a 10x speedup for developers, which I don't agree with and no-one has shown)

This is pretty much what blacksmith.sh does -- GitHub Actions but it's on faster and cheaper hardware. I'm sure they spend non-trivial amounts on marketing but "X but much cheaper" doesn't sound like a difficult sale.

(edit) And the design, sadly, can be as simple as "rip-off bigger competitor" -- of course if one day you are the big competitor because you "won" in the market, you'll need to invest in design, but by then I guess you'll have the money?

This hard part when you're doing in house stuff is getting a good spec, ongoing support, and long term maintenance.

I've gone trough development of a module with a stakeholder, got a whole spec, confirmed it, coded it, launched it, and was then told it didn't work at all like what they needed. It was literally what they told me... I've said 'yes we can make that report, what specific fields do you need' and gotten blank stares.

Even if you're lucky and the original stakeholder and the code are on the same page, as soon as you get a coworkers 'wouldnt it be nice if...' you're going to have a bad day if it's hand coded, vibecoded, or outsourced...

This has always been the problem, it's why no-code never _really_ worked, even if the tech was perfectly functional.

Not trying to hype AI, but we are in an interesting transitional period.

related: i'm thinking these vibe coded solutions are revealing to everyone how important and under appreciated good UX is when it comes to implicit education of any given thing. Like given this complex process, the UX is holding your hand while educating you through a workflow. this stuff is part of software engineering yet it isn't "code".

B2B SaaS is a VULN. They get bought out, raise prices, fail. And then you have extremely large amounts of unplanned spend and engineering to get around them.

I remember when we replaced the feature flags and metrics dashboards with SignalFX and LaunchDarkly. Both of those went sour. SignalFx got bought out and quadrupled their insane prices. LaunchDarkly promised the moon, but their product worked worse than our in-house system and we spent nearly a year with a couple of dedicated headcount engineering workarounds.

Atlassian, you name it - it's all got to go.

I just wish I could include AWS in this list. Compute and infra needs to be as generic as water.

If you're working at SaaS, find an exit. AI is coming for you. Now's a great time to work on the AI replacement of your product.

You get the same shocks with internal teams, just from other causes. And you have to manage them.

I'm sure you've only ever seen brilliant software created by internal software teams?

I have no idea how you are spending "large amounts" of unplanned spend on Saas products. Every company I worked for had Saas subscription costs being under 1% of capex. Unless you add AWS, which is actually "large amounts" but good luck vibe coding that.

We had an in-house system that worked, but it was a two pizza team split between time series and logging. "Internal weirdware" got thrown around a lot, so we outsourced to SignalFx for a few years. It was bumpy. I liked our in-house system better, and I didn't build it.

Splunk then buys SignalFx and immediately multiplies the pricing at a conveniently timed contract renewal. Suddenly every team in the company has to plan an emergency migration.

Your supply chain is messed up. You need sign longer contracts with price guarantees.

I am a user, I like to tinker, I'm fairly confident there's more than 1% of people who care about these things. If you live in a country that is threatened by export embargos and the like it also makes a lot of sense to prioritize open.

in fact, such ISA is only going to fuel more closed ecosystems as it made hundreds of Chinese vendors to join the game for free, they all suddenly got the chance to build their totally closed platforms.

And if you are a country, nobody can kill your RISC-V ecosystem. Worst case, you have to design your own chips but at least all the software exists and is established. And Ooen Source cores exist and are getting better. They may not be bleeding edge but they could be good enough if push came to shove. The BOOM chip just got vector extensions.

High performance implementations, i.e. actual chips you can buy, are going to be proprietary and that's not going to change. Engineering hardware is expensive.

But there are different levels of proprietary. Having your entire software ecosystem impossible to lock-in means something. And competition tends to breed openness.

MIPS certainly did gain a lot of traction. It was a real force at one point and the world is awash in them. But of course MIPS (the company) is RISC-V now.

A cutting edge processor requires personnel across several disciplines and millions in specialized equipment to both validate the implementation of the architecture and the electrical behavior of the circuits and each time it's "compiled" (a batch of test chips fabbed and QAed), it takes a few weeks to be delivered and costs hundreds of thousands of dollars. The ISA being open and royalty-free doesn't affect any of those massive costs.

To use a famous quote: "The answer to any question starting, 'Why don't they...' is almost always, 'Money'" Nobody is offering up that kind of money without practical guarantees of success and some kind of profit at the end of it.

The Linux kernel may be "free" but it represents millions of man hours (or years) of engineering. Creating a viable RISC-V chip would be easier.

Creating the AV2 video codec cost money. I assure you. There is a reason that the Alliance for Open Media is a list of Fortune 500 companies and not a bunch of individual developers.

I have worked in industries dominated by a single chip supplier that made the chips that everybody used. Video surveillance is a good example. It would have been much cheaper for the major players in that industry to fund the collaborative development of chips they could all use and that could maybe be "tweaked" to add differentiated value for the largest players. It would save them money. It would give them more control (even more valuable).

I assume you know what a "chiplet" is. RISC-V is going to change things. In my view, you are focused on the wrong constraints.

We are both saying that money matters. We are simply coming to different conclusions about what that means.

If there were an economically viable number of people who cared about those things (and it would need to be significantly more than 1%), we'd be running SPARC or POWER or maybe SuperH derived systems, all of which have open source, royalty free implementations.

For example, OpenSPARC is something like 20 years old, and covers SPARC v8 through t2. SPARC LEON is a decade older, and is under a GNU license, and has been to space.

And that doesn't consider going the Loongsoon route: take an existing ISA (e.g. MIPS), just use it, but carve off anything problematic (4 instructions covered by patents).

It's a pretty inescapable fact on the ground that in the 'processor hierarchy of needs', an open source license is of no consequence in the actual market.

There are already literally billions of RISC-V chips in the wild. Qualcomm alone has shipped a billion or more. They wrote an article back in 2023 where they disclosed that they had already shipped 650 million of them by that point. Andes Technology has said that there are 2 billion chips using their IP. A recent industry report suggested that RISC-V could represent 25% of the global SoC market by 2030. That is based on growth trajectory, not speculation.

RISC-V is not some obscure ISA that cannot get any traction.

There are a dozen or more credible competitors designing modern 64 bit RISC-V CPUs. Most of them have shipped silicon. Some have shipped multiple generations. Has any ISA ever had so many independent companies independently creating core designs (not designs from a single source like ARM)?

Tenstorrent alone likely made $500 million dollars in 2025. Easier to confirm is that they closed a $650 million funding round.

NVIDIA has announced CUDA support for RISC-V. I do not remember them doing that for SPARC, or POWER, or SuperH.

The current RISC-V standard, RVA23, includes advanced instructions for things like vectorization and virtualization. Many large, important industry players are involved in designing future extensions as well.

RISC-V is an officially supported platform in many mainstream Linux distributions including aggressively commercial ones like Red Hat Enterprise Linux but also foundational ones like Debian and its derivatives (like Ubuntu).

GCC and Clang have excellent support for RISC-V. FFMPEG just released hand-written vector optimizations for RISC-V. Again, can we say this about any of the platforms you mentioned?

It's a pretty inescapable fact on the ground that RISC-V has an absolute mountain of support in the industry. And starting this year, multiple vendors will be shipping cores faster than you can license from ARM.

Honestly, what universe are you living in?

The one where I actually read what I'm replying to.

I never one single time said RISC-V wasn't successful. Not even implied it. What I did say, should you ever climb of your apparently thinking-averse, pre-conceived notions is that its license isn't the overriding reason it's successful, because the world is full of open source ISAs that never gained any traction. Something you might be aware of if you took a brief break from furiously jerking off over RISC-V and paid attention.

you need to be totally autistic to believe that Chinese vendors are going to share anything meaningful with you. they don't hate you, they want their paying customers to be happy, but the brutal competitions in China doesn't allow them to be open in any sense. For products like RISC-V processors and MCUs, the moat is extremely low, being open leads to quick death. It is not about how much stuff they share with you as paying customer, it is about how much they are willing to share with their competitors when there are hundreds of companies trying everything to survive.

as a developer, you just need to ask yourself a dead simple question - how such risc-v platforms are going to be more open than raspberry pi.

They are pushing their RISC-V products into the Linux mainline before those products even ship.

Those autistic Chinese also contribute a rather surprising amount of Open Source RISC-V out of their academic world.

There is (so far) nothing 'open' about RISC-V. and I wonder if there really ever was any desire for it, at this point.

This whole "Open ISA" crap appears to be a thin veneer to funnel quite large sums of investment into an otherwise completely proprietary and locked-down environment that could never harm the incumbents in any meaningful way - while still maintaining just enough of a pretense of open source, that the (regrettably myself included) shallow nerds and geeks could get smitten by it.

Where is the RTL? Where are the GDSII masks? Why am I unable to look at the branch predictor unit in the Github code viewer? Or (God forbid!) the USB/HDMI/GPU IP? I reject the notion that these are unreasonable questions.

I want my SoC to have a special register that has the git SHA ID of the exact snapshot of the repository that was used to cook the masks. that, now that - is Open Source. that is Open Computing. And nothing less!

I dont care about the piece of paper with instruction encodings - the least interesting part of any computer!

Wasn't that the whole point? We're more than a quarter of a century in and we're still begging SoC vendors for datasheets. Really incredibly embarassing and disappointing.

As you note correctly, the ISA is open, not this CPU (or board).

The important point is that using an open ISA allows you to create your own CPU that implements it. This CPU can then be open (i.e. you providing the RTL, etc.), if you so desire

I assume it will be much more difficult (or impossible?) to provide the RTL for a CPU with an AMD64 ISA, since that one has to be licensed. I wonder if you paying for the license allows you to share your implementation with the world. Even if it does, it's less likely that you will do so, given that you will have to pay for the licensing fee and make your money back

Since there is no license to pay for in case of RISC-V, it allows you to open up the design of your CPU without you having to pay for that privilege

So? You've been able to do that since...computers. Anyone can roll their own ISA any time they want. It's a low-effort project that someone with maybe a Masters student level of knowledge can do competently. When I was in school, we even had a class where you would cook up an (simple) ISA and implement it (2901 bit-slice processors); these days they use FPGAs.

So you got your own processor for your own ISA...that was slow, expensive (no economy of scale) and without a market. But very fun, and open source, at least. And if "create your own CPU that implements it" is what you want, go forth and conquer...everything you need is already there and has been for a long time.

But if your goal is "I want an open source ISA that I can produce that's price and/or performance competitive with the incumbents", well, that's a totally different ballgame.

And there are open source ISAs that have been around for decades (SPARC, POWER, SuperH). These are ISAs that already have big chunks of ecosystem already in place. The R&D around how to make them competitive already exists. Some, like LEON SPARC have even gone into something like production (and flown in space).

So, yes, an open source ISA affords the possibility that we can make processors based on our own ISAs on our own terms. It has even in extremely rare occasions produced a product. But the fact remains, the market hasn't cared in the slightest to invest what's required to turn that advantage into a real competitor to the incumbent processors.

Yes, you can create your own ISA. But to run what software?

If I create my own RISC-V implementation, I can install Ubuntu on it. Maybe even Steam.

See the difference?

And, the market has responded with a tidal wave of CPU contenders. Like in the rest of the world, not all of them target the highest end portion of the market. But some are choosing to play there. Have you checked-out Ascalon?

And why did Qualcomm pay all that money for Ventana recently? You do not expect them to release high-end RISC-V chips? I mean, they already ship many low-end ones.

Ventana is an extremely bad example to be used here. It is acquisition price is undisclosed, it could be just some $ for acquiring the team behind it. Secondly, Qualcomm's nuvia acquisition was pretty huge, there is no reason whatsoever to believe the Ventana acquisition is remotely comparable, that proves no one uses RISC-V anyway.

Here is an article from a company called Qualcomm from two years ago saying that they had, at that time, already shipped 650 million RISC-V cores.

https://www.qualcomm.com/news/onq/2023/09/what-is-risc-v-and...

I notice that the three benefits they flag for RISC-V are: flexibility, control, and visibility.

I wonder how they felt about "control" after ARM tried to stop them from commercializing the value of their Nuvia acquisition? I wonder if it had anything to do with their next big acquisition being RISC-V based instead?

I also wonder, why on their Oryon page does Qualcomm never meanion ARM. Not even once. Even to the question, is Oryon x86, they do not answer that it is ARM. Why not?

https://www.qualcomm.com/processors/oryon

with the majority players being Chinese vendors (those you can buy, not including those building RISC-V for their own in-house applications), RISC-V is far less open than ARM or x64.

expecting openness from Chinese vendors is like trying to hook up with some virgin bar girls in your favourite gogo bar in Bangkok.

https://github.com/OpenXiangShan/XiangShan

if you search their public media releases, they mentioned that their cores are used by some imaginary vendors for undisclosed platforms. just go and check how CLOSE those junks are. product names and models are always omitted, it is always "certain vendor", "one AI card", no spec no details whatsoever...

searching their names on taobao.com returns 0 hit, searching their names on the largest Chinese second hand platform returns 0 hit. 4 years after they started doing their great open project, you can't even buy one from the OPEN market! that is VERY OPEN to me.

Ok fine. Here is a link to a completely open design:

https://github.com/tenstorrent/riscv-ocelot

And here is a high-performance evolution of it that you can license. They would be happy to take your check today. https://tenstorrent.com/ip/risc-v-cpu

Silicon will be available in a few months.

And just for you, it is not Chinese.

https://github.com/Wren6991/Hazard3

Claude Sonnet 4.5 was able to figure out a way to resolve it eventually (around 7 fixes) and I let it create an rllib.md with all the fixes and pitfalls and am curious if feeding this file to the next experiment will lead to a one-shot. GPT-5 struggled more but haven't tried Codex on this yet so it's not exactly fair.

All done with Copilot in agent mode, just prompting, no specs or anything.