@freya shit like this is why I mandate that all #Software Packages for @OS1337 be statically compiled, because I'm not gonna bother dealing with #dependencies and if a program can't be shipped as a tarball to unpack & drop in then maybe it shouldn't exist on OS/1337…

• I have #rsync on the wshlist alongside #SPARC support…

@miyuru AFAICT #Ubuntu did drop #ix86 in favour of #amd64 some time ago.

• Personally I do want to continue working on an #i486-supporting distro with #OS1337...

@lymenzies I know that an #i486SX with at least 16 MB RAM is the absolute minimum you'll need to get the 1440kB prerelease image to go brr...

• I've tested #OS1337 both in VMs and on physical devices like the #EeePC701 and #Vaio #P11Z and it runs super-fast on those.

As for #i386 support, #Linux yeeted that with Kernel 3.4.99 LTS & 3.6.9 respectably

@lymenzies Granted the #Wyse3040 has #DisplayPort and there are cheap driver boards that do #DP -> #eDP.

• Using the #iGPU which AFAICT can't be deactivated but only given less shared VRAM" makes adding a different output besides some USB-Serial Console port kinda redundant.

Worst-Case you just go with #MDA output at 80x25 (or even higher if you feel fancy and/or have something better than some tiny 480x800 screen(s)) as #VGA is 100% backwards compatible with with that.

• Tho even if you don't do much in terms of fancy display output, you'd still get some decent output for a fancy shell like #fish... (which I have wishlisted for #OS1337.

In terms of hardware there's an M.2 A+E key slot AFAICS and for PS/2 & VGA you can find ample of adaptors to go from USB and DisplayPort respectably: They don't cost much and I'm confident you won't get better DIY results anyway with limited time and budget.

@mrmasterkeyboard maybe if I can get #PipeWire and #Audio support on #OS1337 working I'd consider something like it for it...

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

@gettie @chesheer Sadly not even #AdelieLinux, which @ActionRetro uses all the time...

I am working on an #i486 distro ( @OS1337) but for #i386 the support in terms of Linux ended with Versions 3.4.99 LTS & 3.6.9 respectably, and my #userland & #toolchain (#toybox & #musl-cross) doesn't support that at all, and I'd propably have more success convincing @landley to join #OS1337 than to support i386 even if I could pay him for that!

@mrmasterkeyboard @landley glad I could get you guys connected then...

I'm convinced #toybox is a good #userland to get a basic OS up and running and on it's feet. If it's good enough for #Android then it's certainly gonna be good enough for #embedded stuff as well...

• After all that seems to be the main goal of it: Allowing "self-hosting" as in building itself under itself if not deliver under the same OS...

I don't leverage that capability with #OS1337 (at least for now) but that's because I treat it more akin to how #VxWorks and #WindRiverLinux is being developed and deployed...

@mrmasterkeyboard @cesarpose case in point:

Just because "My Little Distro" (#OS1337) runs of a single /etc/init file doesn't mean this is the "correct" or "authoritative" way to do it nor that this is scalabe at all.

• Just 'let me cook' on @OS1337 because it's more of a 'learning exercise' rather than "production grade"...

Back to #Xorg: I do think that metux's actions really salted the fields re: #Xlibre and any #X11 releases!

• Granted non-#Linux OSes like #OpenBSD already forked off or DIY'd and now moving towards #Wayland because it is the way forward just by virtue that there's hardware in stores right now that doesn't support #Xserver but Wayland...

@ramin_hal9001 except that's yet another package and yet another config file and thus requires #Guix to support the target system. Which may not be the case (i.e. ancient versions of #Solaris or some #BSD-based distro or some weird embedded linux device...

• So whilst that may be attractive to some (and I don't deny the fact that it has merits) I don't think that me publicly hating #YAML and working on a #GNUfree toybox+musl/linux distro is the target audience of it.

I mean if someone wants to port guix to #OS1337 they are happily invited to do so and I'll gladly accept that contribution, but it's currently not on my agenda...

@HeatSinkAmbassador yeah, but we both can agree that these distros are "rounding errors" compared to the rest just as much as #OS1337 is an anomaly compared to them.

• I don't deny the necessity to have more than 1 option at hand, but I doubt we'll see much of it going to get any foothold...

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

@freya @BrodieOnLinux makes sense, ofc.

• I like SystemD but for #OS1337 had to stick with the classic /etc/init file for space reasons alone.

Tho in fairness I'm shure #SMF did inspire #Apple to do #LaunchD which in turn was copied with #SystemD, abeit all 3 are very much centric about the Kernel and Userland they target.

• Reminds me of that legendary talk "The Tragedy of SystemD"…

@freya @BrodieOnLinux I mean, why not?

• That's the beauty of #FLOSS...

If someone wants to make a "Square-Wheeled Car" then they can...

• I don't expect #OS1337 to get anywhere, because it's more of an exercise in minimalism but hey, I see it as a fun little idea...

Me wanting to do something #GNUfree and going "statically compiled binaries only" is also a bit of "headbanging against concrete" kinda style...

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