More #inxi / #pinxi CPU issues, it looks like #fedora / #rhel have changed a default standard path in /sys for unknown reasons, thus breaking inxi cpu speed collection. This tripped need to do more refactors, this time to the fake cpu data debugger logic, it was not complete.
Also, a new codeberg issue pointed out that in many #Linux I can get basic RAM/RAM array data from udevadm, which appears to dump some dmi data into itself, available to user.
@adamw@mjgardner@Perl There's a solution to that, which is I believe somewhat acceptable albeit annoying, #Debian#sarge used to use it, around 2006ish? @Perl was only the language, and core-modules was core modules. But as someone who packages for #TinyCore, I can tell you what nonsense such concerns are, in TC, perl, the whole thing, is 30 MiB.
Maybe more uncompressed, I don't know, that's the install size of the binary. Full core modules.
@adamw I assuemed you aren't, but the perl packagers are, and have been, and thus cannot offer a real excuse.
They even pulled microtimers, critical for debugging, out of core modules, it's pathetic.
But they will never admit their error because you can always get someone to rationalize stupid decisions done for stupid reasons. Again, #TinyCore 30 MiB for full @Perl package.
And if someone wants to get a newer version of module, what's stopping them? that was the dumbest excuse I'd read.
@adamw@Perl@mjgardner the core concept appears to be remarkably difficult to communicate. As I said, #tinycore has no problems with this. I'm curious if anyone actually cares about this alleged reason to have newer versions, if they do, you are breaking the entire perl ecosystem to cater to probably a handful of users who could just install the updated versions themselves.
All the workarounds in #inxi were added due to fedora failures due to breaking core m odules over past 3 years.
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 Yeah, I get what you mean, with THICC Distros like @ubuntu having dropped #i686 support half a decade ago...
I do however think that #thinn and #minimalist#Linux isn't just possible (see #TinyCore) but also could be made to work from a single 1440kB 3,5" FDD...
New #inxi 3.3.30 out the door! First release that is #codeberg primarily. Note that all the new data and docs in the codeberg #pinxi repo are not on github, and that's basically all the dev data/docs for inxi.
Here's hoping the #codeberg and #gitea devs can manage to keep the servers running and not have significant issues, I'd like to stay there a while if possible.
The tags were updated on github/codeberg since gh is mirrored to cb, but that won't last forever. Hopefully packagers adjust.
The #Debian/#Ubuntu#inxi packager becomes the first person to package inxi from the #codeberg repos. So the new era is under way, I should package it for #tinycore, maybe I will tonight.
@JohannessNilsson personally, I just wanted to beat #Floppinux and actually make something that is more practical than just existing and spitting out text on screen.
OFC long-term I do want to expand this further and make something that is still smaller than #TinyCore yet also practical to run on my #Atom#Z520-powered #VaioP11Z or any of those shitty #StickPC's and #Trash-#Tablets that have a #Z8300 and just 1GB of RAM and that already felt painfully slow on #Windows8 when they got released.
Doing research on #Linux distros supporting a 80MB memory Pentium 200MHz MMX system that are still maintained and so far only #TinyCore looking viable.