@mcc @dalias @whitequark @becomethewaifu

Changing compiler is not the problem. But changing the standard library becomes one. systemd gained problems with #musl because of this.

#systemd

https://tty0.social/@JdeBP/114646325165347305

@gettie @chesheer Sadly not even #AdelieLinux, which @ActionRetro uses all the time...

I am working on an #i486 distro ( @OS1337) but for #i386 the support in terms of Linux ended with Versions 3.4.99 LTS & 3.6.9 respectably, and my #userland & #toolchain (#toybox & #musl-cross) doesn't support that at all, and I'd propably have more success convincing @landley to join #OS1337 than to support i386 even if I could pay him for that!

@FandaSin @cleverboi @BrodieOnLinux @neal I think #i486 is a good baseline because that's the furthest some systems can go!

• And supporting #i386 is out of the question for @OS1337 - unless someone wants to also abckport #toybox and #musl!

https://infosec.space/@kkarhan/114738983433662865

@cleverboi @FandaSin @BrodieOnLinux @neal as for #i386 I understood why cuz it was more and more painful m, but the problem with #i486 is that in several #embedded and #industrial setups there are still newly deloyed systems based off it.

I.e. #Vortex86 #SoC's cuz #MSDOS and shit still gets used in #industrial equipment.

• And #Linux is kinda necessary to keep that rollin'...

Linux stopped supporting i386 with versions 3.4.99 (longterm) & 3.6.9 respectably.

• And unlike with i386 where none of the toolchain (#musl) and utilities (#toybox) supoort it, i486 is still supported there.

And I really want to continue developing a minimalist "rescue" distro that can handle such legacy hardware because it may be the only option to ddrescue stuff from certain systems or to properly & reproduceably backup & restore them!

@mrmasterkeyboard I mean, that's why I chose #musl for @OS1337...

Shoutout again to @landley for making this super easy by releasing the musl-cross - toolchain used for #toybox, making it super easy to just build against that.

@mrmasterkeyboard np.

To me @OS1337 is just an attempt to a minimalist #Linux distro because I want some #reproduceable & #auditable #firmware for various other projects, and both @yoctoproject and #RaspberryPiOS 'lite' seem rather excessive to me.

• Also a proper minimalist #CLI-based #distro that can be used for an "#SSH-#Terninal" does have merits.

I just think that it can have serious benefits being less distracting and allowing me (and others) to just use basically any hardware to get work done...

• The rest of the component selection came because it was either dictated by necessity (Linux has the most driver support and biggest community), alignment with values & goals ( @landley 's #toybox is a clean & minimalist userland) and being better than #GNU stuff (i.e. @musl / #musl) by not bricking shit at random minor updates…

@lmemsm basically the Idea behind it is to be a brutally simple #toybox + #musl / #linux distro that grew out of the necessity for me to actually think about #firmware for some projects.

• And lets just say I did saw @w84death 's #Floppynux and @landley did present a lot of convincing arguments alongside a literal walktrough to get started.

Basically I want something that is so simple and auditable that it's practical to make it pass any #verification demands for #SecureTerminal|s in #CriticalInfrastructure and #Communications.

• OFC one may point at my other projects and say: "Why don't you just put #RaspberryPiOS on a #microSD?" ignoring that the smallest image is >330MB in size and that seems kinda overkill for essentially my demands for a minimalist #Linux with very few programs in userspace.

Not to mention a #GNUfree - #Linux distro is the way to go if I want that thing to not get bricked constantly by minor #GlibC-changes...

• End goal is something akin to #MSDOS in it's brutal simplicity, but way more extendable.

I hope that answers your question...

• Sorry for the delay.

@stman @eff @theruran @50htz @vidak @forthy42 once you have a "#SoftCPU" that can be supported by gcc or llvm as well as #linux, #musl & #toxbox I can port @OS1337 to it.

https://en.wikipedia.org/wiki/Soft_microprocessor

Details on progress in this post to the #musl mailing list: https://www.openwall.com/lists/musl/2025/06/11/1

Actual draft code repo is now up too, at https://github.com/richfelker/musl-uca-draft

This thread by @ariadne on Treehouse's intent to defederate from Fosstodon lays out more details, in more diplomatic terms:

https://social.treehouse.systems/@ariadne/114632131776730666

I (@dalias) have tried my best to engage with the new Fosstodon admin in good faith on what mistakes they're making, only to be met with assertions that their comfort is more important than marginalized folks' safety on their instance. I cannot in good conscience ask folks to maintain a relationship with Fosstodon in order to follow #musl libc updates on the fedi.

@dalias @ska

Well they *are* making their own versions of those two macros. I'd already read the ostensible rationale for it, and it seemed poor.

They have a problem with their own code's headers having lots of cross-dependencies. (Strong coupling and low cohesion: a long-standing #systemd problem.) That's not a reason for fiddling with the #StandardC library, let alone making one's own FILE and DIR macros.

@ska @dalias

I understood Daniel J. Bernstein's avoidance of the Standard C library, especially strings and standard I/O which had been rife with pointer mis-uses for decades.

But this is not that.

Why on Earth would one continue to use stdio but roll one's own version of the GNU C library's FILE and DIR macros?

https://github.com/systemd/systemd/issues/37779#issuecomment-2952813363

@wyatt Also glancing from the #PC98 architecture and specific quirks that #Linux accounts for in menuconfig it's most likely not gonna be enough to "just boot the #i486 version of @OS1337"...
https://github.com/OS-1337/OS1337/blob/main/OS1337-core-prerelease.img

• Tho given the fact this is just a #toybox + #musl / Linux Distro that is barely booting using #syslinux and able to spit out a 80x25 MDA console, it is in an early infancy.

As for the specifics of the #PC9821+ and their detailed hardware I'm clueless beyond the Wikipedia Article and can only Assume anything before a (RAM-upgraded) #9821Ap & #9801BA is off the table and a #9821Af or better is desireable as the 14,6MB RAM limit will really become a problem quickly, as I'm pretty shure it's impossible to get linux-6.6.6 run on anything below 8MB at all and most recommendations hint that 16MB is more often than not a practical limit (tho that may be becaise 10/12/14 and other "asymetric" configurations were already avoided back then)...

• The #9821Ce should be workable in theory tho again that's just me reading a specsheet.

On the flipside I did manage to install #WindowsXP on machines with 32MB RAM and actually get them to display a desktop (abeit with seconds per frame instead of frames per second) so this is more likely a question of chipping down things.

• Worst-Case one could see to build a bootable CD-ROM or dd something on a #BlueSCSI or similar...

@wyatt +9001%

I want shit to be as brutally simple as #C because I can just take #musl, #toybox, #linux & #syslinux and with a few config files make a booting #distro like @OS1337 …