@BrodieOnLinux@fuchsiii OFC not - and not because they don't want to [tho I'd also nope ransomware groups' demands] but also because #nvidia can't legally do that in many cases, as they too are #licensees of #patents and are bound to #NDA's.
So #GPLv3 and #AGPLv3 are impossible to comply with and even #GPLv2 would be hard to.
Kinda like the shitshow #BusyBox did (gojng GPLv3 and sueing the crap out of license violators), so @landley left that project and started #toybox from the ground up.
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.
@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 I think this is great forward-thinking on your side since OS/1337 should long-term be developed into a robust yet "clean slate" for #minimalist#Linux that isn't as bloated as #Yocto but remains customizeable and flexible.
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 Well, for OS71337 I took inspiration from @w84death 's #Floppinux and took his #documentation and went full "chimp banging rocks together" on it, but swapping #BusyBox for @landley 's #toybox since I prefer #bash over #ash and wanted something really basic that would do more than cat text files but provide i.e. a portable #SSH#client on a FDD.
Something that could serve as a foundation or rather plain "slate for my other projects in lieu of a THICC distro that is not practically auditable
@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.
@rory That being said, Contributions and Feedback is welcome and as per it's #0BSD license you could even go so far as to fork it and put a #NetBSDor any other #unix-esque #Kernel under it if you so please.
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...
For a minimalist system that wants to be a successor to #tomsrtbt and #Floppinux there isn's anything smaller nor more efficient.
After all, I don't expect OS/1337 to be used as a "#Server" in lieu of @ubuntu / #UbuntuLTS or #Debian but instead want to use it as a clean foundation for other projects of mine in need of an #OS.
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'm convinced that it's possible to get a #i486-SX #linux with #toybox and #dropbear into 1440kB since someone managed that with way less optimization and with ample wiggle room [272kB] using Linux 5.13.0-rc2 and #BusyBox 1.33.1 manual and not even halfassing optimization at all.
So yeah I've to look deeper into it and see what I'm missing.
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.
@SweetAIBelle@landley yeah, it's still somewhat broken but it's at least in a booting state where I could see how much #toybox and #dropbear I can squeeze into the rootfs.cpio.xz given the limitations and the fact that it competes with the Kernel [bzimage] for space...
@SweetAIBelle in theory that initramfs and kernel files should boot on qemu out of the box as @landley would've intended for #Toybox / #Linux to do.
I only tested on #VirtualBox out of lazyness and convenience.
The Flopply-Fill - Script should basically shove those files over.
I merely replaced rootfs.cpio.xz with the new file and booted that up to this point, but if you're pedantic you could literally rebuilt the entire floppy image.
I for once only have i686, amd64, arm5r11 (Pi0) & armv7 (Pi3B) at hand and whilst I wish to support all the platforms #toybox & #linux do support, I only intent to gradually add those I can't test on physical hardware based off demand and once I got the entire build pipeline automated to the point that it's merely an argument to pass down for building those.
I do expect that to take quite some time but I happily accept contributions and welcome testers.