rufo

He started selling Floppy Emus in 2014[1], bought a run of 10,000 DB-19 connectors in 2016[2], mentioned that he sold "several thousand" in 2021[1], and decided he no longer needed to horde as many DB-19s as he had held onto in 2025[3]. So based on all if that, probably somewhere between 4,000-8,000? (One of which is currently on my desk for connecting to an Apple IIe I recently acquired.)

[1]: https://www.bigmessowires.com/2022/02/16/bmow-business-updat...

[2]: https://www.bigmessowires.com/2016/06/04/db-19-resurrecting-...

[3]: https://www.bigmessowires.com/2025/06/30/bulk-lots-of-db-19s...

Voodoo 1-3 couldn’t render 32-bit color, so maybe you were noticing the lower bit depth?

3dfx did design some tricks into the video pipeline on Voodoo 2 and 3 cards that allowed for what they called 22-but color, and it definitely looked better than other 3D accelerator cards’ 16-bit modes - but it was still not as clean looking as true 32-bit color. (Interestingly, the filtering they did was applied after the framebuffer, so screen captures would only ever show the lower quality original.)

Because, as one of the original GUIs, when they conceived of how the Macintosh worked, you used the command keys to perform actions on files, and you could rename the file just by typing. Cmd-O was the shortcut for opening files, which makes sense for obvious reasons.

When they released the Macintosh to the world, Andy Hertzfeld realized that people were renaming items in the Finder by accident; so he added the "return" key (already used to confirm actions) as an "arming" step[1].

Now, one might ask: wouldn't that interrupt people navigating via the keyboard? No, because the original Macintosh didn't have arrow keys on the keyboard. This was an intentional choice—or, perhaps, mandate from Jobs—as a way to get users to use the mouse as their primary input device, and to force developers to create mouse-driven interfaces. With no arrow keys, no typeahead search implemented, and a clean slate for designing an interface, I'm guessing using Return to open a file wasn't a strong consideration at the time.

Why wasn't it changed? Because Mac OS X was made for Mac users, and we all have muscle memory dating back decades :P

[1]: https://www.folklore.org/A_Floppy_named_lsadkfjalhkjh.html

As positive as I can be without having bought one just yet. The ones I've seen specifically say they "solve the problem that low power devices cannot be powered via C to C", that they support 480Mbps data transmission, and are listed as 5.1K ohm resistor adapters.

As someone with a bunch of "USB-C" devices that do this, I'd wondered for years why nobody sold these. I recently just found them on Aliexpress in a more finished format (nice-looking case and such), so I'm hopeful they'll start to filter out into the world more. (If you're interested, do a search for "usb c resistor" and you'll find them for ~$2-$4.)

Gotcha. I look forward to checking it out.

Ooh, is this public anywhere? Definitely an area of interest of mine :)

Seconded. I went in with only a vague awareness of what Bois' thing is and knowing it somehow involved Tims, Als, and oceanic telegraph cables. I was not disappointed.

Ah, interesting - I saved the video but haven’t gotten around to watching it yet. I don’t know if this is touched on, but it certainly does seem like Gabe’s statement could be a nicer-sounding front for what Becky says; if there are fewer users than the math for supporting HL on Macs on an ongoing basis doesn’t make as much sense.

Apple’s new Foundation model for the 27 OS releases does some interesting things in exactly this area: https://machinelearning.apple.com/research/introducing-third...

I was so steamed about this as a teenager back when it happened - pretty sure it was one of the foundational reasons I started to consider building my own gaming PC once I got the money together.

As an adult, and with the hindsight of seeing how Valve has (generally) supported their games over the years, I can appreciate gaben's reasoning for cancelling it... though as someone gaming on the Mac, we were all kind of used to being second class citizens and bodging together mod support and whatever, so I still think they should've let it come out.

> “Given the realities of the Mac gaming market, our Mac customers were… always going to be second-class customers where we couldn’t invest to the same degree in the Mac version as we did elsewhere,” commented Newell. “I don’t want to be in that business. I would much rather we just eat the money we’ve spent so far than take money from Mac customers and shortchange them.”

Yes, I mean, that’s also a possibility - or someone didn’t know they needed to screw on the antenna, or it’s otherwise borked. Every PC motherboard (sample size of four, three for me and one for a nephew) I’ve bought in the last five years has had on-board WiFi and Bluetooth though, so I’m curious to know, was that a deliberate choice?

(In thinking about it, it’s possible that the motherboards I bought did have non-wireless alternatives that weren’t stocked at my local Micro Center - lot of digging required to figure that out, though :) )

