Fedora Linux 41 released

Red Hat, Fedora, CentOS

Jól látom, ez ma történt? https://fedoramagazine.org/announcing-fedora-linux-41/

https://fedoraproject.org/

Valaki próbálta már esetleg a 41-est?

( ntomasz | 2024. 10. 29., k – 17:30 )

Basszus, egy hete frissítettem a 40-esre.

Hogy repül az idő... :)

nTOMasz
"The hardest thing in this world is to live in it!"

( ulysses v | 2024. 10. 29., k – 18:13 )

Ejha, én még novemberről tudtam. Akkor este frissítek :) 

( locsemege v | 2024. 10. 29., k – 18:58 )

Szerkesztve: 2024. 10. 29., k – 19:00

Már vagy egy hónapja használom, csak nem volt kedvem írni róla, mert minek. A dnf5 tényleg gyors, kicsit szokni kell az elején. Annyi, hogy eddig a dnf erase az a dnf remove alias-a volt, de elavultatták, megszűnt az erase opció, tehát ha van scripted - nekem volt -, amelyben használod, akkor át kell írni remove-ra.

Mit beszéljek róla? Működik, munkahelyen is használom.

Munkahelyi gépen volt egy ijesztő jelenség - de mondom, ez még egy hónapja volt, de lehet, hogy még régebben -, hogy frissítés utáni boot-olásnál emergency módba került, mint amikor nem sikerül mount-olnia a root fs-t, vagy valami szörnyűség. Para, hogy most még command line-ból tudsz valamit kezdeni vele, megpróbálod-e, de vettem egy mély levegőt, reboot, aztán hiba nélkül indult. Azóta sem tudom, mi baja, de talán 6.11.0-s kernel volt, lehetett SELinux probléma, vagy valami nem sikerült a dracut-nak, s elrontotta az initram-ot, bár akkor nem értem, másodjára mitől indult el. Azóta semmi baj.

Illetve desktop gépemen hibernáláshoz tartozó daemon faild-et mond, viszont nem használom a hibernálást, másfelől ezer éve változtattam a default configon, s nyilván a config file-om ott van még, és akár ez is ütközhet a disztribúciót megalkotók elképzeléseivel. Nem nagyon érte el az ingerküszöbömet. RAID1 működik, minden van, hang, levelezés, böngészés, video, Microchip fejlesztői környezet megy rajta, virtualizáció működik.

Valami anomália volt a kulcsokkal, de nekem tiszta install Fedora 18 óta nem volt, azóta csak upgrade, még úgy is, hogy hardware-t és fs layout-ot is cseréltem alatta. Azt hiszem, rövidek voltak az ssh-hoz használt kulcsaim, újra kellett generálni, de az is lehet, más baj volt, s azért generáltam újra, mert azt hittem, ez a gond, már nem emlékszem. Lényeg, hogy megy az ssh kulcsos és password auth is. Távolról továbbra is be tudom kapcsolni a gépet, meg nyilván ki is.

Szóval működik, ahogy szokott. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Hát, nekem most telepítés után működik, bár a korábbi kernellel kellett bebootolnom.

Egy ideje, még Fedora 40 alatt kezdte el csinálni, hogy csak akkor jelenik meg kép, és kéri a jelszót a titkosított lemezhez bootoláskor a Fedora, ha kernel frissítés után lefuttatom ezt a shell script-et:

#!/bin/bash
set -e

if [ "$EUID" -ne 0 ]; then
  echo "A scriptet root felhasználóként kell futtatni."
  exit 1
fi

VERSION=$(rpm -q --last kernel | head -n 1 | awk '{print $1}' | sed 's/kernel-//')
FILENAME="/boot/initramfs-${VERSION}.img"

echo "Kernel verzió:  $VERSION"
echo "initramfs fájl: $FILENAME"

dracut -fv --add-drivers "nvidia nvidia-drm nvidia-modeset nvidia-uvm"  $FILENAME $VERSION

most ez már nem működött, mert telepítés után hiányolta a drivereket, vagy valami egyéb problémája volt.

Az itt kikisérletezett, és leírt módon telepítettem az nvidia drivert, mert nekem a python-os cuda-s lehetőség is kell: https://hup.hu/node/184701 + kiegészítve a fenti scripttel, amit magamnak csináltam, és mindig lefuttattam, ha kernel frissítés is jött.

 

+ 41-re frissítés után kiírta, hogy a boot alatt vészesen kevés a hely (de az nvidia driver update hibát nem ez okozta).

Letöröltem az nvidia drivereket, és most újra fel akartam tenni, de itt már csak hibát mond a gnome update.

Szerintem újrahúzom 0-ról, mert amúgy is írtak valamit az nvidia driverekről, hogy https://fedoramagazine.org/announcing-fedora-linux-41/ Secure Boot support for systems which need the proprietary Nvidia driver

Lehet, hogy felesleges, de tisztább - szárazabb érzés, és nem tart semeddig. - Bár komolyan gondoltam rá, hogy kiírok egy debian-t is, és ha nem megy elsőre az update, azt teszem fel. :)) (de az igazság, hogy az nvidia driver frissítéssel volt csak igazából gondom eddig)

Bár at a Debiant nem neked írtam. :)

Azért az gyilkos, amikor egy awk outputját egy sed-be pipe-olod. Mi az, amit nem lehet megcsinálni az awk-val ott rögvest? Nézd meg az awk sub() függvényét! ;)

Nekem rengeteg beállításom összejött évek alatt, s nem csak a /home alatt, szóval kizárt a tiszta telepítés.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Azért az gyilkos, amikor egy awk outputját egy sed-be pipe-olod.

:)) észre sem vettem, ez így sikerült. :D Nem nagyon szoktam használni az awk-t, csak kicsit ismerem. :)

Debian: az első linux volt, amit sokat kellett céges környezetben használnom, és nagyon szeretem. De utána ez történt a RHEL, és a CentOS-sel is. :)

