Omarchy 2.0: Best Linux Setup Ever?  ## Metadata - Author: [[The Changelog: Software Development, Open Source]] - Full Title: Omarchy 2.0: Best Linux Setup Ever? - Category: #podcasts - URL: https://share.snipd.com/episode/16036101-c490-43d0-8bc2-73d384e81bce ## Document Notes ## Highlights - **Omarchie Evolved Into A Complete Linux Stack** - DHH expanded Omarchie into a full distro experience with an ISO, repo, snapshots, and themes. - The project grew with 30+ new contributors and aims to be a polished Linux love letter. Transcript: Jerod Santo Omarchie 2.0, the best Linux setup ever. DHH calls Omarchie his latest love letter to Linux. Up until today, it was a script that turned a fresh Arch installation into a fully configured, beautiful, and modern web development system based on Hyperland. Now it's a lot more than that. Version 2.0 just dropped, adding an ISO installer, a package repository, a snapshotting setup for easy rollbacks, a minimum Starship prompt, Chrome theme matching, and a bunch more. This version features over 30 new contributors and a lot of love being poured into the project. David sure knows how to inspire and enable people to get involved and contribute to his software ideas. This begs the question, could Omarchi become to DHH what Git has been to Linus? Managing developer's block. Quote, writer's block is the paralysis induced by a blank page, but software developers experience a similar block and it can even get worse over time. Sometimes a good analogy is that your wheels are spinning and you need to gain traction. End quote. In this post, Glenn Normington explores different kinds of developers block, what causes them, and how to get unblocked. You probably already know what causes your developer block, so I'll just highlight his unblock methods for you here. One, take time with learning. Two, realize when you're tired. Three, work incrementally. Four, write a prototype. Five, start with draft documentation. Six, avoid premature optimization. Seven, Release early. Release often. And 8. Choose which yaks to shave. Glenn explains these, so click through if you want them ([Time 0:01:01](https://share.snipd.com/snip/ecc2e41e-7cdf-49fd-8584-1cc9f7e47901)) - **Always Disclose AI Assistance In PRs** - If you use AI to contribute to a project, disclose it in the pull request as Mitchell Hashimoto requires for Ghosty. - This transparency helps maintainers assess AI-generated code and prevents low-quality submissions from slipping in. Transcript: Jerod Santo AI tooling must be disclosed for contributions. Mitchell Hashimoto makes a rule for Ghosty that I expect will be copy pasted all around the open source maintainer community. Here it is, quote, if you are using any kind of AI assistance to contribute to Ghosty, it must be disclosed in the pull request, end quote. And here's why he thinks this common courtesy is necessary at our current stage of AI. Quote, in a perfect world, AI assistance would produce equal or higher quality work than any human. That isn't the world we live in today, and in many cases, it's generating slop. I say this despite being a fan of and using them successfully myself with heavy supervision. I think the major issue is inexperienced human drivers of AI that aren't able to adequately review their generated code. As a result, they're poll requesting code that I'm sure they would be ashamed of if they knew how bad it was, end quote. In the comments of the linked PR, Tobias Luque weighed in with this good idea, quote, I think this is an opportunity for AI tools too. GitHub should publish a standard for a special AI byline that all AI tools can write to. Anytime you use an AI tool, it adds itself to a.git staging file and the next commit lists all the involved tools appended to the message similar to co-authors. Then GitHub lists and links to the tools. This way the tools get some exposure, but maintainers also require the standard to be followed. ([Time 0:02:41](https://share.snipd.com/snip/8926ec95-7282-411c-9d1e-ff99d63e7e64)) - **Standardize AI Tool Attribution In Commits** - Tobias Luque suggested a machine-readable standard for AI tool bylines that auto-append to commits. - A standardized AI attribution could expose tools while keeping human co-author fields clean and enforceable. Transcript: Jerod Santo Everyone wins and the tool can stop spamming the co-authors byline, which is the current viral loop, which is a bit obnoxious. It's now time for sponsored news. Is the future of software engineering beyond the IDE? Our friends at Augment Code sure think so. Their conviction is that the real bottleneck in software development isn't typing code into an editor, it's understanding the whole system. The repo, the history, the intent, the hidden complexity. IDEs are great at syntax and autocomplete, but they weren't built to reason across your entire code base. Augment believes AI changes the equation. By giving a model access to your repo and context, you can shift from editor assistance to system-level collaboration. That's more than faster autocompletes. It's about AI helping you reason, refactor, and evolve software at the scale it actually exists. It's a thought-provoking take. Maybe the future of engineering isn't about cramming more into the IDE, but about moving beyond it altogether. ([Time 0:04:04](https://share.snipd.com/snip/d52cfabe-94fb-48df-8a0e-9ed8f24717b5)) - **U.S. Equity Stake Buys Intel Time** - The U.S. took a roughly 10% equity stake in Intel as part of existing grants and programs. - The investment buys Intel time but doesn't guarantee long-term turnaround. Transcript: Jerod Santo The U.S. Buys a 10% stake in Intel. We've been wondering how Intel might survive its long, slow decline. I don't think they're out of the woods after this deal, but they've certainly bought some time. The details, quote, the government's equity stake will be funded by the remaining $5.7 billion in grants previously awarded, but not yet paid, to Intel under the U.S. Chips and Science Act and $3.2 billion awarded to the company as part of the Secure Enclave Program. Intel will continue to deliver on its Secure Enclave obligations and reaffirmed its commitment to delivering trusted and secure semiconductors to the U.S. Department of Defense. The $8.9 billion investment is in addition to the $2.2 billion in chips grants Intel has received to date, making for a total investment of $11.1 billion. ([Time 0:05:09](https://share.snipd.com/snip/e3c16097-e006-4717-bfad-eea6eddd2b70)) - **Build Small Things And Resist Scaling Pressure** - Consider building tiny, unscalable solutions that solve problems you care about and then stop scaling if it's better. - Embrace small, deliberate projects when GPT tools let you skip growth-forcing steps. Transcript: Jerod Santo Do things that don't scale, then don't scale. If my recent coverage is an indicator, I'm clearly on a personal software kick. Adam Darawiecki is too. Quote, a little over a decade ago, Paul Graham popularized do things that don't scale. The idea was at first you do the scrappy, personal, labor-intensive stuff just to get traction, and then you figure out how to make it huge. But with GPT-assisted coding, I think we're in an era where you can just stop after the first part. You can do something that doesn't scale and leave it that way, that might actually be the best version of it, end quote. Adam goes on to describe a few of his projects that he intentionally hasn't scaled and why he thinks they're better off for it. The pattern he follows, that maybe we should too, is this. Step one, see a need that matters to you. Step build the smallest simplest thing that solves it step three resist the urge to make it bigger step four enjoy it step two used to be the hardest part these days step three where's That crown? ([Time 0:06:06](https://share.snipd.com/snip/beb39019-8e5d-4fa4-9110-077c22abbc3e))