- This topic has 33 replies, 6 voices, and was last updated Jul 31-10:29 pm by h2.
-
Posts
-
h2
Hi Brian, nice to hear from you too! I’ve recently been making my inxi.changelog much more user friendly, you can find it on github inxi, it’s cleaner and better organized now. I was amused to see that the inxi -Ca feature was actually primarily developed with Antix users, I can’t remember if they asked for it, I think I’d been thinking about a cpu mitigation / security report for a while before implementing it, so I suspect it was a basic issue/feature request someone made, then I realized how easy it wast to implement, and with antix samples, antix forum support, etc, we got that one done.
I agree re what I consider ‘newer’ vintage thinkpads, I actually asked over at thinkpad forums https://forum.thinkpads.com/ way back when before upgrading from my trusty but annoying [that oscillating cpu fan speed bug, lol…] and failing t42 to the t400 series, I was warning away from t430,440,450 due to keyboard issues, but 400 [still has the tall rectangular ‘classic’ size screen], t420, has the wide but less high screen, are very good, and rock solid. Batteries are the main issues there. but ssds, from intel, crucial, samsung, are cheap [avoid the weird brands for ssds, it’s not worth the few dollars you save – warranty time shows all, 5 years is what I look for] per GiB now, that generation ram is cheap if you get it used on ebay, as long as the laptop is working, it’s going to be fine. Old spinning metal disks however are literally way past EOL at this point, and laptop spinning drives were always terrible anyway, so I consider a spinning drive in a laptop now a no no, ssds in 250-1000 GiB are just too cheap to warrant trying to save a few dollars there, plus the ssds are so much faster, and you don’t have to worry about banging the laptop and breaking the spinning hdd.
It took me a while to realize that when people asked my advice re what laptops to get, there was no point, since the only laptop I’d personally get is a thinkpad anyway, at that point, it just comes down to which one. Avoid ideapads, I had the misfortune to volunteer to work on one of those, thinking it would be that rock solid guts/mechanics of a thinkpad, it’s not. I find going to thinkforums to ask what thinkpads to avoid is generally worth it if I’m looking at a newer generation thinkpad and want to avoid known issues.
check out the new inxi, it’s at 3.3.06, it’s gotten kind of, cough, how do I put this politely?… feature rich, lol. Lots of useful stuff, particularly for support, -E/–bluetooth took several iterations to get useful for support, but as usual, -v8 will show everything, including the kitchen sink. Raid/lvm support, and fixing some longstanding issues with wrong disk used percentages, required doing a full internal refactor of all mounted, unmounted, disk, raid, lvm modules. Also has hugely upgraded bsd support, with a focus on openbsd, which I like, and freebsd, which I’m less fond of after doing a lot of work on it over past months.
inxi system information script (install info) :: inxi git
anticapitalista
Wonderful to see you here again h2!
For those that perhaps don’t know, h2’s inxi/smxi/sgfxi scripts have been part of antiX for at least a decade (maybe longer).
Have a look in /usr/local/bin for such scripts and you’ll see them even in antiX-21!Philosophers have interpreted the world in many ways; the point is to change it.
antiX with runit - leaner and meaner.
Even as time goes by, we continue to have a similar outlook. As far as “feature rich” software, as any software “gracefully ages”, it is the exception, not the rule, for the “mid section” to grow. Some people refactor and rewrite software. That only goes so far and then the same happens. You’re in good company with the vast majority of GNU utilities. Some of the finest GNU replacements for the original UNIX utilities are often 2-4 times larger than what they replaced, mostly because they have so many options and additional capabilities. It’s not all bad; there are many really good tools, but there are not very many “single purpose tools” available any more.
inxi actually has hit a few key points:
1. I knew for at least a year or two or three before the Perl rewrite from bash/gawk that trying to have this complex data/logic run via gawk/bash was clinically insane, I knew this because I actually feared working on most inxi features of any complexity at all. I would usually have to psych up for weeks to just approach working on bash/gawk inxi because it was so painful and difficult. I also knew nobody in their right mind would ever take it over. I’ve been tempted to warn some smaller cross platform sys info tools to not fall into the bash trap, but they did, and can never escape. I also had a very real fear that at some point, bash/gawk inxi would literally just not run as it got bigger, or take so long to run that it would become useless.
2. rewriting it to perl, which mostly involved translating the bash/gawk logic into perl, sometimes almost directly. Some of the most directly translated logic proved to hide the most tricky to find and fix bugs, so I’ve tried to dump as much of that as possible when I come across it, I can almost always recognize it as a direct translation because it makes little logical sense, unless it was from bash/gawk. That’s logic that was created to work around the weakness and badness of bash+gawk.
3. refactoring that rewrite over the last year or so into better perl, as my perl got better. that is still ongoing, but most of the biggest stuff is done. Hint: perl is technically fastest when you use the most perl type expressions and logic and syntax, so I was able to pick up a lot of speed/optimization by switching to the more native perl syntax, I’d avoided that since it’s very hard to understand until you get used to it. Native perl using tested/optimized perl syntax is FAST. It’s not uncommon for me to gain 5% total execution speed just by switching to better logic/syntax internally, though most of the low hanging fruit is done, the remainder generally involves making the code less readable.
4. moving away from some code shortening tricks I’d used to avoid having inxi get too long physically, those always bite me in the butt in future changes/updates, so I’ve started unraveling some of those. My newer preference is to put raw execution speed first, unless it conflicts with readability/maintainability, then readability.
5. Because I wasn’t very good at perl when I started the inxi perl rewrite, I tended to use a lot of copy and paste code bits, without understanding them, which led to using different methods to do the same thing, which leads to super hard to read and debug code, so now I always use the same, and have moved most of those offenders away and made most code use standard efficient native perl, not the more conceptually easy to understand but more inefficient methods I’d used to avoid learning the ‘right’ way to do it. Array/Hash references in particular were a big stumbling block, they are hard to really understand so I avoided them in the initial rewrite, except when I accidentally used them in copied code without understanding them.
Perl users have a super annoying, and totally wrong, expression, TMTOWTDI, there’s more than one way to do it. Perl encourages this, which is a big reason perl got hte reputation for creating write only codebases. Also, by doing some intensive optimizations using real optimizer tools, I learned that consistently while there might be technically more than one way to do something, there usually were only one or two ‘good’ or ‘right’ ways to do it. Then a few years working with this codebase taught me that further, there’s also really only a handful of ways to write perl code that is easy to work with over time.
6. The truism that well refactored code always opens more possibilities, and never closes any, seems to be a rock solid principle of coding, I have never found any time where a refactor did not make it more robust, more powerful, and easier to add support for new situations. And I likewise have never found any time where not doing a refactor when required made anything better.
For a while I was fighting the code expansion, but now I gave up, with Perl, it really doesn’t matter as long as I avoid falling into some traps that can lead to something being literally 700x slower to do than another way involving a bit more code. An odd thing is that despite perl users pointing to perl modules as great tools, I’ve found in many cases, using them is far worse/slower than coding the stuff directly, it also keeps the dependencies down, which is always critical for inxi, which is supposed to run anywhere. In fact, I just got some bugs fixed from an issue report I got where the guy tried running it on debian sarge or etch, I forget which, and it had all these bugs, which are now fixed, lol, so inxi runs as intended on 15+ year old os/hardware, and it will run on brand new hardware with Perl 7, when that is released.
The inxi to perl experiment was a total success, I never fear working on it anymore, it’s easy to do, and as my Perl gets better, so does the code since I’m always refactoring stuff when it causes roadblocks/obstacles. Maybe the downside is that I don’t fear the codebase anymore, usually it’s just too easy to add stuff, in fact, during covid lockdown, I checked off some longstanding feature requests, bluetooth, lvm, etc, which were HARD to do, and would have been impossible to do with old bash inxi.
I still test inxi on a 200mghz laptop with 192 MiB ram, running I think debian lenny, optimizations are super obvious on that system since they can knock off literal seconds. For normal optimizations, I tend to do things that will result in 0.01 or more seconds improvement since those tend to a dd up over time, particularly in loops/repeated tests. I’ve tended now to toss more and more data into ram to speed it up, since inxi only needs to run once in a while, how much cpu/ram it eats up isn’t really relevant, though I do wince when I see it using something like 32MiB to run, lol.
But it’s been reasonably fun, except for annoying github issue posters, but that’s life, script kiddies demanding dumb features are always going to be annoying, otherwise it’s overall been pretty pleasant.
Re small single purpose tools, I think I tended to try to get to that point, but then over years I realized that all the fixes required to handle diverse hardware/os/software scenarios were impossible to handle while maintaining simplicity, so I don’t even fret about that anymore. I see a few not to be mentioned light sys info tools fail to handle some scenarios that inxi handles easily because they are trying to be too terse and clever in their code, and that results in the code being unable to resolve or handle some corner cases. I don’t think inxi has any code or internal complexity that weren’t required to handle real data/user/os/hardware situations, and I try more and more now to add in comments to logic that doesn’t seem to make any sense to explain what it handles, why, so I don’t accidentally refactor it out in the future.
inxi docs are also now much better, though inxi itself, actually pinxi, will always be the primary reference, but the docs are a lot better, that’s to help me too, and to avoid cluttering up inxi with urls and links to resources etc.
- This reply was modified 1 year, 9 months ago by h2.
- This reply was modified 1 year, 9 months ago by h2.
- This reply was modified 1 year, 9 months ago by h2.
inxi system information script (install info) :: inxi git
CyberGhost
Just as an aside, inxi -Ca shows the mitigation status:
inxi -Ca CPU: Info: 6-Core model: AMD Ryzen 5 2600 bits: 64 type: MT MCP arch: Zen+ family: 17 (23) model-id: 8 stepping: 2 microcode: 8008204 cache: L2: 3 MiB flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm bogomips: 81586 Speed: 3898 MHz min/max: 1550/3400 MHz boost: enabled Core speeds (MHz): 1: 3898 2: 3898 3: 3809 4: 3386 5: 3693 6: 3393 7: 2709 8: 1715 9: 2392 10: 1971 11: 1539 12: 1415 Vulnerabilities: Type: itlb_multihit status: Not affected Type: l1tf status: Not affected Type: mds status: Not affected Type: meltdown status: Not affected Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl and seccomp Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization Type: spectre_v2 mitigation: Full AMD retpoline, IBPB: conditional, STIBP: disabled, RSB filling Type: srbds status: Not affected Type: tsx_async_abort status: Not affected
But 4.9 is way too old, /sys may not show the mitigation data, can’t remember. If I remember right, /sys started showing that as soon as the kernels had the mitigations, but I can’t remember the details there. I know inxi has had that feature for a long time though. Oh, I looked it up in the changelog, it was actually AntiX forums that requested and helped test that feature, back in 2018-09 or so, first inxi version to have it was 3.0.23
From Debian’s spectre/meltdown page:
https://wiki.debian.org/DebianSecurity/SpectreMeltdown
Scroll down to: 32-bit PC (i386), can’t copy in tables.Pentium M is not pae, so that suggests that spectre 1 and 2 will fixed with 4.19, and meltdown cannot be fixed.
You might give some thought to picking up an older Thinkpad T420, those are pretty inexpensive used, and are excellent machines, and have a 64 bit modern cpu, handle sata, etc. I’ve gotten those for 100 bucks each, once saw someone selling them for something like 2 for 100 back when corporate buyers were moving up to next version for their corporate fleets, those deals I don’t see anymore though. I got a T400 for 20 bucks at a fleamarket, just needed replacement battery, with SSD upgrade I think it cost about 100 total, give or take. With an old spinning hitachi travelstar, it’s not a question of if, but when, your hdd fails.
I tried running pentium m for years, a T42, and finally gave up.
Hmmm, why isn’t bbcode working? Post says bbcodes are enabled, but it doesn’t use them, needs html, maybe fix that text?
Thanks for the info h2! This laptop was gifted to me by my brother so it’s just a project computer. I really like antiX and especially the usb tools. I had to install antiX using a Plop disc because for some reason the BIOS wasn’t recognizing the usb ports. It originally had windows xp on it and with xp, the usb ports weren’t recognized and the wireless nor the ethernet didn’t work. Once I got antiX installed everything worked. Well for the most part. I have had some issues but I have since resolved those issues thanks to everyone here at the forum. I do have a question. Are you saying that I need a non-pae kernel? You said Pentium M is not pae. Also are you saying no matter which kernel I use, my machine is still vulnerable to the meltdown? I’m a bit confused. Thanks
- This reply was modified 1 year, 9 months ago by CyberGhost.
anticapitalista, excellent as always to hear from you. Always glad to see antix alive and kicking, one of the better distros out there imo, always has been, so I’m glad to see you guys still around.
inxi system information script (install info) :: inxi git
Sorry, I’m trying to respond, but your spam filters keep eating my posts, it’s very difficult typing in stuff when your answers just vanish, I suggest, again, that you dump these filters or fix them, I write stuff like this, and nothing I typed should trip them.
inxi system information script (install info) :: inxi git
Thanks for the info h2! This laptop was gifted to me by my brother so it’s just a project computer. I really like antiX and especially the usb tools. I had to install antiX using a Plop disc because for some reason the BIOS wasn’t recognizing the usb ports. It originally had windows xp on it and with xp, the usb ports weren’t recognized and the wireless nor the ethernet didn’t work. Once I got antiX installed everything worked. Well for the most part. I have had some issues but I have since resolved those issues thanks to everyone here at the forum. I do have a question. Are you saying that I need a non-pae kernel? You said Pentium M is not pae. Also are you saying no matter which kernel I use, my machine is still vulnerable to the meltdown? I’m a bit confused. Thanks
I’m getting rusty on this, but yes, pentium M was not a pae cpu, that was one of its defining characteristics, in fact, most distros would have dumped non pae kernels years ago were it not for pentium m, which is really a rebranded mobile pentium 3 if I remember right. Almost all other cpus at that time supported pae, amd and intel did, but pentium m was this strangely odd holdover that lingered on, mainly because it was used so much in laptops until the intel core series, or some atoms, replaced it.
Antix is by far the best choice for old hardware, but in this case, I’d suggest it’s not worth the headache, I don’t believe that generation had sata either, correct me if that’s wrong, so you can’t even replace the hdd with and ssd for some $25 or so. Without pae, you also couldn’t use more than about 3.5GiB of ram, usually those used shared ram for video I think, so you wouldn’t get the full 4gb ram anyway. A lot of older systems won’t support usb boot, I have some still here that don’t, that’s not uncommon.
Yes, I’m saying you need a non pae kernel, but the 486 kernel if I remember right is non pae, again, I’m rusty on this, but these guys won’t lead you astray, they know their old hardware, way better than most newbies out there, lol.
And yes, according to that debian spectre/meltdown page, which I suggest you take a look at, non pae kernels can’t fix the meltdown variant, if I understand it right. I don’t want to take this too far afield, but I did a lot of research and listened to a lot of openbsd developers, who were all over these vulnerabilities, and the actual causes for these issues was intel’s poorly done and insecure multithreading in their cpus, at least in part, they called it HT, hyper threading, but it’s just running > 1 thread per core. Pentium m didn’t do that anyway, that wasn’t introduced until the core series if I remember right. OpenBSD recommends hardware disabling intel multithreading always. AMD multithreading does not appear to suffer from this issues I believe.
I used to be more up on these things, but that’s the basics, most of the cpu mitigations are fixing optimizations intel created to make fake fast speeds possible, that is, the cause was intel making bad choices, not clever hackers. I don’t know if intel has fixed that problem, but I know a lot of the linux kernel mitigations involved basically removing some of the fake speed from the intel cpus, which annoyed commercial users since they had bought hardware to run at x speeds, but with the mitigations, it would only run at maybe 3/4 of that listed speed, but the listed speed/processing power was always fake because it required insecure modes of operation.
I can’t remember the details, but basically vulnerabilities connected to multithreading won’t affect the pentium m, but other ones will. I wouldn’t personally worry too much about it, the odds are your hdd is going to die/fail before you get hacked or compromised, and I don’t think there’s any easy way to replace a hdd using laptop ide connections with a sata ssd anyway, I know for years I looked for reasonable ways to get a solid state drive into my T42, but they almost all involved using a simple ide to flash adapter, and flash isn’t good for active os because it can’t handle writes the way ssds with internal controllers can.
- This reply was modified 1 year, 9 months ago by h2.
- This reply was modified 1 year, 9 months ago by h2.
- This reply was modified 1 year, 9 months ago by h2.
inxi system information script (install info) :: inxi git
Re your question, you should install the latest non-pae kernel that debian or antix offer for your pool, in debian testing it’s:
linux-image-5.10.0-8-686 – Linux 5.10 for older PCs (signed)
The pae one has the -pae extension.
- This reply was modified 1 year, 9 months ago by h2.
inxi system information script (install info) :: inxi git
CyberGhost
Ok thanks again h2! FYI I have 2 modern high end laptops and a desktop running MX Linux 19.4 so thats not the only computer I have. Mainly, I just wanted to see if I could even install Linux on that old laptop. My brother told me he had a new 500gb hdd put in it before he gave it to me so I’m sure it will last for a little while. I did check out that link on the debian site briefly. I’ll look more into it later when I have more time. I’ll try the kernel you suggested and see how it goes. I don’t do anything serious with that old laptop. Lately I’ve just been using it to learn Linux stuff and further my terminal/cli skills and trying to learn more about antiX. Thats pretty much it.
Oh, no worries, I share the idea of keeping old hardware alive as long as humanly possible, so don’t get me wrong, I’m a fan of this idea. I have a 1998 laptop running an old IBM early SSD drive, 1 GB, someone donated to me, it’s been running 24/7 now for at least 15 years I think. Excellent test platform for inxi, I like to say it keeps inxi honest, since if it can’t run on that, I’ve made a mistake.
Working out problems, figuring out how to make old hardware work, is generally very educational, and tends to make you a much better overall linux user in general, so it’s a good strategy. Now and then I think of pulling out my old t42 pentium m and getting it running again, but it had a few failed ports, 1 dead usb, dead audio, and that annoying oscillating fan, make it not worth it probably.
You came to the right distro though, they have been good at this stuff for a long time.
inxi system information script (install info) :: inxi git
Xecure
HI, h2.
I saw the thread you opened in December, about testing pinxi, but at that time didn’t know it was in fact inxi (I didn’t read too much into it, and didn’t know the current inxi in antiX was in fact the same tool).I think you could have gathered more attention if you had posted in the then antiX bullseye alpha thread to get feedback there, hinting at the possible inclusion of the updated inxi in the upcoming antiX 21 release.
Anyway, I wanted to thank you for your work on inxi. We rely on this tool heavily for troubleshooting problems. Without it, we would have a lot of trouble figuring out what is going on. Thanks for inxi.
antiX Live system enthusiast.
General Live Boot Parameters for antiX.
marcelocripe
H2,
I also want to register my thanks for your work on inxi. I use it for every new installation of antiX on different computers or laptops. I am not sure, but I believe that if inxi-gui exists, it must be because inxi was created before.
marcelocripe
(Original text in Brazilian Portuguese)———-
H2,
Eu também quero registrar os meus agradecimentos pelo seu trabalho no inxi. Eu o utilizo em cada nova instalação que realizo do antiX em computadores ou notebooks diferentes. Eu não tenho certeza, mas acredito que se existe o inxi-gui, deve ser porque antes foi criado o inxi.
marcelocripe
(Texto original em Português do Brasil)Xecure, it’s too hard to keep up with distros specifics to know where the ideal place to post is, takes too much time, I have to be practical. pinxi is always next inxi, if you want to do yourselves a favor, just install pinxi in /usr/local/bin, then use pinxi -U to update it whenever you feel like, and you’ll always have the most current cutting edge inxi. The only time pinxi and inxi are roughly the same is right after a new inxi release, but then fixes, issues, new features/ideas, etc, start to happen, and once enough of those collect, I do a next/new inxi, and it all starts over again.
Inxi of course also has the -U self-updater, if it’s blocked, you just change /etc/inxi.conf value: ALLOW_UPDATE=false to true, and then you can use -U.
I don’t use inxi myself, except to run it once or twice when doing a new inxi release to make sure there are no bugs that make it crash, those tend to make packagers aggravated, rightfully so. When I install any distro, first thing I do is install pinxi, then when I want to update it, I just use pinxi -U.
For distros, I really recommend just scripting a packaging tool for inxi, which will always support all systems by definition, and keeping inxi current in all your branches/pools. The ideal is to fully automate that, just check the github inxi tags list, and if it changes, update to next inxi automatically, package it, etc. That’s how I’d do it. Usually you can use the deb from unit193’s ppa, but I think he’s behind at the moment due to the Debian next stable freeze of sid/testing. In other words, bypass the frozen pool inxi completely, which is always totally out of date, and use the current one from git master branch. Don’t use pinxi for packaging because it can and often does contain active debuggers, sometimes bugs, etc, it’s only the development branch, that is. inxi is never architecture or specific software version dependent, that’s a core feature of inxi/pinxi, to run on anything from any time, back to about 2005 or so.
For example, debian sid/testing freeze happened at inxi 3.3.01, sadly right before a bunch of significant fixes for various features that were only exposed after the freeze, but that’s why I’m not a huge fan of frozen pool inxi’s, by definition, hardware, operating systems, etc, change, morph, new issues and old issues are found and fixed, it’s pretty constant, so no benefit really ever comes to anyone from using a frozen inxi. A few distros have realized this, and, for instance Manjaro, finally update inxi in their 3 branches roughly at the same time now for new inxi releases. I think they may be the first to do this across all branches, I’ve advocated doing that for years now since it offers users the best support possible, and helps support people because new things are always added or fixed or tweaked or enhanced.
marcelocripe, I have nothing to do with inxi gui project, I don’t know how good or bad of a job they do with keeping up with inxi features, inxi evolves a lot in terms of output formatting and syntax, though I try to make changes mostly be for improved clarity or better syntax or formatting. It obviously came long, long, long, after inxi itself, I remember seeing it years ago but I don’t really follow it, I faintly remember that it was an antix project originally? though that could be wrong, I really don’t know, never seen or used it.
I can say that over the years, a few key distros have really helped in inxi development, antix is one of them. Currently I’m not having a lot of luck for new feature testing or debugging with distros anymore via posting on their forums, so I am not posting as actively as I used to, it’s a function of time used vs benefit gained, but that’s how it goes, things change, people’s energy, interests, change. Nowadays, if I post to a forum a few times for feedback/dev help, and no meaningful responses come, I tend to move on, since I don’t have infinite time to check back for responses.
- This reply was modified 1 year, 9 months ago by h2.
- This reply was modified 1 year, 9 months ago by h2.
- This reply was modified 1 year, 9 months ago by h2.
inxi system information script (install info) :: inxi git
Xecure
Xecure, it’s too hard to keep up with distros specifics to know where the ideal place to post is, takes too much time, I have to be practical
Of course, I understand. Maybe not you but someone else could have pointed it out, as they were already in the know.
Anyways, anticapitalista has already packaged the inxi version 3.3.06 from your git repo and should arrive soon to all antiX users as an update, so now we can enjoy the new features and improvements you have included.
Thanks for the tips on downloading and keeping pinxi updated. This way there is no need for waiting to get the latest features.Again, thank you very much for your tool. It is really a god-sent. I cannot understand how it is not included by default in the ISOs of some distributions.
antiX Live system enthusiast.
General Live Boot Parameters for antiX.Oh, good, glad to hear anticapitalista packaged new one. 3.3.06 is really quite good, it handles a lot of small and large issues that were found and fixed over the past months, I had a lot of trouble getting bluetooth stable and reliable for support people, it took me 3 tries, 3.3.00 was first try, then it took 2 more releases after that to get it reliable, or as reliable as something as odd as bluetooth can be. I still see subtle issues out there, but can’t figure them out until I get full datasets, there’s a lingering raspberry pi 4 failure to show bluetooth sometimes, but not always, that I don’t know the cause of.
Although 3.3.06 superficially looks very similar to 3.0.xx, internally I think over half the codebase has been totally refactored, I’d estimate that almost as much was written or rewritten between 3.0.00 and 3.3.06 as 2.3.56 > 2.9 > 3.0.00. One of the results of that was a lot of real optimizations that resulted in maybe 50% more code internally running at quite close to the speed it ran before that new code was added. All the BSD stuff was completely rewritten, and all the block device stuff was totally refactored, that’s -R, -L/–logical, -D, -p/-P, -o, though the Linux block device logic isn’t actually as good as the fully refactored BSD block device logic, eventually the linux stuff will use the same type of logic as bsd block device tool uses since it’s much better, but that’s a lot of work.
I don’t believe antix really does the ARM stuff, but ARM is a good example of totally randomly changing system info detections, it’s literally case by case, new SOC / embedded device by device, so any distro that focuses on ARM should never use old inxi’s, stuff just won’t work, that’s the fault of the ARM spec, or rather, failure to create one reliable spec, not inxi.
As someone who scripts solutions to avoid the tedium of doing stuff manually, I’ve actually thought of just making my own debian repo, but that would be more work, which I don’t really need, and it wouldn’t really help users that much since they’d have to know to install it, and at that point, they might as well just install inxi or pinxi and use the -U to update, it’s not really any work to do that.
The only incomplete current feature is btrfs RAID type output support, but I gave it a start, and honestly just don’t like the btrfs reporting tools, they are really not very complete or good, unless I’ve missed something, and they also require root, again, unless I’ve missed something, so that feature isn’t implemented yet. I don’t generally like features that require root, and only use them if there absolutely no other way to get the data.
- This reply was modified 1 year, 9 months ago by h2.
- This reply was modified 1 year, 9 months ago by h2.
- This reply was modified 1 year, 9 months ago by h2.
inxi system information script (install info) :: inxi git
- You must be logged in to reply to this topic.
