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.

Comments URL: https://news.ycombinator.com/item?id=35880872

Points: 2

# Comments: 0

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

    Because I’m in a very very blue state and city

Suburban school districts are smaller, have more children (which equates to more funding) and generally have newer buildings and facilities, so they're not in the same dire shape as city school districts. For that reason, you hear much less about them. After all, who wants to write a news story that reads, "Okay, everything is actually functioning as it more or less should?" This leads to a mistaken impression that all school districts everywhere are on the verge of breakdown when in reality the failures are localized to city districts like San Francisco or Chicago.

[1]: https://www.reddit.com/r/Teachers/comments/11620il/the_us_is...

As for applying a delta to the weights, that would likely break the model. It would be like randomly scrambling bytes in a compressed file and then expecting the file to decompress properly.

[1]: https://futureoflife.org/wp-content/uploads/2023/04/FLI_Poli...

[1]: https://usatoday30.usatoday.com/tech/science/space/2006-11-0...

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 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.

    while Java originated the billion dollar mistake

[1]: https://www.infoq.com/presentations/Null-References-The-Bill...

    There, you can $$$ your way out of data corruption. You can even loss all the data if you have enough replicas and backups.

You can't buy your way out of having to deal with the fundamental problem of, "How do I provide the illusion of a single unified system for a highly distributed swarm of microservices?"

[1]: https://en.wikipedia.org/wiki/Fallacies_of_distributed_compu...

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.

The real fear with deploying code directly against production is data corruption. I've seen more than one instance where two pieces of code, both of which had impeccable unit test coverage, interacted in strange ways to cause data corruption, because of mistaken assumptions that their respective authors had about each others' code. This is the kind of thing that you need integration tests to catch. Integration tests need some kind of common environment (even if it is ephemeral) in which to run. And now you have a development environment.

    The only reason Circle isn't bothering with this market is seemingly that they didn't want to deal directly with retail

But I'm willing to bet that they won't, because dealing with retail investors is a hassle. You have to have customer service. You have to deal with additional regulation. You have to deal with random social media firestorms. It's a mess. I don't blame Citadel for leaving it to Robinhood to deal with these issues and I wouldn't blame Circle for leaving it to Coinbase to deal with the retail issues surrounding crypto.

    But that relegates the centralized exchange into the position of being nothing more than a "fiat on-ramp"