Omarchy 2.0: Best Linux setup ever? (News)

0:29What up, nerds? creating a multi-agent AI software company at XAI, where Grok spawns hundreds of specialized coding and image slash video generation slash understanding agents, all working together and then emulates humans interacting with the software in virtual machines until the result is excellent. End quote. As a lover of good software, I hate everything about this. But as a lover of good names, Macro hard doors, that's hilarious and amazing. Okay, let's get into this week's news. Omarchi 2.0, the best Linux setup ever. DHH calls Omarchi 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.

1:19Now 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.

2:02Sometimes 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 developer's 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. 1. Take time with learning. 2. Realize when you're tired. 3. Work incrementally. 4. Write a prototype. 5. Start with draft documentation. 6. Avoid premature optimization. 7. Release early. Release often. And 8. Choose which yaks to shave. Glenn explains these, so click through if you want them unpacked.

2:41AI 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 assistants 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.

3:21I 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. 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.

3:57Then GitHub lists and links to the tools. This way the tools get some exposure, but maintainers also require the standard to be followed. 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.

4:37Augment 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. The link to this post is in your chapter data, and you can read this post and many others at augment.code.blog. The U.S. buys a 10 % stake in Intel. We've been wondering how Intel might survive its long, slow decline.

5:16I 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.

5:58As a hobbyist investor, I wouldn't have touched Intel stock with a 10-foot pole. As a U.S. taxpayer, I wasn't given that choice. 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.

6:32You 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 two, 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? That's the news for now, but go and subscribe to our Change Log newsletter for the full scoop of links worth clicking on, such as...

7:11CS grads are struggling to find jobs. The missing protocol. Let me know. And recreationally over-engineering my location history. Get in on the newsletter at changelog.news. Have yourself a great week. Like, subscribe, and five-star review us if you dig the show. And I'll talk to you again real soon.