johnklos

One of the biggest problems with CPUs is legacy. Tie yourself to any legacy, and now you're spending millions of transistors to make sure some way that made sense ages ago still works.

Just as a thought experiment, consider the fact that the i80486 has 1.2 million transistors. An eight core Ryzen 9700X has around 12 billion. The difference in clock speed is roughly 80 times, and the difference in number of transistors is 1,250 times.

These are wild generalizations, but let's ask ourselves: If a Ryzen takes 1,250 times the transistor for one core, does one core run 1,250 times (even taking hyperthreading in to account) faster than an i80486 at the same clock? 500 times? 100 times?

It doesn't, because massive amounts of those transistors go to keeping things in sync, dealing with changes in execution, folding instructions, decoding a horrible instruction set, et cetera.

So what might we be able to do if we didn't need to worry about figuring out how long our instructions are? Didn't need to deal with Spectre and Meltdown issues? If we made out-of-order work in ways where much more could be in flight and the compilers / assemblers would know how to avoid stalls based on dependencies, or how to schedule dependencies? What if we took expensive operations, like semaphores / locks, and built solutions in to the chip?

Would we get to 1,250 times faster for 1,250 times the number of transistors? No. Would we get a lot more performance than we get out of a contemporary x86 CPU? Absolutely.

I'm truly surprised that later versions of AIX like 4.3 can't be run on the ANS. How different is the close-to-Power-Mac hardware from real IBM hardware? I wonder...

This reminds me that I need to recap my close-to-ANS hardware Power Mac 9600...

> They definitely could have made avx512 instructions trigger a switch to p-cores,

That'd be an OS thing.

This is a problem that has been solved in the mainframe / supercomputing world and which was discussed in the BSD world a quarter of a century ago. It's simple, really.

Each CPU offers a list of supported features (cpuctl identify), and the scheduler keeps track of whether a program advertises use of certain features. If it does want features that some CPUs don't support, that process can't be scheduled on those CPUs.

I remember thinking about this way back when dual Nintendo cartridge Pentium motherboards came out. To experiment, I ran a Pentium III and a Celery on an adapter card, which, like talking about self hosting email, infuriated people who told me it can't be done. Different clock speeds, different CPU features, et cetera, worked, and worked well enough to wonder what scheduler changes would make using those different features work properly.

A square that's one thousand units by one thousand units doesn't give a rational number, much less an integer one, for the diagonal.

A 9" CRT would never be precisely 9", because beam trace width and height are analog, plus there's overscan, so a 9" screen would simply give something pretty close to 9".

The title is incorrect, because b&w Macs have 512×342 resolution, not 512x324.

It wouldn't've been too crazy had Apple went with 64K x 4 chips, so they'd've just needed four of them to get 128 KB at a full 16 bits wide.

512x342 was 16.7% of 128 KB of memory, as opposed to 18.75% with 512x384. Not much of a difference. But having square pixels is nice.

I don't think software engineers were independently looking at emissions data and unilaterally decided to "fix" the emissions shortcomings in software. I think they were told by others to do that. It's good that Germany is going after the people who decided that fraud was the answer.

Imagine being filthy rich and thinking, "You know what? I'm going to risk going to jail to do illegal things because I'm not rich enough."

Why is this so common?

Mozilla continues to appear to not get the philosophies behind open source. If they really wanted to help people and not simply try to get market share and make money, they'd examine ways to make Pocket itself open source, including the server end of things.

"We're handing this over to a non-profit" would be nice.

Does it surprise anyone that Verizon's Department of Evil would lie, cheat, bribe, steal, or otherwise do whatever it can to not be held to account for its agreements?

I'm not surprised, just as I won't be surprised if Verizon gets their way after throwing a few million dollars in the direction of Trump's "Library" or whatever.

> How long Netatalk will be able to support AFP remains to be seen however, since it too is based on the protocol itself. Since Apple removed native core AFP support from macOS, even third-party AFP products may no longer work.

> AFP has served Apple well. It was simple and easy to use - and it was reliable. But since we live in a TCP/IP and Windows-based world now, it has outlived its usefulness.

What? Huh?

Since when does an open source project somehow stop working because an OS stops supporting whatever the project does?

Netatalk may very well become MORE relevant, because it may be the only way for Macs running the newest macOS to interact with older Macs.

And "TCP/IP and Windows-based"? Is this AI generated slop, or just a really bad author who doesn't understand technology? AFP has been able to use TCP/IP since at lease System 7.6.

Sigh.

