NC - SC

NC - SC

◇◇◇◇◇ REMARK – THIS IS NOT MY MAIN BLOG ◇◇◇◇◇◇

The Better Blog Version is ON WORDPRESS *****To jest blog pomocniczy. Podstawowy jest tu (link trzeba przekopiować): **** https://tradycyjnyyahwista.wordpress.com/ STRUKTURA STRONY:•Wordpress blog zasadniczy, NOWOŚĆ: INDEKS A...Z. Bogate menu, galerie, *AKTUALIZACJE*, ŹRÓDŁA! •Blogger to blog pomocniczy – notatki, też komentarz itp. •YT – playlisty (aż z kilkanaście, PL i ENG.), WYCINKI - FRAGMENTY •Rumble – filmiki, filmy i WYCINKI, Dżek •JustPaste – pozostałe materiały i notatki, koment.

Search This Blog

Tuesday, October 20, 2026

Problem z trawieniem MLEKA? Laktoza ze ŚMIETANY z kebabu b. dobrze sie trawi!!! | Problemy taskie jak #zgaga ... ELIMINACJA!

DO CHOLERY!!!

Jakoś żołądek i okolice DOBRZE się mają po zjedzeniu kebaba! DLACZEGO? Ponieważ jest RÓWNOWAGA, ALE nie taka jak np. równanie Clapeyrona — jakieś z paroma (bowiem: jedynie) zmiennymi!! Dobrostan organizmu to KURKA nie jakaś genetyka, co religia Dvarim Ha-Akolah. Biblia JASNO i zwięźle podaje, ŻE KURKA ZIEMIA OPŁYWAŁA (właśnie) MLEKIEM, WY POLSKIE MULTIRELIGIJNE HIENY.  

NieTOILETrancja laktozy, wymysł umysłów kiblowych!

•Czepiać się gnojki o wersety – podaj to, tamto – bo nie pamiętacie, nie macie pamięci wielowątkowej i stąd wy ciągle chcecie numery wersetów na WSZY//stko.

Mnie nie interesuje wasza polska, amerykańska biblia. 

Inwersyjnie została napisana w innym języku, nie dla ŚWIŃ//-dyferentyzmów przeznaczonego. Biblia szatana musi upaść, wbrew polskiemu defetyzmowi. Azjaci mają ładny język, kiedy polaki wypieprzają do Ameryki i kolejną TRANS-lację (tłumaczenie Biblii) próbują KIEDY to trzeba wrócić do języków oryginalnych.

     Tak jak kebab jest azjatycki, zresztą. Równowagowo i homeostatycznie do jasnej... .
A wy myślicie, że zdrowie organów wewnętrznych jest jak algorytm AI. 
NIE!! Dieta zbilansowana to ta z Turcji, Izraela, może też z okolic.

Słynne wideo „Dlaczego aż 75% ludzi ma nietolerancję laktozy?”. Dlatego, że, goje, chemia w brzuchu to nie jakieś proste obliczenia, tabelki z VITY (nie wiem czy jeszcze pisemko to -zresztą- istnieje, nie obchodzi...)...

W ogóle nadmiar, czy może nawet, KORUPCJA dietetyków i „lekarzy”, jest zła, niewskazana » I WYPIEPRZAĆ do polityków z waszym defetyzmem. To oni odpowiadają za „dietę planetarna”, postępujący brak -i WRAK-, razem z długiem zdrowotnym.

Wednesday, October 14, 2026

NV's NEVER(MIND)! and Mesa dri(/vers)... NVIDIA cards maybe generally better acc. to screen/window tearing under *Xlibre*XServer*, but NVIDIA crashes in BOTH new Xlibre & Wayland. |#Xlibre #testing #actualization #Mesa

NVIDIA graphics cards on Linux – nonsense. All very LONG testing, „new” 7.3 kernel line, Weston & kwin/x11 - kwin/Wayland..., initcpio KMS hook & ramdisk boot stage's wait for fbdev somewhere in /dev , •by a sleep hook,

