@mrmasterkeyboard I mean, you're way deeper into the weeds than I am, and I guess you're competent enough to find any issues with #toybox and let @landley know about them.

@mrmasterkeyboard If that #kernel is mostly #POSIX-compatible it should be possible to port #toybox over there (alongside any other software one may want to get running on @OS1337), but that's as far as I know.

Not shure if @landley has the time and spoons beyond testing toybox against #Linux as he does aim to make it a better alternative to #BusyBox & #GNUtils.

@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.

@davidgerard problem is that I can't rely on #python being available and being allowed to install it!

• Whereas #bash (or a subset of it as in #toybox) does exist on any #Linux that isn't specifically not having it...

@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 …

@Madic @lmemsm nodds in agreement

Last time I checked #toybox only had su, not #sudo, but outside if #OS1337 I do stick with the distro's defaults cuz they should know best how to keep it as secure as can be.

@kobilacroix nah.

You'd propably find him and Howard doing some weird shit, like an #OpenBSD / #toybox distro or a #DragonflyBSD cluster...

@gettie I know #i386-#linux support was deprecared and #i486SX became minimum spec as per linux-3.4.99 & linux-3.6.9 respectably.

• And yes, the deprecared i386 support and non-support by #toybox is why @OS1337 requires an #i486 minimum. (And frankly, I don't blame @landley cuz by the time toxbox got started i386 was long deprecared)…

@wolf480pl OFC limiting the scope of a project is important.

• I.e. "I don't want to do a #GUI with like a modern desktop for @OS1337 because that'll exceed the desired complexity and sticking to #TUI / #CLI is the best I want to do." is such a scope.

OFC there are reasons why #bash is bash and why i.e. #toybox will most likely only implement a tiny subset of bash in toysh and why @landley hasn't implemented support for .bash_aliases yet [if he'd ever do that considering there are more pressing TODOs than "some hobbyist doodler's wish"...

• Either way I don't fault either #developers for that: I don't pay them for their work so I don't get to tell them what they should do! In fact I'm grateful for their work and that they decided to release it and license it as #FLOSS and not #CCSS...

@gnulinux #Android ist #Linux, genauer gesagt:

#toybox + #bionic / #Linux

@asie wow.

Granted, #ELKS really is a "subset" and can't do much on it's own, but if #toybox was even remotely an option, I'm shure you would've tried that.

@target

@cstross isn't even joking, I think.

Both BusyBox and ToyBox actually do have an init program, a getty program, and a login program.

BusyBox also has the Almquist shell. ToyBox has a Landley shell. BusyBox even has runit.

It is possible to have a system where even if you are doing various things in a shell you're just invoking the same program image over and over, using all of the same code that is there in process #1.

@freya @BrodieOnLinux same with @OS1337 ...

It's #GNUfree-ness is a goal, because it's a #toybox+#musl / #linux distro!

• I just haven't got the time to change it over from #GCC to #LLVM...

@musl Any info if #toybox or #linux are affected?

Cc: @landley @torvalds

@natalie consider it with @OS1337 or like #mkroot (#toybox+#musl / #linux) for 80x25 glory!

@bagder Problem with that is (besides occasional bugfixes), most people including myself would see #curl to be functionally complete and anything "nice to have" would be considered not worth the balooning in #complexity and #size.

• I mean, does curl need to be able to do #BitTorrent (magnet:), #IPFS (ipfs://) or god forbid #blockchain (i.e. #EVM) support?

• Do you really want to integrate @torproject / #Tor support natively into curl when using #HTTP (localhost:8118) and #SOCKS5 (localhost:9050) #proxy allows for the same and doesn't necessitate having to handle and ingest Tor arguments as well??

In fact if #toybox didn't have a #wget implementation that I could use for OS/1337 I would've merely chosen tiny-curl -o as a global alias or if #tinycurl wasn't an option, curl -o instead.

• Maybe someone who wants to have said functionality like tor support built-in will go and IDK make i.e. #neocurl or sth. along those lines or build something like #ethcurl or #torcurlor #ipfscurl or whatever...

That being said I am glad curl isn't solely maintained by you but has other contributors (give them a shoutout!) but I also am glad you maintain that vital software that most "#TechIlliterate #Normies" most likely never heard of but propably use on a daily basis as part of all the #tech they use to #consume media with...

• I consider curl to be "the #vim of downloaders" (tho that's kinda insulting and limiting since curl is more than just a downloader and more intuitive than vim) with wget being "the #vi of downloaders" (tho wget is even simpler to use than vi)...

Either way, curl is awesome...