Igen, az egész head meg csere mehetett volna egy awk, vagy egyetlen sed parancsként (mindkettő tud csak az első sorban műveletet végrehajtani), de végül is nem olyan rossz a scriptje. Alapvető hibakezelés van benne, nagy hülyeséget nem írt bele, az egész működőképesnek látszik. Amit én talán még tanácsolnék neki, hogy univerzálisabb legyen a scriptje:
1) #!/bin/bash helyett #!/bin/sh, ez úgyis Fedorán is a /bin/bash-hoz van symlinkelve, de így több rendszeren is használható lesz a script, jobb lesz a hordozhatósága, a kódban egyébként sincs semmi bashizmus, amihez feltétlen csak Bash lenne jó, és ne futna ksh, dash, stb. shell alatt
2) nem hiba, de kicsit fura, hogy a változóknak nagybetűs a nevük, ezt akkor szokás, ha globális környezeti változóként export-álják őket az egész shellbe
3) én az üzeneteket angolul tenném bele, ez is a script hordozhatóságát javítja, esetleg így más is hasznát venné, aki nem magyar. Tudom, sokan azt szeretik, hogy ha egy magyar rendszeren minden magyarul van, és nincs „kűffődi string” benne hagyva, de ez limitálja a felhasználhatóságot egy nyelvre

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ezek ilyen izomból készült és "lusta" script-ek, amint működött már készen is volt. :) Meg nem is gondoltam, hogy bárhova kiteszem. :) De köszönöm a tippeket, átgondolom és javítom.

Bash programozásban a freebsd alatt érdemes amúgy a bhyve-hoz készült vm utility-t megnézni, én már tervezem egy ideje, de azok nagyon jó script-ek szerintem. A múltkor kerestem benne hibát.
Egy másik, komolyabb szinten van, mint ahogy én csinálok egy scriptet.

1) #!/bin/bash helyett #!/bin/sh, ez úgyis Fedorán is a /bin/bash-hoz van symlinkelve, de így több rendszeren is használható lesz a script, jobb lesz a hordozhatósága, a kódban egyébként sincs semmi bashizmus, amihez feltétlen csak Bash lenne jó, és ne futna ksh, dash, stb. shell alatt
 

NEM. Szigorúan tilos, mert pont Debian-Ubuntunál szokott lenni az, hogy a /bin/sh nem a Bash-hoz, hanem a Dash-hoz van linkelve, ami egy csomo Bashism-ot nem tud. Pont attól lesz hordozható több környezeten a script, ha explicit bash-hoz kötsz, mert akkor nem függesz attól, hogy ott konkrétan a tcsh, a Dash, a Busybox vagy mi a jóisten adja a /bin/sh -t, ha tudod, hogy Bash-ben irod a scriptet.

Szomorú tapasztalat ez sajnos, végtelen sokszor sikerült már beszopnom.

 

3) én az üzeneteket angolul tenném bele

Magamnak írt scriptbe annyira mindegy. Meg hát ha valaki nagyon akarja, Google Translate-tel átteszi, a parancsokból egyértelmű kb hogy mi történik.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Ez a hordozhatóság mennyiben fontos egy kifejezetten Fedora-specifikus scriptben, ami az nVidia driver nyűgjeivel vesződik? Ezen felül jó a legkisebb részhalmaza a shelleknek, csak hát az a jó az adott shell saját tudása, hogy azt használjuk bátran. Azétr tud annyi mindent a bash, hogy éljünk vele, de akkor viszont kötelező interpreterként bash-t mondani neki, mert mással nem lesz kompatibilis s script.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

1) #!/bin/bash helyett #!/bin/sh, ez úgyis Fedorán is a /bin/bash-hoz van symlinkelve, de így több rendszeren is használható lesz a script, jobb lesz a hordozhatósága, a kódban egyébként sincs semmi bashizmus, amihez feltétlen csak Bash lenne jó, és ne futna ksh, dash, stb. shell alatt

Imádom, mikor nem látjátok a fától az erdőt, aztán szajkózzátok a generic best practicet :D Igaz ugyan, hogy a script konkrétan a fedora problémáját akarja megoldani, de azért legyen univerzális. És ha átírod sh-ra, akkor majd milyen jó lesz, hogy megy dashon is. Igaz ugyan, hogy a benne levő rpm hívás nem fog menni, meg ahol megy is, ott majd a konkrétan a fedora nevezéktatnjára ráokosított sedwkhead fog elvérezni. De hordozható lesz, mer sh 🤦🏻

Bezzeg, ha a chatgpt csinálja... :D

Ezt nem tudtam, hogy ez egy Fedora only megoldáshoz készült. Nyilván van, amit nem lehet általánosítani, de best practice gyakorlása akkor se rossz.

Abban igazad van, hogy magamból indulok ki, nekem semmi ilyen babzsákfejlesztős cuccom sincs, se Fedora, se shim, se secure boot, se SELinux, se KDE, se Discovery, se dnf, NV-át se használok, így nem tudom lekövetni milyen az, aki ezeket használja. Amit én írok szkripteket, azok univerzálisak, pont ezért, jó, van 1-2 nagyon ritka kivétel. A dolgom is megkönnyíti, hogy nem kell a Red Hat-nek ezeket a bloat „biztonsági” megoldásaivel meg az NV agymenéseivel harcolnom.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ezt nem tudtam, hogy ez egy Fedora only megoldáshoz készült. Nyilván van, amit nem lehet általánosítani, de best practice gyakorlása akkor se rossz.

Ecsém, hát arról szól a probléma, hogy a fedoraján valamit mindig meg kell mókolni frissítés után. Konkrétan ugye nem tesz be pár drivert az initramfs-be.

Nyilván van, amit nem lehet általánosítani,

Szóval valójában minek kellene általánosítani? Mikor konkrétan a Fedora nem csinál vmit, amit kéne neki az upgrade folyamat alatt.

de best practice gyakorlása akkor se rossz.

De hát ez így faszság, nem best practice.  Semmivel nem lesz jobb semminek, ha oda sh-t ír bash helyett. Vannak dolgok, amik jók, ha általánosak, meg vannak, amik konkrét rendszer intergrációjába nyúlnak bele. Ez utóbbiaknál teljesen felesleges hordozható izével időt tölteni. Nem is lehet, mert ugye konkrét hasfájást old meg.

se dnf,

Hallod, a csomagkezelő az aztán nagy babzsákfejlesztés :D :D :D :D

A dolgom is megkönnyíti, hogy nem kell a Red Hat-nek ezeket a bloat „biztonsági” megoldásaivel meg az NV agymenéseivel harcolnom.

Az nem baj, hogy neked nincs rá igényed, csak jöttél bicikli tárolót festegeteni, mert valójában azt se érted mi történik. Csak itt az eredeti példával ellentétben ráadásul senki nem is akart bringával jönni :D

Ez van, én, ha scriptet írok, akkor is festegetem a biciklitárolót. Ezt fogadd el. Mondom, ebben az esetben nem tudtam, hogy ez egy olyan megoldás, ami Fedorán kívül sehol nem működik. Mert attól, hogy valami Fedorára van írva, és Fedora kapcsán jön elő, azt nem jelenti automatikusan azt, hogy máshol nem működhet.