Ooh, thanks for the insight, I didn’t realize that - though that makes sense given how they work. My initial reaction is, I like the idea of the pure hardware-locked passkey as you describe it, but I feel like the syncing is a reasonable-ish nod towards making them more usable in the real world since it does let you have more flexibility.

I haven’t ever looked at the APIs for passkeys; is there any semblance of those types of keys being an option, or did opening the door to syncing basically let anything happen with the APIs and lose those guarantees?

I recognize the point of your post is more about the lack of clarity and details around passkeys. That's real, and I don't really have an answer for that - other than, I think maybe the quest for making them simple and "just work" has maybe made them nebulous enough that we've wound up in the current situation where a lot of even technically savvy people don't really understand them. But I feel like answering your questions might sort of help explain why that's the case, so I'm going to take a stab at it:

> If I accidentally set up a passkey on my phone (let’s say I use Safari one day instead of my go-to, Brave), can I still log in without that passkey on other devices?

Assuming you have LastPass set up to be an iOS password manager, and it fully supports iOS' passkey implementation: when you create a passkey in Safari, it will ask you if you want to store it in LastPass or in the iOS Passwords app (previously known as iCloud Keychain). If you say LastPass, then it's up to them, but I assume it'll sync to all your devices - it's how 1Password works. If you were to accidentally say Apple Passwords, it'll sync to all your Apple devices automatically, and you can either use Apple's password browser extension on Windows, or you can use the "another device flow" I'm about to detail.

> Is there a way to ensure that passkey can be used on other devices?

As mentioned above, passkeys are intended to sync via your password manager of choice as the primary use case. If for any reason you don't have that passkey synced to that device, _and that passkey is on a mobile device with a camera_, most browsers will give you the option to scan a QR code with your phone. This kicks off a flow that will authenticate you via your phone's biometrics or passkey, then use Bluetooth to first ensure device proximity and then handle the authentication exchange. In the case of iOS, this includes any passkey-supporting password manager, so the passkey itself can be in 1Password; it doesn't have to be in the iOS password system for this to work.

When I first read the above, my hackles were raised given how well Bluetooth operates at times; but every time I've used it so far, it's been fast and flawless. Still, I can see a lot of scenarios where this might not work - e.g., the first one I thought of was a public computer at a library where Bluetooth might be locked down; corporate computers or remote servers could also be troublesome. As far as I know, passkeys don't yet have answers to those scenarios; other than to just use your password + 2FA as you would without a passkey.

As far as I know, both of the above apply to every passkey-consuming site.

> Can I add another passkey on another device? How many passkeys can I set up for a particular site/app?

This touches on your last paragraph, where it indeed could change based on the website. In my experience, every website where passkeys are fully supported - e.g., not ones that are using passkeys as a substitute for FIDO/U2F keys - has let me add multiple passkeys and have not _appeared_ to have a limit. I typically will create a passkey in both 1Password and Apple Passwords just to have a backup, and I can't recall any cases where that's been a problem. Still, I can't say for sure that isn't a problem on any website.

I went all in on trying passkeys when they started to be an option, and I don't have any notable regrets. For me, passkeys have generally worked well when the site is designed to use them well; and at no point have they been a _major_ hindrance. That isn't to say there are _no_ annoyances, though:

- Most websites that support passkeys tend to use them as a replacement for both the password _and_ 2FA, which makes them more convenient. However, a few - Amazon being the most notable I can recall - only use them as a second factor, which just makes them feel a little useless.

- A passkey can _also_ be used as the proof of identity, meaning you can log in in one fell swoop and don't need to enter a username or email address, which is IMO the best showcase for passkeys. Like above, this makes websites that ask you to enter an email address before letting you use a passkey also feel annoying.

- Most web browsers I've used support the QR + Bluetooth flow I mentioned above (otherwise known as Hybrid Transport or caBLE) without issue; Linux has been the odd duck out. Firefox doesn't seem to support it at all on Linux, and Chrome-based browsers do but sometimes are missing what they need and in that case don't show it as an option. Since I sync just about every passkey with 1Password this typically isn't a problem; the exception is the passkey for Apple Accounts, which Apple creates automatically, and (AFAIK) doesn't allow you to enroll your own. Apple Accounts are the only service I've found that does this, though.

- Some websites seem to only offer passkeys as an option if you're on a mobile device, or at least did so at the time of enrolling. eBay and PayPal I think are the two that jump out at me as having done this. Why they did it this way instead of simply detecting if the browser supported passkeys, I have no idea.

