in case anyone is curious, yes, it is quite possible to build the solvespace-git package from AUR on manjaro on the #pinebookpro if you edit the pkgbuild arch to be aarch64 instead of x86_64.

#3dprinting

as an aside, I'd really like it if these build-it-from-source distros only specified architectures in packages when there's a technical reason for not trying to compile on other architectures, which should be heckin rare in the world of general purpose CPUs, goddammit.

Follow

@djsundog Every program should just target Z80, and then we'll run an emulator on everything else. Problem solved.

Β· Β· 3 Β· 3 Β· 13

@thamesynne @mdhughes @djsundog This is *literally* the premise behind both the original Tripos/BCPL programming environment, as well as the IBM OS/400 operating system environment.

@mdhughes @vertigo @thamesynne @djsundog I don't agree; CP/M is nice insofar as minimal OSes go, but for not that much more investment in code, Tripos blows CP/M clean out of the water. Real multitasking, virtual consoles, long filenames, true device independence and shell redirection, etc. and it fits quite comfortably in 128KB (it was ported to Data General NOVA, which only supports 64 kilo-words of memory, where each word is 16-bits wide).

@vertigo @vertigo @thamesynne @djsundog 64K (plus a tape or floppy for storage) is all anyone should ever need. Multithreading just means more bugs at once. All files can be expressed in 8.3; folders in later CP/M are a nice improvement, but you can only fit so much on a floppy anyway.

I made a similar flippant comment recently, and I'm really thinking this is a good idea now. Tiny binary images = safe software distribution. Replace the web with Z80 VMs!

@mdhughes @djsundog I've been essentially doing this for years now (though with my own MISC-based architecture, not Z80). I have no complaints with this approach.

Sign in to participate in the conversation
AppDot.Net

Mastodon x appdot.net = fun? A place for former ADN users - on the whole