Search
288 results for “smxi”
-
Found an obscure #Linux #distro #side that appears to be unique. That is, makes its own toolchain, which is what crazy from #frugalware said defines a base distro. Side uses #pisi package manager, #sysvinit and features #LXDE based #SDE with #pekwm or #openbox window manager.
These odd little distros generally help #inxi find and handle corner cases it had missed. In this case didn't have pisi pm/SDE handled.
Wish I'd noticed side before inxi 3.3.37 went out but this always happens.
-
And yes, just sent the #inxi 3.3.37 package off to #TinyCore - which is the last step of the process.
So that completes this 4 month release cycle. It would have been less but the monitor scaling feature of course turned into a rabbit hole.
But read the changelog if you are curious. It's long and thorough by design because it's the actual record of what changed, why, and what isn't currently doable. I use it often to find when why and how features are added or removed or changed.
-
Churning through an unexpectedly complicated series of updates in #pinxi next #inxi
Got the gpu monitor scaling handled which required fixing xrandr and wayland tool parsing and logic. False assumptions led to errors in output.
--force options were glitchy and inconsistently used and documented. Cleaning that up exposed more glitches, like --no-man not working in inxi due to opaque hash names.
It's surprising how fixing docs, help, and man exposes bugs in logic. Still polishing that up.
-
Just released new #pinxi (next #inxi ) has first draft of working monitor scaling support. The higher physical screen resolutions get, the more scaling is used. #mrmazda had off and on mentioned this as nice to have feature.
Not easy to figure out data sources but seems to work with #xrandr and wayland-info now.
I realized I could do scaling on my #xfce with #x11 which made dev a lot easier. Plus a good data file of #wayland scaled 3 monitor setup.
Updated graphics docs with new res section.
-
Just released new #pinxi (next #inxi ) has first draft of working monitor scaling support. The higher physical screen resolutions get, the more scaling is used. #mrmazda had off and on mentioned this as nice to have feature.
Not easy to figure out data sources but seems to work with #xrandr and wayland-info now.
I realized I could do scaling on my #xfce with #x11 which made dev a lot easier. Plus a good data file of #wayland scaled 3 monitor setup.
Updated graphics docs with new res section.
-
Just released new #pinxi (next #inxi ) has first draft of working monitor scaling support. The higher physical screen resolutions get, the more scaling is used. #mrmazda had off and on mentioned this as nice to have feature.
Not easy to figure out data sources but seems to work with #xrandr and wayland-info now.
I realized I could do scaling on my #xfce with #x11 which made dev a lot easier. Plus a good data file of #wayland scaled 3 monitor setup.
Updated graphics docs with new res section.
-
Just released new #pinxi (next #inxi ) has first draft of working monitor scaling support. The higher physical screen resolutions get, the more scaling is used. #mrmazda had off and on mentioned this as nice to have feature.
Not easy to figure out data sources but seems to work with #xrandr and wayland-info now.
I realized I could do scaling on my #xfce with #x11 which made dev a lot easier. Plus a good data file of #wayland scaled 3 monitor setup.
Updated graphics docs with new res section.
-
@jk your fundamental error was obvious in your Initial pist. You believe distros are little corporations competing against each other for supreme dominance.
This is profoundly wrong.
Distro means distribution. Of what? An often massive set of free software projects, #Linux kernel and #LibreOffice being 2 of the larger. #inxi being a smaller.
-
@jk then use osx or windows. My systems all work. Upgraded routinely
1. 2006 - debian sid 32 bit crossgraded to 64 bit and testing
2. 2008? Debian 32 bit testing reinstalled root 2012 64 bit.
3. 2015? Debian 64 bit sid sitched to testing a few years later
Plus servers running remotely.
When you want something to be what it's not you're never going to be content.
#FreeDesktops and #FreeServers are how they are because that's how people who do the work want them. Free as in Freedom.
-
@jk the reason there are different distros is they meet different needs.
RHEL: corporate linux
Fedora: unpaid dev for rhel
Arch: true rolling, minimal package changes from upstream
#Slackware you are expert, want vanilla upstream, patrick v. BDFL
#Debian install once run forever. Really. Sid/testing semi-rolling
Ubuntu: swahili for "can't install debian"
#TinyCore 26 MiB full OS install to RAM. Really.
#Alpine very groovy tech
Mint: new user choice 1
SLED/SUSE: Not rh, w/rpm
And so on
-
From a simple issue (#312) on #codeberg #pinxi (next #inxi) finally dumps the legacy -F/--full option names in favor of much more accurate and easier to explain -e/--expanded. Easier because -F hasn't been full output for over 10 years, and -F now actually expands -b/--basic, so noting that -e expands basic is a lot more logical than explaining that --full is not actually full at all, not even close. -F now listed as deprecated to avoid confusion in help/man. Redid -v too, all consistent now.
1/ -
#inxi #codeberg has slowly been collecting stars. As with #acxi, on github where I considered 1 star equal to 50 inxi stars because it's a very focused and specific tool, so too I think will I consider 1 codeberg inxi star equal to about 50 gh stars. Despite inxi gh not getting an update since 2023-12, and being marked as archived, it keeps getting forked and starred, which is the EXACT reason I realized there was no loss leaving gh in terms of eyeballs. Eyes with nothing behind them = no value
-
#inxi #codeberg has slowly been collecting stars. As with #acxi, on github where I considered 1 star equal to 50 inxi stars because it's a very focused and specific tool, so too I think will I consider 1 codeberg inxi star equal to about 50 gh stars. Despite inxi gh not getting an update since 2023-12, and being marked as archived, it keeps getting forked and starred, which is the EXACT reason I realized there was no loss leaving gh in terms of eyeballs. Eyes with nothing behind them = no value
-
#inxi #codeberg has slowly been collecting stars. As with #acxi, on github where I considered 1 star equal to 50 inxi stars because it's a very focused and specific tool, so too I think will I consider 1 codeberg inxi star equal to about 50 gh stars. Despite inxi gh not getting an update since 2023-12, and being marked as archived, it keeps getting forked and starred, which is the EXACT reason I realized there was no loss leaving gh in terms of eyeballs. Eyes with nothing behind them = no value
-
@mos_8502 these concerns actually were core requirements when I was looking for a real language to rewrite #inxi to. #bash + #gawk were used initially for similar reasons but were a nightmare to work with. One and only one language met the feature stability + robustness + trustworthiness criteria: #Perl
I liked the results enough to start using it for advanced work tools too. Then I spun up inxi dev tools in perl. My life is better now. Inxi runs on 20 year old os, and on 386 + #slackware 9
-
@mos_8502 these concerns actually were core requirements when I was looking for a real language to rewrite #inxi to. #bash + #gawk were used initially for similar reasons but were a nightmare to work with. One and only one language met the feature stability + robustness + trustworthiness criteria: #Perl
I liked the results enough to start using it for advanced work tools too. Then I spun up inxi dev tools in perl. My life is better now. Inxi runs on 20 year old os, and on 386 + #slackware 9
-
And before the questions overwhelm me, yes, just submitted the new #inxi tce package to #TinyCore Linux.
I am trying to do that as close to release as possible now to avoid forgetting to do it, which was my previous tendency.
And that's the last step of an inxi release. Now to see how long the next cycle takes to start. This past one was the longest before changes in many years, which was nice. But they do trickle in eventually. Sometimes trivial, sometimes less so.
-
#mrmazda found a last minute issue, wrong gpu ID match in #inxi nvidia section, which then reminded me that I'd forgotten to update the gpu ids for amd, intel, and nvidia. Added some more, and maybe fixed, or broke, some others. Note tracking cpu and gpu microarch data is really difficult, and time consuming. I wish someone who is passionate about those would step up and help. It gets old tracking that info and researching latest specs.
-
Today was a reminder of how useful documentation is, for help, man page, and standalone docs . #pinxi (next #inxi) had a lot of changes to in particular CPU logic. Editing man and options for those changes forces me to make sure I have it all right.
The thing with docs is, to write them means you have to be able to put into words what the code is doing, where changes are, how new features come to be, aka, UNDERSTAND. The longer I program, the more I realize the value of having to do this.
-
I'm going to call the #pinxi (next #inxi ) CPU die/cluster/core counter refactor good. Nobody has found a failure case, but then again, no new complex topologies have appeared.
The issue with GPU class IDs being translated to usable data I've given up on, unlike the kernel, FreeDesktop has bad docs as a rule, so unless someone can find clear docs about 302/380 classes that are nonambiguous, re Intel, AMD, etc use, there's no way to give correct info beyond the current ID active. Not static :(
-
Last testing of #pinxi (next #inxi ) die cluster core counter core rewrite. Pardon the pun. I can't stop myself. Fixes probably both #codeberg wrong core count issues. 307 was RISCV 2 cluster 8 core reporting as 4 core MT. This fix is a true fix, not a hack. Being tested by #slackware forums now. Looks good.
Also grabbed new #pop_os 24.04 #cosmic w/ #iced toolkit alpha iso. Hoping to add cosmic and ice tk support as well.
The longest period without Issues or dev work in years in this release.
-
For anyone into #inxi / linux graphics arcana, ongoing updates.
https://docs.kernel.org/gpu/vga-switcheroo.html
As I suspected real data comes krom kernel docs. Unfortunately switcheroo state data lives in /sys/kernel/debug which is root read only. But helped define the problem. switcherooctl also has a tiny bit of info with list option but it only shows gpus available.
#mrmazda found great set of hardware, same boards, intel igpu. One with nvidia card. Gpu class id switched depending on w/wo dgpu! ID dynamic!
5/
-
#damentz of #Liquorix kernel found a weak spot in #inxi's screen resolution handling. When display scaling is used, inxi fails to show both the physical and the logical pixel sizes per monitor/display, and instead shows only the logical. And no scaling. Internally there is a weak attempt to store this data as two items, but it's not used correctly. The desired output will be similar to physical and logical block sizes for drives. Physical used to equal logical so inxi reflects that history.
-
An interesting #inxi moment: #Unit193, #Debian inxi packager, told me that #lintian tests had found a typo in the man page. I have no idea how something can go through a code marked up text file containing data and code samples, and determine what is and what is not a typo, yet there it did it, and it was right, a typo. It was however wrong to give an alert to the path /usr/etc or /usr/local/etc which is now, unfortunately, yet another standard. No idea why /etc/[app].d/[app].conf not enough.
-
An interesting #inxi moment: #Unit193, #Debian inxi packager, told me that #lintian tests had found a typo in the man page. I have no idea how something can go through a code marked up text file containing data and code samples, and determine what is and what is not a typo, yet there it did it, and it was right, a typo. It was however wrong to give an alert to the path /usr/etc or /usr/local/etc which is now, unfortunately, yet another standard. No idea why /etc/[app].d/[app].conf not enough.
-
An interesting #inxi moment: #Unit193, #Debian inxi packager, told me that #lintian tests had found a typo in the man page. I have no idea how something can go through a code marked up text file containing data and code samples, and determine what is and what is not a typo, yet there it did it, and it was right, a typo. It was however wrong to give an alert to the path /usr/etc or /usr/local/etc which is now, unfortunately, yet another standard. No idea why /etc/[app].d/[app].conf not enough.
-
New #inxi 3.3.35 just went out the door. Who will package it first? Me, since I just sent out the #TinyCore package. I decided if I was going to package inxi for TC, I should make sure to release it as soon as the new inxi was pushed to @Codeberg For those wondering, still liking CB, and not missing #github for even a microsecond. CB is everything I hoped it would be. Squeezed in a nice last set of fixes, repos, packages, distro name filter glitch. And of course the #Loongson CPU/GPU stuff..
-
I've been gathering data for the Chinese #Loongson #MIPS CPU and GPUs, almost no data on the GPUs for the GPU arch tables (need more product IDs for matches), but found a fairly complete listing of Loongson CPUs on https://en.wikichip.org/wiki/loongson/godson_2/2h then found a collection of sample cpuinfo output files, which was enough to create a rough first CPU arch support in #pinxi (next #inxi). Just debugged last bits, seems to be working. Chinese built #Deepin (#Debian derived) supports #LoongArch.
-
Next #inxi is shaping up well, all running in #pinxi now. Came across an ancient distro I'd never heard of, #TDSDE, which apparently preceded Gentoo by a few months. Poor docs, unreliable source builds, but got everything inxi cares about working, and found some weak spots. These corner case distros often expose weak assumptions.
Also locked down #rpm packages, #urpm #eopkg #pisi repo reports, which were not great, or not working.
Took a while to get enough fixes to warrant a new release.