I thought it would be as in Porteus (waiting for boot disk...) 

–  ALL this W/O success.

Replacing this faulty card with amdgpu/Mesa/CL drivers Gigabyte Radeon. 

Crashes AND system crashes

Xorg's Xlibre console VT-switch, typically after hibernation – stopped some graphics thread, as I assumed.

The AMD brand

Mesa/CL driver are integrated in Linux in more straight way.  As far as I know, Mesa is more regularly bugfixed – even when forums speak about hibernation.

NVIDIA hoax, the NVIDIA forums primitive as the OpenCL NOT built-in into basic (I mean, Mesa dri(vers) and all around...) Linux drivers!!!

When running killall -STOP  flurry (beautiful part of xscreensaver), & sleep & CONT., the program crashes and stalls entire Xlibre (except mouse pointer/compiz NOT hides the original pointer...)

Anyone heard similar treading issues on Windows? NEVER(MIND)!!!

Mesa universal? 

local/mesa-tkg-git 26.3.0_devel.230976.88d2d56a02f-1
    an open-source implementation of the OpenGL specification, git version
 

Monday, October 12, 2026

HUGE patches for NVIDIA 390xx –2nd stage of repair: •I found plenty of patches. •And, along with Xlibre (new Xserver) the still yet present kernel driver NVIDIA crashed (this time REISUB sufficed)

I found plenty of patches!

•And, along with Xlibre (the new Xserver) the still yet present kernel driver NVIDIA crashed (this time REISUB sufficed)

They are for NVIDIA-Linux-x86_64-390.157.run self-extracting archive, which contains some C stubs (BUT SO MUCH of files!! Semi-open-source?)