It's sad, in part because it brought so many generations of Macs together. I have an iMac G3 motherboard built in to a Tonka truck that runs Mac OS X 10.4 Tiger and acts as a file server and can support m68k machines running System 7.6.1, all the way through Arm Macs running Sequoia 15.5. It's a good thing Netatalk exists!

Considering that we've moved from wire wrapping to being able to design and order multi-layer circuit boards, and we've gone from 74 series and basic PALs to CPLDs and FPGAs that regular people can program, I don't think what tinkerers can do will hit any barriers any time soon.

The ability to recreate classic computing is wonderful, both in preservation of history and in making things available to people who hadn't even been born when these machines were new :)

When I was young, I'd use an AM radio right next to my Sinclair ZX81 to hear what it was doing when it was running in FAST mode.

By making loops of different speeds, one could even make basic tones and crude music.

The video really brought back memories of those sounds :)

This is a very basic article telling people how to install and use rsync, but it's behind a paywall. In other words, it's pretty much useless here.

I really wish Troy would've put a little more thought in to this before deciding to host using a for-profit corporation based in the US that wants to be a monopoly.

Will Cloudflare sell data to US TLA agencies? Probably.

I've seen situations like these before. This is why off-site backups are so very important. I've also been in the same position of providing data from a backup that someone was intentionally trying to destroy to escape responsibility.

This story even hints at a common theme that happens even when people aren't trying to destroy data - that some people will tear down whatever they inherit, then blame their predecessors for the problems that result.

The solution is simple: go back in time and get legislation passed to mandate the release of source code for devices that the original manufacturer no longer intends to support.

That might be imposssible right now, and not just because of the time travel thing. While it's a good idea, and while people are working to get legislation passed that would prevent the forced obsolescence of products by companies requiring, then no longer supporting, public servers, for instance, companies would fight to the death any requirement to make their source available.

But the problem isn't only theirs - open source projects that are steered by corporations often lack the willingness to expend some work now in order to save work decades from now.

For instance, NetBSD moved to 64 bit time on all platforms using clever versioning to maintain compatibility with 32 bit timestamps. They did this on 32 bit architectures, too, back in 2012. [0], [1]

Linux, on the other hand, has no shortage of people who either want to drop 32 bit support entirely or who think that the work to modernize 32 bit support isn't worthwhile (because, in part, they've forgotten that embedded Linux is a thing, and they also don't care about people who can't afford modern hardware). The 64 bit time transition for 32 bit platforms has taken ages, but is thankfully finally underway. [2]

There's practically no hope for corporations. If they aren't given stuff that's already fixed (that is, if the fix isn't already baked in to the Linux they choose to use), they're certainly not going to "invest" resources in fixing things from the past. Heck - it took Google more than a week to fix issues with Chromecasts that came from bad planning. [3]

What can we do? Most people aren't going to decide on a purchase based on whether their product might stop working in 2038 unless we make it very easy for them. We should test more things and point out when products will fail. Of course, nobody is going to care if their wifi device bought in 2025 won't run in 2038, but if someone told you that a $50,000 car's infotainment system will stop working, they might care.

[0]: https://wiki.netbsd.org/symbol_versions/

[1]: https://web.archive.org/web/20200122035908/https://twitter.c...

[2]: https://wiki.debian.org/ReleaseGoals/64bit-time

[3]: https://www.theregister.com/2025/03/13/google_chromecast_fix...

Cloudflare hosts ivesoccer.sx.

Compiling rust on a 32 bit system is a several year old issue. Enough of us made a fuss about it that the rust build system was fixed enough that this became possible again.

If rust doesn't compile on an i386 system with 4 gigs of memory, then that's very odd. I don't know much about rust, but I was still able to get it to compile for earmv6hf on a Raspberry Pi 3 with 1 gig of RAM. Perhaps the OpenBSD people need to try some of the things we've already figured out.

https://mail-index.netbsd.org/tech-pkg/2025/05/09/msg031137....

How does this work? Certain shitty email providers, like Gmail, will consider a forwarding email server the source of spam when their spam filter doesn't like what's forwarded.

Which is why i80386 was dropped even though memory instructions could be prefixed with "LOCK" to make them atomic, so cmpxchg equivalent could be done.

So dropping the i80386 wasn't necessary, and saying it was because of the lack of atomic instructions was an excuse, because the real reason was that they didn't want to keep i80386 atomics around.

You're making my point for me, in a roundabout way. These are handwavy excuses, not valid reasons.

I used to belong to Reddit's r/Diesel subreddit. I own a 40+ year old car with a small Diesel engine, and I hoped to trade advice, parts sources, tips, and so on.

A good number of the posts are about people squalking about "freedom" to "delete" the emissions systems, about how they have a "right" to pollute as much as they want, and some of them even think rolling coal is cool and is OK to do.