Tudnád hány ilyen tutorialt, scriptet láttam még, ahol a készítő beharagozta, hogy csak Ubuntu támogatott, meg csak Bash, közben meg belenéztem, és semmi olyan nem volt benne, ami indokolná, ilyenkor könnyen ki szokott derülni az esetek 99%-ban, hogy csak szűk látókörűség, mert az illető épp csak ezeket ismerte, meg ezeken próbálta ki. Oké, legyen igazad, bejött most az az 1%, hogy biciklitároló, ez van, megesik, akármennyire is akarod, nem fogok tőle a kardomba dőlni, továbbra is a best practice híve vagyok, de ha még annyira késztetést érzel rá, ragozhatjuk a végtelenségig, hátha jobban tudod akkor élvezni, hogy most egyszer benéztem valamit, és ez alapján próbálsz általánosságban is lejáratni. Nem is értem téged ez miért zavarna, ha úgyse bringával jössz, én meg lekötöm magam a festegetéssel.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Amikor épp a csomagkezelőt piszkálja, az disztribúció-specifikus. Ezért ebben az esetben lehet bash-only. Írod, egyes scriptekben semmi sem indokolja, hogy a bash dolgait használja. Végülis mindent meg lehet írni nélküle, csak akkor minek fáradoznak a bash írói azoknak a feature-öknek a megírásával, amelyeket beletettek? Szerintem bátran használjuk, azért van!

Munkahelyemen is az van most, hogy van kolléga, aki visszafelé kompatibilitás miatt nyakatekert implementációkat kreál egy műszerbe, míg nekem épp azt mondta a software-es kollégám, aki a műszerrel kommunikáló, bár még azon belül lévő PC software-ét írja, hogy abban a műszerben, amelynek én írom a firmware-ét, bátran engedjem el a fantáziámat, ne kínlódjak visszafelé kompatibilitással, mert a két műszer között olyan nagyok a különbségek, hogy neki mindenképp eltérően kell kezelni, nem megy a kompatibilis, egységes kezelés, akkor meg semmi értelme, ha részeiben kompatibilis, de kellemetlenül korlátolt megoldások vannak benne.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Tényleg, a script kb 5 perc alatt készült, valami egyéb tevékenységek között, amikor én rájöttem, hogy ezt a dracut parancsot nem fogom még egyszer kézzel kiadni, mert keresgetni kell a kernel verziót, és copy pastezgetni. :D

Most csak gondolkodás nélkül bepaste-eltem. Ha rajtam kívül más is használná (nem is gondoltam, hogy ide teszem), akkor jobbra megcsináltam volna, és a sed-en, awk-n is elgondolkodtam volna. Még fel sem commitoltam sehova, ami nem lenne rossz ötlet, mert más ilyan scriptem is van. (pl a freebsd-n az összes jailt felupdate-eli, vagy az ffmpeg van felparaméterezve benne ciklussal meg valami kis plusz dologgal) - egyébként leggyakrabban én is festegetem a bicikli tárolót. :)

Elfogadom én, csak te most tanácsoltad, hogy majd ettől hordozhatóbb lesz. Holott egyáltalán nem. Ha rászántál volna fél percet, te is rájöttél volna. És akkor javasolhattál volna mondjuk olyat, hogy nézd, pl így tudod disztrófüggetlenül megkeresni a kernel verziót. Egy szavam nem lett volna (annak ellenére, hogy cső fölösnek tartom, az ilyen kb egysorosak 99% százalékban pont egy helyen lesznek használva). De nem ezt tetted, hanem előadtál valamit, hogy majd attól jobb lesz. Nem, attól semmi nem lesz jobb. Szóval engem nem zavar, ha te festegetsz magadnak, csak most épp mást akartál festegetésre bírni :)

Amúgy is hülyeség. Ha definiálva van a bash, mint parancsértelmező, akkor nyugodtan lehet benne bashizsmus, ahol van bash, majd fut, ahol nincs, ott nem (most más kérdés, hogy értelme sincs olyan rendszeren futtatni, ahol nincs bash, mert Fedorán képes egyáltalán működni, ott meg van. Korlátozás? Igen. Ahogy ha mondjuk pythont adok meg parancsértelmezőnek, akkor futni fog ott, ahol van Python, ahol nincs ott nem. Mindkét esetben a hordozhatóságnak vannak korlátai.

( dlaszlo | 2024. 10. 29., k – 22:07 )

Szerkesztve: 2024. 10. 29., k – 22:20

Hát, hogy is mondjam...

Felteszem az nvidia drivert, és baromira nem működik, egy fekete képernyővel kifagy az egész, és ez nekem egyet jelent:

Nem próbáltak ki egy 40xx nvidia kártyát úgy, hogy be van kapcsolva a secure boot, és titkosítva van a hdd, tehát jelszót kér az elején. Szerintem elég alapvető dolog, és nem működik.

Most már van egy friss nvidia driverem, és cuda toolkitem. Pont úgy kellett telepíteni, ahogy eddig (nagy kavarással), és az nvidia a f*sz hanyag, mert a legfrissebb cuda-toolkit-et a fedora 39-es repójukból kell feltenni. 41-es még nem létezik, a 40-esben nincs benne... Nem tudom, hogy miért nem lehet ezt úgy megcsinálni, hogy átlátható legyen, hogy mi hol van.

Azt, amit az nvidia driverről állítanak, hogy majd ha gnome-ból telepítem, akkor generál a telepítő egy kulcsot, és azt feltölti a mokutils-sal a secure boot-hoz, hát ez nekem nagyon nem így működik, nyomát sem látom.

Továbbra is használnom kell a kis script-emet, annyi, hogy driver telepítés után ha rebootoltam csak úgy tudok bebootolni, ha a nouveau-t leveszem a kernel paraméterekből a blokkolás listáról. Ha lefutott a dracut-os script, már működik utána minden.

Ezt egy "mezei felhasználó" még mindig nem tudná végigcsinálni, ez az nvidia integráció szerintem egy katasztrófa. Most minden működik, de várom, hogy valami verzió szétcsússzon, mert különböző repo-kból telepítettem az összetartozó dolgokat.

Már gondolkodtam rajta, hogy jobban jártam volna vele... :) Van amúgy egy AMD-s gépem, most nas-ként üzemel, egy 5600G van benne, amiben van GPU is integrálva.

Szerintem a fő gépemnek is elfogadnám, mert meglepően fürge kis masina. :)

