0x0203

Many programs are dynamically linked to at the very least, libc. If the system libc is older than what the binary was developed for, it will often fail. Failures going the other direction are less common, but can and do still happen. If the binary was statically linked with everything it needs, you've got a pretty good chance it'll work, but that's a bit harder to do with GUI programs that need to interact with X or Wayland.

I share the same opinion as the author. That said, it's also important to remember that the display devices of the time were different than they are now and the sharp pixelated textures we see now would look a bit different on a CRT from that period. The sharp, gritty look that he (and I) admire would have been just a little fuzzier back then.

I wonder when Linux distros will start shipping 9.0 or 9.1. Even Arch is still stuck on 8.6, despite 9.0 being released two years ago.

Depends on what you mean by active. The kernel has the code in the binary, but on boot it goes through device discovery and initialization, so it doesn't initialize or run drivers for things that aren't present.

There are also architecture specific builds, so the aarch64 build won't include driver code at all for devices that are specific to x86.

What's the size difference between the AFM needle and the area of stored magnetic flux on a hard drive platter? If you used an AFM as a sort of record player, scanning along lines of little pits, what sort of theoretical information density could be achieved over the whole surface of the disk?

It's not mine; just a project I've toyed with a few times in my search for GUI toolkits over the years. Issues and/or PRs can be filed on the github page though.

Seems some of the listed advantages for Janet would also apply for tcl (small/simple, easy to learn, embeddable, usable as a shell, great for domain specific languages). It would be interesting, to me at least, to see a fan of Janet compare the two.

As long as you're taking suggestions, since many of the books are quite old, adding a publication date or date range to the search functionality might be nice. I personally would find it very useful since I have a tendency to look for things that are older than year _x_ when researching various things.

Thanks for all the effort put into the site!

I don't understand this perspective. How can one accept the objectively more user hostile option because the less hostile one gets money from the other. If one objects to using products funded by google, why is there not also an objection to using products from google?

For as long as the funding for Firefox continues, it remains a viable option. And despite all their bad decisions of late, they still give users the ability to configure or disable user hostile components.

Their funding model is a risk, but I've been using Firefox and librewolf forever and I'd argue it's a much better option than chrome or edge, especially with a handful of plugins. A risk is still better than the actual realization of the risk.

I suspect that timing might help Intel here, with so much of the better established foundries near fully allocated for the next two years, it may be more a question of availability than brand name risk. And for whatever problems Intel has, it's pretty unlikely they'd go completely under and disolve in less than a year. Good non completion clauses in the contracts can mitigate a good chunk of the remaining risk.

Not to mention potential customers who would prefer a US based foundry regardless. My guess is that there's a pretty large part of the market that would be perfectly fine with using Intel.

Even PDFs don't always render the same from one platform to another. I've mostly seen it due to missing fonts.