Fedora 37

Hozzászólások

Én az október 18-as F37 kiadásra frissítettem, amihez most update hozzájött a Plasma 5.26.2 és a KDE Frameworks 5.99.0.

Na azóta, ha Gwenview-ből másolok / mozgatok képfájlokat, a már átmásolt fájlt akarja felülírni és hiába skippelem vagy engedélyezem nem haladunk tovább. :(

És mostantól támogatott a Raspberry Pi 4 is. :)
A régebbi ARMv7 azaz 32 bites modellek nem!

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Debian parti vagyok, az is fut 8+ eve 24/24-et a mukaallomasomon, de par hete frissitettem a hardware-t es sajna Debian 11 nem jatszik a regi kernel miatt, foleg mert az uj gep AMD Zen3+, igy nagyon kellene a 6.x kernel. Probaltam a kernelt backport-bol de sajna vbox csomag modulja nem fordul gcc verzio miatt, SID/testing nem jatszik, mert munkaallomas. Ubuntu 22.04-et telepitettem es 2 hete hasznalom de nagyon csalodott vagyok. Jatszadoztam a 37 Silverblue, Worskstation variansokkal es nagy a kulombseg ubuntuhoz kepest (a jo ertelemben), u.h. migralas lesz Fedora 37 Workstation-ra. Sajnos a Silverblue meg nem jatszik mivel tobb alkalmazas alapbol nem hajlando telepulni/futni a RO root filerendszer miatt.

Altalanos sebesseg erzet.

Debian 11-en, i7 3770K, Samsung SATA3 SSD, 16GB DDR3 (XMP OC) az UI reakcioido es app inditas egy pillantas, Ubuntu 22.04,  Ryzen 7 PRO 5850U, Samsung NVME Gen 3 SSD, 32GB DDR4, lassu app indulas, elejen meg eleg jol valt de tobb nyitott bongeszo, IDE, terminal a munkanap kozepe/vege fele mar "szogletes" es lassu (Wayland es X11  ugyanaz a tapasztalat, videomemoria 4GB). Bizonyos operaciok nagyobb terheles alatt az egesz UI-t baromira belassitjak es akadozik, Debian alatt ez sosem tortent meg. Baromira zavaro. Sleep-bol 15-20mp amig folebred (Fedora alatt 1s es megneztem es lemegy mely alvasba), az amdgpu linux firmware bug-os, sleepbol viszaterve a dock-ra kapcsolt kulso monitor nem ebd fol csak ki es bekapcsolas utan, manualisan upgradeltem a firmware-t es helyreallt.
Nem tudom mi lehet az oka de nem is vagyok hajlando "drotozni", ha van mas distro ami alapbol jol megy. Talan a kulonbozo GTK verziok egyvekege, a "regi" kernel, fene tudja.

A Beta Fedora 37-el jatszadoztam, nem  hasznaltam meg melora, de telepites utan minden ment egybol, 0 mokolas, 6.x kernel es "sima" reakcio ablak valtas es app inditaskor kulonbozo terheleseken.

Ja meg a gnome shell extensionok, azoktol eleg gyakran dob hatast a gjs, foleg sleepbol valo foleledes utan, ugyanazok a kiterjesztesek (termesztesen a Gnome verziohoz igazitva) Fedora alatt gond nelkul elketyegnek.

Az audio forras kivalasztas egy remalom, dock, HDMI, fules, alapbol ramegy a HDMI-re, fuggetlenul attol, hogy van e vagy nincs csatlakoztatva fules. Fedora alatt valamiert mukodik a dbus intergracio es ha a fules be van dugva vagy bedugom akor az lesz az alapertelmezett. Ubuntu alatt nehe megy, neha meg leragad a HDMI-nel vagy random a dock audio portjara annak ellenere, hogy nincs radugva semmi.

 

Tehat kerekebb es kezreallobb, nincs az az erzesem, hogy utamba allna melo kozben, mikor nincs szuksegem ezekre a figyelem elterelo muveletekre.

Wim Taymans úgy eredendően Fedora - meg gondolom, Red Hat - fejlesztő, ő a pipewire fő fejlesztője egyben. Amint kiad a gitlab-on egy új pipewire release-t, a build szerveren már ott van kb. egy óra múlva lefordítva a legfrissebb pipewire Fedorára. Ezen felül két pipewire release között is egy-egy kritikusnak ítélt patch-et backportol és csinál belőle csomagot. Fedorán ezért elég jó a pipewire, de azért nem hibátlan, olykor regressziókba is bele lehet futni.

És akkor ehhez képest még olyan is van, hogy szoktam forrásból build-elni és rpm csomagot készíteni gitlab repóból kihúzott pipewire-ről. :)

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