De most egy darabig marad az intel + nvidia, mert ez is itt van.

Mert a free driver még mindig egy fos(s). Akármit is írnak rá, a tizedét nem támogatja a mondott kártyáknak, és azokon is épphogy csak működnek a dolgok. Belefáradtam abba, hogy hibákat vadásszak amik a free driver miatt van, és szomorúnak tartom, hogy nincs kikönnyítve még jobban, hogy le lehessen cserélni azonnal a propriertary-ra.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( _ventura_ v | 2024. 10. 30., sze – 07:14 )

This release also removes GNOME's X11 support in the Workstation edition.

Szomorú vagyok, ~13 éve váltottam debianról, fedorara lehet megint hopponálnom kell ...

Fedora 41, Thinkpad x280

Sajnos hasonló dolog lesz nekem is: waylanddal, nvidia driverrel a vice (c64 emulátor) nem frame pontos, akadozik, szaggat. Eleve meg sem jelenik a kép indulás után a vice ablakában, csak ablak átméretezés után. Nem tudom, hogy nvidia driver, wayland, vagy vice hiba, de így nem maradhat, megoldás kell. X11 alatt jó volt. Tegnap éjjel jöttem rá…

https://imgur.com/a/z79bgtK - két gépen is így indul, amíg nem méretezem át az ablakot ez látszik, ha kicsit állítok az ablak méreten, akkor helyre ugrik.

Driver version: 560.35.03

NVIDIA GeForce RTX 4060

Kernel: 6.11.5-300.fc41.x86_64

Gnome 47, Wayland.

Vice verzió:  3.6.1 (GTK3 3.24.43, GLib 2.81.0, Cairo 1.18.0, Pango 1.54.0)

A másik gép egy RTX 4070 Ti Super.

Mi lenne más a gond? X11-el egyébként tökéletes. + ami inkább fájdalmas (és nekem használhatatlanná teszi), hogy például megy egy scroll, ami frame-enként frissülne és waylanddal "riceg"/akad időnként. Vagy egy rasterbár, vagy bármi. - így kódoláshoz nem nagyon lehet használni.

Korábbi driver verziókkal is így működött (egy adott verziótól) a Fedora 40-es alatt, és ott is x11-el használtam emiatt a rendszert.

Most nekifutottam még egyszer, és szerencsére egy mozdulat feltenni az x11-et: https://imgur.com/a/VogvnSw

dnf install gnome-session-xsession

ezután már ki tudtam választani belépéskor a szokásos helyen, megjelent az opció. Remélem működik is minden. :)

Máson derültem. Egyfelől vicces, hogy valaki felteszi a Fedora 40-et, amikor megjelenik a 41, de jó, legyen, Debian szemlélet. Kapott egy +1-et a hozzászólás, de volt egy olyan áthallása, hogy Fedora 40+1, azaz Fedora 41 már az aktuális, amire frissíteni volna jó. :)

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én nem hinném, hogy ez Debian szemlélet lenne. Egyszerűen csak abban reménykedek, hogy pár hónap javítgatás után nem lesz semmi probléma a frissítés után.

De ez persze még sosem jött össze. Maga a frissítés eddig még mindig sikerült elsőre, sosem volt gondom, és ez a 26-os óta van így.

De a frissítés után mindig van valami apróság vagy nagyobb dolog, ami nem működik vagy nem működik helyesen.

 

Egyébként, ha új telepítést kellene csinálnom, akkor nem szórakoznék a 40-essel, akkor menne egyből a 41. Le is húzom az ISO fájlt, és kiírom a telepítős pendrive-ra, hátha kelleni fog...

nTOMasz
"The hardest thing in this world is to live in it!"

Otthoni géppel nem aggódok, inkább kipróbálom, hatalmas probléma esetén max visszateszem a régit.

Céges géppel más lenne a helyzet, de azt sajnos én csak irigykedve olvasom, amikor valakinek ez merül fel kérdésként, hogy frissítse-e a linuxát a céges gépén. Én ott max a windowsomat frissítem (ami szintén fájdalmas tud lenni probléma esetén).

Ne hülyéskedj már, azért mert céges gép, meg félsz a komplikációktól, ezért nem frissíted soha egyáltalán? Felelőtlen halogatás, ez az amíg megy, nem nyúlunk hozzá. Ez nem szentély, épp úgy mentésből vissza tudod tenni a régi rendszert a céges gépen is, mint az otthoni gépeden. Megint más, ha olyan cég, hogy túl szigorúak ilyen tekintetben, akkor lepasszolni egy céges supportosnak, hogy frissítgesse ő, szopjon vele.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

A céges gépemen windows van sajnos (kötelezően), és nem azt mondtam, hogy nem frissíteném, hanem azt, hogy körültekintően tenném. Akár 1 verzióval lemaradva, ha ez kell, mert nem fér bele sajnos időben, hogy a gépemet "reszelgessem", mert valamibe belefutottam. - de mindenképpen egy támogatott verziót használnék. Fedora alatt előferdülnek problémák időről időre, amit bejelentesz, cserébe ingyen kapsz egy szuper rendszert. És nem azt mondom, hogy security patch-eket nem kell rögtön feltenni, csak a főverzió frissítésre gondolok.

(Tudom, windows alatt is vannak gondok, de az legyen az IT osztály problémája, ha már csak azt támogatják.)

Vagy én vagyok ezekre érzéketlen, vagy te finnyás, nem tudom. Három gépem van, mindhármon Fedora 41 kb. másfél hónapja. Az egyik a desktop gépem, használom szórakozásra, munkára egyaránt, semmi bajom vele. Mivel nem bírom a Windows életérzést, van ugyan a munkahelyemen az asztalomon egy windows-os céges gép, amelyet Win-only programokhoz használok, de ott van a másik saját gépem is az asztalomon, szintén Fedora 41-gyel. Semmi baj nincs vele, munkára használom. A harmadik gép pedig a nappaliban, elsősorban zenehallgatás, kaja készítéshez recept nézés, ilyesmi a feladata.

Mindegyik működik. Olyan valóban van, mint például most, hogy a dnf-automatic be volt kapcsolva, majd észrevettem, nem működik az automatikus frissítés. Mivel dnf5 lett, ezért változott ez is, de elég volt újra engedélyezni a timer-ét, így megint működik. Ezt viszont nem érzem olyan mélységű problémának, ami megugorhatatlan lenne. Egyetlen parancs kiadása, s az is csak egyszer.

Mindenhol Xfce + Compiz van.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nos, teljesen igazad van.

