@blinry @b0rk

You really should tell the #BusyBox people about that C bug in the feature autodetection.

I recently had to update a whole lot of K&R code (written a decade after C89) for similar reasons. I even had a similar autodetection break.

C99 has and C23 is even more going to hit a lot of old codebases where people wrote things K&R style, sadly in the cases of many of them well after #StandardC came into existence.

@katyswain I din't think that #CCSS is good either, but the demands of #GPLv3 are not compatible with the (adnitteldy shitty) reality of how #IP, #Licensing and #Patents work and thus it kneecaps a lot of things.

• GPLv3 caused #Apple to freeze their #bash version and divest into #LLVM and adopt #zsh.

• As @landley showed, enforcing the #GPL(v2) resulted in exactly 0 code being committed to #BusyBox and it only made said project look toxic and litigatious.

• Also i've yet to see anything happen re: #paywalled #SourceCodeAccess for #grsec & #RedHat #Linux. Maybe #GPLv4 will ban #paxwalling and force violators to work on #GNU / #HURD?

I chose #0BSD for _OS/1337 because as with any "intellectual labour", one cannot force others to collaborate and I'd rather have people join in out of the goodness of their hearts instead of just dumping some random git commit that is useless.

@santi @mos_8502 @Wintermute_BBS well, as for #GPLv2 and license enforcement, using #copyleft as a bat to club corporations with isn't effective.

@landley still feels remorse for having started that with #BusyBox.

Not to mention #GPLv3 & #AGPLv3 really is bad unless one wants to commit "asset denial" aka. be an anticompetitive dickhead and at that point it's close to "asshole licensing" of #SSPL & #RSAL!

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

@burnoutqueen the problem is that #enforcing #copyleft doesn't get you a single line of code improvements.

• Ask @landley and his successor(s) that are now maintaining #BusyBox.

In an ideal world it would, but we all know that's not the case.

• Consider #BSD-licensed alternatives a competiton, which is more likely to get contributions back (again, Rob Landley can most likely attest to that) from corporations and see it as a motivation for copyleft-licensed projects to step up their game!

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

@notjustbikes precisely!

Only #OpenSource & #OpenStandards can yield #MultiVendor & #MultiProvider systems necessary to prevent #monopolies and #oligopolies and enshure #ITsec, #InfoSec, #OpSec & #ComSec, thus being able to comply with #NatSec & #IntlSec demands.

Guess why #NORAD runs #BusyBox / #Linux?

• Because they demand every single line of code to be audited MANUALLY!

@cas TBH, this actually makes sense in some #CriticalInfrastructure when someone wants to finally replace some #MOS6502-based system and chug a low-end SBC in...

And given it targets #BusyBox, I'd not be surprised if #NORAD is already looking at the code to see if they can use it...

GOOOOD NEWS EVERYONE! (/ref)

#Bim (although not in #Kuroko fully but still uses Kuroko to an extent) and Kuroko itself work in #Musl on a bare kernel! I'm only using #BusyBox and util-linux (which are the only non-Kuroko tools)! Everything including the #Linux kernel is compiled to Musl.

I'm calling this Lunaris. Yes I reuse names from failed projects of mine a lot. This is very volatile. One wrong move and I need to remake the rootfs or the disk image or packages... I hate it.

@AugierLe42e I assume that port is fixed to a specific USB Hub / Controller / Port and the button is similarly linked to some GPIO / I²C / PS/2 port...

• What you can do is check lsusb for #USB devices and see if the specific port in question has a USB mass storage device or SATA bridge chip attached to it when said button is pressed.

If #QNAP used #Linux they should've provided those drivers / scripts as part of their #GPLv2 obligations to buyers/owners of said #NAS boxes.

• Just don't expect any of that code to be useable, as @landley can attest from the #BusyBox license enforcement…

Either way if you can reliably identify the port & detect the button presses that should be sufficient to build like a #bash or #python script to basically detect the drive, mount it and cp -r /dev/$DRIVE/ /home/copied_drives/$LABEL/

• It may need some fiddling and will most likely only work reliably on unencrypted drives with ext2-ext4, btrfs, ntfs, fat32, exfat filesystems...

Pretty shure you'll have to tweak a bit unless you want to use /dev/by-uuid/$UUID and the UUIDs of the partitions as name...

@reallylazybear
#Alpine has a massive community behind it thanks to its usage in #Docker and other #container based projects. That would be my go to.