skrrtww

IIRC, part of the order was for stuff like Steam achievements, upgraded assets, modern resolution support, other platform conveniences, plus other required changes to the game due to licensing agreements shifting, all of which made slapping it in a VM a poor fit.

I know from people who actually worked on this that the process of actually getting the game running and following modern platform conventions was somewhat insane and tortuous, but interesting. Too technical for the Times to go into though I guess.

But yeah, essentially the whole port is done with binary patches to the original executable.

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.

But can it play BlockDude?

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.

The dependency list is also...something: https://github.com/J-x-Z/cocoa-way/tree/main/vendor

I'm not sure if these selectors are hit in SwiftUI or not.

I feel like the vast majority of these are features of an operating system? Not a web browser?

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.

I have a lot of pet Apple bugs. Top of mind at the moment:

Why can't we adjust the order of photos in a Shared Photos album?

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.

HN's auto-editorializing has tripped on "Report: " matching not just as a prefix but in the middle of the title as well.

(original title: "Dolphin Progress Report: Release 2512")

The latter link is referring to different people.

It's somewhat bizarre to me for this to impact "casks" but not "bottles". Bottles are all ad-hoc signed and presumably have the quarantine attribute removed manually since I do not see Gatekeeper warnings for bottles I install via Homebrew.

I've had the same iTunes (now Music.app) library since 2004, with only one botched library migration with an iTunes update in like 2013. It has 40,000 MP3s or so. I still keep it on my boot drive too.

It's a treasure. I understand why most people don't do this, but I will probably forever.

A really significant amount of it isn't otherwise available on streaming services. While I'm an Apple Music subscriber, I still acquire my own mp3s for most of the new music I listen to.

iCloud Music Library is an immense value here as well. Rarely it will sync the wrong version of something in my library, but usually it's on the money. The fact that it doesn't cost anything extra on top of an Apple Music subscription is a huge boon, and it doesn't count against my iCloud data either.

In Safari 26 on an M1 with WebGPU enabled I get "InvalidStateError: GPUCommandEncoder.beginComputePass: Unable to begin compute pass."

In Chrome I get "Failed to start: Failed to create State. Caused by: failed to find GPU adapter."

So I guess it runs on "some" GPUs, in "some" browsers!

Uh, does this apply to the autogenerated source code artifacts? Those are famously not stable because they are generated on-demand with `git archive`. The value of this feature is really undermined if they don't also provide a source code download with a stable hash.

If this was genuinely unintentional on your part, then bless your heart and I'm sorry for assuming the worst. You might be the least morally corrupted internet user alive today.

This might be the worst named project of all time. Not funny and demonstrates an absolutely terrible impulse on the part of the author. Probably the worst way possible to advertise your project.

edit: According to the author in a reply, the double entendre was in fact not intentional.

Pretty cool!

I have heard stories of people in 2025 creating a fat macOS binary containing arm64, x86_64, x86, and ppc slices.

I hope that we can get virtualization of x86_64 macOS on arm64 hosts. It would be really cool to be able to do such a thing solely on a modern machine!