Fel is frissítettem 41-re. Mivel a mentésem még aktuális volt amúgy is most volt célszerű, így azzal nem kellett újra bajlódnom.

A szokásos unalom volt a frissítés, hiba nélkül.

És sajnos utána a szokásos dolgok nem működtek, de már megszoktam, és kb. 10 perc alatt majdnem minden újra működik.

Én Gnome-ot használok jó pár kiterjesztéssel, és valamiért az openweather nem működik. Idővel vagy megjavul, vagy keresek mást helyette.

nTOMasz
"The hardest thing in this world is to live in it!"

a szokásos dolgok nem működtek

Mik ezek? Különösképpen, hogy visszatérő. Nekem egyébként szokott arra 10 percem lenni, hogy a könnyen orvosolható problémákat megoldjam. Gnome-os időjárás előrejelzőt nem ismerem, az Xfce-jét használom, az működik. Olyan volt, hogy elfelejtette a beállításait - lehet, hogy épp akkor állítottam le a gépet, amikor update-elte a file-jait, ezt nem tudom -, de ez sem gyakori. Ekkor újra beállítom, és kész.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az egyik ugye az nvidia driver. De ezt gyorsan meg lehet oldani egy

akmods --force --rebuild + restart kombóval.

Aztán ugye a gnome-extension cuccok. Van amikor egyik sem megy, kézzel kell egyesével frissíteni. Most "csak" a felét kellett. De plussz negatívum, hogy az egyik (weather) ugye nem frissíthető.

Ezen kívül a google hitelesítés szokott gondot okozni, újra kell hitelesíteni, utána tudom megnézni az e-maileket (GMail + Evolution). De érdekes módon ez most nem volt, viszont pár hete  a 39 -> 40 frissítés után újra kellett hitelesítenem. Az Online fiókoknál kellett megcsinálni.

Aztán a jelszótároló alkalmazásom (Gnome-os cucc, Titkok a becsületes neve) frissítés után mindig elfelejti, hogy hol van a kulcsfájlom, és meg kell neki adni. De most erre sem volt szükség. :)

Aztán a hangkártya beállítások szoktak még "elmenni", 5.1-ről visszaáll sima sztereó kimenetre, de gondolom most fura lesz, ha azt írom, hogy most megmaradt az 5.1.

Igazából, még sokmindent nem próbáltam ki, de úgy tűnik, hogy javul a frissítés mechanizmusa, már, ha ennek köszönhető, hogy egyelőre kevesebb problémával megúsztam a dolgot.

nTOMasz
"The hardest thing in this world is to live in it!"

AMD gépem van CPU-ba integrált VGA-val, szóval az nVidiát megúsztam. :) Gnome-ot nem használom, tehát azt is megúsztam. Gmail-es levelező fiókom nincs, ezért ez a probléma sem érint. :) Jelszótárolót nem használok. Csak sztereó beállításokra van szükségem, de itt jegyzem meg, a pipewire és wireplumber sokat fejlődtek, valószínűleg ezért jó most már.

Levelezéshez Claws Mail, munkahelyen Thunderbird, működik. Xfce kisalkalmazások szintén működnek. Van egy Intel alapú gépem, ott is megy a VGA egyből.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az nem baj, ha valamennyit vársz vele, de túl sokat nem érdemes. Ha vannak is az új kiadásban hibák, pár nap, max. 1-2 hét és javítják. Azután nem hinném, hogy akármibe is belefutnál, ami a frissítés akadálya lenne. Túl sokat halogatni nem érdemes, nem nyersz vele se időben, se stabilitásban.

Vagy váltasz full rollingra, ott nincs disztróupgrade, egy kiadást használsz örökre, csak a csomagok újulnak meg szép észrevétlenül, egyenként, sose lesz drasztikus rendszercserélődés, ha valami bug is lesz, azonnal izolálható, workaround lesz rá, olyannak nem fogsz találkozni, hogy használhatatlanra törjön a rendszer, ne bootoljon, stb..

“The world runs on Excel spreadsheets.” (Dylan Beattie)

A "hadd forrja ki magát" témához:

Mivel a hivatalos Fedorában elég sok megkötés meg korlátozottság van alapból, én ma már nem bajlódnék vele.

Akkor inkább a Fedorából készülő Ultramarine Linux-ot tenném fel, mert valahogy szimpatikusabb hogy minden benne van, ami az alap Fedorában nincs. Kb. egy hónapra rá jelenik meg az aktuális kiadás.
 

A legelejétől használok Fedorát, előtte Red Hat 7.2 óta Red Hat-et, de nem érzékelek korlátozásokat. Külső programok, mint a Microchip Mplab X IDE és IPE is működnek, virtualizáció megy, p2p VoIP telefonálni tudok, böngészés, levelezés, irodai programcsomag mennek, nyomtatás működik, zenehallgatás, filmnézés működnek, OpenWrt/LEDE router-re image készítés majd telepítés megy, saját fejlesztésű USB-s hőmérő hőmérsékletének panelre kiírása megy, RAID1 HDD-n és SSD-n működik, szóval nem tudom, mi az, amiben korlátozottságot, megkötéseket kellene megtapasztalnom.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( dlaszlo | 2024. 10. 30., sze – 11:43 )

Szerkesztve: 2024. 10. 30., sze – 11:45

Ha másnak is van beragadt "Secure boot dbx konfigurációs frissítés - UEFI secure boot forbidden signature database" csomagja a gnome szofverközpontban, ami se jobbra, se balra, és nem lehet feltenni:

sudo dnf reinstall dbxtool
sudo pkcon refresh force
sudo systemctl restart packagekit
sudo fwupdmgr update

Ezután végre eltűnt...

+1, de annyiból jó egyébként (pl a családban idősebbek gépére), hogy kb annyira meg van csinálva, mint egy windows update.

Azaz: 1. kitalálja, hogy frissítések érkeztek, 2. feldobja a figyelmeztetést, 3. rá kell klikkelni, hogy "most telepíted", 4. újraindítja a gépet, és indításkor felkúsznak a frissítések. 5. megint újraindítja.

Míg a másiknál, amit xfce alatt találtam, ott soha senki nem frissített.

