I'm very surprised it's organized as just a single 162 kB source document instead of being divided into smaller modules to make the code easier to work with, speed up build times, etc.
Were PDP-10 text editors of the day able to easily work with such large documents? And how long would it typically take to assemble all of that code in one go?
I don’t think TECO is inherently bad for this size of file. What might be tough is, if anything were compute-bound, and the processor were loaded down with other jobs, you could have the usual timeshare-related problems. If you wanted to look at a chunk of text, it would be a problem to send it to your TTY.
If you were using a KA10 variant, your process could get evicted pretty easily because the core memory requirements of all the running jobs had to be less than 256K words. The variants with paging would have a more efficient method for virtual memory.
Compile times would be affected by the same issues.
While it's true that early production machines had reliability problems, the same was also true for the C64. The machine we got for xmas 1983 was as solid as a tank.
The tapes were extremely robust and resistant to abuse, much more so than floppy disks. I tried to fry tapes, and couldn't.
For games, the tape drives were surprisingly effective. Sequential data transfer rates are faster than the C64 disk drive, and unlike the C64 they operate independently from the main CPU, with DMA access to the full 64 kB address space.
This means that many games were up and running in seconds and could load upcoming levels in the background while you were playing the game.
(The tape drives were much less effective for random-access, file-based storage, as the seek times were obviously atrocious compared to a disk drive.)
First-party software was also very high quality.
The problem was the business plan. Coleco made the same mistake as Atari and Texas Instruments, in that the business plan was modelled after the game console business. The tapes were expensive and proprietary when they didn't need to be, and the 3rd-party software ecosystem was completely locked down. Technical info was unavailable for hobbyists and independent developers.
By the time the Adam is released, the C64 and Apple IIe are already entrenched in the home markets with exponentially expanding library of independent software. The Adam's locked-down ecosystem couldn't complete.
It only took one year for hobbyists to completely reverse engineer the Adam, at which point some interesting independent software starts to appear. But by that time the business was already dead.
> Sequential data transfer rates are faster than the C64 disk drive
The C64 disk interface is notoriosuly broken. The C64 and the 15x1 drives effectively had the same relatively fast processor but with a tiny pipe connecting the two.
It's not odd at all for a machine that was designed in 1976/77.
However, for a machine released in 1983 (the Apple IIe) it is indeed very odd. But the IIe is an odd machine in many ways.
The Apple II platform stagnated as Apple poured all their resources into the Apple III (which has all those features and much more).
The Apple II refused to die, so Apple assigned a pair of engineers to design a cost-reduced version of the Apple II, and this became the IIe. The goal was only to minimize manufacturing costs, so the new features like timers were off the table.
The IIe became an unexpected smash hit in the home and education markets (stealing those markets from the 128k Mac), and only then did Apple devote some new resources to the platform (and reposition the 128k Mac as a laughably underpowered productivity machine).
The Apple IIc (1984) was the first Apple II to get a proper modern makeover. Of course it was a flop, while the odd-ball IIe continued to fly off the shelves.
This game achieves its smoothness by synchronizing to the video refresh. That's not a particularly challenging thing to do, but it wasn't a viable option for commercial games back in the day due to uncertainty of how to do it properly across the different Apple II models.
Apple added VBL polling with the IIe in 1983, and then broke it a year later with the IIc. And an unfortunate typo in the IIc technical reference manual meant that developers couldn't figure out how to do it properly.
The only official, cross-platform way to do it was through the mouse firmware, but most users didn't have the mouse hardware installed.
This game uses the mouse firmware, if available (II+ w/ mouse card, IIc, IIgs), to generate VBL interrupts. On the IIe without a mouse card, it polls for VBL.
By the way, if you're running this game on the Virtual ][ emulator for MacOS, be sure to disable the mouse card. Its emulated mouse card only generates VBL interrupts at 30 Hz, so the game runs at half speed.
After Google Reader shut down paid for Feedly for a while before switching to self-hosted FreshRSS. (https://freshrss.org)
I'm not a web guy and I detest all forms of system administration, but I had no trouble setting it up on my host. I've got it configured to update its feeds one per hour from 6AM to 8PM. It just does its thing, and works fine on both desktop and mobile.
I did not have internet access at the time, but it was possible to order contents of this newsgroup on floppy disks from the national HP48 user group, I think they were located at Chalmers university in Sweden. This was my first encounter with the internet, around 91-92-93, browsing Usenet posts from snail-mailed floppy disks.
There was lots of useful software written for it but I was totally blown away by the accuracy of the Phoenix port. Obviously, the graphics couldn't be replicated but even that was well done given the hardware limitations. The game mechanics were pretty close to the original.
it literally says it uses global search index on the label below the check mark. It seems more than likely that (now or at least in the long run) they will use user data to enhance this index.
It's funny how one can use "literally" while almost demonstrating illiteracy.
It's right there in the help text:
> Allow this device to privately match places in your photos with a global index maintained by Apple so you can search by almost any landmark or point of interest.
They are saying that they match your photo against their global index.
They are not saying that they will add your photo to their global index.
It sounds like you're arguing against passkeys, two-factor authentication, and password managers.
Do you use single, easy-to-remember plain-text passwords for all of your accounts and services? If not, you need to understand what the recovery process is when your passkey/2FA/pw-manager is unavailable or lost.
GP doesn't seem to mention password managers. The nice thing about password managers vs passkeys is they need not be locked to a particular device or platform. I can sync the same database of credentials between my phone, pc, and laptop without worrying if they are from the same vendor. I can export backups. I can access it through my personal website on any device (assuming I also remember my personal website login too) if desperate.
The problem with passkeys isn't the concept, it's the lack of flexibility in implementation.
This prompted me to read more about it as I was quite certain this was the reason I had stopped using them. It seems the initial wave of complaints fed into some change about a year after the initial launch. Android 14 (Oct 2023) via the new Credential Manager API and iOS 17 (September 2023) when 3rd parties could actually be a registered passkey provider.
I've been using them with my BitWarden/VaultWarden setup now for a while. I was also extremely crabby about the idea of tying my accounts to hardware to the point of being unwilling to use them, but this problem is resolved. The resulting user experience is now the best of any login methodology and I remain in full control of my passkeys, up to and including the ability to back them up. I think it sometimes takes a "Never Offer Me Passkeys" from the browser sometime, just like they default to trying to get me to save my passwords into their vaults (and I always have to look up the magic setting to tell them to stop doing that on a new install), but it hasn't been that hard to make work.
I think I've heard that the passkeys providers have an option to force it to be hardware, but I've yet to encounter that, and it would also make me quite cross without a very good reason. I, personally, do not want my accounts tied to any particular bit of hardware, I want it tied to the single (very!) strong password I use for everything.
Edit: Browsing through the rest of this HN conversation it seems the password managers have some PR to do. Many HNers are not aware that password managers, even perhaps the one they are already using, have the ability to store passkeys in them. If HNers don't know, certainly outside of the HN bubble it must be even less well known.
The passkey pitch needs to incorporate this. Last time I paid attention, which was a long time ago, passkeys were non-portable. This is a deal breaker for me, so I wrote the whole thing off. I guess they fixed it.
> I think I've heard that the passkeys providers have an option to force it to be hardware, but I've yet to encounter that, and it would also make me quite cross without a very good reason. I, personally, do not want my accounts tied to any particular bit of hardware, I want it tied to the single (very!) strong password I use for everything.
If the functionality is built in, don't be surprised when they alter the deal and force it on you. What are you going to do if no one lets you use or migrate back to a username / password at that point?
We've seen the same thing thousands of times from big tech. They give us a system that's tolerable, but designed to leverage us into a bad position in the future. Once there's a critical mass, they'll flip the switch and we'll all get screwed.
I'm not sure that the big players have a motivation to force us to hardware. If anything, a lot of these entities will be happy to not have you forced to hardware because it's a support headache when people lose hardware.
(Also, be sure to understand that being forced to hardware is not "you must use a phone"... it is specifically "this passkey is locked to this Yubikey and can not by any means be moved to any other device". I don't think we're going to be stuck on that. Plus I haven't dug into the protocol but I'm not sure anything stops BitWarden from just claiming to be hardware.)
That said, my eyes are peeled, and at the moment the momentum is in the other direction, in that they actually headed away from that.
It surprised me too since I thought the whole point of passkeys is that you're using a thing-you-own to authenticate, but really the whole point is that the security credential is never transmitted to the service doing the auth.
That’s not the (entire) point of passkeys/WebAuthN at all!
It’s a pretty powerful/complex spec allowing various use cases, from a modern way to store SSH keys on hardware credentials to a more usable and less phishable password replacement backed entirely by software.
I use them for a bunch of things on a bunch of different devices/OSes and one light frustration I've had is I've accidentally stored a few of them in different apps because I'll be on a different device and either not have access to an app that I usually put the key in (1pass) or I'll mistakingly hit a "save passkey" that Windows, or Chrome, or whatever pops up. I've had to go in a few times and change my devices.
I think this is because it's so new with these apps. 1password acts really strange with them sometimes and my chrome extension will lock up or not actually push the passkey through or whatever it does. Sometimes I just get annoyed and throw it wherever worked.
When they're flawless they're awesome. I don't mind the quirks right now.
Various password managers. They're just private keys. Optionally you can use a private key that is kept in a secure enclave on-device, these would not be synchronizable.
And how do you protect the password manager, with a passkey that needs to be stored in another password manager, or with a password with all the security risks that come with it?
I use easy to remember plain text passwords for services that are low risk. It's a spectrum. I'm not concerned about someone hacking into my Hacker News account for example but I am very concerned about someone breaching my bank.
Were PDP-10 text editors of the day able to easily work with such large documents? And how long would it typically take to assemble all of that code in one go?