I make open source dev tools at entire.io like mise, aube, fnox, hk, mbx, pitchfork. Previously I wrote the heroku cli and oclif. ex-amazon/meta.
Dallas, TX
- Tweets 1,829
- Following 1,269
- Followers 6,921
- Likes 1,536
this was awesome @dhh
Here's my conversation with @DHH. He is back for round 2! It was an epic fun 5 hour conversation about the future of programming, AI, Linux, and human civilization.
It's here on X in full and is up everywhere else (see comment).
Timestamps:
0:00 - Episode highlight
1:27 - Introduction
2:56 - Programming with AI agents
18:14 - How software will change
27:30 - AI impact on open source
37:21 - Building Omarchy Linux distro
47:05 - Vibe coding vs agentic engineering
1:00:06 - The end of manual programming
1:10:24 - Advice for programmers
1:22:30 - Surviving Internet Hate
1:31:46 - Programming setup for AI Agents
1:44:11 - Obsessing about speed
2:07:06 - Voice prompting vs typing
2:21:05 - Best AI coding models
2:37:55 - Best AI coding harnesses
2:50:57 - AI video generation and filmmaking
3:10:28 - Fatherhood
3:38:35 - Linux will win the desktop
3:49:51 - PewDiePie
3:59:24 - Future of programming
4:22:17 - Politics and immigration
4:53:54 - Longevity, over-optimization, and fear of death
5:05:38 - Eternal recurrence and future of human civization
13
20
501
48,690
here's my plan for moving the industry off of using curl|sh for anything: github.com/jdx/packslip/disc…
20
9
203
18,804
yes, that’s why the proposal is a distribution-packaged bootstrapper. you get it through the system package manager you already have (macOS excluded). then it can verify releases from any participating vendor without executing their installer scripts. there’s still a trust root (the distro), but trusting one verifier doesn’t require giving every vendor arbitrary code execution just to install their tool
14
Ok yeah that makes sense. Have enough people packaging and the distros might respond.
So how do you see this playing out:
Distro pre installs packslip->packslip install mise->mise install other tools
Or does packslip eventually replace the need for mise?
And does mise then leverage packslip also?
1
20
mise has a packslip backend yes mise.jdx.dev/dev-tools/backe…
you could use packslip instead of mise for extracting cli artifacts, but that's all it does, it's not a package manager like mise is
17
Are vendors usually the problem? I would figure curl is used by vendors because it works and they can install what they need and keep instructions simple for users.
Even if in that script they used packslip 🙈
1
18
i wouldn't use the word "problem", however in order to meet my goal of getting into the distros the distro maintainers are going to want to see relatively broad adoption of packslip in the ecosystem.
luckily though this isn't something i have to twist vendors arms on too hard because vendors get a lot of advantages from adopting packslip right out of the box via mise, so it's a relatively easy sell.
also vendors want to see other vendors having adopted packslip too, so the more vendors adopt it the more likely future vendors will adopt it too
it'll probably be a while until we see packslip instructions to replace curl|sh but getting at least the packslip json into as many vendor releases as possible is the first step along that path.
1
2
19
I think that mise, software that has version locking as a core feature, ought itself be version-lockable. I am even able to do this, but the way to do it is not ergonomic.
1
27
mise is not like the tools it tracks, it deals with breaking changes on time schedules not with versions so if you don't update regularly you won't get breaking change notifications. you also cannot rely on old versions of mise because the vendors mise tracks are always changing so it must be kept up to date in order to continue functioning
21
hk 2.5.0 is out! No major features, this is a snow leopard release fixing lots of bugs/perf.
hk is really taking off in terms of downloads. It’s approaching 100k/day which isn’t far off from where mise was 3 months ago.
github.com/jdx/hk/releases/t…
3
36
2,333
i'll be honest even tho curl | sh are insecure by nature, one of the biggest advantage is that code can be inspected, and today's vet by llm in a breeze ; but i've never read a brew file and feel less comfy with hidden installs (took me a while to trust mise but now it's pure ❤️)
1
16
i suspect you'll find packslip a lot easier to trust than mise since nothing you fetch with it will ever run any sort of scripts—at least that's the design i have today. my thinking is things like postinstall hooks should be explicit action for this very reason.
because mise installs things like npm packages it can't have this same guarantee
admittedly one sort of weird thing is that it isn't going to extract to a single directory by design. right now i have 2 directories, a `--bin-dir` and `--install-dir`. reason being is that the install dir is where the tarball installs to but `--bin-dir` would probably default to something like ~/.local/bin. otherwise you'd have to add every tarball dir to PATH which would not be fun
12
the anthem for everyone struggling with cargo's 100gb+ target/ directories from rust git worktrees: pray silence for mr-boxington 📦🍓 github.com/jdx/mr-boxington
6
6
52
4,326
oh and brew also wouldn't be shipped with debian because they also cannot keep long term commitment and move too fast for their much slower release cycle...
so you're basically making a baby brew, more stable, just to wrap their bash script and avoid the insecure curl | sh 👀
1
1
66
to be clear, packslip isn't a package manager and doesn't compete with them.
packslip the standard is something that package managers could use both for vending themselves and consuming other tools.
packslip the cli is more similar to curl than brew. it replaces `curl | tar -x` basically with extra security features and is designed around tool/application installations. the idea is that it's simple and stable enough that it can go directly into linux distros so that can be used to bootstrap faster moving and more complex tools
2
262