Ezt az egyet nem szeretem a Fedorában, hogy a Windowst utánozza update-kor, hogy csak újraindítás után frissít. Szerintem használd helyette a terminált, úgy frissíts dnf-fel, mert akkor ott még futás közben frissít, és tudod használni közben a gépet, nem reboot közben várakoztat meg, amikor tényleg nem használhatod a gépet.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ezt sose értettem, hogy még szakemberek közül is miért ódzkodnak ennyire sokan a termináltól, mintha az ördög műve lenne, és embereket vinne el miatta a mentő. Még egy frissítés erejéig 1-2 sor terjedelemben sem merik használni, annyira félnek tőle, mint a tűztől. Szerintem egy ilyen frissítés jó alkalom, hogy ha valaki nem volt eddig Terminál Matyi, az valamennyi gyakorlatot szerezzen benne, ismerkedjen vele.

A shell és a terminál szerintem a *nix rendszerek legjobb része. Elsőre idegennek, szokatlannak tűnhet, de simán megszokható, és értékes tudás is headless, felhős, embedded, stb. cuccokhoz, meg automatizáláshoz, debugoláshoz, tehát még azt se mondanám, hogy felesleges időzpazarlás, mazohista önszopatás lenne, amivel csak nolifer emberkék töltenék ki az időt.

Ezt az indokolatlan terminálfélelmet még laikusoktól sem tudom elfogadni, én se vagyok informatikus, sem mérnökúr ( ®© hajbi), meg számos más embert ismerek, akik szintén nem azok, és simán megtanultuk. Semmi ilyen jogszabály nincs, hogy mindent GUI-ból lehet csak csinálni, és ehhez köteles mindenki GUI eszközöket biztosítani. Még Windows alatt sem igaz, mert néha ott is kell telepítő alatt Helyreállító Konzolból diskpart-tal és bootolás helyreállításával szórakozni, meg cmd/Powershellben egy soros okosságokat futtatni (pl. aktivációkor), meg Registry-t hekkelni, meg Policy Editorban vitézkedni, amik semmivel nem felhasználóbarátabbak, mint egy *nix-es shell vagy terminál, csak a Windowst már mindenki megszokta, és annak elnézik. Egyszerű elfogultság és képmutatás, meg szemellenzős ragaszkodás a jól megszokotthoz.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Terminált használom leggyakrabban. :) Eleve hasznos, mert ha valami baj van, egy live oprendszer ad egy konzolt, aztán lehet megoldani a problémát. Ja, meg fejlesztés alatt álló műszerhez is C-ben egy konzolos alkalmazást írtam, amivel parancsokat tudok adni a műszernek, vagy például logot le tudok kérni tőle.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Persze, bárki meg tudja tanulni. A 70-90-es években a normik is simán használták a konzolos shellt, CP/M, MS-DOS, stb. alatt, kicsit nyűgtek, hogy tanulni kell hozzá, de simán megszokták, hangsúlyozom, hogy nem az informatikusokról beszélek, hanem teljesen normál felhasználókról. Teljesen könnyedén nyomatták rajta a CLI/TUI programokat, Wordstar, VisiCalc, Lotus-1-2-3, Wordperfect, Word for DOS, IBM Personal Editor, Norton Commander, Xtree, stb.. Kénytelenek is voltak, mert nem nagyon volt más, GUI csak Mac-en volt elterjedve, meg nagyon drága unixos workstation gépeken.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Napi szinten használom a terminált, és unix típusú rendszereket is ott kezdtem el megismerni még gyerekkoromban, nem gui-n. De anyósomtól pl nem várható el. Ő joggal elvárja (és a legtöbb felhasználó is), hogy van egy számítógépe, akkor a frissítés két kattintás legyen. Persze, jobban  jár egy Fedora-val szerintem, mint a Windowssal, de nem baj az, ha jól működik a frissítés, és szépen végigviszi. (egyébként engem kérne meg, hogy frissítsem a gépét)

Akiket ismerek szakembereket (legtöbben fejlesztők, üzemeltetők), nem ódzkodnak a termináltól. Ismerek olyan menedzsereket is, akik ezt már nem hajlandók használni.

Vannak területek, ahol eleve utálom a GUI-t. Ilyen pl a verziókezelők felülete. Ki nem állhatom, ha egy random kézrándulás miatt véletlen átmozgatok valamit, vagy a felületen kell keresgélnem, hogy hova kattintsak.

A termnál sokkal kevésbé áttekinthető egy laikusnak, sokkal nehezebb lekövetni, hogy mi történik, miért és hogyan. Ráadásul az, hogy valamit gépelni kell hogy történjen valami, nem a természetes módja a dolgok használatának. Gondold el, ha egy kalapács használatához be kellene valahogy minden alkalommal pötyögni, hogy "sudo bonk --force=2 --count=5"... Abszolút nem természetes. Ehhez képest egy GUI sokkal közelebb van ahhoz, ahogy naturálisan használják - a laikusok - a dolgokat: rákattintok gombra, történik valami. Nyomok még egy gombot, történik még valami.

Szóval, laikusnál igenis van értelme a GUI-knak, sokkal kevésbé tudnak elbökni dolgokat. Főleg, hogy sokszor az elgépelést sem díjazza a terminál, mert nincs ilyen kis hullámos kijelölés, hogy azt az upgrade-t te nem update-nek gondoltad?

Szakmabelinél meg ízlés és szokás kérdése. Attól, mert informatikus vagy, nem feltétlenül terminálban éled az életedet. Én is szeretem a GUI-s dolgokat, pláne, hogy ha push jeleznek, hogy halló, van update.

Az teljesen más, amikor valamit kell parancssorból futtatni 1-1 dolgot (bár hogy egy laikus mikor fog neked diskpart-ot futtatni vagy PowerShellben akármit, arra nagyon kiváncsi lennék, kicsit összecsúsztak ott a gondolatok), meg más az, amit rendszeresen kell futtatni (rendszer update).

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Nem biztos. Persze most már mindenki gyerekkorban találkozik GUI-val, ha máshol nem a telefonon, tableten. Én viszont voltam olyan helyzetben, hogy idősebb embereket (akik mellesleg informatikusok voltak) kellett rávennem a GUI és az egér használatára (90-es évek legeleje). Elég sokat szenvedtek vele. Ők még ahhoz szoktak, hogy a számítógépen gépeléssel kell kiadni parancsokat, aztán kaptak OS/2-t és Windowst.

Szerintem ki is írja a dnf ha újra kell indítani valami futó service-t. Én kernel update után azért indítom újra a gépet, ha van időm, hogy ne következő bootnál érjen meglepetés. Volt már rá példa. Pl lehalt a bluetooth, ha jól emlékszem Te segítettél, hol vegyem fel a hibát nekik. De az nvidia driver már többször megszívatott, ott elképzelhető időnként kézi beavatkozás. - persze a korábbi kernellel be lehet bootolni.

