quanticle

Mail delivery doesn't seem to be working, or, at the very least, is considerably delayed. I just sent an e-mail to my primary Fastmail-hosted e-mail address from my secondary GMail, and it hasn't shown up despite several minutes having passed.

No you cannot. Copilot plugins are currently only supported for NeoVim, VS Code, and JetBrains IDEs. Emacs is not on the list.

>ActiveX just had the nice side effect of only running on Windows and IE.

It also had the nice side effect of being the security equivalent of a sucking chest wound. Flash and Java Applets were bad too (c.f. the famous Java classloader vulnerability, which could be exploited by loading a malicious applet), but they didn't seem to be nearly as bad as the horror that was ActiveX. Perhaps it was because ActiveX was intentionally designed to integrate with the host OS, or because it was more deeply integrated into the browser, but my recollection of ActiveX is that Microsoft never managed to get security right for ActiveX, and the way that ActiveX security was "solved" was by ditching ActiveX entirely.

    ATT has provided the best service of any carrier while traveling, so I will use them.

Really? My experience with AT&T while traveling has been pretty awful. In the US, in rural areas, Verizon is better. And outside the US, Google Fi gives you international data roaming as part of the base package. One of the reasons I switched to Google Fi is because it's so much better when traveling.

One of the issues with many of those studies is that they track per-pupil spending and track educational outcomes without actually verifying that the per-pupil spending is actually being spent on pupils. If a significant fraction of the per pupil spending is being spent on facilities maintenance, then the water, so to speak, is evaporating before it reaches the mouths of the thirsty.

I look forward to reading breathless thinkpieces in the New York Times about how "techies" are keeping their kids away from AI, written in the same tone as articles written today about how they're limiting the "screen time" of their children.

I'm not going to respond to your points one by one. My overall response to you is that the system you're describing, with its multitude of RAID controllers, ancient webcam, overclocked CPU, etc, etc, wouldn't even have been possible to put together in the '90s. You'd have ended up spending all your time debugging random crashes and failures, and figuring out how to get stuff working. Whereas today, it's usable and functional and, while it still might have issues, it at least all works most of the time.

As far as the system not recognizing newer processors without a BIOS update, that was also true in the '90s. It's just that, back then, things changed so much, you'd just end up tossing the entire motherboard when it came time to install a new CPU, and you'd "upgrade" the BIOS that way.

When was the last time you had to debug an IRQ conflict? I remember when "Plug and Play" was derisively nicknamed "Plug and Pray". Today, it all just works. When I'm assembling a computer, I don't have to set jumpers. I don't have to fiddle with making sure the boot drive is at the end of the IDE cable rather than the middle. I can just snap all the pieces together like Lego, hit the power button, and be assured that I'll get a bootable system (assuming, of course, that I haven't been a dolt and forgotten to plug the video card power cable in).

When was the last time you had an application blue-screen/bugcheck/kernel panic your machine? Yes, Windows still blue-screens from time to time, but over the past decade, I've found that 100% of my blue-screens have been caused by faulty drivers, rather than application code or bugs in the OS itself. This wasn't always the case. I remember, on Windows 98, there was one particular game that my brother had (I think it was Reader Rabbit), which would repeatedly and reliably blue-screen the machine when we got to a certain level. I haven't seen any errors like that in more than decade. And even the driver blue-screens are getting better. I remember not too long ago, my Windows PC's monitor blinked off, then came back. When I looked in Event Viewer, I saw that the GPU driver had crashed and had been automatically restarted. This is something that still causes kernel panics on Linux and MacOS, but Windows just shrugs it off and keeps on chugging.

With regards to Linux, when was the last time you had to mess with xorg.conf? Wifi drivers? WPA supplicant? I remember when I had to download the Windows drivers for my wireless card, extract the binary blobs, compile NDISWrapper, and then pray that I'd set everything up correctly, before unplugging the Ethernet cable to test whether my wifi was working. Now? I browse Hacker News while Linux is installing, because wifi drivers have been part of the kernel for years.

As for programming tools, they're more stable, robust, and widely available than ever. When was the last time you had to pay for a compiler, interpreter or language runtime? When was the last time GCC or LLVM crashed? Today one can write code in C, C++, Java, Python, Go, Rust, and a plethora of other languages... all for free, even on Windows! This is a huge improvement from the bad old days when your choices were to either pay for Borland or pay for Visual Studio. And as for web programming, do you really pine for the days when your only option for a backend language was a collection of perl scripts in `cgi-bin`?

The one regression, in my opinion, is with communication software. We used to have open (or "open-enough" i.e. reverse engineered) protocols that enabled multi-protocol, multi-platform clients such as Pidgin. That world is gone. Our communications are now siloed into proprietary, hostile software stacks, such as Slack, Google Meet and Teams. And our personal communications are siloed between Discord, WhatsApp, and the multifarious other messenger apps that we have to install in order to communicate with that one person who refuses to use anything else.

But other than comms, has software improved? I have a hard time arguing otherwise.

Is it just me, or does Ed Huang skip over the most important part of database design: actually making sure the database has stored the data?

I read to the end of the article, and while having a database as a serverless collection of microservices deployed to a cloud provider might be useful, it ultimately will be useless if this swarm approach doesn't give me any guarantees about how or if my data actually makes it onto persistent storage at some point. I was expecting a discussion of the challenges and pitfalls involved in ensuring that a cloud of microservices can concurrently access a common data store (whether that's a physical disk on a server or a S3 bucket), without stomping on each other, but that seemed to be entirely missing from the post.

Performance and scalability are fine, but when it comes to databases, they're of secondary importance to ensuring that the developer has a good understanding of when and if their data has been safely stored.