Ezert jo valasztas a btrfs es/vagy silverblue, rollback es varunk a javitasig, de nem kell szoszolni.

Sajnos a Silverblue nem jott be, a btrfs nem tudom, a workload-om alapjan ext4 lenne a jobb valaasztas, igy majd tradicionalis rollback es  gyakori automata incremental backup snapshoting filerendszerre.

És ma reggel már meg is érkezett a javítás.

Szerintem a Btrfs jobban teljesít szerver alkalmazásokon is. Telepítéskor, beállítja nodatacow értéket és alkalmazza a tmpfs-t is. Hw támogatott checksum - algoritmus crc32c-intel , zstd compression level 1, space caching v2,  ssd optimization. Az 5.20-as kerneltől támogatja a full data stream-et (data and metadata). A tmpfs tartalma auto elmenthető és visszaállítható rendszerindításkor, igaz ezt még nem tudtam tesztelni.

devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=4096k,nr_inodes=1048576,mode=755,inode64)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,seclabel,inode64)
tmpfs on /run type tmpfs (rw,nosuid,nodev,seclabel,size=3153224k,nr_inodes=819200,mode=755,inode64)
vendorfw on /usr/lib/firmware/vendor type tmpfs (rw,relatime,seclabel,inode64)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,seclabel,size=7883060k,nr_inodes=1048576,inode64)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,seclabel,size=1576608k,nr_inodes=394152,mode=700,uid=1000,gid=1000,inode64)

A Timeshift+btrfs mentést és visszaállítást a csak Manjaron tudtam tesztelni, de eszméletlen kényelmes. Észrevehetetlen a mentés folyamata, a visszaállítás meg tökéletes. Legkisebb nem kívánatos változtatást is visszaállítja. pl: a mysql telepítés beállítás során sikerült teljesen kizárni magam, töröltem a root felhasználót, de nem jött létre az új:) és kiléptem.  1 perc volt a rendszer helyreállítása.
 

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek 

Én rdiff-backup-ot használok offline HDD-re. Lassú, de mindig a legfrissebb backup a bázis, a korábbiak ehhez képest dekrementális backup-ok. Van RAID1-em, ext4-et használok LVM fölött, szóval ha nagyon akarnám, snapshotjaim is lehetnének, de az kicsit falná a helyet. Virtuális gépben volt, hogy figyelmetlenségből default btrfs lett, de azzal sincs baj.

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

Nem ismerem, de gondolnám, hogy a btrfs snapshot foglalja a legkevesebb helyet, mivel checksum alapján csak a fájl változást menti a többire linket készít. De most olvasom az rdiff ami rsync*re épül és "rdiff-backup csak az előző biztonsági mentés és a következő (úgynevezett fordított növekményes biztonsági mentés ) közötti különbségeket tárolja" Hasonló a módszer:)

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek 

Egy hete megtortent az upgrade a munkaallomasomon is es egyelore boldogsag van. ~1 honapot hasznaltam Ubuntu 22.04-et es a Fedora 37 egy megvaltas hozza kepest.

Egyelore marad, meglatom, hogy maradando e az "uj baratsag" vagy ropulok Debian 12-re amint megjelenik.

A fentiek mellett én csak annyit tennék hozzá, hogy a Fedora bizonyos esetekben ragaszkodik az őskövületekhez.

Például Sigil-ből még most is a 0.9.14-et hozza, a jelenlegi 1.9.20 helyett (állítólag nem tudják lefordítani amit nem akarok elhinni), vagy a másik példám a p7zip 16.02 most is a Fedorában, míg az OpenSuse már rég átállt az eredeti fejlesztő által kiadott 22.01-re.

Biztos vannak még ilyenek, én ezekbe futottam bele, és ezt azóta sem értem.

Nem akarom a Fedorát védeni, mert nem értek egyet több dolgukkal, de ez, amit írsz, egy más rolling disztrókon is előfordul. Pl. Archon a Sigil épp nem, de pl. a p7zip 17.04 a mai napig, Bash jó ideje megrekedve 5.1-en a jelenlegi 5.2 helyett. A Thunderbird 100-ra is valami 6-8 extra hetet kellett várni, valami konfigolós. profil update-es picsogás miatt. De volt már elmaradva a glibc is sok verzióval vagy fél éven át.

Hasonlókkal találkoztam Void-on és Gentoo-n is.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Tegnap frissült végre Arch-on a Bash 5.2-re, nem látok vele problémát. Az is igaz, hogy a scriptjeim nagy része szigorúbban POSIX kompabilis /bin/sh-t használ (ami a Dash-ra van symlinkelve) és kerülöm bennük a bashizmusokat. Csak egy pár script van, ahol valami speciális read vagy egyéb miatt kellett kifejezetten a Bash, de azok is működnek, ahogy néztem. ~/.bashrc sem tört el.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Időközben debugoltam, megtaláltam, mi történik, aztán jeleztem a Fedora bugzillában is, meg a GNU Bash fejlesztőjénél is. Ez utóbbi megköszönte, de már tudott róla, van hozzá patch is talán. Persze forrásban valahol, release talán még nincs belőle, Fedorához meg nincs újabb: bash-5.2.9-3.fc37.x86_64