Böngészőt, levelezőt be szoktam zárni, ha épp frissül, mert volt ilyen tapasztalatom nekem is, de szerintem nem jó irány, hogy állandóan indítsuk újra a gépet. Az alkalmazás bezárása azért mégsem a gép újraindítása.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerintem meg jó irány. Egy desktop rendszer nem szerver, nem kell uptime-ra húzni. És több különböző esetben is tapasztaltam már, hogy akkor stabil a rendszer, ha egy nagyobb update után újraindítom. Especially kernel vagy videó driver update után, az újonnan induló videókártya-használó cuccok néha összefossák magukat, restart után meg jó egyből.

Én is rászoktam, hogy ha látom a frissítések közt, hogy kernel, nvidia, böngésző, stb, akkor utána reboot. Nincs 1 perc hogy újraindul az egész gép, abszolút semmi időt nem vesztek vele.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Persze, ha épp zenét hallgatsz, meg elolvasod, ki kit ölt meg, akkor nem gond, de amikor benn van egy rakás terminál, fejlesztői környezet, soros terminál, böngésző, de nem csak hírek olvasására, kapcsolási rajzok, MCU és egyéb vackok dokumentációi, akkor nagyon fájdalmas a reboot. Szóval akkor úgy vagyok vele, örülök én az új kernelnek, de ezt a napot már ezzel csinálom végig.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kényelemről beszélünk. Műszert fejlesztek, soros interface-en írja a logjait, moserial terminalon nézem. Lehet file-ba menteni, de nem szeretném, mert azzal is az idő megy, hogy kitaláljam, hova tegyem és milyen névvel. Ráadásul legtöbbször reprodukálható a log, de szeretném ezeket elkerülni, mert idő. Nincs bajom a reboot-tal a gép bekapcsolása után közvetlenül, vagy a kikapcsolása után - illetve ezáltal helyett, aztán majd kikapcsolom utána -, de az is megoldás, hogy valamikor frissítek, nap végén leállítom a gépet, aztán másnap már az új libeket használja, az új kernellel boot-ol, és a többi. Csak munka közben nem akarok ezzel foglalkozni, mert nem poén.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

ezt remelem nem komolyan dobtad be ide... :D

The moserial Project

 

Contents

moserial is a clean, friendly gtk-based serial terminal for the gnome desktop. It is written in Vala.

 

Features

  • ASCII and HEX views of incoming and outgoing data
  • Logging to file of incoming and/or outgoing data
  • Support for x, y, and z-modem file send and receive
  • Support for profile files, to load/save common configurations
  • Easier to use than the alternatives
  • Supports i18n
  • It even has docs!

de - mint masik kommentben irod is - max 1 napig. se. aminek az elejen meg frisstgetsz es ugyis rebootolsz ha kell. meg mielott csinalnal barmit. nap vegen meg megy a poweroff. akkor meg hol a problem? :) ha meg tenyleg akarod latni, a szoftvered pont tudja. win-win. nem is ertem :D
azon mélázok, mi legyen a logfile neve és melyik alkönyvtárba mentsem > /var/log/serial/`date "+%Y-%m-%d %H:%M"`.log :) olyan sokat tenyleg nem erdemes melazni ezen :)

Ez világos, kicsit túl is beszéltük. Nem kell a gépet újraindítani azonnal, nap végéig elvan, függetlenül attól, mikor kerültek rá a frissítések. Más egy szerver, ami állandóan jár, de egy desktop munkagépen ez nem probléma.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Várjál, milyen soros terminál ez? Min keresztül használod? Mert sok terminálos megoldás ugye bufferel, és a célgépet hiába indítod újra, a terminálban megmaradnak az előzmények is görgethetően. De igazuk van az előttem szólóknak, a logokat fájlba kell küldeni, ott tovább megmarad, hosszabban visszakereshető, szűrhető.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

moserial

Mikrokontroller kitárja a lelkét 115200 baud, 8n1 formában, ezt megetetem egy TTL szintű RS232-USB bridge-dzsel, terminálon láthatóvá válik, én meg nézek magam elé, hogy de hát miért épp így történnek dolgok? :) Aztán kijavítom a firmware hibát.

sok terminálos megoldás ugye bufferel

RAM-ban, aminek nem nagyon tesz jót a reboot. :)

igazuk van az előttem szólóknak, a logokat fájlba kell küldeni, ott tovább megmarad

Amennyiben nem lenne elég bajom, valóban felakasztanám a viharlámpát is a tökömre, hogy éjjel is tudjak dolgozni, de ha ezeket az önsorsrontó ténykedéseket kizárjuk a fejlesztés tevékenységéből, akkor marad az a változat, hogy a munka kellős közepén nem indítjuk újra a gépet, mert az úgy hiányzik, mint üveges tótnak a hanyatt esés.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Lényegében én. :) Naponta újraindítom, mert este leállítom, reggel meg elindítom a számítógépet. Amúgy most mi a vita tárgya? Kell-e reboot frissítés után? Nem kell. Azt a napot végig lehet csinálni reboot nélkül is. Ugyanakkor szoktam reggel frissíteni, s ha van valami megkerülhetetlen komponens, pl. kernel, systemd, akkor újraindítom, s csak utána indítom a böngészőt, levelezőt, verziókezelőt, fejlesztői környezetet, kapcsolási rajzok, dokumentációk pdf file-jait nyitom meg, és így tovább. Ami kell.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Jó, de ha kikapcsolod, akkor mit akarnál rajta mégis látni. Az a baj, hogy játszod a hülyét, és nem áll jól. Ha reboot, kikapcsolás előtti dolgokat akarsz látni, arra a logfájl való. Attól, hogy valami logfájlba megy, attól még párjuzamosan watch-csal, head-del, hasonlóval nézheted realtime, amikor épp megy a terminálod. Nem látom hol itt a probléma.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

A kényelmetlenség a probléma. Nem azt mondtam, hogy ezek megoldhatatlan dolgok, csak azt, hogy ha megoldom őket, az elviszi a fókuszt, és nem az eredeti műszaki problémával foglalkozom, hanem „linuxozok”, amivel semmi baj, csak kicsit nagy lesz az overhead. Sok munkavégzésből kevés fordítódik a probléma megoldására.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Kernelfrissítésnél sem szoktam mindig újraindítani, mert minek, elvan még a jelenlegivel. Archnál szívtam meg párszor, mert az hajlamos az új kernel felrakásakor akár a jelenlegit is leszedni, ami nem probléma - addig, amíg épp röptében nem kéne betölteni egy addig nem használt kernelmodult, és a /lib/modules/kernelverzió könyvtár már nem létezik :)