I personally take good care of my engine, and in spite of the fact that it predates most emissions solutions by decades, it's well tuned enough that I can't see smoke out the back even if I floor it and wind up the engine. After all, a properly tuned engine is one that properly burns all the fuel you put in to it.

So I left that subreddit, and I'm glad for it. That stupid worldview where we are intentionally ignorant of our impact on the rest of the world is uniquely ugly.

Now on to motorcycles: all those motorcycles with no mufflers or with mufflers that don't do much to quiet their engines piss me off. People claim the noise makes them "safe", but that fails to address the fact that if there were lots of motorcycles on the road and all of them were super noisy, the noisyness would lose all value. In other words, it's a solution that can only help a small number of people to the detriment of everyone else, and can't be applied fairly if more people did it. It's selfish.

Also, gasoline engines run better and burn fuel better with a proper amount of backpressure. All those motorcycles that idle like shit are wasting fuel and polluting the air, even if they don't put out black smoke like deleted Diesels do.

It all sucks. I just wish people would be a little less selfish and less self centered.

The minimum requirements for a portable OS on 32 bit hardware really doesn't need to be anything more than:

* 32 bit CPU

* relatively recent toolchain support

* MMU

* memory, storage, I/O

In the last couple of decades, we've added as a requirement:

* atomic operations

The i80386 didn't have atomic operations, so after gcc 4.1.2, the decision was made to drop i80386 support from gcc. Dropping i80386 from Linux simplified MP code because of the lack of these instructions.

But other than these requirements, what does the i80486 processor not do that newer processors do? People who don't know any better like to talk about the amount of maintenance and testing that's required to support an older processor, but I think most of those people are either repeating old tropes or are misattributing issues. Sure, cleaning up pre-PCI code is one thing, but attributing that to the i80486 is a little misleading.

Do people really sit around and worry about whether their code will compile and run on SuperH, for instance? Heck, no. So does that mean we can't have a modern OS running on SuperH systems without all this testing and maintenance? Well, maybe this "maintenance" is a bit of a myth, because not only do we have a modern OS, but we have many thousands of open source programs that compile and run on SuperH, even without their authors necessarily knowing that SuperH even exists.

My point is that there may be good reasons for a commercial focused kernel / OS to no longer support older CPUs, but let's not buy in to the handwavy BS they use to try to justify the changes. They can be honest and just say they want to clean up and remove things that don't have many users.

Temperature? Really? How does that work?

Your point is taken, but if things are crashing because your CPU is running at 100%, you either have an Intel CPU or you have other hardware problems. There should be no issue running a CPU at 100% 24/7/365 indefinitely.

"This move is part of a broader effort by Canonical to improve the resilience and maintainability of core system components."

Somehow "maintainability" has never been something I'd ever associate with Ubuntu. Is it a reference to their source tree? That'd make a lot more sense than if they were referring to the OS itself.

People who know me know that even though I'm very public (my handle and my email address are my name, for instance), I care about privacy, and therefore it's unacceptable to post abount me on corporate social media without asking permission, just as they also know to not name or tag me.

People who post without asking don't know me well enough to name or tag me, so I don't care.

If someone posted and named / tagged me without asking, I'd have a serious conversation with them about it.

We need to stop acting like others' ignorance gives them an excuse to do things we don't want. "But everyone does it" is bull, and we're doing people a disservice when we let things slide because of that.

Imagine explaining this to someome in 1995:

"In thirty years our computers will have sixteen threads of execution at 4.5 GHz each, with 4 IPC or better, along with 16 gigabytes of memory that can move data at 50 gigabytes a second. Practically everyone will have solid state storage that loads and saves at more than a gigabyte per second. Many computers will have GPUs capable of beating the fastest supercomputers in the 1995 world, and most of that capacity will be used for little more than just pushing pixels to a monitor."

"Wow! I bet Microsoft Word will load instantly!"

"No. It'll take longer to load than Word 5.1 takes to load on an Amiga with an '060 accelerator running ShapeShifter. It'll be so slow that Microsoft decides to load key parts of Office when the system boots, but only if you have more RAM than can be directly accessed by a 32 bit processor."

It's something you'd expect from a snarky article from The Register or from me, if you know me, but I think both El Reg and I wouldn't've quite gotten the full extent of it.

It's a sales writeup:

"Japan unveils world’s first solar super-panel: More powerful than 20 nuclear reactors"

How can a "super-panel" be more powerful than twenty nuclear reactors? By letting salespeople write stuff, it seems.

It's a shame this won't work on VAX.