#pinxi — Public Fediverse posts

Ongoing #pinxi next #inxi updates. After the #Loongson data and upgrade, I decided to grit my research teeth and dig into #Zhaoxin x86 Via Centaur based CPU. As usual, I had to combine data sources to get the info on each variant. Now pinxi detects Zhaoxin, and gets advanced microarchitecture data for each known model.

Previously this was tossed in with Centaur data, which cut off when zhaoxin split from via (cpuid family 6 > 7). And was wrong too.

It's absurdly hard to find this cpu data.

Ongoing #pinxi next #inxi updates. After the #Loongson data and upgrade, I decided to grit my research teeth and dig into #Zhaoxin x86 Via Centaur based CPU. As usual, I had to combine data sources to get the info on each variant. Now pinxi detects Zhaoxin, and gets advanced microarchitecture data for each known model.

Previously this was tossed in with Centaur data, which cut off when zhaoxin split from via (cpuid family 6 > 7). And was wrong too.

It's absurdly hard to find this cpu data.

Ongoing #pinxi next #inxi updates. After the #Loongson data and upgrade, I decided to grit my research teeth and dig into #Zhaoxin x86 Via Centaur based CPU. As usual, I had to combine data sources to get the info on each variant. Now pinxi detects Zhaoxin, and gets advanced microarchitecture data for each known model.

Previously this was tossed in with Centaur data, which cut off when zhaoxin split from via (cpuid family 6 > 7). And was wrong too.

It's absurdly hard to find this cpu data.

Ongoing #pinxi next #inxi updates. After the #Loongson data and upgrade, I decided to grit my research teeth and dig into #Zhaoxin x86 Via Centaur based CPU. As usual, I had to combine data sources to get the info on each variant. Now pinxi detects Zhaoxin, and gets advanced microarchitecture data for each known model.

Previously this was tossed in with Centaur data, which cut off when zhaoxin split from via (cpuid family 6 > 7). And was wrong too.

It's absurdly hard to find this cpu data.

More battery updates in #pinxi next #inxi

Added more values and updated docs using kernel.org /sys/class/power_supply items.

They have been busy and added many new values.

#codeberg issue #341 prompted me to check what was available. Answer was a lot more! Most consumer systems won't have many of these, like battery temp, but now will show extra if it finds it. Also reordered and restructured fields to allow more clear ordering.

Fun fun.

Turns out 3.3.39 will be the battery upgrade release

More battery updates in #pinxi next #inxi

Added more values and updated docs using kernel.org /sys/class/power_supply items.

They have been busy and added many new values.

#codeberg issue #341 prompted me to check what was available. Answer was a lot more! Most consumer systems won't have many of these, like battery temp, but now will show extra if it finds it. Also reordered and restructured fields to allow more clear ordering.

Fun fun.

Turns out 3.3.39 will be the battery upgrade release

More battery updates in #pinxi next #inxi

Added more values and updated docs using kernel.org /sys/class/power_supply items.

They have been busy and added many new values.

#codeberg issue #341 prompted me to check what was available. Answer was a lot more! Most consumer systems won't have many of these, like battery temp, but now will show extra if it finds it. Also reordered and restructured fields to allow more clear ordering.

Fun fun.

Turns out 3.3.39 will be the battery upgrade release

More battery updates in #pinxi next #inxi

Added more values and updated docs using kernel.org /sys/class/power_supply items.

They have been busy and added many new values.

#codeberg issue #341 prompted me to check what was available. Answer was a lot more! Most consumer systems won't have many of these, like battery temp, but now will show extra if it finds it. Also reordered and restructured fields to allow more clear ordering.

Fun fun.

Turns out 3.3.39 will be the battery upgrade release

In #pinxi (next #inxi ) a full refactor of the venerable Battery module. A #Codeberg issue exposed the bad logic of the battery feature, which near as I can tell was roughly translated verbatim from the original bash during the #perl rewrite. I thought I'd redone all those but I missed battery section obviously. The only difference most users will see is fewer or more decimals. Issue was 0.01 Wh capacity and current charge. Which was prematurely trimmed to 0, actually string '0.0', aka true.

In #pinxi (next #inxi ) a full refactor of the venerable Battery module. A #Codeberg issue exposed the bad logic of the battery feature, which near as I can tell was roughly translated verbatim from the original bash during the #perl rewrite. I thought I'd redone all those but I missed battery section obviously. The only difference most users will see is fewer or more decimals. Issue was 0.01 Wh capacity and current charge. Which was prematurely trimmed to 0, actually string '0.0', aka true.

In #pinxi (next #inxi ) a full refactor of the venerable Battery module. A #Codeberg issue exposed the bad logic of the battery feature, which near as I can tell was roughly translated verbatim from the original bash during the #perl rewrite. I thought I'd redone all those but I missed battery section obviously. The only difference most users will see is fewer or more decimals. Issue was 0.01 Wh capacity and current charge. Which was prematurely trimmed to 0, actually string '0.0', aka true.

