@DropBear@serge There is so much wrong with your post that it would take forever to properly unpack... Primarily you are tokenizing Jews via one of the most fringe sects out there. Secondly, you fundamentally do not understand what Zionism is.
I haven't caught up on even important changes in #nixos , #initrd has stopped using #dropbear
but why ? Though?
alternative doesn't sound very cool either
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.
Also nen Kernel samt Netzwerktreiber + initramfs mit notwendigen tools wäre ausreichend...
Notfalls können estimmte werkzeuge entweder von 2. Floppy/CD/USB und/oder online heruntergeladen werden.
Im Notfall würde @OS1337 einfach mit nem #SSH-Server (#Dropbear) autostarten und darauf SSH'n lassen - was für #headless und/oder #retro-Systeme sinnvoll ist.
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.
@landley I'll propably have to gut functions out of toybox to get it where I want it to be, but then again the "#CORE" Version of OS/1337 will be very much barebones....
Just the essentials to get #Dropbear#Client to be able to #SSH into stuff, be able to make a #ramdisk and #wget / tiny-#curl everything else (i.e. a system image one could dd onto a HDD/SSD)...
@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...
Not to mention that OS/1337 should really excel with #transparency and #reproduceability in that the first #release should be completely possible to #DIY from scratch by running a single #bash script that yoinks said sourcecodes, .config files and in the end spits out a working & #bootable#1440kB 3,5" #FDD image.
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)...
@HopelessDemigod The current goal is to get a 0.1 release that fits on a 1.400kB 3,5" FDD and includes #Linux (ideally 6.6.6 for maximum meme factor) #Toybox and #dbclient (#Dropbear#SSH as SSH-Client only) compiled against #musl-cross and bootable on any #i486 and up.
Wow, @linux does actually improve efficiency over time...
I just compiled a minimal kernel 6.5 for OS/1337 targeting #i486 instead of #i686 and the resulting binary is even 10kB smaller than the one for 6.4.12...
For real: That's awesome cuz it allows me to make the #Floppy version for #486SX a reality and still have #Toybox & #dropbear as #SSH client in it...
Cudos to @torvalds and the maintainers for that:
They really did cleanup the codebase and made it #smol|ler!
When I use LUKS to encrypt the root partition on my Linux server, I need to supply the crypt passphrase at boot to unlock the system for startup to continue and get to login. That's OK if I'm sitting in front of a keyboard and display. But what if it's a headless server or located in a remote location?
This HOWTO is dated 2017 but can confirm it still works today using Debian 12. It was so helpful getting the wireless interface setup on my home server initramfs so that I could remotely unlock a LUKS-encrypted root partition using Dropbear: https://www.marcfargas.com/2017/12/enable-wireless-networks-in-debian-initramfs/
OC My Current Daily Driver