•Getting source (not knowing yet if it is a whole driver (w/o blob), or patches' part only...): 

wget "https://ftp.altlinux.org/pub/distributions/ALTLinux/p11/branch/files/SRPMS/nvidia_glx_src_390.157-390.157-alt303.src.rpm" 

Patch list is huge (https://github.com/aroldobossoni/nvidia-390-modern-kernel/blob/main/install_nvidia_patches.sh): 

    "do-div-cast.patch"
    "kernel-4.16+-memory-encryption.patch"
    "0018-backport-nv_install_notifier-changes-from-418.30.patch"
    "nvidia-390xx-kmod-0024-kernel-6.2-adaptation.patch"
    "nvidia-390xx-kmod-0025-kernel-6.3-adaptation.patch"
    "nvidia-390xx-kmod-0026-kernel-6.4-adaptation.patch"
    "nvidia-390xx-kmod-0027-kernel-6.5-garbage-collect-all-references-to-get_user.patch"
    "nvidia-390xx-kmod-0028-kernel-6.5-handle-get_user_pages-vmas-argument-remova.patch"
    "nvidia-390xx-kmod-0029-kernel-6.6-backport-drm_gem_prime_handle_to_fd-changes-from-470.patch"
    "nvidia-390xx-kmod-0030-kernel-6.6-refuse-to-load-legacy-module-if-IBT-is-enabled.patch"
    "nvidia-390xx-kmod-0031-kernel-6.8-adaptation.patch"
    "nvidia-390xx-kmod-0032-kernel-6.8-conftest_h-wait_on_bit_lock.patch"
    "nvidia-390xx-kmod-0033-kernel-5.6-ioremap_nocache_removed.patch"
    "nvidia-390xx-kmod-0034-kernel-5.9-dma_is_direct-removed.patch"
    "nvidia-390xx-kmod-0035-gcc14-no-previous-prototype-for-nv_load_dma_map_scatterlist.patch"
    "nvidia-390xx-kmod-0036-undef-NV_ACPI_BUS_GET_DEVICE_PRESENT-in-conftest_sh.patch"
    "nvidia-390xx-kmod-0037-add-RPM_CFLAGS-setup-in-conftest_sh.patch"
    "nvidia-390xx-kmod-0038-workaround-NV_EFI_ENABLED-macro.patch"
    "nvidia-390xx-kmod-0039-incompatible-function-type-nv_gpu_numa_c.patch"
    "nvidia-390xx-kmod-0040-fix-fallthrough-warning-nv_mmap_c.patch"
    "nvidia-390xx-kmod-0041-no-previous-prototype-for-exercise_error_forwarding_va.patch"
    "nvidia-390xx-kmod-0042-undef-NV_DO_GETTIMEOFDAY_PRESENT-in-conftest_sh.patch"
    "nvidia-390xx-kmod-0043-undef-NV_SET_MEMORY_ARRAY_UC_PRESENT-in-conftest_sh.patch"
    "nvidia-390xx-kmod-0044-undef-NV_ACQUIRE_CONSOLE_SEM_PRESENT-in-conftest_sh.patch"
    "nvidia-390xx-kmod-0045-undef-NV_UNSAFE_FOLLOW_PFN_PRESENT-in-conftest_sh.patch"
    "nvidia-390xx-kmod-0046-undef-NV_JIFFIES_TO_TIMESPEC_PRESENT-in-conftest_sh.patch"
    "nvidia-390xx-kmod-0047-undef-NV_PNV_NPU2_INIT_CONTEXT_PRESENT-in-conftest_sh.patch"
    "nvidia-390xx-kmod-0048-fix-atomic64-include-in-conftest_sh.patch"
    "nvidia-390xx-kmod-0049-fix-dma_buf_map-renamed-to-iosys_map.patch"
    "nvidia-390xx-kmod-0050-no-previous-prototype-for-nv_pci_register_driver.patch"
    "nvidia-390xx-kmod-0051-no-previous-prototype-for-nvidia_init_exit_module-in-nv_c.patch"
    "nvidia-390xx-kmod-0052-no-previous-prototype-for-on_nv_assert.patch" 

    "nvidia-390xx-kmod-0053-no-previous-prototype-for-_raw_q_flush.patch"
    "nvidia-390xx-kmod-0054-no-previous-prototype-for-nv-ibmnpu-functions.patch"
    "nvidia-390xx-kmod-0055-no-previous-prototype-for-uvm_tools_init_exit.patch"
    "nvidia-390xx-kmod-0056-no-previous-prototype-for-uvm8_test_set_prefetch_filtering.patch"
    "nvidia-390xx-kmod-0057-no-previous-prototype-in-uvm8_va_space_c.patch"
    "nvidia-390xx-kmod-0058-no-previous-prototype-for-uvm_channel_manager_print_pending_pushes.patch"
    "nvidia-390xx-kmod-0059-no-previous-prototype-in-uvm8_va_range_c.patch"
    "nvidia-390xx-kmod-0060-no-previous-prototype-in-uvm8_range_group_c.patch"
    "nvidia-390xx-kmod-0061-no-previous-prototype-in-uvm8_gpu_replayable_faults_c.patch"
    "nvidia-390xx-kmod-0062-no-previous-prototype-for-block_map.patch"
    "nvidia-390xx-kmod-0063-no-previous-prototype-for-try_get_ptes.patch"
    "nvidia-390xx-kmod-0064-no-previous-prototype-in-uvm8_pushbuffer_c.patch"
    "nvidia-390xx-kmod-0065-no-previous-prototype-in-uvm8_kepler_mmu_c.patch"
    "nvidia-390xx-kmod-0066-no-previous-prototype-in-uvm8_pascal_mmu_c.patch"
    "nvidia-390xx-kmod-0067-no-previous-prototype-for-parse_fault_entry_common.patch"
    "nvidia-390xx-kmod-0068-no-previous-prototype-in-uvm8_volta_access_counter_buffer_c.patch"
    "nvidia-390xx-kmod-0069-no-previous-prototype-for-va_block_set_read_duplication_locked.patch"
    "nvidia-390xx-kmod-0070-no-previous-prototype-for-map_rm_pt_range.patch"
)

NVIDIA GARBLING BUG REPAIRED?! •Yea, the Linux Xlibre Xserver drivers gave CLEAN (w/o side effects) visuals experience after s2disk hibernation & resume. |Still testing it myself: MONOTONIC uptime is 15:09:33.710957. |#Wayland #KMS #Compiz #KWin #modesetting

No buffer garbling on browser window, nor in any another part of Linux screen (including (FB/)console).

It seems than Xlibre Xserver not supports whole-screen gamma/HSV correction,
— but I must test the DRM ownership dmesg's message (not causing the other problems now).

Dear user, remember about uninstalling evdev when you use libinput for mouse pointer, for surety. And the old xf86-* nouveau's Xorg things, also!

No need to rebuild initcpio / initrd!!! I applied the thread-safe version of KMS by some option in X .conf /settings dirs – even if nvidia DDX (that is, Xorg's) not supports it explicitly / supports it in build-in manner already:

The /etc/X11/xorg.conf.d/xlibre.conf , for peace of mind

Section "Device"
    Identifier "nvidia"
    Driver "modesetting"
    Option "Atomic" "on"
EndSection


#Section "ServerFlags"
#    Option "IgnoreABI" "1"
#EndSection
 

—the other driver can be a fallback. Rather not for Wayland, as Wayland depends on another .so libraries (system objects simply – something as DLL in Windows), but Compiz is better than KWin. Rather one thing that the reversal does apply is situation when Fisheye lens effect is necessary – perfectly for showing the astronauts' big fake, the „old-old-stable” he he... hoax.

Browser's card preview is much better under Wayland (than on the old Xorg version), bur in new Xlibre Xorg, garbling of graphics is very, VERY low. 

•While Blender 3D is garbling intensively under OLD X, this one (IMO) depends on GLX quality, not being possible to correct as X/even at Wayland, level. 

•Not surprising if it remains even on „higher” NVIDIA cards, „new” NV open source drivers, etc. 

The ABI seems to be a topic more important only when dealing with Boost libs, Qt, and/or the old buggy Xorg version.

BTW, Python also changes its API interface, a bit. Now it seems to slow down, fortunately.
Standarization is very important.
•In Linux world, the basic interface change you need would be changing LXDE into LXQT. With such DE enabled, Qt big libs can be preloaded into RAM as cache – w/o any prefetch technique!

I have NVIDIA in initcpio as standard – a key for nice 2×boot-splash (that is, starting also as systemd's sevice later!!)  – not wantin' to check if standard fbdev/„NV dev” FB & so on... 

I can't fully understand the console FB's, kernel console takeovers... difficult topic still. Even GRUB2, without grub-customizer application (it needed manual patching !! – I noticed that for sake of „modern” UEFI program on „old” BIOS – but a BIOS working better when DDC VGA(=D-Sub) cable is FULL in pins' number!), is difficult.
 
The boot process is especially DIFFICULT on the RebbeccaBlack OS – despite it has nice (not bug-free, but operating nice... before system crash) Wayland – KWin perfect speed, similar to one of Compiz's on proper NVIDIA-enabled whole-system setting.
 
But KWin is very quick also on the Xlibre Xorg's continuation software. Buggy, at least without system crash (as the Wayland on main system...), but Xlibre not requiring computer to restart!
The compiz start-again script seemed to have influence on Xlibre stability once, but I deactivated it – Compiz is so stable now that I not need to adapt Porteus „wait for device” thoughts into another domain.

The FireDragon Browser is now STABLE at playing Youtube – on the contrary, at OLD Xorg Server, there was hard desynchronizations of YouTube video playback VISUALS.