*Monotonic* uptime BETTER NOW. [!METHOD NOTE: Linux needs restarts often] |+Secondary issues

Grew to 5 days, 20:35:23.923087 .

Linux needs restarts often – this fact implies that methodology cannot be so strict. But the new maximum is determined now. Linux bugs need esp. to be addressed when there is so much bad-bugs in LXQt Panel, i saw something bad even in glibc — strange error about QGis popular geo-mapping application specifically.

You don't know when glibc or some other, BASIC-SYSTEM related, bug arose under Linux.

Interesting „phenomenons” was also with installing tmux in systemd, understood as service controller. Multiple combinations of .service file contents, and... why?? VT is so strange, even when no after-boot (to be understood: in the framebuffer stage - but after initcpio) console problems.

GRUB configuration with a background image cannot be done manually – but it WAS easier than executing image showing in next phase(s). Fbsplash actually was OK only with MANUAL invocation – it is a service - or - not?? Why so much calls in the initcpio scripts??

If fbsplash is SO DIFFICULT, only manually-run as OK, then why STUPID Linux community can't write better handbook?!

Damned „manually”: Clang «fast» Compiler still, 2024, NOT fully compatible with «gcc-code»: The nsxiv app’s compilation is one example.

 

Problem WAS, I updated some packages in Arch Linux and, after that, tried to replace old sxiv’s program custom enhanced variant to the new nsxiv from its git repository.

3 „old-fashioned” errors
— with fast Clang compiler, „new technology” of compilers, that are also accompanied (across… MULTIPLE Arch Linux packages) with the LLVM compiling orientation:

clang-16: warning: treating ‚c’ input as ‚c++’ when in C++ mode, this behavior is deprecated [-Wdeprecated]
autoreload.c:70:17: error: assigning to ‚char *’ from incompatible type ‚void *’
scratch.buf = erealloc(scratch.buf, scratch.len);
^~~~~~~~ autoreload.c:73:9: error: cannot initialize return object of type ‚char *’ with an rvalue of type ‚void *’ return memcpy(scratch.buf, filepath, len); ^~~~~~~~
autoreload.c:87:9: error: assigning to ‚char *’ from ‚const char *’ discards qualifiers
base = strrchr(filepath, ‚/’);
^~~~~~
3 errors generated.

Rerun make with old, „straight” gcc

 (by unset CXX & unset CC bash commands- and OK:

CC autoreload.o
c99 -Wall -pedantic -O2 -DNDEBUG -D_XOPEN_SOURCE=700 -DHAVE_LIBEXIF=1 -DHAVE_LIBFONTS=1 -DHAVE_INOTIFY=1 -I/usr/include/freetype2 -I/usr/local/include/freetype2 -c -o autoreload.o autoreload.c
CC commands.o
c99 -Wall -pedantic -O2 -DNDEBUG -D_XOPEN_SOURCE=700 -DHAVE_LIBEXIF=1 -DHAVE_LIBFONTS=1 -DHAVE_INOTIFY=1 -I/usr/include/freetype2 -I/usr/local/include/freetype2 -c -o commands.o commands.c
CC image.o

Yea, this one was simple.

 But generally, in IT world we have bigger projects that must be (re)compiled (or linked dynamically), DUE TO *.SO libraries issues.

There is no „hot” alternative. I don’t want the difficult special scientific system distrubution — I prefer to, AS WITH the icu lib, to put *ALTERNATIVE* libs in its special folder – not in /etc/alternatives but in /usr/local/lib/ICUxx, for example. While the icu library is the most wide, heavy alternative (Libre Office tends to link version after version of icu!!!), the (re)compilation of application turns out to be solution (as it was with BibleTime, also).

Some time ago, I replaced Arch Linux packages with the manjaro repo – resulted, not instantly but after update+manually, QGIS started working.

Previously I run QGIS from chrooted Debian system (that is, the container – not the VM nor similar, but live ability to change root directory – the SO objects are linked from distribution file tree).

Theory of Concave Earth PC Programs