and a small bug for blank files there.
Second, made the --output error message more clear for bad file structure now lists
the 3 requirements: must be full path, must be writeable directory, and must have
a file in it.
Third, another subtle thing, after a lot of research, am trying the MiB GiB format
because it's technically more accurate and less ambiguous than GB, which is used
either to refer to 1000 bite blocks OR to 1024 blocks, depending on the platform etc.
So rather than hope people get it, trying that slightly more wordy format, and maybe
if people wonder what it is.
It's here! Perl inxi, first official release. So many changes, really too many
to list.
But here's a few:
1. of course, full rewrite to Perl 5.x. Supports as old as 5.008, as new as current.
2. Better line length nandlers. Fully dynamic, robust, shrinks and expands to fit
either taste or viewport.
3. Long options for all options now, plus of course the short options everyone
is used to.
4. New options: --usb; --slots (pci slot report); --sleep (change cpu sleep time);
and many more. Check --help or man page for details.
5. Vastly improved --recommends, now does per distro package recommends, and shows
only Linux data to Linux systems, and BSD data to BSD systems.
6. Hugely improved debugger as well.
7. Far more accurate output, most output is now in key/value pairs, because:
8. inxi now exports to json and xml! See --output/--output-file for info.
9. Enhancedd repo output, added deb822 type, solus
10. Radically enhanced network data, now shows all IP / IF devices connected to
each nic, not just one, both IP v4 and v6.
11. USB audio and network device actual drivers
12. better handling of compiler data.
13. Basic ARM machine data now, if present to inxi
14. Graphics: per card driver info alongside the original xorg drivers.
15. Better integration of partitions, RAID, unmounted partitions, and HDD data.
16. Better sensors handling of free video driver sensor data, well, not better,
it's now there, along with fan speeds for gpus.
17. RAID is enhanced, and now can show > 1 RAID type on a system, and the RAID
is improved.
18. Much improved disk/partition/memory sizing, inxi now always works internally
with KB units, and changes them on output to the appropriate units.
19. Fully redone man page for all the new options and the long options.
And so much more. Anyway, here it is, the first release.
2018-03-19 release. I'm putting the last issue requests on the last forums,
so assuming no real further bugs found, expect Perl inxi 2.9.01 to hit around
Monday or Tuesday. If any bugs are found, of course, those will be fixed before
release of the new Perl inxi.
Basically, if you want to see if you can find bugs, this is the time to do it, not
AFTER release. I've posted on many forums, and have given the various distros a
chance to help squash the bugs their users might see, some have been fantastic
(AntiX, you were the best by far), others, not so much. Their loss in the latter
case since the purpose of beta testing is to find bugs before, not after, release.
If you want to see the differences in recommends, and dependencies, grab pinxi
development branch here:
wget -O pinxi https://github.com/smxi/inxi/raw/inxi-perl/pinxi
or:
git clone https://github.com/smxi/inxi --branch inxi-perl --single-branch
and run: pinxi --recommends
The main thing I'd strongly urge all maintainers to add, for long term stability
and speed and reliability, is dig, which can be used if present to get very fast,
reliable, WAN IP information.
All of the other recommends are pretty much the same, for graphics, xdpyinfo,
xrandr, and glxinfo. For networking, ip or ifconfig, along with dig. For all usb
related identification, lsusb, unfortunately, I wish I could get rid of that tool,
it's very slow, but I can't. The --recommends output shows the complete set.
Obviously, Bash and Gawk are no longer recommends, nor are the tools like grep,
sed, tr, wc, etc, all those are done with Perl, so any shell plus Perl 5.08 or
newer Perl 5.x is all that's really required, beyond normal system reporting
tools like lspci etc.
For json/xml export, two Perl modules are needed, again, see --recommends
Making sure tarball etc is up to date, so it can be stored in 'tarball's branch.
MAINTAINERS:
Pinxi 2.9.00-xxx-p (inxi-perl branch) is nearing completion of its beta test cycle,
and, barring any new issues or bugs (TEST IT NOW AND REPORT ISSUES NOW!), I expect
to release pinxi 2.9.00 as inxi 2.9.01 shortly after I complete the advanced
RAID feature, which should be this week.
If no real issues appear during the following week after the inxi 2.9.0 release, it
will be moved to inxi 3.0.0, as the first stable Perl inxi release.
There will be a new branch, inxi-legacy, that will have the Gawk->Bash inxi 2.3..56
files for historical purposes only. No further work will be done on inxi 2.3 from
now on.
cpu output issues. Now inxi handles > 8 cores in terms of output filters,
descriptions, correctly noting that it's multithreaded.
Because AMD has entered the Multithreading game, I've changed the trade term:
HT - HyperThreading to MT - MultiThreading to support both Intel and AMD variants.
Updated CPU output filters to also account for these very large core counts.
I believe this commit now adds full support for the new Ryzen series, but I'll have
to see when it comes to other variants that may appear. I've tried to future proof
the MT tests, but I won't know of those are fully functional and accurate until
inxi sees the real data.
Because I don't want to break existing cpu logic, I just added in a rizen switch,
which will just use cpu_core_count value, then trigger HT output.
This fix may or may not work, but the issue poster vanished and has not followed up.
For now I'm keeping this a Ryzen specific adjustment, but it may be safe to extend
it further, that is, if siblings > 1 && siblings = 2 * cores then it's HT.
issue a forum poster raised, which is the fact that despite the fact that GNU/Linux
has had reasonably ok zfs support for years now, inxi only tested for zfs on bsd
systems.
This has been corrected. Due to the complexity of handling software raid, inxi
will now test first for ZFS data, if none is found, it will then test for
/proc/mdstat.
In a perfect world I'd like to have full dynamic Raid support, but I'm missing
all the key ingredients required to add that:
1. systems to test on
2. software raid, I don't use it
3. data collection for non mdraid and zfs software raid, including the values
possible to gather from all non software raid.
Basically, the only way I'd extend -R raid option is if I get direct ssh access to
a machine that uses the alternate software raid type, otherwise it would take
forever to figure out the options.
Since the number of people who might be actually running zfs and mdraid and
using inxi probably numbers in the 10 globally, I figured this solution was a fine
way to handle adding zfs without messing up mdraid, which is more common on linux.
It also does not break BSDs, since bsds as far as I know don't use mdraid, and don't
have /proc/mdraid in the first place.
Also redid the man page to add -! 41, -! 42, -! 43, -! 44 options, which bypass
curl, fetch, wget, and all of them, respectively. Plus making the lines less wide.
That should make those people who actually use 80 column wide vi as an editor
happy, lol.
easier and more predictable to find. Better section headers, all ordering alpha
by subsections.
Fixed some small debugger gatherer oversights as well.
Note that I made the debugger stuff more portable, so I could use it in another
program.
Note that this is the last choice because it's slow, the order has been revised:
1. curl
2. wget
3. fetch
4. Perl 5 HTTP::Tiny
5. OpenBSD ftp
wget has been downgraded due to the recent 1.19-2 bug with wget -O that did
not get resolved quickly, and which should never have been released since
that's a basic wget action, which means they aren't testing gnu wget the way
they should be.
All inxi downloaders can now use this option. However, in my tests it's signicantly
slower to use HTTP::Tiny than curl or wget, so inxi will test for the downloaders
in that order. While -i uses dig as it's primary IP tool, if dig is not installed,
the IP will follow the same downloader priority. -U and -w/-W use downloaders.
Because HTTP::Tiny is optional, and is merely used if wget/curl/fetch are not
installed, I would not consider Perl to be a real dependency yet, just an option, so
I guess for packager maintainers, Perl should be added as a recommends, or a
dependency if you want to fully support the debugger options (Core Modules).
While I'm still not sure which Perl modules I'm going to be using, I'm sticking
for now to Core Modules, the standard, with some experimental exceptions that
would only be used if the user had them present.
Long term the goal is to get rid of as many dependencies as possible, replacing
them were possible with Perl tools, but this is going to take forever, if it
ever happens, so don't hold your breath.
In the future, I expect more and more components that were gawk to be rewritten
to Perl (Core Modules), slowly, however, very slowly.
Updated --recommends to indicate the downloader options more clearly as well.
Added new options for bypassing curl (-! 41), fetch (-! 42) wget (-! 43), or
curl, fetch, and wget (-! 44) to disable all of them. This is in case one of
those is broken or you want to test Perl downloader, mostly.
Also cleaned up debugger output and made debugger portable to other scripts.
ARM data collection in /sys.
Using 'tree' now instead of ls if it is installed for debugger /sys tree listing.
Added to recommends. Updated bluetooth recommends to note it's dev only. That
should fix issue #127
branches, simplified the options. This corresponds to updates on github where
I'm finally bringing the alternate location self updater back into operational
state after a long dormant period.
Also, and this may be of interest to some maintainers, please note, there is
a new branch: master-plain which does NOT have the gz files inxi.1.gz and
inxi.tar.gz
If you want to avoid the big clones, you can use that branch with this command:
git clone https://github.com/smxi/inxi --branch master-plain --single-branch
And that should only track the basic 3 files: inxi inxi.1 and inxi.changelog
This fixes issue #94
explicitly setting Passive => 1 (true) for some systems and firewall
configurations.
This corrects a failure to upload issue I experienced for a test remote
system that had a different firewall configuration than the dev system has.
nvme disk capacity in full disk capacity listing. Adds nvme name/serial/firmware
revision number. The latter is a new -Dxx output option. Note that as far as I could
tell, so far, nvme is the only disk type that has firmware revision data.
Added support for nvme disk temperature as well, that requires the cli tool nvme.
Updated AMD microarchitecture list to be more granular and complete. Added Intel
microarch type. Note that they are releasing a few new microarchitectures soon but I
was not able to find any model numbers for those.
of the xiin.py tool, which is going to become obsolete when python 3 fully replaces python 2.
Since the odds of perl being around and stable are far higher than the odds of xiin.py
even working on python 3, I'm getting ahead of the race. Plus Perl is nicer to work with.
And Perl is a lot faster. I mean, a lot. Not slightly.
And it also works on much older systems, and does not have that Python version < 2.6
failure due to changing Python syntax even between sub versions. xiin.py never ran on
Python 2.5 even when it was relatively recent, which is one reason I'm removing all Python
from inxi.
Basically xiin.py worked only on Python 2.6 or 2.7, period.
Oh, and also handled issue #115 by not making -B show -M data.
The issue was not so much with xiin.py as with some new values in /sys that would
hang tree traverse, however, in order to remove the python dependency (except for
uploading -xx@ debugger data, until I can figure out how to do it with Perl), I
rewrote the tree traverse tool into Perl, which also makes it a lot faster and
easier to work with.
This issue appeared on kernel 4.11 as far as I can tell, some new values in /sys make
the traverse hang if it tries to read the values, **/parameters/** and **/debug/** seem
to be the main culprits, but inxi doesn't need that data anyway for debugging purposes
so it's just excluded.
in issue #118
The data seems to suggest that using POWER_SUPPLY_VOLTAGE_MIN_DESIGN as the factor will
be right more often than using POWER_SUPPLY_VOLTAGE_NOW.
Also optimized a bit more on the desktop id logic.
the conversion from mA hours to Wh, and had a math glitch too for charge (ma).
Not sure how this went undetected during testing, oh well. I assume that mA h is not
as common internally as Wh or something.
Anyway, it should be fixed.
-o, -p, -l, -u, -P, -S, -G, -N, -A
Now most output should tend to not wrap, though some strings are unpredictable and
will have to be trimmed by adding them to the min size trimmers one by one.
But it's much better than it was.
Note the following changes required to make the wraps more consistent:
-S - the gcc/bits have been made separate, like: bits: 32 gcc: 5.3
-C - the new microarchitecture -x option now is: arch: K7 [for example]
cache wraps to next line with arch. with -f, bmips now shows on same line as
arch/cache
would have caused failure on older systems. Also added Bash version checker.
Most ps aux data is now searched using bash parameter expansion, and several functions
that were in subshells are now printing to globals instead.
as well so you can see which revision of the cpu microarchitecture your cpu has.
Also fixed a few random vm id issues, I found cases where systemd believes it's bochs
but it is actually kvm, so now the systemd data is not fully trusted, but is confirmed.
Will need some updates to bring the family/model ids to fully current, but should show data for most
cpus. Next release will hopefully include latest model/family ids and microarchitecture names.
Note that while /proc/cpuinfo has the family/model id in decimal, the values are actually generally
found as hexadecimal, so inxi translates that interally so we can store the data the way it is presented.
See issue #116 for ongoing additions to this feature.
but Xorg has not started, which means inxi can't get the video driver from Xorg.0.log as with X.
Added in extra data collection from lspci -v to include the driver for graphics card. this is
only used, for now, if the initial Xorg based driver test works.
Note that this may also work for systems that have not yet started X out of X, in console, I'm
not sure about that, but the graphics driver reporting should be improved.
Note that I'm not yet linking the driver to the specific card/device, it's just going to show
in a comma separated list, I couldn't find multi card systems where the card types are different,
like amd gpu with nvidia card, for example.
But this should correct an issue, at least to start, with expanding wayland support for systems
that don't use or have not started the desktop with Xorg/X11 etc.
core profile data being null, which in turn triggered a bash oddity, where if the IFS is
\n for an array, and if the value of one element is '', then bash ignores that and does
not simply set an empty array key as you'd expect. The correction was to change the IFS
to ^, which worked fine for empty array values.
However, since this bug will impact anyone with empty opengl core profile data, I recommend
updating inxi.
Also, added support for two smaller wm, Sawfish and Afterstep.
This is a good source for lists of wm: http://www.xwinman.org/http://www.xwinman.org/others.php
However, that does not show how to ID it, so i have to do it on a case by case, but I'll
add an issue for showing how to get your wm of choice if it's missing to inxi.
long-standing issue where /dev/ram.. data shows in unmounted disks output. This is
now properly filtered out.
Note that the floppy disk output has no information beyond it's /dev id, eg: /dev/fd0
I could find no meaningful data in /sys related to the floppy disk, not the model, etc, so
I'm just showing presence of disk.
wget/fetch/curl. This allows systems with for example out of date certificate stores
to still download without error. Also a legacy system fix where tty size failed to show.
Also cleaned up man page, slightly changed output for compat version to: (compat-v: 3.0)
gfx variable name fixes to make more obvious the logic as well.
Default will get data from display :0, but if you append :[display-number] to -! 40, it will
use that display instead, for example: inxi -! 40:1 would get information from display 1. Note
that most multi-monitor setups use :0 for both monitors, depending on how it's setup.
This will also let users see any desktop information based on xrop -root output, but it will
depend how it works based on how environmental variables have been set. gnome and kde, which use XDG for
primary detection would not work, for example.
used to not work as root in X, but they do now. So I've removed the root tests for graphics
output, and now only rely on the returned data to determine the output when in X. Out of X
behavior remains the same.
Note that at some point I'll have to see if wayland systems have usable reporting tools to get
screen resolution, opengl info, and so on, but that will have to come one step at a time.
-xx option will show OpenGL compatibility version number as well, though that's largely useless
information for most users, thus the -xx. Note that this reverses the default, which previously
showed OpenGL version, which is actually the compatibility version.
This should resolve#105 pull request, though it does it differently, by switching the default
output to what is more relevant, and offering the compatibility version as an optional output item.
Note that much of the glx information will probably change to more neutral terms once wayland support
starts growing, and systems without xwayland etc libraries appear.
Further note that non free drivers showed the OpenGL core profile version numbers all along, so really
this simply corrects misleading output for free drivers.
and compositor support.
This finally implements a first try at mir/wayland detection, along with basic handling of actual
display server type output.
New output for Display Server: Display Server: x11 (X.Org 1.19.0) driver: nvidia
Note that since almost all current Wayland systems will have X.org also installed, for the time
being, the data in the parentheses will be from X.org regardless of what display server is detected running
the actual desktop. Out of the desktop, console, the only thing that will show is x data..
No other data is available to me yet until I get way more debugger data so I can see what information the various
implementations of wayland without x tools actually makes available, my guess is it won't be much.
Also experimental -xx option: -G shows compositor, but only for wayland/mir currently.
I have no idea if this will work at all, but it's worth giving it a try as a rough beginning to
start handling the wide range of wayland compositors being created.
This feature will probably take several versions to get stable.
Also added new debugger data collector data for wayland information, but the pickings are slim, to
put it mildly.
Now there is an -x option for -i that will show the additioanl IPv6 address data for scope global,
temporary, and site. Also a fallback for unhandled scope: unknown. If the tool 'ip' is used, it will
filter out the deprecated temp site/global addresses, ifconfig tool does not appear to offer this
option.
Also changed is that now ipv6 address always shows, it's not an -x option. Probably about time to
start rolling out ip v6 data to users now that ip v6 is starting, slowly, to be used more.
Another small change, the link address for ipv6 is changed from ip-v6: to ip-v6-link so that it's
more clear which IP v6 address it is.
The last commit had a significant logic error in it that did not distinguish between the link address,
which is what should have only shown, and the remaining possible addresses.
I've tried to get a basic bsd support, but it's difficult to know the variants of ifconfig output syntax
Note that this bug is not universal, but I believe this will make inxi more right than wrong
as a general rule. Further note that altitude is NOT actually the altitude of the city/location
requested, in most cases, but rather the altitude of the weather station data assigned to that
location request.
from BIOSTAR. Also fixed a few other sloppy gsub, and fixed a few gensub errors as well.
Since BIOSTAR is a fairly common mobo, I'm surprised I haven't gotten this bug report
before.
This closes issue #102.
While default configs remain in /etc/inxi.conf, the user overrides now use the following order of tests:
1. XDG_CONFIG_HOME / XDG_DATA_HOME for the config and log/debugger data respectively.
2. Since those will often be blank, it then uses a second priority check:
$HOME/.config $HOME/.local/share to place the inxi data directory, which was previously here:
$HOME/.inxi
3. If neither of these cases are present, inxi will default to its legacy user data: $HOME/.inxi as before
In order to make this switch transparent to users, inxi will move the files from .inxi to the respective
.config/ .local/share/inxi directories, and remove the .inxi directory after to cleanup.
Also, since I was fixing some path stuff, I also did issue 77, manual inxi install not putting man pages in
/usr/local/share/man/man1, which had caused an issue with Arch linux inxi installer. Note that I can't help
users who had a manual inxi install with their man page in /usr/share/man/man1 already, because it's too risky
to guess about user or system intentions, this man location correction will only apply if users have never
installed inxi before manually, and have no distro version installed, unlike the config/data directory,
which does update neatly with output letting users know the data was moved.
Note that if users have man --path set up incorrectly, it's possible that the legacy man page would show up
instead, which isn't good, but there was no perfect fix for the man issue so I just picked the easiest way,
ignoring all man pages installed into /usr/share/man/man1 and treating them as final location, otherwise
using if present the /usr/local/share/man/man1 location for new manual install users.
Also, for users with existing man locations and an inxi manually installed, you have to update to inxi current,
then move your man file to /usr/local/share/man/man1, then update man with: mandb command (as root), after that
inxi will update to the new man location.
Also added some more XDG debugger data as well to cover this for future debugger data.
This closes previous issue #77 (man page for manual inxi install does not go into /usr/local/share/man/man1) and
issue 101, which I made today just to force the update.
Just as a side note, I find this absurd attempt at 'simplifying by making more complex and convoluted' re the XDG
and .config and standard nix . file to be sort of tragic, because really, they've just made it all way more complicated,
and since all 3 methods can be present, all the stuff has to be tested for anyway, so this doesn't make matters cleaner
at all, it's just pointless busywork that makes some people happy since now there's even more rules to follow, sigh.
graphics driver, so it would not show in output, which causes support issues for users of that specific
driver, like some cases of Intel. Also inxi would always have failed to show it unloaded in cases where
radeon/nouveau were used but it had been loaded by xorg to begin with. So probably worth updating packages
I'd say.
each disk is on its own line always, this makes it easier to read and/or parse.
Also, the lines now wrap nicely for extra data > console width, or -y 80 for example if
you're trying to force most of the data to fit into 80 columns.
handling, and legacy linux. VM id will remain a work in progress, and will probably
require a few fixes for fringe cases. Nice to have would be things like OpenBSD's
vm which is difficult to detect. However, I believe this should handle roughly 99% of
realworld vm id cases, except for some commercial stuff that will require more data.
Now -M shows device type, like desktop, laptop, notebook, server, blade, vm (and tries to get vm type).
vm detection will take more work, for now I'm just going for the main ones used, but it will certainly
miss some because it's hard to detect them in some cases unless you use root features. Also note, in
most cases a container I believe will display as a vm, which is fine for now.
For BSDs, and older linux, there is a dmidecode fallback detection as well.
Basic support added for Budgie desktop detection. This is waiting more data, so the support will be
missing the version information. Go Budgie!!
Added /var/tmp and /var/log and /opt to basic partition data: -P
This will probably not impact more than a handful of people in the world, but that's fine.
Modified the static BIOS in -M to now show UEFI for actually UEFI booted systems, and, ideally,
UEFI [Legacy] for UEFI booting in bios legacy mode, and BIOS for all others. Hopefully this will
work ok, we'll see.
-B option now shows, if available, battery data. Quite good data for systems
with /sys battery data, only rudimentary for systems using dmidecode (BSDs).
dmidecode has no current voltage/charge/current supported capacity.
Main row shows charge and condition. Condition shows you have much capacity the
battery currently has vs its design capacity. Charge shows the Wh/percent of
current capacity of battery (NOT the rated design capacity).
-x adds battery vendor/model info, and battery status (like, charging, discharging,
full).
-xx adds battery serial number and voltage information. Note that voltage information
is presented as Current Voltage / Designed minimum voltage.
-xxx adds battery chemistry (like Li-ion), cycles (note: there's a bug somewhere in
that makes the cycle count always be 0, I don't know if that's in the batteries,
the linux kernel, but it's not inxi, just FYI, the data is simply 0 always in all
my datasets so far.
For dmidecode output, the location of the batter is also shown in -xxx
A sloppy unescaped / triggered a failure I didn't notice in partition info.
Please update your inxi packages immediately if your version is 2016-03-21 or newer.
on /etc/issue step to first test for os release and not mint, then lsb verison and
not mint, then /etc/issue. This should keep the mint detection working well, as long
as they keep mint string in the /etc/issue file, that is, but that's out of our control.
test for the non deprecated battery test, /sys/class/power_supply/BAT0 existence.
This resulted in failure to indicate 'portable' where applicable.
I may also now add battery information where applicable since that's easy to get from
/sys
1. Add amdgpu to possible xorg drivers list (and gpu sensors data)
2. switch to default dig command to get WAN ip. This is usually but not always faster than
the http method. Because the IP source is not truly trustworthy (run by cisco), I'm keeping a
fallback mode on 1 second time out failure of the previous http based methods. Added dig
to recommended tools list.
NOTE: missing product name/serial info, because it's not being treated by linux kernel
as a standard disk. Could not find that data anywhere in the system debugger dump.
If you know how to find the model name/number and or serial, let me know.
Also small fix, as noted: ip: should be ip-v4 to match with ip-v6, thanks mikaela.
Also some debugger fixes and updates.
Changes: updated inxi updaters to use github locations.
I will do this commit once for googlecode, and once for github, after that,
all commits will go only to github.
inxi moves to github, despite my dislike of for profit source repos, and git,
I decided that I just don't have the time or energy to do it right, so I'm going
to use github.
The project is already moved, though I have left inxi up for the time being on
code.google.com/p/inxi until I move the wiki to http://smxi.org
Everything is pretty much the same, the project url is:
https://github.com/smxi/inxi
The direct download link for the gz is:
https://github.com/smxi/inxi/raw/master/inxi.tar.gz
git pull is:
git pull https://github.com/smxi/inxi master
svn checkout url:
https://github.com/smxi/inxi
And that's about it.
showing Frameworks version, which is apparently NOT the same as the plasma version.
Also added debugger kde versioning to make this stuff less of an ordeal for data collection.
#kde-devel, now using kf5-config --version which gives similar output to kded4 --version
I use this for both 4 and 5, but since 4 has worked fine for years, I'll just use this for 5
and later.
normal, in this case, sddm decided that using a .pid or .lock file in /run was too easy
so they changed to some session id type string in the /run/sddm/ directory.
Speaking for myself, I find such pointless changes from anything resembling normal behaviors
to the reason that gnu freedesktop systems will never achieve significant desktop use globally.
Also, in the same vein, added debuggers to try to figure out what plasma5/kde 5 is using
internally to give command line version information. Again, something pointless internally
was changed, thus breaking something that had faintly resembled an api, which is of course
why desktop gnu linux will never actually take off, developers in the real world have no
interest in chasing after such pointless and never ending churn in even the most trivial
areas of the OS, let alone the core.
inxi remains however as a log of this ongoing churn and lack of discipline, and so remains
an interesting process of observation, and a way for users to try to avoid the constant
changes in simple system queries that should really never change, so I can see a reason
to keep it going since it's obvious that the actual foss ecosystem itself will not and apparently
cannot grasp that it is the lack of stable apis, methods, etc, that has kept desktop gnu linux
from achieving any actual real world success or popularity, and that is the actual problem
that should be fixed, not some pointless internal change to something.
On the source repo front, maintainers, I still can't find an acceptable alternative to the
impending shutdown of googlecode. github is a for profit venture that people who seem totally
void of any sense of history believe is actually going to be around longer than say, sourceforge,
or googlecode, as a legitimate source hosting site.
I'd welcome any suggestions. So far all the options are bad that I can find.
Top preference is svn, but if git is the absolute only other choice for an otherwise good option,
I'd consider git, but it's a horrible option for inxi because of how inxi development and debugging
works, vs how git works. ie, svn branches are perfect, git branches are totally wrong.
I may end up just hosting the svn on my own servers to avoid having to move yet again when the next
for profit flakey site decides to close up or monetize the source hosting.
The original idea of googlecode was for google to 'pay its dues to the foss community', but apparently
they got bored with that idea, plus of course, the ongoing total failure of google to deal with
automated spam, which has always been a huge bug in the core google corporate culture. But googlecode
was by far the best option I've come across, it was done by a deep pocketed corporation not for profit
for pretty good reasons, and was never intended to be a profit center, which is the closest I could
see for a non free option.
Setting up svn gui stuff however is a royal pain and requires ongoing maintainance for the life of
the software, which is NOT fun, nor will I sign up for that obligation.
I may end up moving to github anyway, even though git truly sucks for inxi and myself, but it's an
idea I find fairly vile, apparently free software (sic) authors seem to have no grasp of the concept
of fredom when it comes to source code hosting, judging by the absurd popularity of github as the
default go to source repo. Their website is pathetic as well, which isn't very promising.
So we'll see where it goes, I think I have until august to decide what to do for source hosting.
Since I'm old enough to have seen sourceforge and now googlecode do the same thing, along with a lot
of other options, to say github won't do this too is delusional, what you can almost certainly say is it
will do it, the only question is when. But, just as Linus did with his non free linux kernel version
control, people will stick with the non free stuff until you realize you can't use it anymore, because
it is non free. Free software hosted on non free source repos is to me one of the most absurd and
stupid things I've ever heard of to be honest.
the switched file name. Kudos to anyone out there fighting to create a working alternative
to the unreliable and buggy and windows emulating systemd, I wish devuan luck. Maybe between
devuan and gentoo and slackware we can save the free software core systems before it's too late.