Nem bug, feature :) Nem szeretem ezt a viselkedést, nekem szimpatikusabb, ha mondjuk egy kernelfrissítés után megmarad az előző (illetve az aktuális), és a régi csomagot pedig majd az autoremove paranccsal törlöm le, illetve azt is hasznosnak tartom, hogy legalább két kernel van a gépen. De a pacman egyszerűen linuxnak nevezi az aktuális kernelt, tehát upgrade-nél felteszi az új kernelt, természetesen törli a régit. Biztonsági megoldásként fel lehet tenni a linux-lts csomagot is, az az aktuális lts verziót tartalmazza, tehát ha valamiért elszállt az új kernel, még be lehet bootolni.

Szerintem bug, mert a modulokat dinamikusan tölti be. Mi a fenét csinálsz, ha kernel frissítés után csatolnál egy filerendszert, de már nincs az adott kernelverzióhoz tartozó modulja? Lényegében kirántod alóla a szőnyeget, az van, ami épp a memóriában van, ami meg nincs, de kellene, az meg már nem is lesz.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( Friczy v | 2024. 10. 31., cs – 09:18 )

Tesztként feltettem egy Fedorát a Vmware Fusionba (Mac, arm verzió), frissítettem 41-re, és gondoltam, feldobom rá a 6.2-es KDE-t. Na most a wiki szerint 

dnf install @kde-desktop-environment vagy dnf groupinstall "KDE Plasma Workspaces" a megfelelő varázsszó.

dnf groupinstall ebben a formában nem létezik már, dnf group list viszont semmi KDE vagy plasma desktopot nem listáz. Olvastam, hogy van valami kavar az arm KDE körül, lehet, hogy ez az oka, hogy nem létezik a group listában. Ha mégis szeretném feltenni, akkor vajon milyen csomagot kéne feltelepítenem hozzá? A sima listában plasma-desktop létezik, vajon az felhúzza függőségként a többit?

Amikor néztem a letöltéseket, akkro aarch64 image-ek mind raw.xz formátumúak voltak, azt viszont a vmware fusion nem ette meg. Örültem, hogy találtam egy sima .iso-t. Megnézem a plasma-desktop csomagot, aztán ha nem jó, akkor új vm, és megpróbálom a kde-spint. úgyis csak játszani, ismerkedni kell, szóval nem kár érte, ha törlöm.

A plasma-desktop telepítése felrántott függőségként >300 csomagot, és határozottan KDE-nek látszik a felület :) Mondjuk bűn lassú, a hang is akadozik, de szerintem ennek az az elsődleges oka, hogy a Vmware Fusionban úgy látom, nincs arm Linuxhoz vmware-tools, Windowshoz persze van.

Érdekes volt a folytatás. Utánaolvasva kiderült, hogy vmware-tools már nincs Linuxhoz, nem is lesz, viszont a frissebb Linuxokban (including Fedora) open-vm-tools és open-vm-tools-desktop csomagok meg megfelelő kernel modulok helyből benne vannak, és így nem is kell. És valóban, pl. Gnome alatt simán megy az átméretezés meg minden egyéb, KDE alatt nem, ráadásul a képernyőbeállítások sem jelennek meg a beállítások közt. Kerestem valami KDE displayre utaló csomagot (most nem jut eszembe a neve, feltettem ezt is (a dnf hozott vele még egy rakás csomagot), az eredmény jelenleg az, hogy ha a bejelentkezéskor Plasmát választok ki, akkor a jelszó begépelése és az enter után visszatér a login screenhez. Szóval sokat javult :D Logot még nem néztem.

( szkaresz v | 2024. 10. 31., cs – 10:11 )

Frissítettem. Kivételesen kipróbáltam a KDE Plasma Discover-en keresztül. Elég jól ment. Megcsinált mindent amit korábban terminálablakban kellett végrehajtani.

Legyalulta a plasma-workspace-x11-et a hozzátartozó függőségekkel együtt. Nem kellett volna. Ebbe beleértette a Displaycal-t is amit Fedora 32-óta sikerült békén hagynia a frissítések során a függőségeivel együtt. Van egy Displaycal python script amit új projektként kezelnek. Nekem még egyszer sem sikerült életet lehelni bele.  Egyenlőre visszalépek 10 évet és Windowson kalibrálom a monitorom és a kapott icc-t betöltöm a Waylandhoz. :)  Kétségtelen, hogy a Wayland mostanra gyorsabb lett mint tisztes korban lévő elődje, még ha nem is olyan stabil.

Van még egy új szolgáltatás amit nem értek, minden ok nélkül, műveletektől függetlenül elsötétül a monitor majd újraéled. Ezt a szolgáltatást  eddig csak Windows-os gépeken tapasztaltam mint egyfajta rejtély,  most én is megkaptam.

Karesz

Letölthető háttérképek  |  Portréfotók

És jól tetted, mert nagyon gyenge lábakon áll szerintem.

Gondolom nincs kapacitás minden esetet kitesztelni, de:

- ha titkosítva van a partíció
- be van kapcsolva a secure boot
- nvidia videókártyád van a nonfree repóból letölthető driverrel

Akkor utána el sem indul a gép.

Félreérthető amit írtam. Most úgy frissítettem, hogy a Kde Discover csomag kezelőt használtam.

Jelezte, hogy megjelent a Fedora 41 és frissítsek! 🙂

Na ez működött úgy mint egy "gyalugép" 😄

Valószínűleg a háttérben ez is dnf-et használja csak olyan beállítással, ami nem kíméli a régebbi, de nem ütköző pl. lib fájlokat. Gondolom a gondmentes egyszerűségre gyúrtak a fejlesztők.

Karesz

Letölthető háttérképek  |  Portréfotók

( dlaszlo | 2024. 11. 10., v – 10:33 )

Szerkesztve: 2024. 11. 10., v – 10:34

Egyébként úgy tűnik, lekopogom, hogy nekem telepítés után semmi hiba. Persze ez csak egy gép, egy konfiguráció. Felment az nvidia driver, kicsit nehézkesen, és azóta szépen teszi a dolgát. Az video driver, és kernel update-ek is jól működnek (amitől kicsit tartottam, hogy nyögvenyelős marad).

( msandor v | 2024. 11. 11., h – 10:01 )

Örülök az ilyen témáknak, mert totál kiment a fejemből, hogy kijött az új verzió, mehet az upgrade.