All of the above issues have gone down over time, so it's generally been a net decrease in friction over time. And, at least as far as I can recall, passwords themselves continue to be an option in every instance I've enrolled a passkey. So if you like your passwords, generally speaking, you can keep them :P

I have a history of asking incredibly basic questions about the assumptions that are going in to a debugging issue for exactly these kinds of reasons. Something changed somewhere; so have we verified our basic assumptions that things are what we think they are... or did something change under our feet without our knowing? Or maybe we actually have a different understanding of the state of the world, and one of us is actually wrong?

It's not fruitful every time, but the number of times you skip asking those questions and chase something around, only to realize that, actually, it _was_ the ridiculous/simple thing... well, it feels a lot better to realize it earlier :)

(personal footnote: do be mindful of the context you're asking in! I feel like in general those sorts of questions are _fairly_ well tolerated by technical people. Sometimes you feel a bit stupid asking the question, but many of the systems I've worked on are large and complicated enough that it's not that weird - and if there's downtime and a healthy team, people genuinely want to hunt every possibility down. People not used to that, though, will sometimes bristle a bit, thinking you're implying that they're stupid and don't understand the basics. There can be ways to be more tactful, but at the very least, it's worth being aware of that reaction so you can follow up with a "just making sure I understand!" or something like that.)

Given they’ve had several skirmishes with customs and law enforcement agencies around the world, this always struck me as similar to the “don’t talk about installing retail Switch games on the Switch modding Discord” type of deal - everyone knows you can do that, but allowing mentions in official channels opens us to liability and causes nothing but headaches for both us and for customers, so if you’re going to do that, you need to talk about it somewhere else. I freely admit that’s an assumption on my part, though, and I don’t know if there’s something uglier there…?

To be clear, while there is _specific_ language around DEI/gender identity, the actual language of parts of this goes far, far further, and essentially codifies giving political appointees explicit discretion over what gets funded and what conferences scientists with government funds can go to, and disallows any government money to go towards publishing research.

I just finished a video game called 1000xResist this afternoon. There's a lot going on, to say the least - a sci-fi story involving an alien virus, intergenerational trauma, what it's like to be an outsider. It's a hell of a ride, one where certain moments resonated in a way I'll think about for a long time to come.

One of the dynamics is that a character's parents, both of whom protested in Hong Kong during the Umbrella Movement, left for Canada in the wake of the crackdowns wanting to start a family. At a moment when both of the parents are tired and feeling regret, one of them asks why they left, why they bothered to protest, and if those actions had any meaning if the PRC wound up winning control anyway. The other says this:

> ...if we stayed silent? Didn't stand up for ourselves? They would say this is how it always was. They would say this is what the people wanted. But no. They can't say that. Because it has gone down in history that we resisted fiercely. That we fought for a different future until we couldn't.

I admit: ultimately, that statement doesn't mean anything quantifiable - in fact, it kind of states the exact opposite, which is not the most convincing on a site like this. Still, I think there is truth in it: even if the protests don't have a quantifiable number associated with them, people see them, and know that they happened.

Ultimately that may or may not matter; it may just be a sentiment lost in the wind, or papered over by the victors. But it's still _something_.

The reasoning tokens are really just there to extend the amount the LLM can "compute" the problem; put another way, the only way a given model can "think" more about a problem is to fill more of its context with predicted tokens, which has the effect of increasing the accuracy of each token. The reinforcement learning these models go through generally doesn't care what the chain of thought tokens look like (outside of preventing loops/gibberish/reward hacking), only how good the final answer is - so while it does look something like "reasoning" to us and has a rough correlation with the final answer, treating it as actually representative of what the final answer will be or an actual thought process is giving those tokens too much credit :)

…lots of major mail services do?

https://www.fastmail.help/hc/en-us/articles/360060591413-Spa...

https://senders.yahooinc.com/smtp-error-codes/

https://www.xfinity.com/support/articles/email-errors

I would buy this argument if Flash as a browser plugin had been proven to perform well on a mobile device of the time, but it never was, on Android or any other platform.

Even AIR apps - think Electron, an application shell for Flash apps - were on the edge of usable on desktop Macs of the era.

For the first year, Scott Forstall, the Senior Vice President in charge of the iPhone's software, very directly encouraged companies like Pandora[0] to jailbreak iPhones in order to get a head start on app development, protected that community from Steve Jobs' ire, and then used the existence and popularity of jailbreaking to convince Steve that a sandboxed app store would be a better idea than Apple writing every single app for the iPhone[1].

Once native APIs were available, that was true, but before it was even clear that the iPhone would have an app store, they very much did let it flourish.

