[bitcompost]

While I love the idea of self-hosting HW and SW, I can't even imagine the pain of building stuff like GCC on 60Mhz CPU. Not to mention the Rocket CPU is written in Scala. I recently stopped using Gentoo on RockPro64, because the compile times were unbearable, and that's a system orders of magnitude faster than what they want to use.

[sweetjuly]

You can definitely go considerably faster. A lot of these FOSS cores are either outright unoptimized or target ASICs and so end up performing very badly on FPGAs. A well designed core on a modern FPGA (not one of these bottom of the barrel low power Lattice parts) can definitely hit 250+ MHz with a much more powerful microarch. It's neither cheap nor easy which is why we tend not to see it in the hobby space. That, and better FPGAs tend not to have FOSS toolchains and so it doesn't quite meet the libre spirit.

But, yes, even at 250MHz trying to run Chipyard on a softcore would certainly be an exercise in patience :)

[shrubble]

People used 50Mhz SPARC systems to do real work, and the peripherals were all a lot slower (10mbps Ethernet, slower SCSI drives) with less and slower RAM. But it might take a week to compile everything you wanted, I agree; of course there is always cross-compiling as well.

[RobotToaster]

That was before everything became a snap package in a docker image.

[musicale]

> That was before everything became a snap package in a docker image.

A modern app should consist of dozens of of docker images in k8s on remote cloud infrastructure, all running "serverless" microservices in optimized python*, connected via REST* APIs to a javascript front-end and/or electron "desktop" app, with extensive telemetry and analytics subsystems connected to a prometheus/grafana dashboard.

That is ignoring the ML/LLM components, of course.

If all of this is running reliably, and the network isn't broken again, then you may be able to share notepad pages between your laptop and smartphone.

*possibly golang/protobufs if your name happens to be google and if pytorch and tensorflow haven't been invented yet

[bitcompost]

Oh I believe in theory a 50Mhz CPU is capable of doing almost everything I need, but it just lacks the software optimized for it. I think a week to compile everything is too optimistic.

[musicale]

Old compilers/IDEs like Turbo Pascal or Think C were/are usably fast on single-digit MHz machines and emulators.

And even if the CPU is 50 MHz, modern DRAM and NVMe flash are very fast compared to memory and storage on 1990s (or older) machines.

Older versions of Microsoft Office (etc.) ran about the same on 50 MHz systems as Office 365 runs today.

[kwhitefoot]

I did valuable work on a 2 MHz Apple II with a 4 MHz Z80 add-on running CP/M that I used to write the documentation. The documentation part was just as fast forty years ago as it is now but assembling the code was glacially slow. The 6502 macro assembler running on the Apple too forty minutes to assemble code that filled an 8 k EPROM.

[musicale]

6502 assemblers are amazingly fast on more recent hardware. Something like 60-70ms to run a script to assemble and link an a version of msbasic (AppleSoft) on my old laptop.

https://github.com/mist64/msbasic

[musicale]

I usually only notice typos after hn has disabled editing... ;-(

[marssaxman]

> I can't even imagine the pain of building stuff like GCC on 60Mhz CPU

Some of us remember what that sort of thing was like, not so very long ago...

[brucehoult]

I remember when I got CodeWarrior on my PowerMac 6100/60 and suddenly I could answer questions online about weird MacApp problems by making a temporary project with their code and compiling the whole of MacApp in 5 minutes.

Previously that had taken about 2 hours (Quadra with MPW), and I did clean builds only when absolutely necessary.

Truly painful was trying to write large programs in Apple (UCSD) Pascal on a 1 MHz 6502.

[nineteen999]

Back then GCC was much smaller, and only contained C code, not C++. But sure, let's compare apples and ... much bigger heavier apples.

[Gibbon1]

I made a meme and sent it to my even older coworker with two guys from the office looking pensive. Titled 'The Build Failed Saturday and Again Sunday Night'

[dwheeler]

At one time many of us dreamed of having a computer that could run as fast as 60MHz. The first computers I used ran around 1MHz. Compilation will take longer on a slower machine, but that really isn't a big deal. If the computer is reliable and the build scripts are correct, you can just let the process run over days or weeks. I've run many tasks in my life that took days or weeks. Cue "compiling": https://xkcd.com/303/

The real problem is debugging. Debugging the process on a slow system can be unpleasant due to long turn-arounds. Historically the solution is to work in stages & be able to restart at different points (so you don't have to do the whole process each time). That would work here too. In this case, there's an additional option: you can debug the scripts on a much faster though less trustworthy system. Then, once it works, you can run it on the slower system.