Learn 3 Linux areas, requiring increased AWARENESS, or even instant REACTION after UNIX-like OS installation.

I NOT tested big variety of Linux distros of course – but we can assume that there is some VERY bad habit across „some” distro lines, as in Arch (-Bang, Manjaro...)

1. NVIDIA proprietary threading – [Xid] bugs here: , seems similar to hibernation/s2disk problems

–a tricky issue, I  hope the env. combo helps: even when proper environment applied, FPS can be 1 (Xorg/glxgears) – see blog entry about „NVIDIA combo” [in testing]

2. CD/DVD/BD writer driver – also, here (Arch Linux with standard kernel, before KNOPPIX'ed) – its fault of Arch developers, even not to mention necessarity of placing some disk vendor id into some kernel internal hibernation special-treating PM list

KNOPPIX is so mature distro – replacing Linux kernel (contains basic [non-NVIDIA...] drivers automatically] across the distributions repairs even >1 problem. I not had to edit kernel source code in such manner!!!

 

They broke it overwhelmingly.

3. Hibernation/s2disk HDD spindown BEFORE even PC actually shutdowns – what a shame!! My blog covers it in basic details. Again, simplest way is replace it to the KNOPPIX kernel.

Do not forget about modules (drivers!) & recreating initrd. Maybe, also, some „extra” modules (in other directory... but all stuff under /lib/modules).

Along KNOPPIX-ation of the Arch, or other faulty Linux system, I recommend Fedora inside chroot/systemd's nspawn command, or similar. 

This one is user-mode solution – and the previous 3 was kernel-mode ones.

Fedora can be better than Debian, if you need GUI applications stability, and, as I assumed – the stability of package manager process.

 

No removing autoinstalled unneeded, blah blah... QGiS and Libre Office runs OK (remember, these are older versions – but usable, esp. when there remains LIBRE OFFICE bug with picture transparency/some image-op widgets BUG). 

All similar bugs shows you Babel/ity of social fragmentation – more precisely, the fall of America.

W/o PROPER religion you have no peace needed to fix the computer problems. To try, to wait, even to sit down with the machine. 

All my Linux tests show you an important rule of UNIX-like operating system: if NOT regulated, some BUGGY processes 'd be RANDOM, or 1/0 yes/no–autoCONVERTING.

Preface:

(I do NOT know precisely how with hibernation in another UNIX-like, Mac for example, etc.). I concentrate on „mere” (but good if you'll be hard-working) Linuxes: Arch Linux usermode running on KNOPPIX kernel.

I do not like term userland if its too exclusive: Windows term is USERMODE – simplifies things with an uniform nomenclature.

Hibernation is one of 3 areas, where Linux needs instant ADDITIONAL out-of-the-box operation to apply manually.

•Hibernation, in its GUI/graphical/DRM/DDX/framebuffer stuff depends on NVIDIA. But in my (current) experiences so far, it does NOT seem to be problem with hibernation „as it is”. Dmesg log „Xid” errors can arose even if no hibernating Linux! But they simply seem —

—only: seem, to be straight hibernation issues.

     If we cease using Windows, then GLX (that is, proprietary one Open GL library from NVIDIA installer) MULTITHREADING bugs we could treat, improperly – as the source of screen tearing, console switch system crash (but this bug was actually GONE! Even on proprietary!) bugs. 

Its multithreading, NOT the hibernation. NVIDIA env combo applied – still in testing phase.

I even do not know, if DDX (that is, some Xorg driver) also has similar problems

 – environment variables combo has been applied also to running Xorg instance.

 

1. Do not rely on /etc/profile – I remember my old negative experiences.

2. Systemd may have its own env managing – thus copy everything into several bootup script execution places, even into .xbindkeysrc, for making surety.

 

It is overall complicated slightly, requiring maybe making startcompiz script along some startlxqt variant – but:

If we have some help from NVIDIA, then why not to experiment with the Linux starting environment? 

As stated in the title, randomness of some Linux OS behaviors imply we must have proper, long-lasting timespan for proper methodology of tests (now monotonic system uptime: 2 days, 0:49:35.459530)

 

Maybe as in Blu-Ray writer test: when it turned out the need to copy KERNEL from KNOPPIX, and it works OK months – as in GLX test: firstly, strong need to wait, simply, wait and be much patient here.

Linux requires patience, and a good PAPER book.

I hate smartphones. Not important if from China or not. 

Smartphone (and electricity!!) SLAVERY

After long months, applying Linux #NVIDIA stability combo of 1. __GL_SYNC_TO_VBLANK... paired with 2. __GL_YIELD... var seems to REPAIR NVIDIA propietary compiz runtime locks & system after HIBERNATION.

Env vars, placed into .bashrc, lxqt start, xbindkeysrc & LXSESSION script (@ my specifically KNOPPIX'ED Arch Linux)

(Sorry, I do not fully comprehend difference between env, export, printenv, set, „=” & declare...)

declare -x __GL_SYNC_TO_VBLANK="0"
declare -x __GL_YIELD="USLEEP" 

The first one „flattens” circumstances where glxgears test gives FPS rate result around 1.

 •Monotonic uptime now: 23:13:45.417555.

•Compiz ALT+TAB static switcher (+wall/etc... that 're dependent to static switcher even actually turn on!) plugin have black background, often in this part of tests – visually sign that threading model of desktop environment and Open GL user applications changed. I see it several series this time so far.

Because it doesn't matter „effectability”, when more important is stability.

I remember that Linux „everywhere” has some threading problems, from an udev non completing in time at boot (worser thing is two GLX Xorg modules mixing!! And generally the Xorg conf.), through lower ext FS partition HDD efficiency with secure sync mounting, to problems with long lag new-tab console terminal opening.

 

But the last one is subjective... . Except the thing, that BFQ, RT kernels, etc. not helping ALSO in... ALSA sound system („rarely”) lagging [and still with 1 MB–1 CPU approach].

RT kernel?

Is is linked that someone's wrote Linux games (GODOT engine...) with CPU-demanding approach, something as it would be programmed in Java, the IT internal dysthopia of using C# and Java /remember blog users: Python is OK!!/ . 

RT kernels seem to be SCAM – it is better even to install Wayland INSTEAD of changing the Linux kernel style.

Even both Xterm and NVIDIA GT 610 work with Wayland (KWin_*Wayland* ver. works fine under RebbeccaBlack Live ISO OS, and NOT completes starting (bug?) under main Arch Linux OS).

 

Generally, you have 

•GTK

•Qt

•and mere (U)Xterm, etc.

— working OK with Wayland.

But Wayfire WM is WORSER (under-worked!) than compiz.

Khronos page too difficult fore me. At least now. I not want mess with GL/X/ES internals so deep!!! Why the standarization when (to show the minimum of „ice block”) you NOT have Wayland on proprietary, and DO HAVE on nouveau, on the same system. 

Switching NV and Nouveau modules no problem, but Wayland is a problem.

– HaShem ten ezrat... ba dvarim ken zeh...

 We need strong Holy Spirit Ruach HaKodesh to have peace with IT systems at its current state.

The Linux stereotype of „Use Nouveau all times when encountered bug under proprietary driver” – pure nonsense.

If you users convince me to apply „new Khronos group tips”, after reneval of Khronos site – then, maybe, yes. But only with that state.

 

Generally, IT is much overmarketed. We need more printed stuff, NOT Apple/iOS/Google/Samsung smartphones/iPods/iPads/tablets.

Compiz MUST be slightly slow. I not believe in IT, but in God (as stated above).

REPAIRED FPS≈1 on Nouveau Compiz'ed Desktop. OK after env var vblank_mode=0 has been set.

Extremely important! I thought it was internet browser problem, when disabling FireDragon graphics acceleration not helping!!

Export the variable vblank_mode=0 in your /usr/bin/start... file (a file that runs Xorg / session pair soft).

-or- 

If you have Linux DE that starts in a systemd service, runit or similar: add the export to proper DE startup place.

I do not know how to resolve potential problems under Wayland/Sway/Weston/etc – except you need nouveau, NOT the nvidia/nv driver (various names under Xorg?!!).

For me, LXQT starts from two files to debug dbus (now OK), and startup commands (from script: BAD, desynchronisation of when-or-if xmessage program appears)

(From linuxvox service, but who knows that COMPIZ need its application too?? Noy only at glxgears performance test!!)