Arról van szó, hogy ha read belső parancsot használsz -t timeout paraméterrel, majd picit később újra használsz read belső parancsot, de már timeout nélkül, akkor ez utóbbi read is az első timeout idejével fog működni. Ennek az a következménye, hogy ha a második read vár valamit, például y vagy n lenyomását, a korábbi timeout-os read idejének indokolatlan használata miatt tovább megy, nem vár, s üres string lesz a beolvasott érték. Ez az, ami még az 5.1-ben jó volt.

Valószínűleg valaminek az inicializálása marad el. Néztem a forráskódját, megtaláltam a file-t, amelyben javítani kellene, de eléggé össze van nőve a többi paraméter feldolgozásával, szóval gondolkodós, inkább megvárom, amíg megjavítják hivatalból.

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

Aha. Használok én is ilyet, pont az egyik watch-pótló scriptem azért használ /bin/bash shebanget, mert konkrétan ez a read -t seconds -n 1 kell (replikálható subshellben hívott dd-vel és kill-el POSIX shellből, de elég macerás és ronda hack), viszont én egyrészt nem hívok utána másik read-et, illetve az is lehet. Nálam az 5.2.0-s verzió van fent, valószínűleg ez még nem patchelt.

A watch-t és klónjait azért nem szeretem, mert csak Crtl+C-vel lehet kilépni belőle. Nem is értem, hogy millió éve nem teszik bele egyik ilyen progiba se, hogy valami beállítható kilépési módozat legyen benne.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Ja, elég hasznos. Vannak klónjai is. BSD-ken is elérhető gnuwatch-ként.

A másik hasznos parancs, amit nem szokott senki ismerni, az az „entr”. Fájlokhoz lehet lefuttatandó műveletet rendelni, onnantól figyeli a fájlt, ha az megváltozott, akkor futtatja a hozzárendelt műveletet. Hasznos, ha IDE nélkül akarsz forráskódot fordítani vagy interpretálva futtatni, pl. én vim-et használok és ha C-ben, vagy XeTeX-ben megírt cuccot kell fordítani, akkor csak mentem a fájlt, és az entr újrafordítja. Nem kell így külön compile funkció a text editorba.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

De, nagyon hasonló, mint az inotify. Nem része ugyan az inotify-tools-nak, hanem külön csomag, de általában minden disztró tárolójában ott van. Csak azért említem, mert rettenet hasznos az is, és nem sokan ismerik. Én is egy maces-iPad-es angol fószer videójában hallottam róla pár hónapja, ahogy mutogatta shellben a hasznos parancsokat.

Lehetne éppen inotify-t is használni helyette, azt még nem használtam. Lehet megnézem azt is magamnak egy ponton.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Ez az entr is inotify-t használ, ami persze nem baj, mert erre való:

Description: A utility for running arbitrary commands when files change. Uses
inotify to avoid polling. It was written to make rapid feedback
and automated testing natural and completely ordinary.

 

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

Csak én látok temetőt ebbe a képbe?

Először simán temetőnek néztem én is. Annyira nem ronda egyébként, csak béna. Az is igaz, hogy nem tudok túl szigorú lenni ezért, a legtöbb disztrón vagy valami unalmas corporate/brand logó háttér van default, vagy valami másik béna háttérkép, rosszabb esetben még lehet oltári ocsmány is, mint az Ubuntuk állatos-lilás hátterei, azok tényleg merénylet a közízlés ellen.

Ez mindenkinek szinte az első lépése, hogy lecserélje. Vannak rá kifejezetten DE-khez készült wallpaper csomagok (gnome, mate, elementary, stb., ezek használhatók nem csak a saját DE-jükhöz, hanem bármihez), meg egy csomó git tároló, ahol haladó linuxos/BSD-s usereknek és rice-olással, témázásassal foglalkozó emberkéknek, youtubereknek van jó háttérképgyűjteménye, plusz egy rakat háttérképes oldal, wallheaven, wallup, unsplash, alphacoders. Régen még az interfacelift volt jó, és az működik ma is, de tetszhalott oldal, nem kerül fel rá új kép, és a meglévők is nehezen kereshetők, tölthetők le, mert a kereső nem működik rendesen. Szedtem már össze nagyon jó háttérképeket redditről is (háttérképes szálak, plusz unixporn), plusz Google képkeresővel is lehet találni jókat. Egy másik topikban a kolléga a Bing, Brave stb. helyekről is húzott le automata scripttel jó háttérképeket.

