I think the only way to interpret a one million line LLM-generated diff with no proper reviews as an employee of Anthropic is that my company no longer has an interest in understanding, or even looking at, its own code.
I'd be concerned that by jumping onboard with this sort of development process I'd lose touch with how to engineer software in a detail-oriented or remotely rigorous way.
It also makes me question what sort of value the entire Bun project ever had if a drop-in replacement can just be thrown in here like it's nothing. Why do we need all these JS runtimes again?
The AI bubble is so large that we've also forgotten how useless and dumb a lot of software engineering labor was even before LLMs came along. We were already in a bubble.
All that is to say, I think it's useful to reframe some conversations about AI as, "if AI can accomplish this task, was it ever actually valuable?" I think for some specific things, the answer will be yes, but the tech industry has been huffing its own farts for so long I really don't think anyone has sight anymore of what's economically valuable in a ground truth sense. Much like LLMs themselves, this confusion pollutes the entire well of discourse about their economic utility.
A lot of the conclusions they're drawing in this post about the "agentic era" seem quite misguided and some don't really seem to make sense.
I have no doubt GitLab has too many employees and can benefit from being a more focused company, but it's tiring reading these layoff posts so chock full of buzzwords. I guess they're desperately hoping if they prognosticate about AI enough it will placate the investors.
The most important thing is probably to use native UI controls, either AppKit or SwiftUI, rather than Qt or other frameworks, even those that espouse the use of native controls. That will get you a lot of things for free, generally.
Don't install invasive "helpers" or login items in weird locations; don't ask for huge amounts of system permissions without an appropriate introductory flow for your application, explaining what it needs to do before trying to install or get permission for something.
Bundle your dependencies appropriately; don't go fetch weird stuff post-install, the application should be designed so that everything is already there in the bundle.
Put application data in the idiomatic locations; ~/Library/Application Support, ~/Library/Preferences, etc.
Carefully consider what keyboard shortcuts your application uses; if you use the Escape key for something, or modifier keys, make sure it does something that makes sense on the platform and doesn't conflict with other shortcuts.
Don't bundle Chromium.
Generally: Respect the user as much as possible. Things should "just work." If there's a situation where it doesn't or something feels "odd", you should do whatever you reasonably can to fix that.
If Codeberg starts offering Mac and Windows runners alongside their Linux ones for free (or at an achievable price point) for a modest OSS project I'll certainly look at it very closely. If all I needed was a Linux runner, I'd probably be on there already.
And yes, if we make OSS just about hosting the code, things are much simpler. If you're a piece of desktop software though, and you have users, they'll typically (and reasonably) want auditable signed binaries on all the platforms you support, which requires multiplatform CI.
For companies with resources for infrastructure, sure.
For OSS, the unlimited free minutes of multiplatform CI offered by GitHub are literally impossible to replace. Maintaining runners yourself to do the same things would be somewhere between a part- and full-time job.
If the primary forge's only job is to host the actual Git infrastructure (the code, the MRs, the issues, maybe a wiki), it's a lot more simple than GitHub, and probably more within the scope of what people can reasonably administer themselves.
A "reasonable" answer is probably a primary self-hosted Forgejo instance as the canonical forge, while using GitHub as a mirror solely to take advantage of its free CI, while that lasts, while hosting secrets with a dedicated secret-hosting provider (I don't know what the provider du jour for this is these days).
I'm not sure I'd put it at full slop, but the book is clearly AI assisted. You can view samples on retailer websites, and it features 'interjections' from an AI avatar. Further, in the opening pages, the author feels it pertinent to point out that every fact in the book is verified. Not my cup of tea.
I mean, to those who played them, 'custom map' is basically just a term of art indicating the things you said. In the parlance of the mid-2000s WC3 scene, you would call them custom games or custom maps.
Or, if you were slightly older, you might call them UMS, as they were in Starcraft. Short for "Use Map Settings", indicating that the game logic should come from the scripts and triggers in the map file rather than the built-in logic for ladder games.
> “We work in tech,” she says. “Our kids [aren’t] getting any cell phones, no smartphones, no Instagrams. I write the algorithms. I don’t want my kids to touch those algorithms.”
It's disgusting that this has become a casual attitude and admission by the tech worker class. No one should be getting this free pass.
"I am actively harming children and society with my livelihood (except my own, because I am so smart). Here I am proudly and smugly stating this in a news article."
Is a panel of 'neutral' experts even possible to field in this area? I feel like anyone with sufficiently in depth knowledge of both the AV1 and HEVC specs has almost certainly derived a big paycheck for years from stakeholders on one side or the other of these lawsuits.
I'm no expert, but Google having designed AV1, I can certainly imagine a world where the codec infringes upon HEVC just enough that the lawsuit fees would come out in the wash.
This looks like slop? The README is full of emojis and kind of incoherent, there are no implementation details, there claims to be a Metal backend that doesn't seem to exist, etc.
When I was 12, I watched a redneck in a pickup truck try to race the light rail downtown and cut across the road in front of it, only to get T-boned by the railcar against a nearby station. It was the middle of the day and the guy was definitely sober.
People in the U.S. are simply constructed differently, and as a result I think are unfortunately immune to a lot of the subtle forces that generally help to improve safety in other civilized societies.
This is pretty great stuff, I knew about the raw interop features but had no idea what API Notes offered. Quite cool.
I can't help but feel that Swift will ultimately be the "slow and steady wins the race" safe language of the future. Swift steadily working "first" on both tooling and cohabitability with existing ecosystems is a huge boon for adoption. It understands what an ABI is! If I were doing a greenfield cross platform application I think Swift would be the first thing I reach for now.
The qualms I have with Swift are mostly some of the more recent complex language features that can make Swift code much harder to understand and read, as well as the brainpower required to use Swift concurrency. That and some performance concerns, though many of those seem like they may be solvable with optimizations in LLVM.
Does anyone have a mirror of the old Mac SETI client? setiathome_mac_3_08.hqx? I'd like to see if I can get it running again on my old iMac. Either the OS 9 or the early OS X one would work.
I checked the wayback machine and the download pages are still findable, but the client downloads are all FTP links and don't seem retrievable.
I'd be concerned that by jumping onboard with this sort of development process I'd lose touch with how to engineer software in a detail-oriented or remotely rigorous way.
It also makes me question what sort of value the entire Bun project ever had if a drop-in replacement can just be thrown in here like it's nothing. Why do we need all these JS runtimes again?
The AI bubble is so large that we've also forgotten how useless and dumb a lot of software engineering labor was even before LLMs came along. We were already in a bubble.
All that is to say, I think it's useful to reframe some conversations about AI as, "if AI can accomplish this task, was it ever actually valuable?" I think for some specific things, the answer will be yes, but the tech industry has been huffing its own farts for so long I really don't think anyone has sight anymore of what's economically valuable in a ground truth sense. Much like LLMs themselves, this confusion pollutes the entire well of discourse about their economic utility.