Good news: Network Support is in it.
Status: Still within #1440kB size for the #Core Edition.
Bad News: PCI(e) stack had to be yeeted in order to fit, so no #Networking in #VirtualBox
I'll now have to get my workflow to follow the pipeline that @SweetAIBelle has been builing...
This might sound silly, but I installed virt-manager to make things a little easier when using qemu, then created a new virtual machine with debian 12 on it... then installed qemu on that.
The actual reason for this is to make github account separation a little easier...
If you get virt-manager set up properly, it definitely makes using qemu easier, though. I practically just had to tell it to make a new virtual machine using this iso with this much memory and this big of a hard drive, and it was right at the debian install screen. (Set it up with xfce...).
Main tricky parts were that I had to install libvirt first, make myself a member of the libvirt user group, enable the service, and install dnsmasq. Not great, but could've been worse...
Used debian on the virtual box just for a little variety. I like to keep my hand in on different distributions a bit.
But speaking of OS/1337, i really need to get crackin' on those open issues and start using the reworked scripts of yours so my old mess can get yeeted sooner than later...
@SweetAIBelle Ideally we'd end up with something more featureful than #toybox's #mkroot when it comes to OS/1337.
Like a more modular configureability for targets and native- & cross-compiling, where supporting a new architecture/hardware is as easy as plopping in a profile with configs (plus i.e. necessary drivers / firmware not included in the kernel) into a folder and kicking off the build pipeline to generate a bootable image to dd onto a drive…
Thanks again to @SweetAIBelle for extensive contributions to OS/1337, making the pipeline and scripts to reproduceably build OS/1337 images and it's parts more flexible and nifty.
@SweetAIBelle After all, I think that longterm OS/1337 should provide a simple yet versatile basis to expand to arbitrary complexity if desired, offering more features than @landley 's #mkroot since I'm convinced that a package manager [ https://github.com/OS-1337/spm ] and accompaining repository [ https://github.com/OS-1337/pkgs ] is obviously out-of-scope for the backbone of #Android, where everything interactive is ment to be on the fancy GUI layer for good reasons...
I've been re-reconverting a lot of my "stuff" to the BSDs (Free, Open, Net). It's refreshing. The Linux every-tool-has-to-be-a-swiss-army-knife ethos is exhausting after a while. The relative simplicity and clean organization of *BSD (especially OpenBSD) re-affirms my fondness for UNIX-y things.
You might think there's not that much difference but, in many cases, I'd rather admin a BSD box. Try it, you'll see.
Also, NetBSD is soo lean, it has made my old Pentium III almost useful again. Even with 333Mhz and 128 MB of RAM 🙃
@rory Since then @SweetAIBelle and I have worked on OS/1337 and whilst we have some booting prereleases, I want to iron it out into something that works and that is easily extensible and "build from source yourself"...
Tho #OS1337 is not to be confused with @landley 's reference implementation of a #toybox + #musl / #Linux distro that is #mkroot, which is close to but not identical to the foundation of #Android, but exceeds my space requirements.
also #gzip is the lowest common denominator of #compression on #linux, so it does make sense given that #toybox aims to provide a good yet space-efficient userland, even if that means i.e. vi instead of neovim or ne.
And given that #mkroot is a minimum viable product of a complete toybox/linux distro that is able to reproduce itself from source, it's inevitably going to be big.
A "self-hosting" distro that fits on 1440kB is very likely impossible...
Oft gibt's genug legacy zeugs und so gern ich's los werden will, so sehr ist's oft notwendig.
Auch wäre das nur das "Minimum viable OS" und natürlich würde ich das ganze sowie das abgeschlossen ist weiterentwickeln zu einem brauchbareren System mit mehr Optionen. https://github.com/orgs/OS-1337/projects/1
My quest is to see if something like #tomsrtbt can be done with modern versions of #Linux & #toybox.
I know #mkroot is meant to show a full #musl + toybox / linux system for each supported architecture without sacrificing features and drivers along the way whilst retaining readability and reproduceability.
I'll take notes later and see how much I can trim toybox too without having useless system...
In theory cat, dd, echo, ls, poweroff, reboot, sh / toysh, ip / ifconfig / ipconfig & wget should be sufficient.
Then just dbclient...
But yeah, minifying kernel is far more pressing then the xz compression of the rootfs is very efficient and not bottlenecking me, but the Kernel balooning is.
Espechally since in terms of Hardware it makes more sense to [me to] optimize per-architecture [I've not seen VIA or AMD NICs on an amd64 or arm5r11 system]...
Granted the #i486 version is my primary target since it's the one most desperately in need of something like OS/1337 and I can't commit the time necessary to support more as I've got € 0 in funding so it's not as if I can quit my dayjob to commit fully to it.
It's just that I intent OS/1337 to be a starting point for something wider in scope long-term than being the most frugally possible Linux that can compile itself and act as basis for the underlying #toybox/Linux that powers #Android.
But maybe my toybox .config is also dysfunctional as I basically gutted most functions out of it since I only want to launch #dropbear#SSH Client (aka. #dbclient)...
I'm trying to play with SH4 CPUs in a few set-top boxes I have. This is difficult as the whole STLinux FTP server is long gone.
If you, or anyone you know has these files:
@gorplop right now I'm still working on getting like a 1440kB 3,5" FDD relese (version 0.1) for #i486-SX done but in theory everything should just cross-compile to #SuperH 4 / #SH4...
I just wanted to make something more practical to use than #Floppinux whilst also making something a bit more versatile than #mkroot.
Kinda going from @landley 's #mkroot and working towards building something that is actually useable and not just some EoL tool (i.e. #tmsrtbt / #TomsRootBoot) or a simple test of feasibility (i.e. #Floppinux which uses #BusyBox instead of #toybox).