In #pinxi (next #inxi ) a full refactor of the venerable Battery module. A #Codeberg issue exposed the bad logic of the battery feature, which near as I can tell was roughly translated verbatim from the original bash during the #perl rewrite. I thought I'd redone all those but I missed battery section obviously. The only difference most users will see is fewer or more decimals. Issue was 0.01 Wh capacity and current charge. Which was prematurely trimmed to 0, actually string '0.0', aka true.

Here's a peek into the arcana of #inxi research, which is then added to docs and tools, in #pinxi repo, in this case docs/inxi-cpu.txt and tools/cpu_arch.pl.
This is the data provided by cpuid binary. These are hex values.
https://en.m.wikipedia.org/wiki/CPUID
Normally extended model 3 and model F would give 3F = 3x16 + 15 = 63. And that is how amd does their extended model : model ids.
/proc/cpuinfo shows this as an integer. So far so good.

But then amd does something which makes my head hurt:
(Con'd)
2/

Here's a peek into the arcana of #inxi research, which is then added to docs and tools, in #pinxi repo, in this case docs/inxi-cpu.txt and tools/cpu_arch.pl.
This is the data provided by cpuid binary. These are hex values.
https://en.m.wikipedia.org/wiki/CPUID
Normally extended model 3 and model F would give 3F = 3x16 + 15 = 63. And that is how amd does their extended model : model ids.
/proc/cpuinfo shows this as an integer. So far so good.

But then amd does something which makes my head hurt:
(Con'd)
2/

Here's a peek into the arcana of #inxi research, which is then added to docs and tools, in #pinxi repo, in this case docs/inxi-cpu.txt and tools/cpu_arch.pl.
This is the data provided by cpuid binary. These are hex values.
https://en.m.wikipedia.org/wiki/CPUID
Normally extended model 3 and model F would give 3F = 3x16 + 15 = 63. And that is how amd does their extended model : model ids.
/proc/cpuinfo shows this as an integer. So far so good.

But then amd does something which makes my head hurt:
(Con'd)
2/

Here's a peek into the arcana of #inxi research, which is then added to docs and tools, in #pinxi repo, in this case docs/inxi-cpu.txt and tools/cpu_arch.pl.
This is the data provided by cpuid binary. These are hex values.
https://en.m.wikipedia.org/wiki/CPUID
Normally extended model 3 and model F would give 3F = 3x16 + 15 = 63. And that is how amd does their extended model : model ids.
/proc/cpuinfo shows this as an integer. So far so good.

But then amd does something which makes my head hurt:
(Con'd)
2/

Got a good #inxi #codeberg issue report. Graphics #Vulkan API item failed to show driver. Turns out that somewhere between vulkaninfo v. 1.3.255 and 1.3.296 they dropped the device driver summary data block. It was always also in a much larger and longer block but I'd never trusted the block name to be consistent. I still don't but there's no choice.This is fixed in #pinxi but sadly just missed the 3.3.37 release by a few days. Oh well. A #Mint user reported it after seeing driver: N/A always.

Got a good #inxi #codeberg issue report. Graphics #Vulkan API item failed to show driver. Turns out that somewhere between vulkaninfo v. 1.3.255 and 1.3.296 they dropped the device driver summary data block. It was always also in a much larger and longer block but I'd never trusted the block name to be consistent. I still don't but there's no choice.This is fixed in #pinxi but sadly just missed the 3.3.37 release by a few days. Oh well. A #Mint user reported it after seeing driver: N/A always.

Got a good #inxi #codeberg issue report. Graphics #Vulkan API item failed to show driver. Turns out that somewhere between vulkaninfo v. 1.3.255 and 1.3.296 they dropped the device driver summary data block. It was always also in a much larger and longer block but I'd never trusted the block name to be consistent. I still don't but there's no choice.This is fixed in #pinxi but sadly just missed the 3.3.37 release by a few days. Oh well. A #Mint user reported it after seeing driver: N/A always.

Got a good #inxi #codeberg issue report. Graphics #Vulkan API item failed to show driver. Turns out that somewhere between vulkaninfo v. 1.3.255 and 1.3.296 they dropped the device driver summary data block. It was always also in a much larger and longer block but I'd never trusted the block name to be consistent. I still don't but there's no choice.This is fixed in #pinxi but sadly just missed the 3.3.37 release by a few days. Oh well. A #Mint user reported it after seeing driver: N/A always.

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.

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.

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.

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.

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/

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/

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/

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.

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.

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.

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.

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 :(

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 :(

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.

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.

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.

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.

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.

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.

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.

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.

Found issues in #inxi repo report for some software sorced repo lists.: #mageia's #urpmq, #pisi, #solus #eopkg. These all are roughly similar and all had same report glitch of showing one repo data source per output line instead of source then all repos. The output was also weird. Corrected in #pinxi. Thanks #mrmazda for noticing.

Then noticed the #rpm package count failed for mageia. Turns out they are using different version of rpm, missing some options so no results. Will add workaround.

Found issues in #inxi repo report for some software sorced repo lists.: #mageia's #urpmq, #pisi, #solus #eopkg. These all are roughly similar and all had same report glitch of showing one repo data source per output line instead of source then all repos. The output was also weird. Corrected in #pinxi. Thanks #mrmazda for noticing.

Then noticed the #rpm package count failed for mageia. Turns out they are using different version of rpm, missing some options so no results. Will add workaround.

Found issues in #inxi repo report for some software sorced repo lists.: #mageia's #urpmq, #pisi, #solus #eopkg. These all are roughly similar and all had same report glitch of showing one repo data source per output line instead of source then all repos. The output was also weird. Corrected in #pinxi. Thanks #mrmazda for noticing.

Then noticed the #rpm package count failed for mageia. Turns out they are using different version of rpm, missing some options so no results. Will add workaround.

To release next #inxi now, or not to release and wait for more fixes/issues etc to show up? Always a tough call when there are not a huge amount of fixes, but there are real fixes that impact some people. Right now it's a little light for a new release for my taste, but it's been about 6 weeks, and the bugs/fixes I got were real issues, and should probably move from #pinxi to inxi.

This makes 3.3.35, like 3.3.34, mostly corner case fixes and updates. Which suggests... stability?!

To release next #inxi now, or not to release and wait for more fixes/issues etc to show up? Always a tough call when there are not a huge amount of fixes, but there are real fixes that impact some people. Right now it's a little light for a new release for my taste, but it's been about 6 weeks, and the bugs/fixes I got were real issues, and should probably move from #pinxi to inxi.

This makes 3.3.35, like 3.3.34, mostly corner case fixes and updates. Which suggests... stability?!

To release next #inxi now, or not to release and wait for more fixes/issues etc to show up? Always a tough call when there are not a huge amount of fixes, but there are real fixes that impact some people. Right now it's a little light for a new release for my taste, but it's been about 6 weeks, and the bugs/fixes I got were real issues, and should probably move from #pinxi to inxi.

This makes 3.3.35, like 3.3.34, mostly corner case fixes and updates. Which suggests... stability?!

Added initial support in #pinxi (next #inxi) for Loongson GPUs, but I have almost no data, so it won't be very meaningful. More important is to add in support on backend tools/gpu_raw.pl and gpu_ids.pl, which is where the GPU arch data for inxi gets generated.

Support for Loongson CPUs is totally lacking, I have no data, no cpuid data, nothing, though I found a good source for at least some of the features, process nodes, etc, but no way to match to actual CPUs.

And so it goes.

Added initial support in #pinxi (next #inxi) for Loongson GPUs, but I have almost no data, so it won't be very meaningful. More important is to add in support on backend tools/gpu_raw.pl and gpu_ids.pl, which is where the GPU arch data for inxi gets generated.

Support for Loongson CPUs is totally lacking, I have no data, no cpuid data, nothing, though I found a good source for at least some of the features, process nodes, etc, but no way to match to actual CPUs.

And so it goes.

Added initial support in #pinxi (next #inxi) for Loongson GPUs, but I have almost no data, so it won't be very meaningful. More important is to add in support on backend tools/gpu_raw.pl and gpu_ids.pl, which is where the GPU arch data for inxi gets generated.

Support for Loongson CPUs is totally lacking, I have no data, no cpuid data, nothing, though I found a good source for at least some of the features, process nodes, etc, but no way to match to actual CPUs.

And so it goes.

Meanwhile, on the #inxi / #pinxi front, all remains peaceful. Issues reported are resolved.

It's lingering in that odd space where not quite enough updates to warrant a new release, so waiting for more to pop up.

I'm calling the long refactor roughly completed with 3.3.33 a win, I'm not hitting code in general that makes me wince, hides issues, or makes logic hard to understand. This was the goal, so looks like a win.

I get slightly nervous when nothing shows up, but that's old habits.

Meanwhile, on the #inxi / #pinxi front, all remains peaceful. Issues reported are resolved.

It's lingering in that odd space where not quite enough updates to warrant a new release, so waiting for more to pop up.

I'm calling the long refactor roughly completed with 3.3.33 a win, I'm not hitting code in general that makes me wince, hides issues, or makes logic hard to understand. This was the goal, so looks like a win.

I get slightly nervous when nothing shows up, but that's old habits.

Meanwhile, on the #inxi / #pinxi front, all remains peaceful. Issues reported are resolved.

It's lingering in that odd space where not quite enough updates to warrant a new release, so waiting for more to pop up.

I'm calling the long refactor roughly completed with 3.3.33 a win, I'm not hitting code in general that makes me wince, hides issues, or makes logic hard to understand. This was the goal, so looks like a win.

I get slightly nervous when nothing shows up, but that's old habits.