[0]: https://www.macrumors.com/2021/03/03/scott-forstall-pandora-...

[1]: https://mjtsai.com/blog/2026/04/06/apple-creating-all-the-ap...

re: #2: I'm in this description, and I am anguished by how much I do not like it.

(reference: https://knowyourmeme.com/memes/im-in-this-photo-and-i-dont-l...)

My understanding is that the case was flimsy enough that no "hardcore" lawyers wanted to represent him. It's not just a matter of money; their record (and, therefore, future earnings) are on the line.

At least as of when I left the company, GitHub was being deployed to fairly close to once every 60-90 minutes (the frequency of a deploy train/merge queue batch going out) 24 hours a day, at least during weekdays… there are a fair number of international engineers and deploy trains get crowded during main US business hours, so while there are fewer PRs going out at odd hours US time, there were typically still some. There aren’t dedicated releases as such for GitHub-hosted instances - everything you release needs to be gated behind a feature flag or other mechanism if it’s not going live immediately, and your code either needs to handle the database in both its pre- and post-migrated state, or you need to run the migration in advance of your code shipping out.

Fun fact: it used to be the case that GitHub was actually _less_ reliable if nobody deployed to it… there used to be various resource leaks that we didn’t see when people were deploying all day, since then the app wasn’t getting restarted constantly. After GitHub went down during a holiday break we had volunteers to deploy GitHub once a day during holiday breaks, until the underlying issues were eventually fixed.

Oh, I completely agree. But I admit I'm a bit of a retro enthusiast and preservationist at heart, so I was curious what "mattered" to a rando HN commenter :P

Wow - I remember that from the System 7 days. I thought that was long gone - how did I not notice that checkbox was still there in Get Info this whole time?

Why doesn’t this project “really matter?”

EDIT: For anyone unfamiliar, the MiSTer is a homebrew FPGA project originally built around a Terasic DE-10 Nano that can emulate in hardware a wide variety of consoles and computers, leading to extremely low latency and (often) higher accuracy than most software emulators due to it being easier/more efficient to recreate cycle-accurate effects in hardware. It’s extremely flexible, allowing for both HDMI and analog output (with scaler effects, if desired), as well as both modern USB/Bluetooth HIDs as well as adapters for original controllers. It’s a very cool project and worth checking out if you’re enthusiastic about such things - retroremake.co has had some well-liked clone/re-engineerings of the MiSTer hardware but they’re going through a big shipping backlog so I don’t know when they’re in stock; there were some decently regarded Aliexpress clones as well, but I don’t know what the status of those is. An authentic DE-10 Nano is an option too, it’ll just be more expensive and you’ll still need to get an SDRAM board to run most cores.

Exactly the first thought I had too. I know extremely little about FPGA development, but three things I noticed that came to mind re: difficulty:

- Alex used a Xilinx FPGA, the MiSTer uses an Altera Cyclone - dunno how portable code (if that’s even the right term for e.g. VHDL) is from one to the other. I know the MiSTer has a light framework for cores to plug into to get input handling, scalers, etc.; so maybe it’s more a matter of porting to the framework…?

- Alex mentioned the SCC didn’t have a pre-made FPGA core so they used a real one. I don’t think serial handling would be critical but I do suspect you’d at least need a dummy to get the OS to pass self-tests and boot properly. Possible that maybe the Mac core has already handled this, though.

- What little I know of RAM and the MiSTer would lead me to think the SDRAM card a MiSTer setup typically needs wouldn’t be a problem over the SRAM Alex used, and that either the framework or the wiring of the RAM card handles the details for you - but I definitely don’t know that.

On the plus side I suspect/hope maybe a bunch of stuff from the classic/original Mac core could be borrowed to get it up and running.

There’s definitely plenty of cores that haven’t yet been developed on the MiSTer… for instance there isn’t a color 68K Mac core, only recently have people started on 3D0 and CD-i and Apple IIgs cores, the Saturn core was pretty shaky until a recent overhaul, etc. I think what’s there is just a function of what was either already developed for an FPGA or what had the biggest demand from their respective communities.

I just watched the Vertasium video[1] on ASML's EUV lithgoraphy machines over the weekend, and I think the qualifier they used was "most complex machine _you can purchase commercially_".

I can't remember if it was an ASML representative that said that, or if it was an overlaid asterisk that popped up on the screen at some point - but I definitely remember thinking about the space shuttle and Saturn V/Apollo and those sorts of things before I saw the qualifier.

[1]: https://www.youtube.com/watch?v=MiUHjLxm3V0