Az évek során begyűjtöttem vagy 5+ giga FullHD és afölötti felbontású háttérképet, van benne vagy 2300 darab, ezzel el lehet lenni az idők végezetéig, bármikor tudok választani belőle, OS-től és disztrótól függetlenül. Oldalakra és tematikára is szétbontottam, minden van benne, természetei kép, absztrakt, minta, minimalista, fekete-fehér, rajzolt, festett, rajzfilmszerű, stb.. Gyűjtött háttérképeim mindig is voltak, de a nagyon régieket nem használom már, mert azok vagy túl kicsi felbontásúak a modern kijelzőkre, vagy túl kicsi a színmélységük.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Én szinte sohase cserélem ki a háttérképet. Legfennebb választok egy másikat a Disztró által nyújtott alternatívák közül.

A hátteret akkor látom amikor frissen indul a gép (pár hetente történik meg, csak altatni szoktam), minden ablakot maximalizálok amúgy, szóval a háttér nem látszik soha.

:wq

Ízlések és pofonok. Én mindig is lecseréltem, és mivel meg is szoktam unni x idő után egy képet, néha a témát is cserélem vele (bár ez tiling WM-nél már csak a panel színeit jelenti, meg néha a terminálét). Pedig én se látom sűrűn, napi 1-2-szer indul a gép, meg néha virtuális asztalváltáskor látom. Az is igaz, hogy ez csak a fő rendszeremre vonatkozik, amit napi szinten használok. A játékgépen (Win10, 3 éves telepítés) már 3 éve ugyanaz a háttérkép, valami almás bokros (talán a wallup-ról, már nem emlékszem), mert azt úgyis olyan ritkán használom, hogy majdnem mindegy mi van kint. Meg a tartalék laptopomon is jó sok ideig volt az utolsó két háttérkép, Arch alatt, majd OpenBSD alatt, míg ki nem hullottak ezek a rendszerek (megpusztult alatta az SSD), egy háttérkép ment csak, de ezeket megint ritkán használtam.

Virtuális gépeknél is lecserélem, ott pláne fontos, látom, hogy másik desktop, másik gép, nem keverem össze melyiken vagyok, ha teljes képernyőn lenne. Ha retró témájú, akkor meg retrós hátteret szoktam betenni. Azt én semmiképp nem tudnám, hogy a default gyári háttereket használjam csak, túl unalmas, monoton, megkülönböztethetetlen, tömegbirkás jellegű lenne. Hiszen az én rendszerem a sajátom, saját igényre testre szabva, működésben (ablak és virtuális desktop felosztása, gyorsbillentyűk, stb), és vizuálisan is, senki másnak a rendszerére nem hasonlít semmiben. Pont ettől otthonos is egyben.

Még az androidos telómon is cserélni szoktam, de ott ritkábban. Sajnos az Android testre szabhatósága elég durván korlátos, nagyon látszik rajta, hogy konzumidiótáknak kitalált, porig butított rendszer. Háttérképet meg néha launchert lehet cserélni rajta, de nagyon szűkre szabottak a lehetőségek. Maga a háttérkép találása nem probléma, sok hátteres oldalon vannak eleve telós felbontásra optimalizált képek.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Lassan frissíteni kellene a fedora 35-ös gépemet :-)

Szerkesztve: 2022. 11. 17., cs – 08:19

No én frissítettem 36-ról 37-re.
Teljesen meglepődtem, mert jól érezhetően gyorsabbnak tűnik.

Igaz főleg még csak a Chrome-ot néztem, de az nagyon kellemes sebességű.
 

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Ma én is erre jutottam, visszatettem a 36-os hátterét:)

"ha valakire rá kiabálunk, hogy rendszergazda akkor az is - szerződés, fizetés csak az átkos időkben kellett" 

és 100 éve még boszorkányt is égettek 

Vélhetően a GTK3 bugja miatt a pasystray nem állítja a hangerőt az egérgörgő hatására, csak akkor, ha közben le van nyomva a középső egérgomb, tehát ami épp a görgő alatt van. Ma sokat foglalkoztam ezzel a problémával, néztem a forráskódját, olvastam a GTK dokumentációját, de végül egy igen egyszerű megoldást találtam. Nem kell hozzányúlni a forráskódhoz, mert már eleve #define-olva van kétféle implementáció. A megfejtés az lett, hogy a pasystray.spec file-ban a %configure helyett ez legyen

%configure --disable-appindicator

Meg persze az elején

    release_number = 2;

Aztán lehet buildelni, majd a keletkezett rpm csomagot feltelepíteni. Három gépen teszteltem, működik. :)

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