PipeWire #2

Fórumok

A PipeWire - mi ez? topic folytatása. Maga a PipeWire és a repository. Hozzá még a WirePlumber.

Hozzászólások

Szerkesztve: 2022. 07. 12., k – 11:11

Kérdés: PipeWire kezeli a pcspkr-t? Azt tapasztalom (Ubuntu 22.10 preview) hogy hiába állítom be, hogy minden fülesen jöjjön, egyes notification hangok hangszóróból, de talán inkább a PC speakerből jönnek, annyira élesek. Blacklisteltem kernel argumentumok között a pcspkr modult, tehát elvileg nem kéne hogy használja. Van-e valami módszer, hogy a notification-ök ne hangszóróból/pc speakerből jöjjenek?

szerk.: gnome.desktop.event-sounds opciót kikapcsolva dconfből megszűntek az idegesítő hangok. Ezek szerint bizonyos hangokat rossz kimenetre routeol, valszeg hibás a konfig alapból.

Szerintem a PC speaker a hagyományos értelemben nem hang. Van még a régi Intel 8086 és IBM XT-k korából egy programozható timer, s annak kimenetére tettek egy flip-flop-ot, hogy 50 % legyen a kitöltési tényező, vagy lehet, hogy fel lehet programozni eleve 50 %-os négyszög jelre. A pipewire szerintem csak akkor tudná, hogy ez hang, ha a kernel az alacsony szintű ALSA driver-én keresztül stream-ben legenerálná azt.

Szóval engem inkább az lepne meg, ha ezt tudná.

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

Azzal árnyalnám a képet, hogy az alkalmazás természetesen küldhet hangkártya felé, tehát alsa, pulse, esetleg jack interfészen audio notification-t. Azt ne feledjük, a PC speaker az 1980-as, legfeljebb '90-es évek technológiai öröksége, sok disztribúcióba bele sem fordítják már ezt a kernel modult. Default szerintem a Fedorában sincs, bár lehet, lefordítják, de úgy kellene betöltenem modprobe-bal. A PC-k hardware-ében is visszafelé kompatibilitási okok miatt van az alaplap chipset-jén ez a timer, ha egyáltalán. Meg az alaplap egyik tüskesorára fel lehet dugni a kis piezo vagy dinamikus hangszórót.

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

0.3.55

Igazából ez a patch is kell hozzá, csak kiadás után lett javítva.

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

Folyamatosan fejlődik, nagyjából 1-4 hetes kiadási ciklussal. Nem úgy működik, hogy rojtosra tesztelik, majd kiadják, hanem kiadják, majd jön a bugreport, hogy valamelyik alkalmazással 32 csatornás módban baj van a 27. csatornán. :) De Wim Taymans legalább foglalkozik vele, nem olyan arrogáns barom, mint Lennart Poettering, aki az alsa fejlesztőire mutogatott, miközben a saját vacka egyrészt hiányosan volt implementálva, másrészt hibásan, s érzésem szerint ráadásul nem is implementációs, hanem elvi baj van vele.

Nekem a mindennapi használat során semmi problémám nincs a pipewire-rel. Amikor volt, jeleztem a hibát, kijavították.

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

Az felfogás kérdése, mi a jobb. Ha van egy hiba, feltesszük a kezünket, s szóljon, ha elkészült, akinél a hiba van, vagy csinálunk rá workaround-ot. Igaz, így bekenjük sárral, de legalább működik. A felhasználónak ez utóbbi kell. A felhasználó semmivel sem boldogabb, ha úgy nem szól a hang a gépén, hogy nem a pulseaudio-ban, hanem az alsa-ban van a hiba. A másik, hogy az imént több dologról beszéltem. A pulseaudio akkor is rossz, ha az alsa bugot már kijavították, vagy olyan hangkártyával használod, amelyiknek a driver-e teljes értékűen és hibátlanul volt implementálva.

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

A sok felhasználónak meg az, hogy konzisztensen működjön minél több dologgal, és hosszú távon az elég nehéz, ha az ember dagonyázik. Illetve továbbra se értem, hogy ilyenkor miért az a hülye, aki nem dagonyázik, miért nem az, aki faszik megjavítani a driverét, miközben a pipewirenél látszik, hogy akkor rendes ember valaki, ha ezt csinálja.

A pulse audio nekem hosszú évek óta köszöni, és működik az eszközeimmel, a pipe slightly rosszabbul teljesít. (és mindkettő subpar kezeli a bluetooth feletti hangot, szóval én speciel élvezném, ha fingreszelés helyett ezzel foglalkoznának, szerintem nagyságrendekkel több usert érint, mint hogy van-e integrált jack támogatás)

Én már annak is örülnék, ha bármelyikben lenne rendes bluetooth headset támogatás. Amikor nem kell érmékkel meg kockákkal dobálózni, meg kecskét áldozni keresztútnál ahhoz, hogy egy BT fülest megbízhatóan életre tudjak kelteni vele.

Blog | @hron84

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

via @snq-

Sajnos ezek a BT perifériák annyiféleképpen működnek, ahányan vannak. Nekem van egy BAA100-asom, ez 3.5 mm-es jack aljzatra teszi ki az analóggá konvertált hangot, ezzel megy a pipewire. Annak idején emlékeim szerint az én bugreportom hatására került blacklist-re a BAA100 olyan szempontból, hogy ne használjon hardware hangerő szabályozást. Nem azért mert nem tudja, hanem úgy emlékszem, lassan inicializálta magát, a pipewire beállította a hangerőt, a BAA100 utána feléledt, s felülírta valami default-tal. Erre lett a megoldás, hogy jó, akkor legyen software-es, szorozgassuk a hangmintákat, persze ez meg rongálja a dinamikát. Bár az elején még nem, mert a belső formátum float, de előbb-utóbb integer-ré kell konvertálni, s ott azért lesz baj.

Azóta nem tudom, változott-e ez, nem néztem utána. Csak azért meséltem el, hogy értsd, nem olyan egyszerű ezt megcsinálni, mert nincs mindenre szabvány - például hangerő init idejére -, így egy rakás paraméter gyártmányonként eltérő. Wim Taymans pedig nem múzeumigazgató, nem szenvedélyes gyűjtő, tehát nincs minden audio eszközből darab az asztalán, így a bugreportokra tud hagyatkozni. Már, ha nem csak szentségelnek az emberek, hanem jelzik is a problémát.

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

Tudod, én leszarom, ha a hangerőt utólag kell piszkálni. De legalább linkeljen fel normális duplex headsetként A2SP-n, és ne tetves mono HFP-n. Hogy torz, halk, nincs dinamika, az már másodrendű lenne nekem.

Amúgy, a PulseAudionak ugyanez volt a problémája, nem hiszem el, hogy annyi idő alatt, amíg az élt, nem sikerült legalább a fele hardverhez embert keríteni.

Blog | @hron84

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

via @snq-

Azért nem ilyen egyszerű. Számít az is, hogy milyen BT modul van a gépben, és milyen közös nevezős codecet tud leegyeztetni a headsettel. De ja, a hangrendszer a Linuxnak, meg úgy általában a unixlike OS-eknek mindig is egy gyenge pontja volt. Ugyanis ezek nem audio-ra lettek teremtve, az csak utángondolás bennük, alapvetően konzolos szerver OS-nek készültek ezek, és bár be vannak fogva workstationra, desktopra, embedded felhasználásra, de itt-ott azért nem zárkóztak még fel a klasszik desktopos meg eleve professzionális audio-ra szánt rendszerekhez. Nem csak BT, de latency terén is.

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

Noha nagyon sok hozzászólásoddal egyetértek, ezzel most épp nem. Te most lényegében felmondtad, amit a '90-es évek Linuxáról illik tudni.

Egyrészt latency problémákra ott volt a Jack. Másfelől a Pipewire sok más mellet ezt is igyekszik orvosolni, ezért lett kitalálva. Nem véletlen az, hogy van pulse, jack és alsa interface-e, s ezeket egyidőben is lehet használni. Az erőforrás problémákra a minél kevesebb memcpy(), helyette a pointerek átadása a megfejtés.

Bufferelni muszáj, teljesen eliminálni nem tudod a latency-t, tekintve, hogy egy operációs rendszer semmilyen garanciát sem ad a process időben történő futtatására, legfeljebb csak halvány ígéretet, ha az betartható. Nézd meg a Windows-t. Desktop oprendszernek mondják, de annak sem jó az audio alrendszere. Volt olyan, hogy Teams megbeszélés volt, de hang nem volt megfelelő, gyorsan linuxos gépre váltottam, az mentett meg.

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

Nem is azt mondtam, hogy rossz, nekem, mint átlag desktop usernek mindig is megfelelt a hangminőség. De professzionális audiósoknak más az elvárása. Ez ilyen. A Linux sem tökéletes, megvannak a gyenge pontjai, nem csak a hangrendszer, a nehézkes mountolás (állandó rendszergazdai jog kell neki oda is, amikor olyan lemezképet, olyan mappába csatolsz, ami a sajátod), hibernációból/sleepből visszajövetel, és még van pár ilyen. Nyilván még így is köröket van a Windowsra, MacOS, de hát semmi nem hibátlan. Nagyban függ attól, hogy ez mennyire jön ki valakinek, hogy mire használja a gépet.

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

Igen, azt tudom, akár fstab-on kívül is lehet, ha a mount-nak extra paraméterként adom meg, de ez megint extra vergődés, amit nem kéne csináljon. Mert akkor okés, ha meghajtót csatolok fel /dev/-ből, vagy valami olyan mappába, ami rendszermappa, akkor kérjen, de egyébként ne. Mert akar a fene szenvedni fstab-bal, mount paraméterrel, meg fuse mount-tal (úgy is megy). Nagyobb DE-kben is van általában automount, fuse-alapú általában. Nyilván nem abszolválhatatlan, ez csak egy példa akart lenni, hogy vannak az Linuxnak ilyen oldalai, amik nehézkesek meg nem ideálisak maradtak, és mi, aki már évek óta toljuk, megszoktuk, de főleg új, kezdő linuxos usereknél eléggé kiveri a biztosítékot.

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

hát, én nem tudom mikor láttam utoljára olyan linuxos DEt, amibe ha belenyomtam valami randomszart, akkor ne tudta volna password nélkül felcsatolni.

Meg egyébként is tök érdekes, hogy az egyik oldalról pápázod itt a minimalizmust, meg az akkor vagy hatékony, ha megtanulod a mindenfélét, másrészt meg hatalmas vergődés, hogy be kell írni egy plusz paramétert a mountnak

Mondjuk nem tudom mit, mert ami megy sima userként is, az flag nélkül is megy, és egyébként se nagyon látom, hogy van egy alapvetően security feature, akkor miért lenne egy --leszarom-nekem-akkor-is-szabad opciója a mountnak.

Igen, mert a minimalizmus nem hozza azt magával, hogy kényelmetlennek kell lennie egy megoldásnak. Nyilván megoldom, felveszek a speciális paraméteres mount-ra egy aliast a shell rc-jébe, vagy írok rá egy fzf-scriptet, amit bedrótozok gyorsbillentyűre (ennél maradtam, doas-zal oldottam meg, hogy ne kérjen jelszót se), csak ezt úgy érzem extra körlefutásnak, hogy valójában nem lenne szükséges ilyennel a usert szivatni. Gondolom még udev-szabállyal vagy init által futtatott service scripttel is meg lehetne oldani, stb..

Az egészből csak azt akartam kihozni, hogy a Linux sem hibátlan, nem ideális mindenben. Nyilván az olyan szutyok rendszereknél, mint a Windows, MacOS, ChromeOS, Android, stb. dimenzionális ugrás a pozitív irányba, de azért megvannak a hibái, nehézségei, amin lehetne még bőven javítani. Annak ellenére, hogy egy rutinos linuxos user már megszokta ezeket, vannak workaroudjai, de ettől még nem természeteseket ezek.

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

Elképesztően sokat fejlődtek a Linux alapú operációs rendszerek az utóbbi két évtizedben. A korábban nehézkes megoldások kényelmessé, elegánssá váltak a legtöbb esetben. Minap tapasztaltam, hogy Thunar filemanager meglátott egy iso9660 image file-t, automatikusan loop mount-olta, s máris hozzá lehetett férni a belsejéhez, mindezt úgy, hogy ehhez semmit sem kellett tennem, csak rá kellett kattintani az iso file-ra, vagy valami ilyesmi. Nem is tudtam, hogy ezt ilyen kényelmesen tudja, véletlenül fedeztem fel.

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

Általában a legtöbb mai modern DE (nem WM-ről beszélek, hanem komplett asztali környezetről), megoldja ezeket, tipikusan GVFS-sel, amihez vannak mindenféle modulok, azok mindent tudnak csatolni, automatikusan, és egy kattintásra is, és a GVFS még a polkit jogosultságokat is tudja kezelni (pl. rendszerfájl szerkesztéséhez a GUI text editornak nem kell emelt jogokkal futni, csak a fájlt éri el emelt jogokkal), meg a kukát is így oldják meg. De ez pl. nekem felesleges bloat, hogy állandóan fusson a háttérben gvfs, egy csomó komponenssel, van helyette udisks, udiskie, stb. megoldások, de azok sem sokkal kevésbé bloatok. Megoldható, persze minden, de ennek alapból így kéne mennie, bármilyen sallang nélkül.

Az .iso fájlokhoz nem csak mounttal férsz hozzá, hanem fuse-zal is, meg bármilyen archívumkezelővel, commanderrel, azok is meg tudják nyitni, fájlokat eléred benne, ha csak ez a cél, még mountolni sem kell hozzá.

Már nekem is van a kényelmes mountolásra doas + saját scriptes fzf-es megoldásom, ami megfelelő paraméterekkel csatol, hogy a felhasználóm is írni tudja az adott drive-ot, lemezképet, ami fel van csatolva, stb., ennek ráadásul nem is kell állandóan a háttérben futni, csak a csatolás, lecsatolás erejéig fut le, aztán kilép. De ez akkor sem teszi természetessé, hogy nekünk, rutinos linuxos felhasználóknak vannak már workaroundjai erre. Aki viszont most kezdi a linuxos pályafutását, az a haját tépi ettől, hitéből kitér, vagy bloatot kell használjon, nem olyan ideális a helyzet, mint elvileg lehetne.

Vannak még a Linuxnak ilyen oldalai, mint írtam, hibernálás, sleep általában nem működik megbízhatóan, nyomtatáshoz kell a CUPS, mikor egyszerűbben is meg lehetne oldani, böngészőkben általában default nem megy a hardveres videódekódolás, bár ez utóbbi nem a Linux hibája, hanem a böngészősök sara, és be lehet ugyan kézi hekkelésekkel kapcsolni, de csak bizonyos csillagok együttállásakor megy (van, hogy Wayland kell hozzá, van hogy adott verziós GPU driver, csak bizonyos GPU + driver kombó), sok disztrón alapból tearingel a X.org, és még lehetne jó hosszan sorolni ilyen problémás területeket. Mind-mind megoldható, de nem olyan ideális, mint lehetne. Az is igaz, hogy mindenben ideális rendszer nincs, nem volt, nem is lesz soha. Törekedni lehet rá, de teljesen megvalósítani nem.

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

Nem, nem az a baj, hogy szerver alapú. Hanem hogy feleslegesen komplex. Elég lenne egy sima service vagy egy egyszer futó CLI tool hozzá, ami fogadná a bemenetet, rárakná a szükséges, bekonfigurált szűrőket, és kitolná a megfelelő formátumba, protokollal a nyomtatóra. Simán nyomtatáshoz a legtöbb felhasználónak overkill és bloat a CUPS, az a vele a baj, komplett szerver, webszerver, stb. fut miatta akkor is, ha épp nincs nyomtatás, ami cégeknél, megosztott nyomtatónál oké, de home usernek agyrém.

Hála istennek, ha valami sztenderd, IPP-s nyomtatója van az embernek, ma már a CUPS elkerülhető, és megfelelő formára (PS, Pdf, SPL, stb.) konvertálva az anyagot néhány pipe-olással be is lehet küldeni a nyomtatónak netcat paranccsal, valami ilyen egyszerűségű megoldás kéne általánosan.

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

Ha általános, akkor az a cups, ha pedig valami rugalmatlan, egyedi, picike, akkor ott van a netcat, socat, ahogy írtad is. Mi a félelem tárgya egy szervertől? Nem fut le az összes kódsorából fordult kód minden egyes alkalommal, amikor időszeletkét kap. Legtöbbször hamar rájön, hogy üresek a bufferek, semmi dolga, aztán visszatér. Gondolom, írtál már programot, akár nagy programot, s tudod, hogy csak ritkán fut a nagy és bonyolult része, de akkor azért fut, mert arra van szükség.

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

Igen, tudom nem fut a nagy kód minden kódsora, a legtöbb esetben csak egy várakozó loop benne (vagy még az se, amikor a kernel altatja a folyamatot, mert nem hívja semmi), de ez a pár sor is feleslegesen fut, ha épp nincs rá szükség. Az egész ezzel a jogkiosztással, szerverezéssel, sorkezeléssel túl van bonyolítva, cégekre van szabva, magánembernek, otthoni felhasználónak legtöbbször overkill az egész, és mégis rá van tolva mindenkire. Persze, lehet trükközni, hogy valami scripttel indítani a szolgáltatásokat, utána lpr-rel kinyomkodni a cuccot, majd szolgáltatást leállítani, de ez csak elfedi a komplexitási fokot, nem szünteti meg. Működni működik, de bonyás, főleg egyszeri felhasználónak, aki nem rendszeradminisztrátor, hogy mindenféle service-ekkel, és szerverrel, jogokkal, ppd fájlokkal huszárkodjon. Meg lehet tanulni, ahogy neked, nekem is megy, de ettől ez még mindig felesleges komplexitás sok esetben. Azért, mert már valamit megszoktál, és a komplexitása fel sem tűnik, egyszerűnek érzed, az nem azt jelenti, hogy az a legegyszerűbb, meg a legjobb megoldás.

Jó példa erre a bootolás. Sok esetben, ha a a gép tud UEFI-t, és csak home felhasználás, akkor lenne a GRUB-nál sokkal egyszerűbb módszer, de mégis a mainstream disztrók a GRUB-ot tolják rá mindenkire, ami sokszor el is törik. A systemd-boot, EFI stub boot sok esetben egyszerűbb, kisebb komplexitású, és emiatt nem is törik el. Igaz nem is tud annyit, mint egy GRUB, mert utóbbi tud szoftveresen titkosított kötetekről, RAID-ről, egzotikus fájlrendszerekről, btrfs snapshotról, stb. bootolni, de ez megint overkill a legtöbb otthoni usernek, akik csak sima partíciókat használnak, sima ext4-gyel, titkosítatlanul (vagy transzparens hardveres titkosítással), stb..

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

nyomtatáshoz kell a CUPS, mikor egyszerűbben is meg lehetne oldani,

Hogyan? A másik lehetőség az lpd, az is egy démon. Linuxon nincs szerver nélkül nyomtatás, ahogy grafikus megjelenítés sincsen. Ez egy adottság.

és még lehetne jó hosszan sorolni ilyen problémás területeket

Akit ezek zavarnak, az átmegy Windowsra vagy vesz egy Macet és hirtelen teljesen más dolgok fogják zavarni. Meg kell érteni, hogy Linuxon a grafikus felület és a desktop felhasználás nem kezdettől fogva természetes dolog. Eredetileg ez egy szerver-jellegúű operációs rendszer, minden, a grafikus felület fejlesztésést és a r=1 user számára "kikönnyített" használatot illeti, alacsony prioritással ment hosszú-hosszú évekig, és most is jórészt hobbiból fejlesztik. Ez még évekig ilyen lesz, ha nem áll teljes grafikus környezetek mögé egy cég, és kezdi el termékként árusítani. Nem azt mondom, hogy ezt szeretném, azt mondom, hogy a stabilitásnak és a wide-spread kompatibilitásnak ez lesz az ára.

Blog | @hron84

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

via @snq-

Valószínűleg az is számít, ki mennyire agresszív. Lennart használt olyan alsa függvényt, amelyet korábban szinte soha senki sem használt - talán a pointer lekérdezése, hol tart a tényleges lejátszás a hangkártyán, vagy valami ilyesmi -, s mivel nem használták, sok driver-ben nem volt implementálva, vagy rosszul. Könnyen belátható, ha csak az a szempont, legyen meg a függvény, de nem használja senki, egy return 0; épp jó is lesz. :)

Ezzel szemben Wim hozzállása jobb, eleve nem használ olyasmit, ami nincs, vagy hiányosan van implementálva. Úgy tekint a driver-re, mintha csak a gyakran használt függvények képeznék az API-t, minden mást megcsinál saját maga.

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

Van az ideális világ, meg van a valóság. Kellemetlen, de sokszor egy-egy errata-ból tudod meg, mi minden nem működik egy processzorban, s vannak olyan hardware bugok, amelyekre workaround sincs. Illetve az a workaround, hogy nem használod az adott hardware funkciót. Példának szántam a valóságra.

A mérnök gányol, ha nincs ideje valamire. Diagnosztikai célból kellett volna mérnünk valamit önmaga függvényében, erre jött egy szép nagy hibaüzenet. Kértük kollégát, javítsa meg. Ő meg mondta, hogy a valóságban nem lesz ilyen mérés, most meg nincs erre ideje.

Szóval de, a mérnök néha gányol. Nyilván törekszem én is igényes munkára, általános megoldásokra, de van az a helyzet, amikor átnyúlsz rétegek fölött, mert nincs arra futásidőd, hogy szépen csináld meg. Például kihasználod, hogy mekkora az USB buffer mérete, miközben semmi köze felsőbb rétegnek a szállítási réteg bufferméretéhez.

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

már elmagyaráztam, akkor sem értetted, vagy értettél vele egyet. ha szerinted pottering rossz, mert használta az alsat, miközben tudhatta volna, hogy a többi kiváló mérnökszakember "elég ide egy return 0, és már implementáltam is az intefacet módon dolgozott", wim meg jó, mert hát ő csak azt használja ami biztosan van [zárójel nyit, és amit igazából nem tud, csak hasal, és aki emiatt újra fogja írni azt is, ami már kész van], és ezt olyan példákkal támasztod alá egy generikus hangszerverhez, hogy te már jártál úgy, hogy valami egyszeri méréshez nem volt értelme megcsinálni, és nem érted, hogy mi ezzel a baj, akkor nincs értelme ezt megint hosszan elmagyarázni.

Úgy, hogy közben a pulseaudio szerinted még elméletileg is hibás, holott arról van szó jó eséllyel, hogy a te konkrét scenariod pont pofára esett akkor, amikor pötyi épp az általad nagyrabecsült gányolást csinálta :)

Nem az a baj, hogy nem értem. Nem értek vele egyet. Az meg miért probléma? A mérnöknek nem idealistának kell lennie, nem egy ideális világ problémáira kell megoldást adnia, hanem egy reális világ nagyon is valós problémáira. Ha az alsa rétegben valami hiányos, akkor ezt tudomásul kell venni peremfeltételként.

Mondhatod, hogy jogodban áll Ferrarival járni Budapest utcáin, csak épp nem bölcs, ha tele van kátyúkkal, fekvőrendőrökkel, meg néhol még gödrös földutat is találsz. Erről az jut eszembe, hogy fiatal csajsziknak is jogukban áll szokásosnál is kihívóbb öltözékben buliba menni, csak utána ne tessék meglepődni, meg hüppögni, ha az este nem egészen az elképzelések szerint alakult.

Ha rád hallgatnék, használnám egy 32 bites MIPS köré épített PIC perifériákból álló MCU i2c interface-ét, de akkor sem fog működni, ha az én kódom hibátlan, és akkor sem, ha ujjal mutogatok a Microchipre. A piacon nem tudom értékesíteni azt a szemléletet, hogy nem miattam nem működik a berendezés, hanem a Microchip hibájából. A berendezésnek működnie kell. Lennart pedig épp ezt csinálta. Olyannyira, hogy arrogáns módon még be is logolta. A pulseaudio jó, az alsa implementációs hibája miatt sz.r az egész. Ezek alapján bizony azt gondolom, Lennart egy beképzelt figura, nem pedig jó mérnök.

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

Még várok a váltással, de kíváncsian követem :)

Már régen jobb, mint a pulseaudio, de tudom, vannak óvatos emberek. :) Különben a váltás néhány csomag feltelepítését jelenti, ami azért nem egy két napos project. Sokkal inkább néhány perces. Jó, meg kellhet a logout, majd login, vagy megoldás a megfelelő service-ok (újra)indítása a systemctl --user daemon-reload után.

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

sub.

A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.

Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!

Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

"Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993

Ahogy nézem a patch-eket (július 12-ét érdemes meglesni), a következő verzióban - meg nekem már most, mert forrásból csináltam csomagokat - érkezik az Audio Video Bridging.

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

Ezt biztos is, hogy használod? Mármint ezt az AVB-t. Egyébként nekem is működik a Pipewire, de én nem tudok annyira lelkesedni érte, mint te. Valahogy nekem csak egy n+1. RH-es bloat. Használom, mert már most se ajánlott pulseaudio-t használni, szépen vezeti ki mindenki, de én még mindig inkább használnék ALSA-t szívesebben.

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

Nem használom az AVB-t, inkább az azóta történt bugok javítása miatt fordítottam a git repóból kihúzott forrást. Bloat? Mert tolják bele a mindent is mennyiségű feature-t, bár szerintem ez nem baj. Amit nem használsz, az nem fog futni, nem viszi a gépidőt. Hiába van egy ezer soros switch() case szerkezeted, ha csak az egyik ága fut mindig.

Szerintem használhatsz alsa-t, bár kliens oldali támogatás egyre kevésbé van hozzá. Audacious-ban még van, de abban van ALSA, OSS3, pulse, jack, SDL, QtMultimedia, szóval szinte minden. Az ALSA-nak az a hátránya, hogy bután csak egy végződtetés a hangkártyához. Pipwire - meg persze a pulse is - megoldja a több kliensről érkező, különböző mintavételi frekvenciájú hangok esetleges keverését, resampling-et, egy időben több kimeneti interface-re küldését, a jelutak route-olását, visszhang elnyomást, hálózati audio I/O-t, szóval úgy kb. mindent, plusz a pipewire szállít mellé video-t is.

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

Másnál is van úgy, hogy nem veszi észre, ha bedugom a fülest, csak egy pkill pipewire; pkill pipewire-pulse után?

A korrekt megoldás az lenne, ha nem kéne újraindítgatni. Azt észreveszi, ha kihúzom, de azt már nem, ha visszadugom.

De más érdekesség is volt már a ki-bedugásnál, pl. bekapcsolom az AV receivert, akkor észrevette, és ki lehetett választani, hogy mondjuk a böngésző HDMI-n küldje a hangot, aztán amikor kikapcsoltam, a receiver ugyan eltűnt, de a hangot nem lehetett visszaterelni az alaplapi hang"kártyá"ba (pkill-ig).

Az az igazság, hogy ezt a többféle kimenet között váltást már anno a pulseaudio se kezelte tökéletesen. Én ebből a szempontból szerencsés vagyok, mert ugyan dugdosok fülest, de csak egyféle kimenetet használok, HDMI-t nem, így nem okoz kavart.

Próbáld meg bedugásnál letiltani azt a kimenetet, ami a gondot okozza. Lehet rá írni egy szkriptet is, ami meghívja a pactl-t, megfelelő paraméterekkel letiltva az adott kimenetet, majd ennek lehet párját írni, ami engedélyezi, ha szükség van rá.

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

Igaz. Ha tőlem is akartok olvasni egy bugot, legyen. Egyszerre két bluetooth eszközre route-oltam hangot. Az egyik egy Panasonic SA-PMX80 micro hifi, a másik egy JBL Flip 5. Hát... meszólalt, egy darabig volt hang, aztán kicsit akadozott, majd az egyiken teljesen kimúlt a hang. Fogalmam sincs, hogy ez pipewire, wireplumber, netán bluetooth réteg hibája. Vagy így együtt.

Ja, a host-on egyetlen bluetooth interface volt, tehát nem volt dedikált interface a két kliensnek.

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

Na most rászántam magam egy kis kísérletezésre, és rájöttem, mi a baj. Az a baj, hogy nekem normál hangszóró nincs is rádugva a gépre, csak fülhallgató. Ha ezt kihúzom, akkor a pipewire az egész hangkártyát offba teszi (mert nincs egy működő kimenete se). Innen viszont nem engedélyezi, ha újra bedugom a fülest. PulseAudio Volume Control-lal visszakapcsolhatom, akkor nem kell pkill. Ha dugok rá egy hangszórót, akkor is jó. Ez azért így elég hülye viselkedés. Talán megér egy bugreportot. Addig is a workaround: üres jackdugó a hangszórókimenetbe.

(Ja, és PulseAudio Volume Control helyett nincs natív? Vagy amúgy is a pulse interfaceit implementálja, szóval jó ez?)

Ez így sokkal korrektebb. Valóban van egy null sink arra az esetre, ha semmi sem nyeldesi a hangot. És szerintem is rájöhetne, hogy ha megjelenik az a sink. Nálam észreveszi, ha USB-n megjelenik az SA-PMX80. Ez inkább tűnik wireplumber bugnak.

Tudtommal nincs natív, mert kliens oldalon a pulseaudio-lib van használatban, s az összes eszközzel működnie kell. Esetleg tedd fel a Carla-t, ez jack kliens, s tudod látványosan route-olni a dolgokat, mintha azok kábelek lennének. Akár fel is cserélheted a bal- és jobboldalt. Én is ezzel oldottam meg, hogy az audacious hangja egyszerre menjen a két bluetooth kliens felé.

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

Nekem hasonló hibám volt Ubuntu 22-n, ha kihúztam a fülest, akkor átváltott a laptop belső hangszórójára, és nem volt hajlandó visszaváltani amikor bedugtam újra. Néhányszor oda-vissza kellett kapcsolgatni a kimeneteket, amíg magához ájult. 

Blog | @hron84

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

via @snq-

0.3.56

Nem tudom, ez segít-e itt bárkin is:

A channel mapping bug was fixed in audioconvert. Unit tests were added.

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

Most olvastam én is a redditen. Állítólag elég sok BT feature került bele, kódekek, stb., akinek korábban Bluetooth problémás volt, próbálja meg újra.

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

Ezen felbuzdulva rápróbáltam tegnap, pillanat alatt párosodott és még codec-et is jól választott. Ja, és mást választ, ha filmet nézek, vagy zenét hallgatok, mint ha headsetként használnám.

Teljesen elégedett vagyok.

A Linux nem ingyenes. Meg kell fizetni a tanulópénzt.

Az emberek 66 százaléka nem tud számolni! Gondoljatok bele, ez majdnem a fele!!

Mindenki jó valamire. Ha másra nem, hát elrettentő példának.

"Az udvariasság olyan, mint a nulla a számtanban. Egymagában mit sem jelent, de sokat változtat azon, amihez hozzátesszük." - Freya Stark 1893 - 1993

Bocsánat, elfelejtettem linkelni:

0.3.58

Azóta van már néhány patch, amit érdemes belefordítani. Legegyszerűbb git repóból mindent.

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

Ez tetszik, fordítottam is egyet forrásból, már ez szól. :)

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

Hú, apám, nagyon keményed tolod. Pedig én is frissességmániás meg verziófetisiszta vagyok, de ez még nekem is meredek, hogy a rollingos kiadást se várod meg, hanem már pörgeted ki forráskódból meg kézzel patcheled. Szerintem feleslegesen dolgozol vele, kb. 1-2 nap után ott kéne lennie a Fedora, Arch, stb. tárolóiban, pl. Arch testingre tegnap érkezett meg a 0.3.59. Tényleg nem értem, hogy egy audio subsystemért hogy lehet ennyire rajongani :D

Persze, még mindig inkább ez, mint az, amit az ubuntusok meg debianosok csinálnak, hogy az új verzió majd csak a fél-egy év múlva megjelenő kiadásban lesz benne, persze addigra már elavult verzió lesz, de annak kell örülni, mert az még stabil volt, ilyen dinoszauruszok kövültek bele, és akkor már muzeális értéke is lesz.

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

Valóban szorosan követem a projectet, ennek érzelmi okai vannak. Mivel használom a seren nevű VoIP klienst peer to peer, s a pulseaudio elfuseráltsága miatt recsegett-ropogott a hangja, a pipewire egy megváltás volt számomra. Aztán előfordult olykor regresszió benne, akkor segítettem Wim Taymansnak debugolással, s így javításra került a kódja.

Pipewire-t fordítani nagyon könnyű. Virtuális gépen szoktam, leszedem a Fedorához való source rpm-et, amiből csak a pipewire.spec file kell. Kihúzom git repóból a forrást, törlöm a .git alkönyvtárat, átnevezem aktuális verziószámúra a legfelső directory nevét, majt tar-ral egybe rakom és egyúttal tömörítem. Utána rpmbuild -bb pipewire.spec, és meg is vagyunk. Nyilván törlöm az esetleges patch-eket a spec fle-ból, mert a forrásban már úgyis minden megvan. Az rpm-eket visszamásolom a host-ra, telepítem, systemctl --user daemon-reload, utána újraindítom, s meg is vagyunk.

Ráadásul gyorsabb csinálni, mert shell history-ban minden megvan már, a fordítás is megvan kb. 2 perc alatt.

De igen, már nálam is a Fedorára Wim által fordított 0.3.59 van. :)

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

Van-e arra megoldás hogy ne ordítson a fülembe a rendszer indítása után? Bővebben: Általában szerényebb hangerőt használok. Kikapcsoláskor is ez van érvényben. Azonban a gép következő bekapcsolásakor a pipewire teljes hangerőt állít be. Aztán pedig meglepetésemben letépem a fejhallgatót. Mintha régebben megjegyezte volna az utoljára beállított hangerőt. Vagy tévednék? Természetesen keresgéltem a beállítások között, de nem találtam olyat amivel kapcsolni lehetne ezt a viselkedést. Fedora 35 és Xfce az alaprendszerem. Örülnék ha valaki tudna segíteni.

Meg szokta jegyezni a hangerőt. Amit én csinálnék:

Leállítanám a pipewire-t:

systemctl --user stop pipewire\* wireplumber.service

Utána törölném azokat a file-okat, ahol ilyesmit tárolhat:

~/.local/state/{pipewire,wireplumber}

~/.config/{pipewire{,-media-session},wireplumber,pulse}

Aztán elindítanám a pipewire-t:

systemctl --user start pipewire\* wireplumber.service

Majd beállítanám a hangerőket a pavucontrol nevű eszközzel, végül leellenőrizném, sikerült-e a kísérlet.

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

Nekem egy ~/.local/state/wireplumber/ alkönyvtáram volt. A ~./config/pulse/ tartalma meg júniusban frissült utoljára.

A törlések után újraindítottam PipeWire-t. Csak a ~/.local/state/wireplumber/ alkönyvtár jött újra létre. A korábban futó zenelejátszót ismét elindítottam és az most nem ordít. Viszont a hangerőszabályozó nem tud kapcsolódni: "Kapcsolat felépítése a PulseAudióval. Kis türelmet..." Ez látszik egy ablakban. Egészen addig amíg úgy nem határozok hogy a kis türelem elfogyott és bezárom az ablakot. Gondolom egy rendszer indítás majd megoldja. Köszönöm a választ.

Természetesen. Egy szolgáltatás sem veszi jónéven ha a futása közben törlöm a hozzá tartozó fájlokat. Azóta viszont béke van. A pipewire ezeket a fájlokat hozta létre ismételten:

~/.config/pulse/cookie
~/.local/state/wireplumber/default-nodes

~/.local/state/wireplumber/default-routes

~/.local/state/wireplumber/restore-stream

Ha változtatom a hangerőt akkor ez a fájl frissül: ~/.local/state/wireplumber/default-routes

Közelebbről pedig ez a sor:

alsa_card.usb-ASUSTeK_XONAR_SOUND_CARD-00:output:analog-output-speaker:channelVolumes=0.27461725473404;0.27461725473404;

 

--------

Azt még hozzáteszem hogy volt már két rendszerindítás.

Elnézést, nem néztem meg hogy esetleg válaszoltál-e valamit. Nos a nyomorult megint ugyanúgy szívózik velem mint korábban. A grafikus felületre való bejelentkezés után az első dolog amit látok az egy kis felbukkanó ablak a jobb felső sarokban (Xfce). Ebben egy hangerőszabályozó látszik ami a maximumon áll. Pedig úgy kapcsoltam le a gépet hogy kis hangerőn volt. Azóta felfedeztem mást is. Ha hosszabb időre itthagyom bekapcsolva a gépet akkor azt szoktam csinálni hogy a Ctrl+Alt+F7 kombinációval átkapcsolok egy olyan terminálra ami nincs aktiválva. Ezután lekapcsolom a képernyőt. (Mindezt azért hogy ne tudjak figyelmetlenségből csinálni valamit ha véletlenül megpiszkálom az egeret vagy a billentyűzetet.) Amikor visszajövök és ismét dolgozni akarok akkor képernyő be és Ctrl+Alt+F1. Aztán Ctrl gombbal felébresztem az ablakkezelőt. (Azért a Ctrl gomb mert az önmagában nem okoz adatbevitelt.) Erre megjelenik a jelszót kérő ablak, vagy az asztal ha csak kis ideig voltam távol. Ha több idő telt el akkor feloldom a képernyőzárat és azonnal látszik a jobb felső sarokban a jelzés hogy már megint teljes hangerőre állt a pipewire.

Arra gondolok most hogy ez lehet esetleg az Xfce sara is.

Eddig mindig azt használtam. Most a javaslatodra kidobtam és egy indítómenübe felvettem a pavucontrol-t. Aztán próba.

Ctr+Alt+F7: Elhallgat mint máskor.

Ctrl+Alt+F1: Megszólal a korábbi hangerővel. Nem ordít. Óriási.

Ezt ösztönzés nélkül is kipróbálhattam volna de nem gyanakodtam pont a hangerőszabályozó modulra. Valami mélyebben gyökeredző disznóságot sejtettem a háttérben.

Akkor remélhetőleg ennyi volt. Köszönöm a javaslatot.

0.3.60 rengeteg módosítással.

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

Úgy néz ki, hogy mégis van gondom ezzel a PW-rel. Csak nem a hang terén, ahogy az ember várná. Már több hónapja akadozik a netes videók lejátszása (pl. YouTube), ha beletekerek egy videóba, akkor random elkezd megállni a videó, mintha töltené a hátralevő részét, de sose fejezi be. Nem mindig, de elő-elő fordul. Eddig azt hittem, hogy a szar Wi-Fi okozza, de gyanús lett, hogy a net a videón kívül működőképes, nem szakadt le, vagy ilyesmi. Aztán jött egy újabb PW verzió, ezzel azt csinálta, hogy megállt a videó, de a hang ment tovább, innen jöttem rá, hogy a PW-rel van a baj, eszembe jutott régebbről, hogy mikor a wireplumbert szedtem le, akkor nem játszotta le a videókat. Következő PW frissítésre (azt hiszem, hogy 0.3.59) megjavult. Jelenleg a 0.3.60-nal megint nem jó, néha beállnak a videók. Mit lehetne ezzel csinálni?

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

Nem tapasztaltam ilyesmit. Melyik disztribúciót használod? Arch? Ha nincs jobb ötleted, a disztrubúciód csomagkészítő utilityjével git repóból kihúzott legfrissebb forrásból fordíts és csinálj új csomagot magadnak, illetve jelezd a problémát a gitlabon egy új ticketet nyitva. Elég jó a hozzáállása Wim Taymansnak. Volt nem rég olyan bug, amit jeleztem, másfél óra múlva javította.

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

Archról van szó. Jelenteni fogom bugként. Az a trükkös benne, hogy eddig félrevezetett, és nem tudtam, hogy emiatt van. Nem biztos, hogy maga a PipeWire, lehet a Wireplumber is, de most már tuti, hogy valahol itt keresendő a probléma gyökere, esetleg a Firefoxnak nem tetszik ez a PW környezet. Az is elég furcsa, hogy csak néha csinálja, tehát nem minden videónál, és azoknak sem minden pontján. Minél többet tekerek bele egy videóba, annál jobban megnő az esélye, de ez sem garancia rá, hogy előjön a bug.

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

Jaj, nem is mondtam:

vezetékes vízvezeték-szerelő 0.4.13

Elvileg jobb lett, kompatibilisebb a pulseaudioval, gyakorlatilag meg ennek folyományaként van olyan konfiguráció, amikor nem jegyzi meg a jelutat. Helyesebben szólva megjegyzi, de az alkalmazás helytelenül kierőlteti, felülbírálja, hogy a default sink-hez és source-hoz legyen csatlakozva. Ez vélhetően pipewire-alsa bug.

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

Nekem most ezzel a Wireplumberrel, vagy a Pipewire-rel lett egy bugom, nem tudom melyik okozza. Videólejátszás és néha játék alatt így berecseg a hang, nem is a recsegés jó szó, mintha belassulva akadozna 1-2 mp.-re. Utána jó. Elég random jön elő, nehéz kideríteni mi okozza.

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

Szerintem a wireplumber a jelutakért felel, amit mondasz, az inkább tűnik pipewire bugnak. Bár van egy olyan dolog is, hogy ha a gép nagyon terhelt vagy lassú, a hangszerver a feje tetejére állhat, akkor sem tudja megjavítani azt, amit már a hardware nem tud. Ennek ellenére valószínűsítem, hogy nem ez a baj.

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

Nem terhelt, Ryzen 6800H, 16 giga RAM, alig van foglalás, swap nincs, rendszer üresjáratban szinte. Ennek nem lenne szabad akadnia, még akkor se, ha menne valami a háttérben. Egyértelműen a hanggal van összefüggésben, most az 0.3.63-as legutóbbi verzióra frissítés óta jött elő. Az a baj, hogy nem tudom semmivel nézni, dmesg, journalctl nem mutat semmit, mást meg nem tudom mit futtassak a háttérben.

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

Közben tesztelgettem ezt, a pw-top és a pwmon > log.txt nem adott használhatót. Biztosan PW bug, mivel előjött a cmus és moc lejátszók alatt is, pedig azok minimális terminálos programok, és most már az is biztos, hogy a pipewire-pulse csomaggal függ össze, mert csak olyan alkalmazásokban jön elő a hiba, amik pulseadio-t használnak. De ahogy látom ez a Pipewire még ingatag Archon, erről az is árulkodik csak a PW 0.3.63-ból egymás után 6 buildet is kitolt a csomagfenntartó, szinte naponta záporoznak, tegnap még 0.3.63-6 volt a csomag, ma már váltott 0.3.64-1-re, majd meglátjuk ez megoldja-e. Túl kapkodós ez, verziókat ilyen ütemben kihozni, ez az erőltetett ütem még nekem is erős, pedig frissességmániás vagyok.

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

Miért erős? Szerintem az Arch csomag karbantartja gyakorta kihúzza git repóból a forrást, lefordítja, a binárist pedig beteszi az Arch repóba. Lényegében én is ezt csinálom magamnak Fedorán, gyakran naponta build-elek egyet. A forrás meg fejlődik. Egyrészt Wim Taymans tolja bele a gondolatait, sok esetben a bug reportok javítása által, aztán más fejlesztőknek is vannak merge kérelmei, és vannak a saját ötletei. Szóval egy rakás kód belekerül minden nap.

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

Nem. Pont most mondom, hogy ugyanaz a verzió, a 0.3.63 release, az nem git-es dev-ág, hanem rendes kiadási ág, de ebből viszont 6 build, majdnem naponta. Ugyanazt forgatja hatszor. Érződik rajta, hogy nincs rendben vele valami, mert tipikusan egy verzióból a többi csomagnál csak 1 build van, esetleg nagyon ritkán kettő, de akkor van nagyobb időbeli távolság közöttük. A 0.3.64 az egy új verzió legalább, reméljük ebből nem lesz túl sok build, egy idő után a csomagfenttartó tapasztalatot szerez, megtanulja, hogy hogyan forduljon le a csomag egy build során megfelelőre. Valahogy látszik az egész történeten, hogy még a csomagolónak is új, tanulja a dolgokat, vadul kísérletezik.

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

Szerintem ezt nem jól látod. Majdnem kizártnak tartom, hogy a maintainer bugreportok alapján hibát keres a kódban, kijavítja, majd szerencsés esetben elküldi Wimnek a patch-et. Klasszikus értelemben nincs devel ág a pipewire-ben. A devel ág létezik csak, s annak bizonyos pontjain Wim úgy dönt, hogy ez most release. Aztán folytatja a munkát.

Fedorára én is úgy fordítottam, hogy volt a 0.3.63-1 hivatalosan, majd én kihúztam git repóból az aktuális állapotot, lényegében daily snapshot-ot, s lefordítottam 0.3.63-2 néven. Aztán egy még frissebbet 0.3.63-3 néven, s csináltam ezt egészen 0.3.63-15-ig. Most Wim fordított Fedorára 0.3.64-1-est, de azóta a forrásba kerültek patch-ek, a gépemen már az általam buildelt 0.3.64-2 fut.

Tehát szerintem semmi egyéb nem történt, mint az Arch pipewire maintainere ráért, kellően izgalmasnak tartott bizonyos patch-eket, kihúzta a cuccot git-ből, növelte eggyel a build számot a legutolsó hivatalos verziószám megtartása mellett, lefordította, majd ez frissült a felhasználóknál. Ugyanazt csinálta, mint amit magamnak én Fedorára.

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

Ezt nem tudtam, hogy nincs külön devel ág. Elég veszélyes ez, hogy az egész devel, és még kiadások is alig vannak benne, a csomagfenntartók, meg dev ágból szemezgetnek random időpontban. Ennél veszélyesebb hozzáállás nincs. Meg értelme sincs sok, hogy konkrétan naponta tutujgatni meg újraforgatni a kódot.

Plusz így a verzióknak sincs sok értelme, hogy 0.3.63, de a dev fejlesztéseket teszi bele egyesével, akkor nem a build számot kéne növelni, hanem máshogy számozni, pl. 0.3.63.1 vagy valami és nem 0.3.63-build1. A kettő nem ugyanaz. Higgyétek el, hogy nem kötözködök, de az a szintű verziószám-hajhászás, meg naponta újrabuildelés nagyon gáz, ettől rosszabbat nem lehet csinálni. Nem is véletlen, hogy ilyen más csomagnál nincs, csak Pipewire-rel összefüggő csomagnál, a többinél rettenet ritka, és jobban szét van húzva időben.

Plusz aki erre vágyik, hogy naponta újraforgassa a legfrissebb kódot, annak ott van egy ideje az AUR-ban a pipewire-git, meg wireplumber-git, stb., aztán ha annyira fetisizálja a frissességet, akkor forgathajta magának újra naponta.

Persze, értem én, a csomagoló túl buzgó, élvezi, és ezt nekem is értékelni kéne, de én ezt már ilyen szinten nem dicséretesnek, hanem veszélyesnek és kapkodónak ítélem. Pedig nincs ellenemre a frissesség, azért is használok Archot, és azon belül is Testing tárolókat, de ez a fajta naponta történő vad rebuildelés sem való már a Testingbe, annak a Staging-ben és az AUR-ban van a helye.

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

Kinek mi a veszély. Nem egy banki adatbázis szerverről beszélünk, ahol konzervatív megközelítés kell, hanem egy multimédia szerverről, amelyben a legnagyobb bajod az lehet, hogy elmúlik a gépeden a hang. Ekkor legrosszabb esetben visszateszed az eggyel korábbi, még működő változatot.

Azt amúgy nem tudom, hogy az Arch maintainere mi alapján buildel, de van olyan, hogy Wim kiad egy verziót, majd utána talál egy csinos bugot, amelyet javít. Maintainer legyen a talpán, aki meg bírja állni, hogy nem buildel egy olyan változatot, amelyben ez a javítás benne van. :)

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

Nekem most volt valami megmagyarázhatatlan és fogalmam sincs, hogyan triggerelhető stream route-olási bugom, amit még a reboot sem mulasztott el. Odáig jutottam, hogy leállítottam a pipewire, pipewire-pulse socketeket és service-okat valamint a wireplumber.service-t, töröltem a ~/.local/state/wireplumber és a ~/.config alatt mindent, ami pipewire-rel vagy wireplumberrel függ össze, majd megint elindítottam az egészet. Lekérdeztem a status-t, valamiért a pipewire-pulse.socket nem indította el a service-t, kézzel elindítottam. Most van hangja, beállítottam manuálisan a jelutakat pavucontrol alól GUI-n. Remélem, jó lesz legközelebb is.

Amúgy többnyire úgy triggerelődött a bug, hogy új build-et készítettem, feltelepítettem, daemon-reload, majd restart amit kell, aztán nem volt hang annak ellenére, hogy a pavucontrol-ban mozgott a kivezérlésmérő és nem volt semmi sem némítva, illetve nem volt nullán a hangerő. A para az volt, hogy még reboot sem oldotta meg. Viszont nem úgy ismerem magam, hogy egy ilyen problémán elbukjak. :)

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

Lehet a te lapod BIOS-ában már javították. Nekem viszont laptopban van, és azok nem kapják meg ezt a BIOS frissítést. Ennek ellenére a kernelben is lesz rá fix. Igazából 6.2.1-es kernellel nem tapasztalom többé.

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

Elvileg így tudod tesztelni, hogy téged érint-e a bug:
sudo cat /dev/hwrng > /dev/null

Hagyjad futni a háttérben percekig, de közben használd a gépet. Ha elkezd akadozni, akkor tudod, hogy érintve vagy. A Fedorán csodálkozok, mert régebben hamarabb elérhető volt náluk a legfrissebb kernel, mint Archon. Mindegy, mert kint van a 6.2.2 is, szóval nemsokára megkapod, ha érintve vagy, segíteni fog. Nálam most jött le az Arch Testing tárolóból a 6.2.2, de már a 6.2.1 alatt sem tapasztaltam ezt a bugot.

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

Annyi feltűnt, hogy a pavucontrol-ban a kivezérlésmérő meglehetősen akadozva, darabosan mozgott. Most meg jó. Igaz, pipewire-t is fordítottam forrásból. Viszont a hang nem szakadozott.

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

Van egy Lenovo MiniPC-m elfekvőben, gondoltam játszok rá egy (számomra) szokatlan rendszert Gentoo-val. Az asztalin egy Pulseaudio->PipeWire csere után rendben vagyok (nagyjából), ebben a kicsiben viszont van bt is és szeretném kizárólag pw-vel használni (meg egyéb csökkentések is lesznek, nosystemd, minimál gui, stb... szóval egyenlőre (újra) ismerkedés azzal ami a systemd előtt volt. Pedig mennyit szenvedtem annak idején, hogy átálljak rá :D ).

Próbálkozom a pw telepítéssel, de rántaná magával a pulseaudiót amit nem szeretnék. Nem találok hozzá hangerő szabályozót sem. Esetleg valaki aki gentoo-t használ meglépte már ezt így? Tényleg kell a pulseaudio? Miféle alternatíva van a hangerőszabályozásra?

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

Nem kell hozzá a pulseaudio, de a pulseaudio client library igen. Ez pulseaudio-libs néven szokott futni, s az sem baj, ha van pulseaudio-utils, de ez már csak opcionális emlékeim szerint. Hangerő szabályozására tedd fel a pavucontrol illetve akár a pasystray nevű programcsomagokat. Ha azt szeretnéd, hogy a route-olás jól látszodjék, akkor pedig a Carla nevű egyébként jack kliens, ami jól jöhet. Ha amúgy is forráskódból fordítasz, a pipewire master git repójából húzd ki a legfrissebb forrást.

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

Hmm... Akkor neki kell veselkednem, hogy lebeszéljem a portage-t a teljes pulseaudio telepítéséről, a lib-et értettem, ezen kommunikálnak a pulsehoz kötött alkalmazások. A portage mai állása szerint a 63-as a legutolsó stabilnak kikiáltott, ma ezzel próbálkozom és ha fenn van akkor engedek neki egy ~amd64-et vagy 9999-et, hogy a gitből húzza az épp aktuális mastert A többit nézem épp :).

Köszönöm!

szerk: az asztalin a helvum-ot használom „kötözködni”.

„Niemand ist unnütz! Man kann immer noch als schlechtes Beispiel dienen!”

dzsolt

Szerkesztve: 2023. 01. 24., k – 22:34

Ma 44 commit érkezett bele, bár én 50-nek számoltam. Természetesen lefordítottam, működik.

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

Most bealudt a két német arch-os csomagfenntartó, még mindig csak a 0.3.64-1-nél tartanak, 12 nappal ezelőttről. Lehet más is szólt, hogy nem kéne ilyen ütemben nyomni. Vagy csak lett életük, és kifáradtak a diszkóban, mikor az ájnsz cváj, poli cáj, dráj fí-á, grená di-á számra nyomták. Persze örülni nem kell, most egy másik csomagoló lendült bele az iparosmunkába. 3 órája frissült az unrar 6.2.3 konkrétan 6.2.4-re, erre most kint van már a 6.2.5 is, az se ért volna rá 3 nap múlva, megromlik, ma kellett még 0 óráig, mint egy falat kenyér. Annál ráadásul sok commit sincs, egy darab orosz fejlesztő, git-en kívül.

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

Ja, vagy lehet hogy most kb stabilnak érzik a csomagot, és várnak a következő nagyobb upstream fejlesztésre, amit majd csomagolnak. 

Unrar -ból release van és gyorsan csomagolják. Tragédia... Szerintem neked nem az arch való, el kéne ezen gondolkoznod. Lehet egy manjaro már jobban feküdne, öregszel?

Meg ez a stílus a maintainer -ekkel kapcsolatban... Megmutathatnád hogyan kell ezt csinálni, többször mondtam már. Valamiért úgy érzed, hogy jobb a pálya széléről fikázni.

De, abszolút nekem való, szeretem a frissességet. Mostanában azonban kezdenek már átesni ezzel a ló túloldalára. Sokszor 1-3 óránként is frissül egy verzió, olyan gyorsan még tesztelni se lehet. Oké, gyorsan csomagolja az unrar-t, akkor ugorja át belőle a 6.2.4-et, ha egyszer pár óra múlva már úgyis a 6.2.5-öt tolja kifelé. Ez már ezen a szinten nem frissesség, hanem fetisizmus, pótcselekvés. Pontosan úgy, ahogy most a Pipewire-rel csinálták, hagyták a 0.3.64-en pár napig, nem adogattak ki belőle új buildet pár darab patchért, hanem helyette rámentek a 0.3.65-re, ahogy megjelent. Ez teljesen rendben is van, mindenki tudta használni a 0.3.64-et, tudta tesztelni, ha bug volt benne, volt ideje jelenteni, mindenki tudott belőle okulni.

Valószínű én is hibás vagyok annyiban, hogy naponta 1-2× frissítek, lehet vissza kéne fogni hetire, vagy leállni a Testing tárolókról.

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

Unrar: az upstream és az arch maintainer ugyanaz? Ha nem, akkor honnan tudja a maintainer, hogy mindjárt lesz még egy release?

Pipewire: az inkább dicséretes, mint megvetendő, ha a maintainer egy ilyen aktív fejlesztés alatti csomaghoz 2 release között cherrypickeli a bugfixeket.

Ebben annyiból még igazad van, hogy lehet nem is a csomagfenntartó csomagolja az unrar-t, hanem egy build szerveren lévő script detektálta az új verziót, és csak simán átcsomagolva betolta az új binárist. Mindenesetre nekem továbbra is erős, hogy ilyen sűrű ütemben követik egymást. Hangsúlyozom, hogy Testing tárolóról van szó, a Testing azt jelenti, hogy teszteli is valaki. Tesztelni úgy nem lehet semmit, hogy megél 1-3 órát. Kicsit olyan, mintha az étteremben a pincér kiviszi neked a fogást, de még mielőtt betolnád az első kóstoló falatot, már venné is ki a kezedből, hogy túl késő, már a következő fogást hozta.

Az is lehet, hogy öregszek, de nekem ez már inkább kapkodásnak tűnik, mint dicséretesnek. Pedig ha valaki, én tényleg értékelem a gyorsaságot, friss verziókat, meg hogy a Linux világában ennyire rugalmasak, nem úgy megy, mint a MS-nál meg a nagy multiknál a corporate bullshit, hogy meg kell várni mindenféle jóváhagyást, meg bevezetési időszakot, következő patch keddet, meg majd soha napján kiskedden, 5 év múlva a következő LTS-sel gyerekek kezdetű baromarckodás, mert azokat ki nem állhatom.

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

Vannak olyan javítások, amelyek szinte teszt nélkül is tudhatók, hogy jók lesznek. Mondjuk \n-nel szeparálod a sorokat, miközben az inputod olyan, hogy garantáltan \r töri a sorokat. Rájössz, javítod, de ezt nem kell hónapokig tesztelni, megnézed, ha működik elsőre, elég valószínű, hogy jó. Tudom, egy ilyen egyszerű dolog is eltörhet valamit másik három helyen, de ha fejedben van a project, mert te írtad, akkor jó lesz a rálátásod. Mondom, én is csináltam ilyet cégen belül. Persze nyilván nagyobb a felelősség, ha ez kimegy a fieldre, elhagyja a céhet.

Egy égető kérdés: az jobb, ha tudod, hogy az aktuális release bugos, van is javításod a bugra, de nem adod ki a javítást annak a pszichológiai hatásnak érdekében, hogy a project fejlesztése komolynak hasson, ne pedig kapkodónak?

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

Sokszor 1-3 óránként is frissül egy verzió, olyan gyorsan még tesztelni se lehet.

Velem is volt már olyan, hogy épp upgrade-eltem a firmware-t a fejlesztés alatt lévő műszereinken, s közben jutott eszembe, hogy hagytam benne bugot, vagy épp írtam bele regressziót, máris javítottam, újabb build, újabb upgrade még aznap.

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

Jó, az ilyen előfordul, de itt rendszeresen van ez, nem úgy, hogy volt már olyan. Mindig ez van mostanában. Meg más egy firmware, amit egy eszköz használ, és más egy csomag, amit embereknek tolsz ki egy tárolóba, akik próbálnák használni is. Még ha Testing is, akkor is kell időt hagyni, pont azért hívják Testingnek, hogy lehessen tesztelni. Ennyire kapkodni nem szabad, hogy csak ontod a buildeket, mert így nő meg a hibázás lehetősége, meg igazából semmi jó nem származik belőle.

zstd csomagnál nem különben, az 1.5.2-es verzió már jó régi, 1 éves, de megélt 8 buildet. Ez egy egyszerű CLI tömörítő könyörgöm, nem millió soros kódbázis, amiben hű de nagy sérülékenységek és bugok lennének, mi a ráknak kell 8× újrafordítani? Enyhítő körülmény, hogy legalább nem 1-2 nap alatt pörgették ki 8-szor, de akkor is kezd sok lenni egy verzióból. Persze, utánanézhetnék, hogy mi volt az oka, de őszintén szólva nem érdekel, egyszerűen csak a trendet látom károsnak.

Még az se baj, hogy 1-nél több build van, mert pl. ha a glibc frissül, akkor általában mindent újra kell fordítani, szinte az összes csomagot, akkor pl. elkerülhetetlen egy másik build, meg mindenki hibázik, egyszer el is ronthat valamit, legyen akkor 3 darab build. Na de 8-szor, meg 1-2 napon belül háromszor? Értem, hogy próbáljátok védeni, de nem szükséges, mert védhetetlen. Van egy szint, amin átlépve morbid lesz az egész, meg csak pótcselekvés szintű, és ilyenkor a csomagolónak magától rá kéne jönnie egy idő után, hogy ez így nem lesz okés hosszú távon, le kell nyugodni, jobban át kell gondolni dolgokat.

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

Van olyan, hogy azért buildelnek, mert változott annak a csomagnak a verziója, amelyre dependál. Pipewire-t fordították azért újra, mert újabb lett a libcamera. Vagy azért, mert valamelyik fejlesztőnek megváltozott az e-mail címe, vagy valaki nyafogott, hogy a dokumentációban nem szerepel, hogyan kell az API egy részét használni, s ez belekerült a manual page-be, a futtatható kód egy bitet nem változott.

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

0.3.68

Van benne egy súlyos bug, ne használjátok!

Nincs hang, ha elindítom mellé a pavucontrol keverőt, akkor van hang. Ha a keverőt bezárom, megint elmúlik a hang.

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

Nálam pont most frissült erre, és van hang. Mindenféle keverő nélkül. Rendesen újra is indítottam a gépet, hogy biztosan életbe lépjen. Nálam amúgy sincs fent a pavucontrol egyáltalán, helyette pulsemixer van, ami egy TUI alkalmazás, és azt se nagyon használom, mert gyorsbillentyűkkel adagolom a hangerőt (sxhkd + pamixer CLI), kimeneteket meg nem váltogatok.

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

Ha bent van legalább két kliensed egyszerre, akkor van hang. Azt hiszem, csak akkor van baj, ha összesen egyetlen kliens csatlakozik be hozzá. Ebben az esetben nem ébreszti fel illetve hagyja elaludni a default sink felé menő útvonalat. Ez a pw-top kimenetéből is látszik.

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

Azért próbáltam többféleképp is, pl. egy darab mpv-s lejátszással, semmi más nem futott, cold boot után. Nálad szerintem valami kimenetre nem kapcsolódik fel, amíg a pavucontrol nem aktiválja azt a kimenetet. Talán valami konfigba nyúltál bele. Vagy ahogy írod, pl. sleep miatt is lehet, nálam az nincs, nem hibernálok, nem teszem sleepbe a gépet. Nap elején bekapcsolom, végig megy, a végén kikapcsolom. Frissítésekkor meg gyakran reboot (ha valami igényli, kernel, systemd, pipewire frissítés), ritkábban tty újra bejelentkezés + xinit (ha az X, mesa, stb. frissült), nincs login manager sem telepítve. Emiatt nincsenek hosszú uptime-jaim, azok már úgyse mérőfokai a stabilitásnak.

Esetleg a DE-vel is összefügghet, amit használsz, hogy belepiszkál a hangkimenetbe, nálam meg csak WM van, az semmit nem piszkál sehová.

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

Nem altatom a gépet, desktop, nem lenne értelme. Az látszik, hogy hagyja aludni az USB audio kimenetet. Aztán elindítom a pavucontrol-t, feléled a kimenet, megy ki a hang az audacious-ról. Bezárom a keverőt, elalszik az USB kimenet, a hang bennreked az audacious-ban. Amúgy nem rég sikerült ezt a bugot belefejleszteni.

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

Úgy tűnik, megjavította Wim.

- Add 2 patches for some critical bugs.

A legfrissebb git master-ből fordítva már jó.

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

Örülök, hogy megoldódott. Ezek szerint tényleg létező bug volt, és nem a rendszereddel van a baj. Én voltam mázlis, hogy engem nem érintett. Van ez így, hogy egy bug csak akkor jön elő, ha valami együttállása forog fent több feltételnek hozzá. Sajnos ez a baja a nagyon komplex kódbázisoknak, könnyen becsúszik bug, és nehéz egyáltalán konzisztensen reprodukálni is, meg megmondani, hogy kiket érint, nem hogy javítani. Hiába nagyon új ez a Pipewire, már iszonyat komplex lett, el van bloatosítva, egyre vaskosabb és bonyolultabb minden újabb verziónál.

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

Erről megfeledkeztem:

0.3.69

Javítja az utóbbi idők csúnya regresszióit.

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

0.3.70

Többnyire regressziókat javít.

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

Egyelőre engem változatlanul elkerül, ezzel a verzióval sincs gond, de már kezdek félni ennyi regressziónál. Idő kérdése, hogy nálam is beüssön valami, ha már itt nektek ennyi gondotok van vele.

Bár engem most az Arch szopatott meg, nem pipewire, de kernelfrissítésnél nem generálódott le jól az mkinitcpio-s initramfs. A rendszer nem bootolt, elakadt a titkosítási jelszó bekérésénél, és az Arch live iso-t is hiába bootoltam be, az meg a hardveresen Opal + sedutil-cli-vel titkosított SSD tartalmát nem látta, a sedutil-cli persze nincs mellékelve az Arch iso-n. Végül megoldottam egy tartalék rendszerbe történő chroot-tal, ott volt sedutil-cli, kititkosítottam az SSD, majd azt felcsatolva chroot-oltam abba, és mkinitcpio -p linux kiadásával normálisan létrehoztam újra az initramfs-t. Vért hugyoztam vele. Igaz ez a sedutil-osok hibája is, mert van ahhoz egy rescue minimal Linux, bootolható, csak épp a noacpi van beledrótozva, és hiába titkosítom ki az SSD-t azzal, mikor indítaná újra a gépet, hogy egy másik OS-t bootoljak, ACPI nélkül áramtalanítódik az SSD újraindításkor, és buktam a kititkosítást, újra lezárva lesz. A jövőben majd építek egy másik live rendszert, amibe mellékelve van a sedutil-cli. Egyelőre áthidaló megoldásnak odamásoltam a sedutil-cli-t és az azt használó unlock scriptem a titkosítatlan boot partícióra, ott elérhető Arch live rendszer alól is.

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

Attól függ, mire és hogyan használtad a pulseaudio-t. Pulse-ban az idők, mintavételezés számolása szerintem nagyon félre volt gombolva. VoIP klienst használva a pulse alsa interface-én használhatatlanul széteső, recsegő-ropogó hangot eredményezett. Pipewire-ben ugyanez a VoIP kliens gyönyörű, stabil hangot hoz, működik a visszhang elnyomás is.

Mivel aktívan fejlesztik a pipewire-t, így előfordul, hogy hiba keletkezik benne, s elromlik valami, ami jó volt. Jelezni kell a hibát, ki lesz javítva.

(Munkám kapcsán én is írtam teljesen újra kommunikációs réteget, ami többet tud, mint a régi, meg javítja a réginek egy sokáig nem tudott, csúnya bugját, de az elején az általam újraírt kódban volt súlyos bug, szóval az elején rosszabb volt, mint a régi kód. Semmi baj, kijavítottam. Szóval ismerem az érzést, s talán éppen ezért nem vagyok türelmetlen Wim Taymans-szal és társaival szemben.)

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

Attól függ, mire és hogyan használtad a pulseaudio-t. Pulse-ban az idők, mintavételezés számolása szerintem nagyon félre volt gombolva. VoIP klienst használva a pulse alsa interface-én használhatatlanul széteső, recsegő-ropogó hangot eredményezett. Pipewire-ben ugyanez a VoIP kliens gyönyörű, stabil hangot hoz, működik a visszhang elnyomás is.

Igen, ezt a sztorit már számtalanszor hallottuk, hogy mivel a te voip kliensed ropogott, ezért a pulseban a mintavételezés biztosan elméletileg rossz. Mindeközben a világ jelentékeny része nyugodtan voipozott rajta. 

Mivel aktívan fejlesztik a pipewire-t, így előfordul, hogy hiba keletkezik benne, s elromlik valami, ami jó volt. Jelezni kell a hibát, ki lesz javítva.

(Munkám kapcsán én is írtam teljesen újra kommunikációs réteget, ami többet tud, mint a régi, meg javítja a réginek egy sokáig nem tudott, csúnya bugját, de az elején az általam újraírt kódban volt súlyos bug, szóval az elején rosszabb volt, mint a régi kód. Semmi baj, kijavítottam. Szóval ismerem az érzést, s talán éppen ezért nem vagyok türelmetlen Wim Taymans-szal és társaival szemben.)

Nem az a baj, hogy elromlik néha, az az igen vicces, hogy a pulse egy teljes szar, pötyi meg egy mérnöknek se nevezhető idióta, wim úrnak meg elnézzük, hogy időnként a faszba szétesik, meg hogy ja, hát most, hogy featureök vannak benne, már nem is olyan lightweight, miközben igazából csak az a különbség, hogy az egyikkel személy szerint szimpi neked, a másik meg nem.

Igen, ezt a sztorit már számtalanszor hallottuk, hogy mivel a te voip kliensed ropogott, ezért a pulseban a mintavételezés biztosan elméletileg rossz. Mindeközben a világ jelentékeny része nyugodtan voipozott rajta.

Nem csak az ő voip kliense ropogott. Nálam szinte minden recsegett, ropogott, laggolt vele. Sőt, volt egy olyan bugja is, hogy ha egy alkalmazást bezártam a hanglejátszás manuális megállítása nélkül, akkor utána az utolsó allokált buffer ott loopolt végtelen ciklusban. És ilyen jellegű hibával rengeteg ember találkozott. Hogy miután Poetteringet kiebrudalták a projektből, utána kifixáltak egy valag bugot és neked (és még sok más embernek) gond nélkül ment, az egy dolog, de attól még ami történt előtte, az megtörtént és az általános helyzet sem változott. A rossz koncepció és a rossz emlékek maradtak, ahogy a bloat is.

Nem az a baj, hogy elromlik néha, az az igen vicces, hogy a pulse egy teljes szar, pötyi meg egy mérnöknek se nevezhető idióta, wim úrnak meg elnézzük, hogy időnként a faszba szétesik, meg hogy ja, hát most, hogy featureök vannak benne, már nem is olyan lightweight, miközben igazából csak az a különbség, hogy az egyikkel személy szerint szimpi neked, a másik meg nem.

Ezért a szimpátia-antipátia dologért mindkét fejlesztő vastagon tett, hogy így legyen. Wim azzal, hogy partnerként és "kuncsaftként" kezelte a felhasználóit, Poettering meg azzal, hogy idiótaként és nyűgként kezelte a felhasználóit. Nehéz nem szimpatizálni az előbbivel és még nehezebb szimpatizálni az utóbbival.
Ami meg a lightweight-séget illeti: hasonlítsd össze a két alrendszer CPU és memóriaigényét null, light és heavy usage közben, ugyanazon a hardware-en, ugyanazon az OS-en. Csekkold le, hogy hány streamet tud összemixelni a PW és hányat a PA, mielőtt bemondják az unalmast és hogy mennyit zabálnak közben. A pulse még akkor is viszi a CPU időt, ha semmi audio művelet nincs éppen...

Nem csak az ő voip kliense ropogott .... És ilyen jellegű hibával rengeteg ember találkozott. Hogy ... neked (és még sok más embernek) gond nélkül ment, az egy dolog, 

Ja, az egy dolog, csak az van, hogy ti elég következetesen ignoráljátok, hogy egy csomó embernek működött

 utána kifixáltak egy valag bugot ... de attól még ami történt előtte, az megtörtént

Szóval ha a pulse kezdetben szarakszik hülye bugokkal, akkor hiába javítódik ki pfujj, ha a pipwire kezdetben szarakszik például az ebben a topikban látható fél vödör regresszióval, de javítódik, akkor az éjjen-éjjen :)

Ami meg a lightweight-séget illeti: hasonlítsd össze a két alrendszer CPU és memóriaigényét null, light és heavy usage közben, ugyanazon a hardware-en, ugyanazon az OS-en. Csekkold le, hogy hány streamet tud összemixelni a PW és hányat a PA, mielőtt bemondják az unalmast és hogy mennyit zabálnak közben. A pulse még akkor is viszi a CPU időt, ha semmi audio művelet nincs éppen...

Méregessen a nehézség, annyira nem érdekel. Amit tudok, hogy amíg pulset használtam, addig nem volt időnként elveszett device, nem volt időnként varázslatosan nem szóló hang, nem pörgött időnként 100%-on a proci. Ezeket az elmúlt 1-1.5 évben, mióta a fedora ezt szállítja mind csinálta a pipwire. Szóval ha ez a mérce, akkor bizony a pipwire egy szar. 

Ezért a szimpátia-antipátia dologért mindkét fejlesztő vastagon tett, hogy így legyen. Wim azzal, hogy partnerként és "kuncsaftként" kezelte a felhasználóit, Poettering meg azzal, hogy idiótaként és nyűgként kezelte a felhasználóit. Nehéz nem szimpatizálni az előbbivel és még nehezebb szimpatizálni az utóbbival.
 

Ja, hát pötyi nem egy matyóhímzés, azt meg kell hagyni. Ezzel együtt feltétlen érdemes ám a szoftver minőségét összemosni a kommunkációjáéval. Pl mert a felhasználói sokszor tényleg idióták voltak. Ha köcsög lennék, mondanám, hogy locsemege átérzi  Wim helyzetét, mert adott már ki orbitális bugos szart a kezéből, én meg tudom átérezni Pötyi helyzetét, mert terelgettem már nagy kódbázisokat meg projekteket, és tudom milyen az, amikor valaki igazsága teljes tudatában érkezik, hogy biztosan teljesen szar a belseje, meg mi a fenéért nem akarom más szarjait megpatkolni egy általános implementációban (lásd még alsa bugok, mert jó az a return 0 implementáció), miközben igazából fingja nincs miről beszél.

Másrészt ha utáljuk azokat az opensource projekteket, aminek vmi borderline pszihó az apukája, akkor azért elég sok mindent kéne utálni, lásd pl Linus "masturbating monkeys" Torvalds vagy Theo "hű vagyok a családnevemben található rágcsálóhoz" de Raat, hogy mást ne mondjak.

(Azt az utcát már ki se merem nyitni, hogy pfujj systemd, mert mindent egybegyúr, bezzeg a pipwireben mekkora jóság már, hogy a videót is belekeverték)

Ja, az egy dolog, csak az van, hogy ti elég következetesen ignoráljátok, hogy egy csomó embernek működött

Ennyi erővel mi is mondhatnánk, hogy te meg azt ignorálod, hogy egy csomónak meg nem megy.

Szóval ha a pulse kezdetben szarakszik hülye bugokkal, akkor hiába javítódik ki pfujj, ha a pipwire kezdetben szarakszik például az ebben a topikban látható fél vödör regresszióval, de javítódik, akkor az éjjen-éjjen :)

Most vagy kezdődik a szalmabábcséplés, vagy nem olvastad el, amit írtam.

Méregessen a nehézség, annyira nem érdekel.

Ez elég sok mindent megmagyaráz.

Amit tudok, hogy amíg pulset használtam, addig nem volt időnként elveszett device, nem volt időnként varázslatosan nem szóló hang, nem pörgött időnként 100%-on a proci. Ezeket az elmúlt 1-1.5 évben, mióta a fedora ezt szállítja mind csinálta a pipwire. Szóval ha ez a mérce, akkor bizony a pipwire egy szar.

Jelentetted ezeket a problémákat? Csak mert ellentétben a PA-val, itt megpróbáltak volna segíteni neked. Még az is lehet, hogy valami konfigmizériába futottál bele, azért volt időszakos a probléma és nem állandó.

Ezzel együtt feltétlen érdemes ám a szoftver minőségét összemosni a kommunkációjáéval.

Nem összemostuk, indoklásként használtuk az antipátia kapcsán. Amúgy a PA (és a systemd) esetén a NOTABUG-WONTFIX szindrómát "kommunikációnak" nevezni erős ferdítés. Ez itt már több, mint kommunikáció, ez a projekt managementje. És amikor a management így kezeli le a hibajelentéseket, ott bizony a "kommunikáció" és a szoftver minősége között ok-okozati kapcsolat is létezik. Azért ez nem összemosás.

Pl mert a felhasználói sokszor tényleg idióták voltak.

Biztosan volt ilyen, de ez nem mentesíti Poetteringet a saját hülyeségei alól.

Ha köcsög lennék, mondanám, hogy locsemege átérzi Wim helyzetét, mert adott már ki orbitális bugos szart a kezéből

Ez kezd átmenni személyeskedőbe. Az, hogy volt a frissen újraírt kódjában egy darab súlyos bug, az távolról sem ekvivalens azzal, hogy az egész egy orbitális bugos szar lett volna.

én meg tudom átérezni Pötyi helyzetét, mert terelgettem már nagy kódbázisokat meg projekteket, és tudom milyen az, amikor valaki igazsága teljes tudatában érkezik

Ezt én is át tudom érezni, de Poettering mindenkit így kezelt.

hogy biztosan teljesen szar a belseje

Bármilyen hülye is volt egyébként a júzer, aki ezt állította, ebben speciel nem tévedett.

meg mi a fenéért nem akarom más szarjait megpatkolni egy általános implementációban (lásd még alsa bugok, mert jó az a return 0 implementáció), miközben igazából fingja nincs miről beszél.

Isoraz, Poetteringet a saját hülyeségei alól nem mentesíti mások hülyesége. Sem a júzereké, sem az ALSA-deveké. Senki sem állította, hogy minden is Poettering hibája volt a PA fejlesztése alatt. Az állítás az volt, hogy a PA-val rengeteg nyűg volt, rossz a koncepciója (buffer-juggling), resource-hog, bugos és Poettering nem volt hajlandó foglalkozni a problémákkal, miközben az alrendszere kvázi-szabvánnyá vált a Linux disztribúciókban. A systemd ugyanez a sztori volt szteroidokon.

Másrészt ha utáljuk azokat az opensource projekteket, aminek vmi borderline pszihó az apukája, akkor azért elég sok mindent kéne utálni, lásd pl Linus "masturbating monkeys" Torvalds vagy Theo "hű vagyok a családnevemben található rágcsálóhoz" de Raat, hogy mást ne mondjak.

Hát utáld. Ki tart vissza? Nekem is megvan a magam elég vegyes véleménye Linusról és a Linuxról, ahogy Theo-ról és az OpenBSD-ről is. Viszont Poetteringről csak negatívumot tudok elmondani, ahogy a "műveiről" is. Jól mondta locsemege: "már jó helyen van a Microsoftnál". Vagy, hogy az öcsém idevágó aranyköpését is idézzem: "Minden jó szakember az ms-nél köt ki, reméljük lesz még windows 12 is..."

(Azt az utcát már ki se merem nyitni, hogy pfujj systemd, mert mindent egybegyúr, bezzeg a pipwireben mekkora jóság már, hogy a videót is belekeverték)

Ebbe az utcába tényleg kár belemenni, mert egyrészt még nem tudjuk, hogy hosszútávon hogy fog elsülni, hogy belekeverték a videót (igen, lehet, hogy igazad lesz és rosszul), másrészt meg a PW esetén a videó opcionális.

Ez kezd átmenni személyeskedőbe. Az, hogy volt a frissen újraírt kódjában egy darab súlyos bug, az távolról sem ekvivalens azzal, hogy az egész egy orbitális bugos szar lett volna.

Ráadásul cégen belül, fejlesztés alatt álló gépre, szóval ügyfélhez nem került ki hibásan, csak néhány kollégának okoztam pár keserű órát.

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

Ennyi erővel mi is mondhatnánk, hogy te meg azt ignorálod, hogy egy csomónak meg nem megy.

Nem igazán, én elhiszem, hogy vannak vele nyűgök, az "egész egy használhatatlan bughalmaz mantrát" nem szeretem. 

Most vagy kezdődik a szalmabábcséplés, vagy nem olvastad el, amit írtam.

Vagy csak próbálom felhívni a figyelmet a kettősmércére :) 

Jelentetted ezeket a problémákat? Csak mert ellentétben a PA-val, itt megpróbáltak volna segíteni neked. Még az is lehet, hogy valami konfigmizériába futottál bele, azért volt időszakos a probléma és nem állandó.

Nem, annyira nem volt akudt, én tudok élni azzal, hogy időnként oldalba kell rúgni. Mondjuk nem tudom, milyen konfig mizéria okozhatná azt, hogy eltűnik az összes device a faszba, de nyilván jó a lelketeknek, ha ilyenkor lehet azt gondolni, hogy én voltam a béna, nem a szoftver bugzott :) (és még mielőtt, simán lehet, hogy a fedorások voltak balfaszok, vagy az udev környéke, nem feltétlen a pipwire. De hát ugye tessék más szarját itt megjavítani, mint tudjuk :) ) 

Ez kezd átmenni személyeskedőbe. Az, hogy volt a frissen újraírt kódjában egy darab súlyos bug, az távolról sem ekvivalens azzal, hogy az egész egy orbitális bugos szar lett volna.

Tudom, hogy ez neked kedvenced, szóval kérlek vedd észre a direkt sarkítást benne. (Illetve hát egyébként egyrészt elég vicces az ezen való leakadás, miközben üzemszerűen törölgetitek a lábatokat pötyibe, másrészt mivel pont ennek a topicnak az előzményében fejtette ki a kolléga, hogy az úr azért nem mérnök, mert nem gányol... szóval akkor tulajdonképp én miért is ne használhatnám ezeket alapul?)

Nem összemostuk, indoklásként használtuk az antipátia kapcsán.

De, mert az utálom a pulset != szar a pulseal. Az utálom pötyit -> utálom a pulset meg aztán főleg nem.

Amúgy a PA (és a systemd) esetén a NOTABUG-WONTFIX szindrómát "kommunikációnak" nevezni erős ferdítés. Ez itt már több, mint kommunikáció, ez a projekt managementje. És amikor a management így kezeli le a hibajelentéseket, ott bizony a "kommunikáció" és a szoftver minősége között ok-okozati kapcsolat is létezik. Azért ez nem összemosás.

Vagy igen, vagy nem. Értem én, hogy nem tetszik, hogy azt mondta például, hogy a szerelje meg a szar alsa drivert az alsa driver írója a helyén, azt főleg értem, hogy nem tetszik a stílus, amiben ezt mondta. Ettől még baromira nem egyértelmű, hogy projekt management szempontból nincs neki igaza (és hogy pl nem segített Wimnek és a pipwirenek is, hogy a köcsög wontfixes pötyi miatt pl jobb minőségűek lettek az alsa driverek)

Az állítás az volt, hogy a PA-val rengeteg nyűg volt, rossz a koncepciója (buffer-juggling), resource-hog, bugos és Poettering nem volt hajlandó foglalkozni a problémákkal, miközben az alrendszere kvázi-szabvánnyá vált a Linux disztribúciókban. A systemd ugyanez a sztori volt szteroidokon.

Mindeközben a pippel is van egy csomó nyűg, és bug, szépen fejlődik a resource fogyasztása is (nem szerintem, a topicban levők szerint), és meanwhile meg valamiért a pulse mégis adott egy olyan többletet a _létező bajai ellenére!_ hogy kvázi szabvány lett. Én tök el tudom fogadni, hogy belül a pipwire jobb, nyilván nem véletlen kapja meg a fókuszt mostanában, de ezzel együtt is nagyon szórakoztató, hogy alapvetően tök hasonló problémákat mennyire másik oldalról szemléltek szeret/nemszeretből kiindulva.

Hát utáld. Ki tart vissza? Nekem is megvan a magam elég vegyes véleménye Linusról és a Linuxról, ahogy Theo-ról és az OpenBSD-ről is.

Miért utálnám, csak mondom, hogy na

Viszont Poetteringről csak negatívumot tudok elmondani, ahogy a "műveiről" is. Jól mondta locsemege: "már jó helyen van a Microsoftnál". Vagy, hogy az öcsém idevágó aranyköpését is idézzem: "Minden jó szakember az ms-nél köt ki, reméljük lesz még windows 12 is..."

Igen, értem, meanwhile egész sokan egész jól elvannak vele :)

Ebbe az utcába tényleg kár belemenni, mert egyrészt még nem tudjuk, hogy hosszútávon hogy fog elsülni, hogy belekeverték a videót (igen, lehet, hogy igazad lesz és rosszul), másrészt meg a PW esetén a videó opcionális.

Pont ugyanannyira opcionális, mint a systemd nagy része. Ki lehetne válogatni azt is, ezt is, a disztribútorok mégse teszik. És míg pl ment a nyavajgás, hogy jjajajjajjaj dependálnak a sessionkezelésre pl a gnomék miatta, most pl nem hallom a hatalmas siránkozást, hogy ha wayland alatt akarsz screen recordingot, akkor lehet használni a pipwiret, a pipwiret, vagy a pipwiret :)

Nem igazán, én elhiszem, hogy vannak vele nyűgök, az "egész egy használhatatlan bughalmaz mantrát" nem szeretem.

Ez nem mantra, hanem tény...

Vagy csak próbálom felhívni a figyelmet a kettősmércére :)

Az nem kettős mérce, hogy a PA-n a bugfixek nem segítenek, mert a koncepció rossz. Vagy a szimpátia/antipátia dologra célzol? Nos, azért, meg mint mondtam, mindkét fejlesztő vastagon tett.

Nem, annyira nem volt akudt, én tudok élni azzal, hogy időnként oldalba kell rúgni.

Tehát nem jelented, mert tudsz vele együtt élni, de azért publicba' meg fikázod?

Mondjuk nem tudom, milyen konfig mizéria okozhatná azt, hogy eltűnik az összes device a faszba, de nyilván jó a lelketeknek, ha ilyenkor lehet azt gondolni, hogy én voltam a béna, nem a szoftver bugzott :) (és még mielőtt, simán lehet, hogy a fedorások voltak balfaszok, vagy az udev környéke, nem feltétlen a pipwire. De hát ugye tessék más szarját itt megjavítani, mint tudjuk :) )

Szalmabáb #1: senki nem mondta, hogy te voltál béna, a default konfig is lehet olyan, hogy nálad összeakad valamivel. Szalmabáb #2: Azt se mondta senki, hogy nem a szoftver bugzott, az volt az állítás, hogy lehet, hogy konfig baj volt. Szalmabáb #3: Azt meg pláne nem mondta senki, hogy más szarját kell megjavítani; az volt az állítás, hogy senki nem mondta, hogy mindenért is Poettering volt a hibás, de más baromsága nem mentesíti őt a sajátja alól.

Tudom, hogy ez neked kedvenced, szóval kérlek vedd észre a direkt sarkítást benne.

Ebben is? Mert ez is személyeskedés volt.

Illetve hát egyébként egyrészt elég vicces az ezen való leakadás, miközben üzemszerűen törölgetitek a lábatokat pötyibe

#1: Nem Poetteringgel vitatkozunk. #2: Poettering üzemszerűen törölgette a lábát a júzereibe és mindenki másba is, függetlenül attól, hogy igaza volt-e, vagy sem.

másrészt mivel pont ennek a topicnak az előzményében fejtette ki a kolléga, hogy az úr azért nem mérnök, mert nem gányol... szóval akkor tulajdonképp én miért is ne használhatnám ezeket alapul?

Mert velünk vitatkozol és nem Poetteringgel és Wimmel. Olyat biztos nem láttál locsemegétől, hogy téged fikázott.

De, mert az utálom a pulset != szar a pulseal.

Szalmabáb: utálom a pulse-t != szar a pulse, de nem is ezt mondtuk, hanem azt, hogy szar a pulse && utálom a pulse-t, pontosabban szar a pulse -> utálom a pulse-t.

Az utálom pötyit -> utálom a pulset meg aztán főleg nem.

Szalmabáb: Nem ezt mondtuk; felcserélted az okot az okozattal.

Értem én, hogy nem tetszik, hogy azt mondta például, hogy a szerelje meg a szar alsa drivert az alsa driver írója a helyén, azt főleg értem, hogy nem tetszik a stílus, amiben ezt mondta. Ettől még baromira nem egyértelmű, hogy projekt management szempontból nincs neki igaza

Nem bírsz leakadni erről az ALSA bugról... Akkor még egyszer: #1: Más baromsága nem mentesíti Poetteringet a sajátjai alól. #2: Poettering mindenkit így kezelt, függetlenül attól, hogy igaza volt-e, vagy sem.

(és hogy pl nem segített Wimnek és a pipwirenek is, hogy a köcsög wontfixes pötyi miatt pl jobb minőségűek lettek az alsa driverek)

Akkor az életben egyszer még haszna is volt a létezésének...esetleg.

Mindeközben a pippel is van egy csomó nyűg, és bug, szépen fejlődik a resource fogyasztása is (nem szerintem, a topicban levők szerint)

Ha Raynesre gondolsz, őt már felvilágosítottam arról, hogy nagyon el van tévedve: 70-100 MB RAM fogyasztás a komplett ökoszisztémának - úgy, hogy ennek a jelentős része valószínűleg a rendszer által kiosztott buffer és cache volt - nem sok.

és meanwhile meg valamiért a pulse mégis adott egy olyan többletet a _létező bajai ellenére!_ hogy kvázi szabvány lett.

Nem. Az a baj, hogy ez nem igaz. A pulse ugyanazért lett kvázi-szabvány, mint a systemd: mert egy a Linux világra rendkívül nagy befolyással bíró multi (Red Hat) állt mögötte, Poettering pedig elég agresszíven tolta magát és a cuccait, hogy sokan elhiggyék a bullshitet, amit tol.

Én tök el tudom fogadni, hogy belül a pipwire jobb, nyilván nem véletlen kapja meg a fókuszt mostanában, de ezzel együtt is nagyon szórakoztató, hogy alapvetően tök hasonló problémákat mennyire másik oldalról szemléltek szeret/nemszeretből kiindulva.

Bocs, ha valami ab ovo fos, a készítője meg anyámat szidja, ha bugreportot küldök, akkor had szimpatizáljak már inkább azzal, aki egy jobb minőségű szoftvert készít és még meg is köszöni, ha bugreportot küldök neki...

Igen, értem, meanwhile egész sokan egész jól elvannak vele :)

Ahogy a maunikasóval és a barátokközttel is. A popularitás nem indikátora a kvalitásnak, vagy, hogy ne NagyZoljak: ez a tehénszar érv, azaz együnk tehénszart, annyi légy nem tévedhet.

Pont ugyanannyira opcionális, mint a systemd nagy része. Ki lehetne válogatni azt is, ezt is, a disztribútorok mégse teszik.

Forrás szinten minden opcionális; ki lehet belőle patchelni. De by-default nem az. Megy a PID1-be, maximum nem használod. Tök jó, hogy ott van.

És míg pl ment a nyavajgás, hogy jjajajjajjaj dependálnak a sessionkezelésre pl a gnomék miatta, most pl nem hallom a hatalmas siránkozást, hogy ha wayland alatt akarsz screen recordingot, akkor lehet használni a pipwiret, a pipwiret, vagy a pipwiret :)

És ez a PW hibája talán? Wim erőszakolta ki, hogy Wayland alatt csak az ő cuccát lehessen recordingra használni? Vagy ő csak megcsinálta, hogy legyen benne ilyen opció, más meg nem tette. Ez őt minősíti, vagy a Waylandos ökoszisztémát? Ezzel szemben a gnómháromnál ki a franc is kérte, hogy kötelezően dependeljen a systemd-re?

Ez a lovon fordítva ülés esete.

pötyibe

Egyébként bocs, de miért nem lehet valakinek a nevét normálisan leírni?

Egy dolog nem kedvelni az illetőt, vagy a munkáját, de az inkább rólad állít ki tanúbizonyságot, hogy ebben az esetben se tudsz tárgyilagos maradni, és ilyen dedós eszközökhöz folyamodsz inkább. Függetlenül attól, hogy mennyire értek veled egyet vagy sem, nehéz komolyan venni ezek miatt. 

El vagy tévedve, krozoo pont őt védte. Egyébként a Pötyi az csak ilyen becenév, nincs feltétlenül pejoratív mögöttes tartalma. Azok is szokták Pötyinek hívni, akik a pártján állnak.
A Pöcstering, vagy a Pöcshering, na, az már inkább olyan jellegű névkifacsarás, mint amire te gondoltál.

Igen, a pipewire szimpatikus, a pulseaudio meg nem. Egyrészt az előbbi működik egy adott környezetben, az utóbbi nem. Másrészt lényeges különbség a hozzáállás. Wimben van szakmai alázat, nem másban keresi a hibát, kér logokat, megoldja a problémát, megköszöni az együttműködést, például, amikor teszteltem az ideiglenes változatokat. Ezzel szemben Lennart elmondja, hogy nem lesz kijavítva, ez ALSA bug, WONTFIX. Mindeközben olvastam, hogy ködösített, s a pulseaudio működésének leírásánál olyasmit írt, hogy ez egy bonyolult algoritmus, blabla... Ugyan nem triviális a probléma, de nem is megoldhatatlan, ilyen ködösítés nagyon zavaró tud lenni.

De semmi baj, Lennart már jó helyen van a Microsoftnál. :D

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

Aki dolgozik hibázik. Emberek vagyunk. A fő, hogy valaki elismerje a hibáit és kijavítsa azokat. A pulse létező problémákat próbált megoldani, de egyrészt tette ezt olyan kód és hangminőséggel, hogy jajj, másrészt a fejlesztői hozzáállás is ég és föld a két projekt között.

Mi volt a pulse-ban? WONTFIX, NOTABUG, FUCKYOU. Itt? Fixed.
Vagy, ha peched van, akkor could not reproduce, de az nem a fejlesztő hibája. Én is kaptam olyan "bugreportot" (igazából enhancement requestet) a YTFE-hez, amit nem tudtam reprodukálni, mert nem volt olyan gyenge gépem. De nem szartam le, amit tudtam, megtettem. És volt, hogy vakon is sikerült javítani a helyzeten.

Poettering nem a systemd-vel vívta ki a közutálatot (azzal "csak" a public enemy no. 1 státuszt érte el :P ), hanem már a pulseaudio-val és a hozzáállásával.

Nekem gondom nem volt vele, de utálom mégis. Jó 1 éve van kint, már óriási vaskos bloat, veri a több év alatt elhízott Pulsaaudio-t is.

A kérdésedre válaszolva: ez nem csak a hangot kezeli, hanem videókat, waylandes portálokat is. Egyfajta átfogó megoldás minden multimédiás cuccra. Ráadásul teljesen ki fogja váltani a Pulseadio-t, egyre több mindennek függősége lesz. Ezt nem értették páran a többi topikban, mikor 10 éves disztrókat akarnak használni, hogy a Linux világa gyorsan változik, és nincs benne állandóság, nem az van, hogy egy Win32 API-val jól elvan bárki 20-30 évig. Elég 10 év, és hangrendszerek, újfajta display megoldások, új initrendszerek, stb. jönnek mennek, minden szinte azonnal dependel rájuk. Persze nekem nem lehet elhinni, mert nem vagyok fejlesztő, nem használok gigás bloatokat, meg ilyen Rust, Java, ChatGPT, egyéb menőségekből is kimaradok.

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

A bloat nem azt jelenti, hogy egy szoftver nagy. Ennyi erővel bloat az OpenBSD, hiszen többszáz MB. A bloat az, ha valami indokolatlanul nagy. A tudásához képest. Az a bloat. A PW egyébként nem igényli a Wayland-ot, opcionális. És egyébként marha kevés program igényli konkrétan a PW-t. A programok a PA-t igénylik, amit a PW a saját PA rétegén keresztül ki tud elégíteni, de ez nem PW-függőség.

Erre meg:

10 éves disztrókat akarnak használni, hogy a Linux világa gyorsan változik, és nincs benne állandóság, nem az van, hogy egy Win32 API-val jól elvan bárki 20-30 évig. Elég 10 év, és hangrendszerek, újfajta display megoldások, új initrendszerek, stb. jönnek mennek, minden szinte azonnal dependel rájuk.

Én fejlesztő vagyok és itt ALSA van, X11 van és a KDE3-fork TDE az ablakkezelőm. Szinte csak "régi" szoftvereim vannak.

Az OpenBSD-t nem mondanám bloatnak. Igen, több száz mega, de egy komplett OS, és a mérete alatta van egy 22 évvel ezelőtti XP-nek. Nekem az OBSD-vel az a bajom, hogy a hardver/szoftvertámogatása és a sebességre optimalizáltsága nagyon elmarad egy Linuxtól, cserében viszont soványabb, és nincs rajta Pötteringware szarkupac. Egy pótgépen néha gyűrődök vele, bár most elromlott az SSD alóla, egy másikon meg most majd FreeBSD-re nyergelek, azt régebb óta nem próbáltam.

Linuxon nálam is X11 van, meg WM (bspwm + polybar, login manager nélkül), a TDE-nél is sokkal kisebb. Szoftverek is régiek, szinte minden terminálos vagy non-GUI (simple terminal, dmenu, mpv, zathura, cmus, ffmpeg, vifm, neovim, neomutt, htop-vim, stardict-cli, bc/calc, headless Transmission, XeTeX, plusz egy csomó saját fzf-es script mountolásra, jelszókezelésre, gyors dokumentummegnyitásra, konvertálásra, stb.), egyedül csak a Steam, Firefox, Signal GUI-s program, még a screenlock-om is terminálos (alock + st + asciiquarium). Ennek ellenére a Pipewire bloat, 68 mega RSS (pipewire, wireplumber, pipewire-pulse folyamatok együtt), de egy hosszabb munkamenet után behízik akár 100 megára is. A Pulseadio ennek fele volt, és ahhoz képest nem nyújt többet. Nekem nem kell portálozgatni, meg streamelni, képernyőt megosztani Waylanden, ezt a tudását úgyse használom ki.

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

Erről beszéltem, hogy a PW sem bloat, hanem sokat tud. Ahhoz képest, hogy mennyit, nem olyan nagy. A Pötteringware szarkupacok, na azok bloated-ek.
Az OpenBSD egyébként a szekuricsira gyúr; ha sebességet akarsz, azt nem ott kell keresni, bár azért lassúnak azért nem mondanám. A HW/SW támogatás hiánya meg nem az ő hibájuk. Nem portolják a drivereket/software-eket OpenBSD-re a fejlesztők.

Az, hogy a PW teljes ökoszisztémája (nem csak a daemon) egy idő után 100 MB-t is lefoglal...azért az még nem a világ, bár látszatra nem kevés, de kérdem: abból mennyi a valódi memóriahasználat és mennyi, amit a rendszer vágott oda buffer és cache gyanánt? A ténylegesen allokált memória sokszor a töredéke annak, amit az usage alatt látsz. És ha folyamatosan hízott fel odáig, akkor az gyanús, hogy annak a java az buffer, meg cache volt és nem a PW cuccai foglalták le. Ha 8-10 processz egy hosszabb munkamenet után bufferestől/cache-estől összesen 100 MB-ot eszik meg, az még nem a bloat kategória. Majd akkor szólj, ha már 2.5 GB-nál jár és összedől tőle a géped. :P Na, az bloat. Nem 100 MB az egész multiprocesszes ökoszisztémának, bufferrel, cache-sel együtt...

Igen, sokat tud a PW, de pechjére nekem csak az kéne, hogy legyen hang és ennyi. Ezt tudja az OpenBSD szög egyszerű sndio alrendszere is, meg a jó öreg linuxos ALSA, kb. 10-ed annyi memóriafogyasztásból és kódméretből. Ma már nem ajánlják, hogy akárki is Pulseaudiót használjon, szerintem lesz egy pont, ahol fejlesztés hiányában teljesen el is fog halni.

A 100 mega foglalás az csak RSS memória, a buffers, cache külön van Linuxnál.

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

A video opcionális. A sndio-t és az ALSA-t nem igazán kéne idekeverni, mert a PW az egy middleware, nem lowlevel layer, mint a másik kettő.

Azt tudom, hogy külön van, csak az RSS ottléte felett elsiklottam. Mindenesetre egy multiprocesszes ökoszisztémának annyira nem sok a 100 MB, még ha nálad indokolatlan is. Mondom: a pulse akár Gigákat is felfal, aztán összedönti a gépet. Ehhez képest mi az a 100 MB, még ha nálad indokolatlan is? Konfigold be, patcheld ki...nem szükségszerű, hogy annyi legyen.

Nálam a Pulseaudio sose dőlt össze, nem memory leakelt. Persze azt se szerettem, mert bloat volt. Pont ez az, hogy nekem nem kell middleware, legyen hang és kész. Jelenleg a linuxos megoldás agyon van bonyolítva, egymásra épülő layerökkel, ALSA fölött Pulseaudio fölött Pipewire fölött Wireplumber (ami szorítja ki a pipewire-media-session-t). Pulseadio épp úgy van továbbra is, de az a PW egyik rétege: pipewire-pulse, ami kell azoknak a programoknak, amik még Pulseaudio only-nak készültek.

Igazából már a X.org is bloat, kapásból egymaga megeszik 100+ MB RSS-t. Alacritty böngésző is már 120 mega egy böngészőablakért, egy vicc, nem véletlen váltottam st-re, az csak 16 mega. Gondolkodom, hogy idővel átváltok xterm-re, az csak 10 mega RSS, annak is a nagy része shared, és legutóbb abba is belepecselték a teljes Unicode + truecolor támogatást, így nekem elég lenne.

A másik, amit mindig is utáltam, az a CUPS. Bloat, igaz nem kell mindig futnia. Hála istennek a normálisabb IPP-s nyomtatókhoz már nem kell.

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

ALSA fölött Pulseaudio fölött Pipewire fölött Wireplumber (ami szorítja ki a pipewire-media-session-t). Pulseadio épp úgy van továbbra is, de az a PW egyik rétege: pipewire-pulse, ami kell azoknak a programoknak, amik még Pulseaudio only-nak készültek.

Nem vagyok a kérdés szakértője, de ez szerintem nem így van. Alul van az ALSA, fölötte a pipewire, amelynek van jack, pulse és alsa interface-e. Továbbá kliens oldal felől megtartották a pulseaudio library interface-t, amely függvényekkel lehet pulse szerverhez csatlakozni, de mivel a pipewire-nek van pulse kompatibilis szerver interface-e, így ahhoz is. A wireplumber pedig a session manager és azért szorítja ki a pipewire-media-session-t, mert ez utóbbi csak egy demo program, ami bemutatja, hogyan lehet a pipewire felé ezt használni, illetve kellett valami munkaeszköz a fejlesztéshez. Amióta van wireplumber, már nem kell a pipewire-media-session.

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

Igen, ám, de ha a wireplumbert leszeded, nem játszanak le a videók. Maradjunk abban, hogy nem csak két réteg. Ami program Pulseadio-t használna, annak is kell a pipewire-pulse. Csomó réteg, csomó bloat.

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

Talán még az audiohoz is kell. Mert szerintem a wireplumber az udev alapján a jelutak, a gráf létrehozásában is közreműködik, de ennek utána kellene néznem, kezeljétek fenntartásokkal ezt a mondatomat.

A pipewire-pulse szerintem a pulseaudio szerver emuláció. Miért zavar, hogy szétszedték külön csomagba? Az egész egyetlen program, az csak a telepítő scriptjének sajátja, hogy egyes részeit külön csomagokba teszi.

Nem feltétlen csomó réteg, mert például a jack, alsa, pulse interface-ek azonos szinten vannak, nem egymás fölé rakódnak. Csak szétszedték, mert ha valami picike hardware-re tennéd, s nem kell a jack interface, akkor nem muszáj feltenni.

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

Nálam a Pulseaudio sose dőlt össze, nem memory leakelt.

Bocs, de ez a WORKSFORME érv.

Pont ez az, hogy nekem nem kell middleware, legyen hang és kész.

Ebben egyetértünk. Nekem sem kell, nincs is felrakva nálam a PW. De ettől még nem szar.

Jelenleg a linuxos megoldás agyon van bonyolítva, egymásra épülő layerökkel, ALSA fölött Pulseaudio fölött Pipewire fölött Wireplumber (ami szorítja ki a pipewire-media-session-t).

Nem, ez nem így van, de ezt locsemege már megválaszolta.

Pulseadio épp úgy van továbbra is, de az a PW egyik rétege: pipewire-pulse, ami kell azoknak a programoknak, amik még Pulseaudio only-nak készültek.

Nope, ez interface wrapping, PA nincs a rendszerben, a PW "emulálja".

Igazából már a X.org is bloat, kapásból egymaga megeszik 100+ MB RSS-t.

Az X11 bloat, de nem azért, mert egymaga megeszik 100 MB-t; a mai nagyfelbontású képernyőkön ez nem is vészes: ha belegondolsz, hogy egy 1920x1080x32-es ablak circa 8 MB-ot eszik, akkor kiszámolhatod, hogy 13 fullscreen-re tett ablak és máris kb. 100 MB-nál jársz... Szóval ez nem sok és az X11 sem ezért bloat, hanem azért, mert egy csomó "döglött kód" van benne. (Azért az idézőjel, mert tkp. nem döglött, csak ma már rohadtul nem használják, így feleslegesen van ott.) A koncepciója is eléggé idejétmúlt: már nem gép<->terminál felosztás van. Viszont visszakérdeznék: a "defacto" Wayland implementáció, a Weston, na az talán nem egy bloated szar? De és még atom bugos is. Az X11 legalább működik. (Többnyire, na. :P )

A másik, amit mindig is utáltam, az a CUPS. Bloat, igaz nem kell mindig futnia. Hála istennek a normálisabb IPP-s nyomtatókhoz már nem kell.

Erre +1. A CUPS-nak a kisebbik baja, hogy bloat, de még egy kalap szar is...

eléggé idejétmúlt: már nem gép<->terminál felosztás van

Ez részben igaz, ezért lett a Wayland, viszont én nem bánom, hogy van X.org, mert szoktam távolról ssh tunnelt használni ssh -X formában, és akkor nagyon kell nekem, hogy a remote gépen futó alkalmazás - jelesül levelező kliens grafikus felülete, ablaka - az abban a pillanatban épp terminálként is funkcionáló gép monitorán jelenjen meg, s tudjam használni.

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

Miért, mit akartál megvédeni? A Wayland-et? Azt nem bántottam. Konszenzus van mt9 és köztem, miszerint a Wayland-del - a protokollal - nincs különösebb baj. A Wayland kompozitorokat en-bloc? Nem azt mondtam, hogy egyáltalán nincs normális, hanem, hogy amik elterjedtek, azok közt nincs. A Clayland pl. jó, de behalt és underground. A Sway-t nem ismerem, az lehet, hogy oké, de az sem egy mainstream kompozitor; a Weston meg a Mutter az. Vagy pont a Westont, meg a Muttert akartad megvédeni? Azokat meg kár lett volna... Ha nekem nem hiszel, kérdezd meg SzBlackY-t: ő jobban vágja a Wayland-es kompozitorokat, hogy melyik mennyire jó, vagy rossz; kérdezd meg tőle, mekkora fos a Weston...

Én nem tudom mi a mérce amit figyelni kellene. Mitől lesz normális valami? Az nem elég jó, hogy pl a Mutter alatt a gnome 98% úgy funkcionál mint X alatt, a maradék 2% félig előny, félig pedig ugyan bug, de cserébe az X javára is tudnék felsorolni komoly problémákat, ami cserébe wayland alatt nincs?

A GNOME önmagában is egy rettenet, szóval ez nem mond semmit. De nem láttad a hibajegyet, amit belinkeltem? De van ott még, szemezgess. A kérdésed ugyanis arra vonatkozott, hogy ha szerintem nincs normálisan implementált mainstream Wayland kompozitor, akkor micsoda a Mutter. Hát nem egy normálisan implementált Wayland kompozitor; ez egy bughalom, mint maga a GNOME is...

Láttam, persze. Nem írtam sehol, hogy ne lennének hibák, de hibák ugyanúgy vannak X alatt is, eközben pedig Wayland alatt kapsz egy csomó pluszt. Nem annyira egyértelmű ez, hogy felmutatsz pár bug ticketet, és akkor a Wayland szar.

Az pedig hogy a Gnome rettenet nem tudom miért mondod. Trollkodás? Szíved joga nem szeretni, vagy egy másikat preferálni, de ha emellett nem ismered el hogy közben az egyik legnépszerűbb DE, akkor nem tudok mit mondani. 

de hibák ugyanúgy vannak X alatt is

De én nem is védtem az X11-et... Fentebb szó szerint leírtam, hogy a tonnányi magában hurcolt döglött kód miatt bloated, mint állat és idejétmúlt a koncepciója.

Nem annyira egyértelmű ez, hogy felmutatsz pár bug ticketet, és akkor a Wayland szar.

Jézusom... Most komolyan nem értetted, amit mondtam, vagy direkt csépelsz szalmabábot? Én nem mondtam, hogy a Wayland - a protokoll - szar. Én azt mondtam, hogy "normális Wayland implementáció nincs, ami elterjedt és használt lenne". Ez nem azt jelenti, hogy a Wayland - a protokoll - szar. Én nem a Wayland-et szaroztam, hanem a mainstream Wayland kompozitorokat. Nagy különbség.
Ami pedig a "pár bugticketet" illeti; neked is leírnám, hogy itt nem "pár bugticketről" van szó, hanem több mint ezer (!) bugticketről, aminek a jórésze több éve (!!!) javítatlan. A Mutter egy bughalom.

Az pedig hogy a Gnome rettenet nem tudom miért mondod.

Mert az.

Trollkodás?

Tapasztalat.

Szíved joga nem szeretni, vagy egy másikat preferálni, de ha emellett nem ismered el hogy közben az egyik legnépszerűbb DE, akkor nem tudok mit mondani.

Elismerem, hogy ez az egyik legnépszerűbb DE. És most? Mi van, ha ez az egyik legnépszerűbb DE? A systemd meg a legnépszerűbb SCS, a windows meg a legnépszerűbb OS. És? Mindkettő egy rakás szar. A popularitás nem indikátora a kvalitásnak. Aki ezt hiszi, az bedőlt a "tehénszar érvnek": együnk tehénszart, az a sok légy nem tévedhet.

De én nem is védtem az X11-et...

Nem is mondtam olyat, hogy védenéd.

De pl mondtál ilyet, hogy 

Viszont visszakérdeznék: a "defacto" Wayland implementáció, a Weston, na az talán nem egy bloated szar? De és még atom bugos is. Az X11 legalább működik.

Igaz ezt konkrétan a Westonnal szemben, ami már egy eleve nagyon fura érvelés, hiszen a Weston egy referencia implementáció, biztos használják páran, de azért nem ez a jellemző.

És mondtad ezt is: 

Én azt mondtam, hogy "normális Wayland implementáció nincs, ami elterjedt és használt lenne"

Mindenesetre számomra nem tűnik fair dolognak kiemelni hogy bármelyik kompozitor is szar lenne, olyan bugokra hivatkozva amik simán X alatt is előfordulnak. Az sem tűnik szarnak, hogy kijelented, hogy az összes szar.

Továbbra sem értem a kijelentésedet. Mitől lesz valami normális? Van egyáltalán normális bármi is, ha azon múlik hogy vannak bugok vagy sem?

Én X-et használok, és rendszeresen előjön több GPU-hoz köthető bug, például az általad linkelthez hasonló laggolás. Intel GPU-val.

De pl mondtál ilyet, hogy

Viszont visszakérdeznék: a "defacto" Wayland implementáció, a Weston, na az talán nem egy bloated szar? De és még atom bugos is. Az X11 legalább működik.

Igaz ezt konkrétan a Westonnal szemben, ami már egy eleve nagyon fura érvelés, hiszen a Weston egy referencia implementáció, biztos használják páran, de azért nem ez a jellemző.

És mondtad ezt is:

Én azt mondtam, hogy "normális Wayland implementáció nincs, ami elterjedt és használt lenne

Igen, ezeket mondtam, de ezek nem a Wayland-del szemben voltak érvek, hanem egyes Wayland kompozitorokkal szemben. Nagy különbség.

Mindenesetre számomra nem tűnik fair dolognak kiemelni hogy bármelyik kompozitor is szar lenne, olyan bugokra hivatkozva amik simán X alatt is előfordulnak.

Olyan bugokra hivatkozva, amik X11 alatt is előfordulnak? Mind? Csak azért, mert a link konkrétan egy nvidia szarsággal kapcsolatos bugra mutatott? Helló, a többi ezerrel mi lesz? Meg a másik ezerötszáz (!) lezárttal?

Az sem tűnik szarnak, hogy kijelented, hogy az összes szar.

Na, ilyet meg nem mondtam. Légy szíves ne adj szavakat a számba. Direkt kiemeltem, hogy pl. a Clayland jó. Meg azt, hogy a Sway-t nem ismerem, lehet, hogy az is oké.

Továbbra sem értem a kijelentésedet. Mitől lesz valami normális? Van egyáltalán normális bármi is, ha azon múlik hogy vannak bugok vagy sem?

Na, de mennyi? Több ezer? Mert a Mutterben annyi van/volt.

Én X-et használok, és rendszeresen előjön több GPU-hoz köthető bug, például az általad linkelthez hasonló laggolás. Intel GPU-val.

Engedd már el a GPU-t... Direkt lovagolsz rajta? Tallózd egy kicsit a Mutter issue-jait, nem csak GPU-related bugok vannak...

Igen, ezeket mondtam, de ezek nem a Wayland-del szemben voltak érvek, hanem egyes Wayland kompozitorokkal szemben. Nagy különbség.

Ne haragudj, de ez süketelés. Azt írtad, hogy egy "normális Wayland implementáció nincs". Nem EGYES, hanem az ÖSSZES kompozitorról alkottál véleményt. 

Na, ilyet meg nem mondtam. Légy szíves ne adj szavakat a számba.

Nem, azt mondtad, hogy ... beidézem mégegyszer:  "normális Wayland implementáció nincs"

Szóval ne terelj, nem a szar szót használtad, de negatív kritikát kapott az összes.

Mindegy, kiszálltam, fenének van kedve valakivel vitatkozni aki saját magát cáfolja meg.

Ne haragudj, de ez süketelés. Azt írtad, hogy egy "normális Wayland implementáció nincs".

Nem, azt mondtad, hogy ... beidézem mégegyszer: "normális Wayland implementáció nincs"

Nem igaz, nem ezt mondtam, ne adj szavakat a számba. Azt írtam:

Hát, csak épp normális Wayland implementáció nincs, ami elterjedt és használt lenne...

Nem egyáltalán nincs, hanem elterjedt és használt - AKA. mainstream! - nincs ami normális lenne. Idézz pontosan, ne ollózz, ne szalmabábcsépelj!

Nem EGYES, hanem az ÖSSZES kompozitorról alkottál véleményt.

Szóval ne terelj, nem a szar szót használtad, de negatív kritikát kapott az összes.

Nem igaz. Csak lehagytad az idézet végét. Direkt csináltad?

Mindegy, kiszálltam, fenének van kedve valakivel vitatkozni aki saját magát cáfolja meg.

Nem cáfoltam meg magam. Vagy nem tudsz olvasni, vagy direkt hazudsz.

Az a baj, hogy innentől tényleg nem lehet mit hozzáadni a beszélgetéshez.

Meddő vita az egész. 

Csak hogy tudd, - aztán nevezz hazugnak, fenét érdekel - a vita szempontjából számomra tök mindegy, hogy 

Nem szalmabábot kergetek, hanem egyszerűen nem gondolom hogy volna különbség aközött, hogy az összes kompozitorról mondasz véleményt, vagy arról a háromról (?) amit a userek 99%-a használ. 

Ja értem. Tehát mivel te úgy gondolod, hogy nincs különbség aközött, hogy az összes kompozitorról mondok véleményt, vagy arról a háromról (kettőről, actually; Weston és Mutter), amit a júzerek 99%-a használ, tehát akkor én azt mondtam, hogy az a) összes szar és b) a Wayland - a protokoll - szar. Tehát direkt csináltad. Direkt ollóztad le az idézetem végéről azt a kitételt, amiben kiemeltem, hogy a mainstream kompozitorokról van szó. Direkt ignorálod, hogy többször is mondtam, hogy a Clayland szerintem jó, a Sway-t pedig nem ismerem, lehet, hogy az oké. És direkt ignorálod azt is, hogy többször is mondtam, hogy a protokollal nincs bajom.

Igen, ebben az esetben bizony szándékosan hazudtál, méghozzá nem kicsit.

(kettőről, actually; Weston és Mutter)

Plasma? Szerintem sokan használnak KDE-t.

Tehát direkt csináltad.

Miért tudod te jobban hogy én milyen szándékkal csináltam valamit, mint én? Innentől minden amit írsz az csak kötözködés és flame. Minek?

Megpróbáltam elmagyarázni mit hogy gondoltam, nem muszáj szeretned érte, de ne tudd már nálam jobban.

Plasma? Szerintem sokan használnak KDE-t.

A Plasma Wayland kompozitorja még kész sincs teljesen! Még gőzerővel melóznak rajta! Csak kísérleti jelleggel elérhető! Ennek megfelelően hiába használnak sokan KDE-t, azt X11-gyel teszik! Miről beszélsz?

Miért tudod te jobban hogy én milyen szándékkal csináltam valamit, mint én?

Akkor visszakérdezek: miért tudod te jobban, hogy én mit akartam valójában mondani, mint én? Ráadásul, amikor explicit mindenre kitértem. Te meg kivágsz belőle részeket a saját szád íze szerint, mert te úgy gondolod. Épp most ismerted be...

Megpróbáltam elmagyarázni mit hogy gondoltam, nem muszáj szeretned érte, de ne tudd már nálam jobban.

Ezt inkább magadnak mondd, ld. előző bekezdést.

Tekintve, hogy épp most ismerted be, hogy direkt vágtad le az idézetem végét, mert szerinted nincs különbség, így neked itt nem nagyon van mire hőzöngened.

(Egyébként már sokadjára búcsúzol el, hogy te befejezted, de csak folytatod.)

Hát én nem használok KDE5-öt, de itt (https://community.kde.org/KWin/Wayland#Wayland_Support_in_Plasma) azt írják:

Wayland support in the KDE Plasma Workspaces is in a tech-preview state. The workspaces have been developed for X11 and much functionality relies on X11. To be able to make proper use of Wayland these bits have to be rewritten.

The most complex task is to implement Wayland support in KWin, KDE Plasma's Compositor and Window Manager. Since 5.4 KWin is able to manage Wayland clients and this allows to start a Plasma session on Wayland.

Hogy csak tech-preview-ként van jelen, amire lehetőség van, hogy úgy használd. Azaz a KDE5-ben magában nem default. Az, hogy a Fedorában default-tá tették, az lehet, de az a Fedora döntése volt, ami csak a Fedora 34+ usereket érinti. Abból is csak azokat, akik direkt KDE-öt használnak Fedora-n, mert mt9 fentebb azt írta, hogy a Fedora az GNOME-os. Ők hány százalékát tehetik ki a Wayland-capable platformok felhasználóinak? És ahogy nézem, a Fedora rá is faragott arra, hogy félkészen tette defaulttá. (#1, #2, #3)

Hogy csak tech-preview-ként van jelen, amire lehetőség van, hogy úgy használd. Azaz a KDE5-ben magában nem default

Most játszak TCHt? Nem állítottam, hogy a KDE5-ben default lenne (már ha ez egyáltalán jelent bármit). Ne csépelj szalmabábokat. Azt állítottam, hogy azzal az állításoddal szemben, hogy aki KDEt használ X11el használja, mert még tech preview, egy major desktop distro két éve defaultként waylandet ad a  KDE alá. A többi már maszatolás, és az állítás lekicsinylése.

Nem állítottam, hogy a KDE5-ben default lenne (már ha ez egyáltalán jelent bármit). Ne csépelj szalmabábokat.

Nem állítottam, hogy állítottad, csak leírtam, hogy a KDE5-ben nem az, szóval te csépeled a szalmabábokat.

Azt állítottam, hogy azzal az állításoddal szemben, hogy aki KDEt használ X11el használja, mert még tech preview, egy major desktop distro két éve defaultként waylandet ad a KDE alá.

Én meg leírtam, hogy a) annak a major desktop distro-nak a default DE-je a GNOME, tehát valószínűleg kisebbségben vannak, akik KDE-vel használják és b) nem is működik rendesen a félkészen defaulttá tett kompozitor és erre forrásokat is hoztam, szóval még aki KDE-vel is használja a Fedorát, az is valószínűleg többségében visszakapcsolt X11-re, mert nem működik rendesen a Wayland-es backend. (Ami nyilván nem róható fel neki, hiszen nincs is kész, de attól még nem megy.) Ergo nem lehetnek túl sokan, akik Fedora alatt Wayland-del tolják a Plasma-t.

A többi már maszatolás, és az állítás lekicsinylése.

Nem. Ezt ellenérvelésnek hívják.

Te azt állítottad, hogy a userek X11-el használják a KDEt. Én meg cáfoltam.

Nem szerepelt benne az a kitétel, hogy kivétel nélkül mind X11-gyel használja. Ez egy általános kijelentés volt, hogy a júzerek X11-gyel használják a KDE-t, nem kizárólagos: nem mondtam, hogy egyáltalán nincs olyan, aki Wayland-del használná; ez elég nagy ostobaság is lenne, hiszen pl. akik fejlesztik, azok is úgy használják. Ennek megfelelően az nem cáfolat, hogy egy GNOME alapú major disztró defaulttá tette, úgy, hogy nem is működik; hányan lehetnek, akik így használják? Szerinted általános?

Nem szerepelt benne az a kitétel, hogy kivétel nélkül mind X11-gyel használja

De pontosan ezt mondtad. 

Ez egy általános kijelentés volt, hogy a júzerek X11-gyel használják a KDE-t,

Nem volt benne semmiféle általában, meg legtöbben.  

hiszen pl. akik fejlesztik, azok is úgy használják.

Azok nem userek. 

Ennek megfelelően az nem cáfolat, hogy egy GNOME alapú major disztró defaulttá tette, úgy,

De igen, az. 

hogy nem is működik;

Ne légy rosszindulatú a Fedora fejlesztőivel szemben.

hányan lehetnek, akik így használják? Szerinted általános?

Ne csúsztass. Soha nem állítottam, hogy általános, ez szalmabáb, rosszindulatúan olyat adsz a számba, amit én nem mondtam, hogy aztán lejárathass, hogy hülyeség, amit beszélek. Ne személyeskedj velem.

De pontosan ezt mondtad.

Nem igaz. Nem mondtam ilyet, hogy "kivétel nélkül mind". Azt mondtam, hogy "Ennek megfelelően hiába használnak sokan KDE-t, azt X11-gyel teszik!" Hol szerepel ebben az, hogy kivétel nélkül mind?

Nem volt benne semmiféle általában, meg legtöbben.

Az se, hogy "kivétel nélkül mind".

Azok nem userek.

User == (fel)használó. Használja, amikor fejleszti? Igen. Tehát user is. De azok is használhatják, akik kísérleteznek vele; teszterek, early adopterek.

De igen, az.

Miért is?

Ne légy rosszindulatú a Fedora fejlesztőivel szemben.

Én? Én mások által nyitott panasztopicokat linkeltem be. Ha itt valaki rosszindulatú, az te vagy, velem szemben. Megint.

Ne csúsztass. Soha nem állítottam, hogy általános, ez szalmabáb, rosszindulatúan olyat adsz a számba, amit én nem mondtam, hogy aztán lejárathass, hogy hülyeség, amit beszélek. Ne személyeskedj velem.

Tudom, hogy most engem próbálsz "utánozni", csakhogy szarul csinálod, mert én nem ilyen vagyok, te akarsz ennek beállítani. Ebből is látszik, hogy rosszindulatú vagy. Én nem állítottam, hogy te állítottad, csak kérdeztem, hogy szerinted az-e. Tehát te csúsztatsz, szalmabábcsépelsz és adsz a számba dolgokat. És mivel már megint engem próbálsz karikírozni, ebből is látszik, hogy a) te személyeskedsz, b) elfogytak az érveid.

Az elején azt hittem, hogy csak azt akartad kihozni a dologból, hogy a saját fejlesztői által is félkésznek minősített Plasma Wayland kompozitor mainstream-nek számít, mert egy GNOME alapú major distro működésképtelenül defaulttá tette. De ebből az utolsó mondatból kiderült, hogy nem, te ezt vastagon telibeszarod, te itt engem próbálsz meg olyannak beállítani, amit itt megpróbálsz nagyon izzadtságszagúan "kiparodizálni", "kifigurázni", te próbálsz meg engem hülyének beállítani, nem fordítva. És akkor még van bőr a képeden azt állítani, hogy nem, te nem baszogatsz engem folyton. De. Méghozzá rohadt aljas módon.

Te itt nem a Wayland kompozitorok kapcsán kommentelsz, te velem akarsz szórakozni. Nos, tudod kivel szórakozz.

Na, látom sikerült észrevenni a tükröt. Bocsánatot kérek, hogy kihoztalak a sodrodból, őszintén szólva azt hittem, hogy egy kicsit előbb fogsz kapcsolni, de esküszöm nem azért tettem, hogy baszogassalak, hanem mert fentebb mt9-el megint előadtad az egyik szokásos paneledet, hogy izomból támadtál, mert lehagyták az idézeted végét, ami szerinted fontos volt. Igazad volt? Igazad. Igaza volt mt9-nek, mikor próbálta mondani, hogy szerinte ez nem érdemi különbség? Hát, minimum internálandó vélemény lett volna. Ehelyett elindultál a szokásos downward spirálban.

Szóval én most igen, tükröt tartottam, hogy lásd miket csinálsz. Az összes fogás, amit csináltam jellemző rád. Sőt, közben behoztál még párat magadtól is, például a netto rosszindulatú alapfeltételezést, gondolom mert akkor könnyebb nem komolyan venni, hogy a fedora használhatatlan defaultal szállítja a KDE-t (pont mint a szomszédban az alap lovaglásod, hogy mert te azt mondtad, hogy ha a rossz C kódot rosszul írják át rustra, akkor az is az lesz. Ami egyrészt triviálisan igaz, nem is érti az ember, mit lehet erről beszélni, másrészt magában foglalja azt a szintén rosszindulatú feltételezést, hogy szarul fogják átírni a kódot, amit én pl azért nem vettem hangsúlyosnak a mondandódban, mert triviálisnak tűnt, és nem volt bennem ez a rosszindulatú hozzáállás felé. Gyanítom mt6 is ezért mellőzte ezt a félmondatot, nem azért mert direkt hazudik, meg rosszindulatú.

Tudom, hogy most engem próbálsz "utánozni", csakhogy szarul csinálod, mert én nem ilyen vagyok, te akarsz ennek beállítani.

Igen, szerintem. Erősen csodálkoznék, ha egyedül lennék ezzel a megélésemmel (túrhatnék linket még legalább pár embertől, aki kb ugyanígy élte meg) És igazából azért csináltam, mert fel szeretném rá hívni a figyelmed, hogy mindegy is, hogy szerinted te nem ilyen vagy. Ha a másik fél ezt így éli meg, az baj. Ha ezeket a másikat alapból rosszindulatúnak, támadónak tartó, és az álláspontját megérteni és befogaadni próbáló kommunikáció helyett ezeket az izomból visszacsapós paneleket adod elő pl egy HRes kislánynak, vagy egy interjún, akkor bizony bele fogsz esni a red flag kategóriába. Hiába nincs benned ilyen szándék, az számít, hogy a másik hogy éli meg.

-----

Egyébként pedig igen, vicces, amikor ugyan se kdet nem használsz, se a fedorában sose láttad, de a status page alapján megállapítod, hogy ez használhatatlan. FYI, annyira használhatatlan, hogy én már az F34 előtt is waylanddal használtam a KDEt. Egy darabig visszaváltottam, egyetlen specifikus feature hiány miatt (ami ráadásul nem is a waylandből/kwinből, hanem az applikációból hiányzott), de már az is elmúlt.

És a fedora pont annyira gnome distro mint a debian. Az van az alap telepítőn, ennyiben kiemeltebb. És mivel pont ugyanúgy nem igazán pistikék által felkapott disztró, ezért szerintem egyáltalán nem trivi, hogy nagy többségében gnome-al használnák. Pl itt a hupon úgy a kedvenc desktop környezet a kde, hogy közben az egyetlen azt default szállító opensuse vonal a kanyarban sinscs (hacsak az ubuntu igazából nem jelent kurvasok kubuntu-t).

Csak annyit hogy az idezett hiba foleg a szar nvidia drivernek koszonheto es elofordul KDE es minden mas alatt is (sot mas compozitorok eseteben is tele vagyunk nvidia workaroundokkal) es koze nincs se a waylandhoz se a mutter-hez. Meg meg par dolgot, de aztan rajottem, hogy foloseges. A waylandot meg nem vedenem meg az implementacioit sem. En momentan nem is hasznalom, mert nvidia van a gepemben es valtozo hogy melyik driver update utan hasal el miatta minden (az intelesen hiba meg nem fordult elo vele kde alatt).

Na mindegy mint latod megsem vagyok annyira oreg csak leirtam :D

Az lehet, hogy az NVIDIA driver is szar, de itt pont az volt a lényeg - hogy ha már szóbahoztad a workaround-okat - hogy egy év után is képtelenek voltak előállni egy nyamvadt workarounddal. És ez csak az egyik fele. Baloldalt az "Issues" mellett nézd meg, hogy több, mint ezer (!) nyitott hibajegy van, amiknek a jórésze több éve (!!!) javítatlan. Ez egy bughalom.

Az a baj, hogy te az issue-k számából próbálsz következtetéseket levonni valaminek a minőségére, holott egy óriási projektről van szó, és egy publikus bug trackerről, persze hogy tele lesz olyan ticketekkel, aminek nincs köze a mutterhez, vagy amik már lettek jelentve többször is. 

Ráadásul úgy, hogy nincs mihez mérni. Ezer az sok? És mennyi hiba van jelentve az Xorg-hoz? Mennyi van jelentve a mutterhez ami nem érinti a waylandet? Stb.

Egyszerűen rossz és hiányos metrikából vonsz le abszolút következtéseket. 

Az a baj, hogy te az issue-k számából próbálsz következtetéseket levonni valaminek a minőségére, holott egy óriási projektről van szó

WTF... A Mutter nem óriási. Töredéke a mérete és a komplexitása az X11-nek.

Ráadásul úgy, hogy nincs mihez mérni. Ezer az sok?

Ez önmagában is sok (egyébként az a kb. ezer az csak a javítatlan bugok száma; volt mellette még ezerötszáz másik), de egyébként van mihez mérni.

És mennyi hiba van jelentve az Xorg-hoz?

Több, de az egy sokkal nagyobb kódbázisban gyűlt össze ~40 év alatt (a Mutter kb. 5 éves) egy sokkal nagyobb felhasználói bázissal (volt, amikor minden (non-Mac) UNIX user X11-et használt, Muttert meg csak azok a GNOME userek használnak, akik Wayland-re váltottak). A Mutter hibaaránya sokkal rosszabb. És ami még fontosabb, az X11 bugjait azért többségében javítják, míg a Mutternél a bugok majdnem fele (!!!) javítatlan! És ami a legfontosabb: az X11 bugjai nem teszik semmissé a Mutter bugjait, nem mentesítik a Mutter fejlesztőit semmi alól. Egy érv az X11 ellen nem érv a Mutter mellett. Ez nettó whataboutism, mutogatás a másikra. Attól, hogy az X11 is ezer sebből vérzik, a Mutter még egy bughalom marad.

Mennyi van jelentve a mutterhez ami nem érinti a waylandet?

Az mindegy, mert én nem a Wayland-et támadom, hanem a Muttert; fogd már fel végre plz.... Te most triggerelődtél, hogy báncsák a Wayland-et, holott nem, nem a Wayland-et bántom, hanem a Westont, meg a Muttert és okkal.

Egyszerűen rossz és hiányos metrikából vonsz le abszolút következtéseket.

Nem, te nem vagy tisztában a számokkal és nem érted, hogy miről beszélek.

Nem jött be a szalmabábcséplés és az ollózás? Leszel szíves nem félmondatokat idézni tőlem, direkt lehagyva a lényeget, hogy rámsüthesd, hogy a Wayland protokollt szarozom, miközben vagy tízszer írtam le, hogy a protokollal nincs bajom.

A wayland hibaja az nvidia hiba.

Ezt, ha megszakadok se tudom értelmezni. A Wayland egy protokoll, ami bármilyen GPU-n megvalósítható. Hogy lehet a Waylaynd-ben hiba, ha az egy protokoll? Mármint nyilván, koncepciós hiba lehet benne, de itt ugye nem erről folyt a diskurzus, meg az hogy lehetne az NVIDIA hibája? Nem Muttert akartál itt véletlenül mondani? Ha igen, akkor ez a konkrét bug lehet az NVIDIA sara, de mi van a másik 2600-zal?

Az hogy a gnome egy fos meg alap. Senki sem tudja vitatni. :D

Azzal is egyetertek, hogy ha egy darab fejleszto a compton-ban meg tudta csinalni, akkor a gnome-nal is lehetett volna valamit kezdeni a mutterral.

Na, ebben konszenzus van köztünk. :D

https://download.nvidia.com/XFree86/Linux-x86_64/515.65.01/README/wayla…  - protokoll ide vagy oda :D (es ezek csak a known issue-k, de szerintem van ott meg par ahonnan ezek jottek)

Amugy azt modod, hogy akkor az nvidia videokartyaknak nem kellene a directx-et meg az opengl-t sem tamogatniuk (mint ahogy a wayland-ot sem tamogatjak teljes mertekben)???

a waylandrol vitazol majd elokapsz egy 2600-as mutter hibaszamot aminek elenyeszo resze erinti a waylandot. 

Mint irtam a gnome-ot egy fosnak tartom. Detto a legtobb wayland implementaviot. Ettol meg azert probalok objektiv maradni es nem csuszkalni ide-oda a fokusszal, nehogy nagy butasagokat irjak.

Amugy az hogy a KDE projekt nem teszi default-ta a waylandot nem jelenti azt hogy csomo disztroban nem az, mert ugy gondoljak a kiadast kezelok, hogy az a par bug a felhasznalok kevesebb szazalekat erintik es lehet a wayland supportja (csomagok forditasa es konfgolas) kevesebb idejuket veszi el, mint az X supportja. Nem tudom. Toluk kellmegkerdezni mi volt a dontes oka. 

Masik hogy maga a wayland protocoll is meg mindig valtozik, ugyhogy nem is lehetne sehol sem egy mature implementacio. A sajat referencia implementaciojuk is ket hetente frissul kb. :D

Ez szar? Szerintem igen (meg nem letezo definiciora epiteni megoldast elegge bator es botor dolog).

Maga a wayland szar? Szerintem nekem errol fogalmam sincs. :D

Kosz a halakat es viszlat :D

a waylandrol vitazol majd elokapsz egy 2600-as mutter hibaszamot aminek elenyeszo resze erinti a waylandot.

Hihetetlen... Itt senki nem olvassa el, amit írok? Én a Muttert fikáztam, nem a Wayland-et. Attól, hogy nem minden Mutter bug kapcsolatos a Wayland-del, attól még a Mutter egy bughalom marad. Tehát szar. A Mutter. Nem a Wayland. A Mutter.

Mint irtam a gnome-ot egy fosnak tartom. Detto a legtobb wayland implementaviot.

Ebben egyetértünk.

Ettol meg azert probalok objektiv maradni es nem csuszkalni ide-oda a fokusszal, nehogy nagy butasagokat irjak.

Csakhogy itt nem én csúszkáltam a fókusszal, hanem az urak nem olvassák el, amit írok, vagy leszarják. Én végig nem a Wayland protokollról beszéltem, hanem a mainstream kompozitorjairól.

Amugy az hogy a KDE projekt nem teszi default-ta a waylandot nem jelenti azt hogy csomo disztroban nem az, mert ugy gondoljak a kiadast kezelok, hogy az a par bug a felhasznalok kevesebb szazalekat erintik es lehet a wayland supportja (csomagok forditasa es konfgolas) kevesebb idejuket veszi el, mint az X supportja. Nem tudom.

De nem működik. Nincs is kész. Kvázi működésképtelen, vagy minden baja van. Ld. a belinkelt fórumokat.

A sajat referencia implementaciojuk is ket hetente frissul kb. :D

Szar is a Weston.

Ez szar? Szerintem igen (meg nem letezo definiciora epiteni megoldast elegge bator es botor dolog).

Ebben még mindig konszenzus van.

Maga a wayland szar? Szerintem nekem errol fogalmam sincs. :D

Én meg még mindig nem a Wayland-et szaroztam.

Kosz a halakat es viszlat :D

"Viszlát és köszi a halakat", de nagyon szívesen. :P

Lehet nem jó érv, de ha egyszer nekem működött, akkor most mit mondjak rá? Vagy 5-6 gépen ráadásul. Az is igaz, hogy az én felhasználásom nagyon alap csak.

A Pipewire meg nem emulálja a Pulseaudio-t, azt a pipewire-pulse emulálja, de az megint egy újabb bloat benne. Az X11 meg igen, bloat. A Wayland az pont nem, használtam Sway-t WM-nek, az soványabb, mint a Xorg + i3wm. Nem sokkal, de valamennyivel. A Wayland nem lenne rossz, de nekem az nem tetszik benne, hogy nehéz benne WM-et írni, ezért csak pár érhető el rá (plusz a nagyobb DE-k), és Linux only. A X meg közös nevező az összes unixlike rendszer között szinte, és WM-eket is sokkal könnyebb rá írni, van is rá kismillió, nagyobb a választék, az egész sokkal hordozhatóbb. Mostanság egyre nagyobb hangsúlyt fektetek a hordozhatóságra, bashizmusok, GNU toolset, Wayland függőségeinek elkerülése, helyette POSIX shell szkripte, X, stabil-régi WM, hogy ha a Linuxszal egy nap történik valami, akkor át tudjak nyergelni valamelyik BSD-re.

A CUPS meg hiába blaot, legalább annak nem kell állandóan futnia, ha nincs nyomtatás, és legalább megint közös nevező a unixlike rendszerek között, így megférek tőle, de nem szeretem.

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

és Linux only

Biztos?

Soha nem próbáltam FreeBSD-t, de nekem úgy tűnik, mint ha ott már megoldott probléma lenne: https://docs.freebsd.org/en/books/handbook/wayland/

Windows-ra is vannak próbálkozások:

https://www.kdab.com/wayland-on-windows/

https://www.phoronix.com/news/Microsoft-Writing-Wayland-Comp

Igen, vannak rá csúnya hekkek, amiknek a működése hosszú távon nem garantálható. X az mindenhol van (Win, MacOS, stb. kivételével), még ha spécibb, régibb verzió is (pl. OpenBSD alatt Xinemara, ami még X11R6-alapú). POSIX shell (ksh, pksh, ash, dash, stb.) is, és CUPS is.

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

Miért lenne csúnya hack az, ha a wayland kompozitor fut az adott oprendszeren? Mi az, hogy a működése hosszú távon nem garantálható? Ezek kicsit légből kapott ellenérveknek tűnnek nekem.

Ráadásul miért érdekes a wayland? Amikor egy alkalmazást fejlesztesz nem közvetlenül waylandre vagy X-re írod, hanem valamelyik toolkitet használod, ami meg elérhető mindenhova. Nem kell ahhoz X sem, hogy a GTK-ban megírt alkalmazásod fusson Mac-en vagy Windows-on.

Mert csak FreeBSB-n megy, és ott is hivatalosan nem támogatott. Linuxhoz készült. Nem kizárt, hogy ez 5-10 éven belül változni fog, és máshol is elérhető lesz, de jelenleg nem lehet rá építeni.

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

A Wayland. Hivatalos attól lesz, hogy felteszed a gyári repókból és megy, külön hekkelés nélkül. Jelenleg nem. Egyes waylandes felületekkel még Linuxon is gond van, pl. a Sway logind-re dependel, és kihekkelhető, hogy anélkül menjen (Gentoo-n kellett ez pl.), de ettől nem hivatalosan támogatott. Pedig nekem nem lenne bajom a Waylanddel, ahogy írtam, Gnome alatt is működött, Sway-jel is, jelenleg ha ilyesmi kéne, talán a Hyperland-et próbálnám.

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

A Wayland. Hivatalos attól lesz, hogy felteszed a gyári repókból és megy, külön hekkelés nélkül.

Na akkor tegyük ezt tisztába - bár nem értem miért kell, mások már tisztába tették.

A Waylandet nem teszed fel semmilyen repóból se hekkelve se anélkül, ugyanis a Wayland csak egy protokoll. Az az "elmélet", a gyarkolati rész, a tényleges szoftver pedig a protokollt beszélő alkalmazások, köztük a kompozitorok. 

Ilyen például a Sway, amit fel tudsz telepíteni "hekkelés" nélkül FreeBSD-re is. 

Tény, hogy a Wayland elsődlegesen Linuxra lett kifejlesztve, de a protokoll maga nem tartalmaz semmit ami erre korlátozná. Technikailag semmi akadálya, hogy bárki leüljön írni egy alternatív kompozitort, ami bármelyik másik oprendszeren fut.

Lehet nem jó érv, de ha egyszer nekem működött, akkor most mit mondjak rá? Vagy 5-6 gépen ráadásul. Az is igaz, hogy az én felhasználásom nagyon alap csak.

Mondani mondhatod, csak ez nem érv, hogy neked megy. Másnak meg nem.

A Pipewire meg nem emulálja a Pulseaudio-t, azt a pipewire-pulse emulálja, de az megint egy újabb bloat benne.

Az idézőjel az emuláción nem tűnt fel?

Az X11 meg igen, bloat. A Wayland az pont nem

A Wayland az egy protokoll, nem program.

használtam Sway-t WM-nek, az soványabb, mint a Xorg + i3wm.

A Sway-t pont nem ismerem. De a referencia-implementáció Weston az egy bloated bughalom és a fentebb említett GNOME-termék Mutter is.

Linux only

Micsoda? A Wayland? Az egy protokoll, az hogy lehetne Linux-only? Nem kevered valamelyik Linux-only Wayland kompozitorral?

Mostanság egyre nagyobb hangsúlyt fektetek a hordozhatóságra, bashizmusok, GNU toolset, Wayland függőségeinek elkerülése, helyette POSIX shell szkripte, X, stabil-régi WM, hogy ha a Linuxszal egy nap történik valami, akkor át tudjak nyergelni valamelyik BSD-re.

Na, ezt jól teszed. Én is így teszek. (Mondjuk én mindig is figyeltem arra, hogy a kódom ne Linux-only legyen.)

A CUPS meg hiába blaot, legalább annak nem kell állandóan futnia, ha nincs nyomtatás, és legalább megint közös nevező a unixlike rendszerek között, így megférek tőle, de nem szeretem.

Tény. De attól még szar. :P

Nem keverem, de valóban pontatlanul írtam. Amikor Waylandet írok, akkor a konkrét, Wayland-protokolt implementáló megoldásokról van szó (Sway, Hyperland, Gnome, KDE, stb.). Konkrétan a Sway még XWayland háttérben futtatásával együtt is kisebb, mint egy i3wm + X.org, nagyon jók vele a tapasztalataim. Szóval nem vagyok Wayland ellenes, de ezek a konkrét megoldások Linuxra vannak tervezve. Elhiszem neked, hogy hekkeléssel felküzdhetők mondjuk FreeBSD-re, de a többi unixos rendszerre tuti nem, vagy csak néhány projektet, iszonyat mákkal. Én mákra építeni nem akarok.

Az X viszont mindenhol megy, és futnak rajta az 1980-as években írt WM-ek is, ezt az előnyt nem lehet tőle elvenni, még ha bloat is, meg elavult. Meg amit szeretek az X-ben, hogy sok WM van hozzá, bőven van mindenféle, amiből lehet választani, sőt, saját WM-et se annyira nehéz írni, ha kellően minimalista, pl. a TinyWM az 50 sor, a nowm az meg egy üres shell script loop, amiben sxhkd-vel indítgatsz néhány CLI toolt (xdo, stb.). Wayland-et használó megoldást sokkal nehezebb írni, még ha wlroot-s alapot használsz is, sokkal komplexebb, több kódsor, és bár lefordítva még így is soványabb, mint egy X alapú megoldás komplett X szerverestől, de nem a hobbi programozók szintje.

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

Szóval nem vagyok Wayland ellenes, de ezek a konkrét megoldások Linuxra vannak tervezve. Elhiszem neked, hogy hekkeléssel felküzdhetők mondjuk FreeBSD-re, de a többi unixos rendszerre tuti nem, vagy csak néhány projektet, iszonyat mákkal.

Nyilván, amit Linux-onlyra írnak meg, az Linux-only lesz, de ez az implementáció sara, nem a protokollé.

> a nowm az meg egy üres shell script loop

Odáig oké, hogy a xinitrc elindít néhány szükséges progit háttérben. Pl. "exec xterm &". Bár nem értem minek az exec(?). És aztán, az utolsó sorban van az agybasz: "exec x-session", ami egy c-ben írt végtelen sleep(1). Arra gondolt a költő, hogy a xinitrc ne lépjen ki. De nem egyszerűbb (és kevésbé baromság) lenne az, hogy "exec xterm"? Vagy pont az a lényeg, hogy így elmondható, hogy ez az egész wm egy üres loop...ami még Arch-mércével sem bloat?

De, az is jó, hogy exec xterm, de akkor ha kilépsz belőle, az X szerver is lelövődik. A nowm azért használ üres loop-ot, mert nem tudja előre, hogy mit akarsz futtatni, lehet nem is xterm-öt, és amíg semmi nem fut, valaminek életben kell tartania az xinitrc-t. Pontosan, ahogy írod. Az alkalmazásokat, meg az X toolokat meg az sxhkd indítja (bár jó rá a xbindkeys is, és hasonló megoldás is), persze attól te indíthatsz vele terminált vagy valami launchert (dmenu, rofi, gmrun, stb.) is vele.

Az exec-nek az a lényege, hogy ha nem használsz login managert, akkor az exec felváltja az xinitrc-t, ha meg kilépsz vagy crashel az exec-kel indított folyamat, akkor visszakapod a tty logint. Ez azért fontos, hogy egy esetleges támadó ne tudjon a X-es munkameneted vagy a screenlock crasheltetésével konzolhoz jutni, hanem mindenképp be kell jelentkezni. Bár ehhez az is elég, ha az xinitet futtatod exec-kel. Persze ez szokás és ízlés kérdése is, ha neked úgy tetszik, használhatsz üres loop helyett exec xterm-öt vagy akármi mást. Ez a szintű minimalizmus a szabadságról szól.

A C-ben írt végtelen sleep is teljesen jó, azzal az a baj, hogy egyes sleep implementációk nem tudnak végtelen ideig aludni (a GNU sleep pont tud az inf paraméterrel hívva), csak tetszőlegesen hosszúig, de kihekkelhető így is, akkor tényleg kell egy while : do; sleep tetszoleges_idotartam; done loop. Persze ez csak szemantika, a végtelen sleep is lényegében egy semmit nem csináló üres loop, csak másképp van implementálva. Továbbá meg ez a nowm-szerű megoldás is bloat, mert ugye épp úgy fut a háttérben a 100+ MB memóriát bezabáló X server, ezzel nem lehet mit csinálni. Épp ezt írom, hogy a Sway még Xwayland futtatása esetén is soványabb.

Lényegében a TinyWM is csak egy majdnem teljesen üres loop, 1-2 keyboard+mouse eventre figyel csak: for (;;) { bla-bla; }. Még az sxhkd is életben tudná tartani az xinitet, de ha véletlen újraindítod, akkor megint kilépne az X. Továbbá valamennyi extra memória a nowm-típusú megoldásnak is kell, hiszen fut az sxhkd is, hogy legyen, ami billentyűzet-egér eseményeire figyel, meg egy panelt is szoktak futtatni mellé (polybar, lemonbar, eww, dzen2, stb.), igaz ez nem kötelező, ahogy pl. notification sem (dunst). Plusz háttérképkezelő, de a feh arra elég, az kilép, miután beállította a X root windowban a képet háttérnek, és nem foglal memóriát.

Van persze a nowm-nek is hátránya, pl. egymást fedő ablakokat váltogtani nem tud, meg újraindítani sem lehet. Szóval annak nem ajánlom, aki nem minimalista alkat. Valahol az értelme is megkérdőjelezhető, hiszen hiába nincs WM, meg minimalizmus van, ha ott fut a háttérben a memóriazabáló X server, pipewire, pipewire-pulse, wireplumber, systemd sok ilyen-olyand szutyka, és akkor a hajunkra kenhetjük, lespóroltunk 100-200 mega memóriafoglalásból egy 2 mega memóriát igénylő dwm-et vagy bspwm-et.

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

> ízlés kérdése is, ha neked úgy tetszik, használhatsz üres loop helyett exec xterm-öt

Lényegében ezt mondom én is: aki ilyen megoldást preferál, az úgyis tudja, hogy a xterm bezárásával kilép az X-ből.

> polybar, lemonbar

A megjelenítést végző gui bar implementációjára lehet mondani, hogy megfelelően minimalista, bloat-mentes. Csak hát a megjelenítendő infók előállításának módja durván erőforrás pazarló. Minden kis infó "parancs | grep | awk | sed | stb..." módon keletkezik, akár másodperc gyakorisággal, ha kell, ha nem. Relatíve rengeteg cpu, ram használattal jár, valamint a csomó fork() rendszerhívás költséges.

 

 

Nem a kód nagysága számít. Nagyon sok tudást beleírtak a PW-be. Hálózati rétegeket, visszhang elnyomást, bluetooth, csillió szolgáltatást. Továbbra is kevés CPU-t eszik, ha lehet, pointereket ad át, nem komplett buffereket másolgat.

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

Hát ez az, amiket soroltál, kb. nekem egyik sem kell. Elhiszem, hogy a tudásához mérten még nem is olyan erőforrás-igényes, de abszolút értelemben meg túl vaskos, ha pont nem kellenek neked a feature-ei. Ez vele a bajom, hogy az ember akkor is megkapja, ha nincs rá szükséges. A systemd-t is hasonló okból nem szeretem.

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

Te tényleg soha életedben nem írtál egy nyamvadt kódsort sem? Attól, hogy valamiben sok feature van implementálva, nem következik, hogy az lassú lesz, mert nem fog kényszeresen minden futni. Az csak lehetőség. Ha van egy switch case szerkezeted megannyi elágazással, elég, ha csak az az egy fut, amit használsz.

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

Hat legalabbis modularis rendszert meg nem lathatott, ahol ugyan van vagy egymillio plugin/modul, de ha neked csak ketto kell, akkor azt toltod be 72 byte-ban, mig a teljes csomag akar lehet 100MB-os is a mindenfele be nem toltott dolgokkal egyutt is. De ugye azok maximum hattertarat foglalnak es nem meoriat meg cpu-t. ez am a bloat....

:D

A Pipewire modularitás nélkül is elég bloat. 82 MB-ot foglal a memóriából nálam, 3 folyamat, pipewire, pipewire-pulse, wireplumber. Korábban a Pulseaudio 20 mega körül evett. Ráadásul a PW foglalása folyton nő, valami 40 körülről indított, most 82, pár év múlva simán megint duplázódhat, lehagyhatja a X servert is. Itt magyarázhattok nekem switch-case szerkezetről, és nem csak a memóriafoglalás, mert az a 16 gigába simán beleférne nálam, hanem ezt s sok szutykot a procinak is be kell töltögetni, ami a lemeznek is munka. Ma már 20-80 mega nem tűnik soknak, de egy modern rendszeren számos ilyen van, a sok kicsi sokra megy, és akkor csodálkozik a user, hogy hosszú a bootidő, meg gigás memóriafoglalással áll fel a rendszer. Ráadásul ha kicsi a kód, az sokszor ultrán gyorsít, mert a proci cache-ből futtatja, nem nyúlkál a memóriához.

Ugyanezt lehetne hozni kevesebből is, vagy meg kéne adni a usernek a választást, hogy minimalistább hangszervert telepítsen. Érdekes OpenBSD-n 89 megába belefért az a  bspwm + polybar + st rendszer, ami már akkor Archon 200-250 megát evett, most meg már 385 megát eszik a pipeszutykokkal. Azt is értem, hogy ma már nem a rendszer, meg egyebek a fő foglalási tényező, a böngészők magukban eszik meg a gigákat, bár itt is nagy különbség van egy FF vagy egy Chrome-alapú böngésző között, de a böngésző az sajnos ma már, ami nem lehet minimalista. Minden más lehet, csak az nem.

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

Nem akarsz írni egy jobbat? Szerintem mindenki profitálna belőle.

Javarészt C-ben van írva, szóval szerintem nem itt lesz a baj. Valószínűsítem, kell hely a buffereknek, leíróknak is. Van egy olyan érzésem, hogy nem nézel messzebbre annál a triviális esetnél, hogy van egy sztereo hangforrásod 44100 Hz-en, meg van egy hangkártyád, ami tud 44100 sample/s mintavétellel lejátszani, s ezt meg kell szólaltatni. A pipewire nem ez, egy cseppet több ennél.

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

De írnék, ám a hangrendszerben a szabványok miatt nem lehet variálni. Azzal is tisztában vagyok, hogy OpenBSD-vel összehasonlítani nem fair, mert az jóval kisebb kernel, kevesebb hw-t és feature-t támogat, egyszerűbb a fájlrendszer, sokkal primitívebb a hangrendszer, stb., de ugye van, akinek megfelelő, és ugyanezt Linuxon csak jóval nagyobb memóriafoglalásból kapja. Visszaraknám én a Pulseaudio-t is, de az egy halott projekt, nem fogják már fejleszteni, nem lesz hozzá támogatás, az vele a gond. Működni tuti működik, de még meddig. Nálam amúgy sem dependel semmi a Pipewire-re, így még akár pár hónapig működne, talán egy évig is, de utána ott lennék, ahol a part szakad.

Ezt a buffert, leírókat azért sem tudom elfogadni, mert az kell az ALSA-nak, Pulseaudio-nak is, meg az OpenBSD-féle sndio-nak is.

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

Ertem szoval inkabb ne foglaljon annyi memoriat (a 4GB-os minimal laptop eseten a 84 MB 2%) de 100%-on porgesse inkabb a procit mint a pulse sot szakadozzon a hang, mert jobb ha cpu forrosodik, mint az a 2% :D

Az en gepemben 64 GB van es azt irja hogy 5GB szabad a memoriabol, aminek kurvara orulok mert meg az nvme diskhez sem kell fordulnia ha kell az adat (persze az 59 GB-bol csak 5 GB az aktiv page altalaban a tobbi buffer 54 GB).

Szoval azt mondod most tepjem a hajam es rohangaljak sikoltozva korbe-korbe, mert minden megy ahogy kell, mivel "de hat hiszen 85%-a a memoriadnak buffercache!!!" ?? :D

Amugy itt egy ket eves olvasnivalo, amiota a pipewire csak meg jobb lett: https://lwn.net/Articles/847412/

Nem, az sem jó. Egy hangrendszernek teljesen észrevétlennek kéne lennie, csak annyi, hogy legyen hang, meg szabályozni lehessen a hangerőket. Egyébként az intenzív procihasználat se jó. A memóriát se úgy veszem figyelembe, hogy nincs, mert mint írtam, nekem is van 16 giga, hanem kell valami mérőszám, amivel mérem egy szoftver bloatságát, és hozzá tudom vetni a tudásához meg a nekem nyújtott funkciókhoz. SLOC-ot nem tudok figyelembe venni, mert nem biztos, hogy C-ben van írva, nem biztos, hogy minden sor lényegi, tele lehet kommentekkel, stb.. Procin se tudod mérni, mert ami az egyik procin 2%, egy régebbin lehet 20 is. Valahogy mérni kell, ez pedig a memóriafoglalás, mert egyenes arányban van a komplexitási fokkal.

Pl. az Alacritty terminált is ezért dobtam egy éve, kezdett túlhízni, 100+ MB-os memóriafoglalás, per ablak. Azóta simple terminal (st) megy, és 16 megával beéri, és nem kizárt, hogy a végén xterm lesz belőle, mert ebbe is integrálták már az UTF- és truecolor támogatást, és 10 megából megáll (ráadásul sixel-támogatás is van benne, amit elég kevés terminál tud), egy hátránya, hogy sok sornál lassú és pain in the ass konfigurálni. Vagy pl. a szintén mimimalista Vifm-et épp cserélem le sfm-re. Ez 9,6 MB memória helyett 2,8-cal éri be (RSS) és ennek az egésze is majdnem mind shared memory. Sok ablaknál már ez is különbség.

Nekem a pulse se pörgette a procit. Igazából a Pipewire se, csak a memóriafoglását sokallom. Elhiszem nektek, hogy rengeteg mindent tud, de vannak olyanok, akiknek ez a rengeteg tudás NEM kell, azért kéne, hogy legyen alternatíva. Ugyanez a baj a systemd-vel, rá van tolva mindenkire, és tud ugyan egy csomó dolgot, meg elismerem, hogy bootidőben is a legászabb, de ha valaki egyszerűbbet keresne, mert elég lenne neki egy egyszerűbb sysvinit egyszerűségű cucc, akkor az megszívta.

A buffer memória engem nem izgat, azt a rendszer eldobja akármikor, ha kéne a RAM. Az nem mérőfoka semminek. Tőlem buffereljen.

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

Mondjuk pont a switch-case szerkezet nem a legjobb példa, mert az oké, hogy csak azok az az ág fog lefutni, ami teljesül (feltételezvén, hogy a programozó ismeri a break parancsot és nem hagyja tovább futni a többi ágra), de komparálni a teljesülésig mindet végig fogja. Ha olyan masszív az a switch-case szerkezet, akkor célszerűbb az ágakat kirakni egy függvénytömbbe, amit a switch-ben checkelt változóval indexelünk. (TL;DR: ugrótábla.)

De ettől persze még igazad van, a nagy kód nem ekvivalens a lassú kóddal és a kicsi sem a gyorssal. Egy végtelen ciklus pár byte és annál lassabb kód nem létezik... :P

Persze, van, amikor az ember függvénypointert használ, táblázatban vannak a címek, vagy az aktuális futási címhez adjuk az indexet, oda ugrunk, ahonnan egy újabb ugrással a függvény bejáratánál találjuk magunkat. Ez a kettő ugyanaz, az első inkább C-ben, a második assembly-ben járható út. Ez így O(1) megoldás, szemben az egyesével történő tesztelésekkel, ami O(n).

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

Néhány perce csináltam a masterből build-et, feltelepítettem, kipróbáltam. Na, mondom, régen láttam már pw-top-ot. Kellemes meglepetés, hogy az emlékeimben jellemzően száz µs nagyságrendű számok voltak, most meg tíz µs nagyságrendűek. Persze nem tudom, mióta, könnyen lehet, hogy a hivatalos 0.3.70 is hozza ezt. Megnéztem top-pal ezt:

top -p`echo pipewire audacious wireplumber | xargs -n1 pgrep | xargs echo | tr ' ' ','`

Jellemzően még az audacious is 1% alatt van, de a többi is. Szép, különösképp, hogy online rádió, tehát van hálózat, kitömörítés, a pipewire-nek meg resampling 44.1 kHz-ről 48 kHz-re. Biztosan nem a számítógépem lett gyorsabb. Nagyon szép teljesítmény!

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

0.3.71 rengeteg jósággal. :)

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

0.3.72

Megint nagy adag javítással.

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

Azért lássuk be, a relnotes.txt-re vannak linkelve ezek a számok, szóval tőled elvár egy kattintást, te cserébe elvársz tőle egy fél órányi gépelést. Max. akkor lenne haszna, ha nagyon sokan a blogján keresztül követnék a fejlesztést, de olyan szinten, hogy ezeket a változásokat is rendszeresen megnézik. Én ezen a blogon keresztül figyelem, de azért az új funkciókra egy évben jó ha kétszer vagyok kiváncsi.

(Amikor meg szopás van vele, azt le szokta írni ;-) )

Igen, már gondoltam arra, hogy be kellene zárni ezt a blogot. A fejlesztés korai szakaszában még izgalmas volt, de most már működni szokott, bár mindig van olyan környezet, amelyben kihullik valami csontváz a szekrényből, ezért, illetve új feature-ök miatt fejlődik ma is.

Egy gondolatot tennék hozzá. Korábban jellemzően 3-6 hetente volt release, most pedig jellemzően hetente. Ez utóbbi szerintem jó ötlet, mert a ritka release esetén ömlenek be olyan bugreportok, amelyekre már van megoldás a master repóban, csak még nem jutott el a felhasználókig. Gyakori release esetén viszont a release sokkal feszesebben követi a master repót, s ezzel a bugreportok élők lesznek, nincs olyan sok felesleges visszajelzés. Szóval a jelenlegi modell szerintem jobb. Már feltéve, hogy tudatos, de gyanítom, hogy az.

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

Ha bezárni nem is, de minden verziót ide írni sok értelme nincs. Elfér tőlem, de a Pipewire ma már annyira ott van szinte minden disztrón, annyira sztenderd tool lett, hogy kikerülni se lehet. A gyerekbetegségeit is nagyrészt kinőtte, így nagyon nincs mit rajta említeni, új verzió, ami jellemzően néhány bugfix. Elvesztette ezt a bleeding edge, érdekesség varázsát inkább. A topik az maradjon, mert akinek mondjuk van PW specifikus problémája vagy kérdése, annak legyen hol kérdezni.

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

Ha Wayland-alapú megoldást használsz, máris nem lehet kikerülni, X-en egyelőre még a Pulseaudio elég lehet, de az is határon van, egyre több projekt fogja dobni. Lehet hozzá ragaszkodni még egy ideig, de készülj fel rá, hogy nem fogod tudni a végtelenségig elkerülni.

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

Mert már most izmoznak rajta, hogy ilyen portál, amolyan portál nem működik. Megpróbáltam én is dobni X alatt, ha más nem a wireplumbert, csak a de erre nem játszottak le videók, simán mpv-ben sem, sem böngészőben. Ennyit arról, hogy milyen jól el lehet hagyni.

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

Hogy ne csak új verziókról legyen log: a pipewire-t hogyan célszerű újraindítani, ha frissült? Jelenleg reboot-tal csinálom, de ahogy olvastam, systemctl restart pipewire pipewire-pulse kiadásával kéne. Ez helytálló?

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

Hát, hogy épp pontosan mik vannak, az kicsit változott, nekem most ez a kettő van. Viszont arra figyelj, hogy 'systemctl --user ...' jó eséllyel, mert valószínűleg user unit, amit a session managered indít. Ebből következőleg egyébként egy logout/login is elég kéne legyen.

(Disclaimer: persze, hogy a te minimalista kicsontozott izéidben mi van, az passz :) )

Ahogy nézem, nálam is ez van. A systemctl stutus alapján ezek a service-ek user@1000 alatt futnak, amit meg az user.slice, amit meg az init maga, indít szerintem a logind indíthatja ezeket. Ilyen téren nem állítottam semmit a rendszeren, sztenderd Arch alaptelepítés (nem archinstall-os, hanem kézi, az Arch Wiki alapján).

Abban lehet igazad van, hogy esetleg egy ki/bejelentkezés is elég lehet, ezt még nem teszteltem.

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

Ahogy nézem, nálam is ez van. A systemctl stutus alapján ezek a service-ek user@1000 alatt futnak, amit meg az user.slice, amit meg az init maga, indít szerintem a logind indíthatja ezeket. Ilyen téren nem állítottam semmit a rendszeren, sztenderd Arch alaptelepítés (nem archinstall-os, hanem kézi, az Arch Wiki alapján).

Akkor jó eséllyel bőven elég. Nekem ha megkotlanak a deviceok, vagy elmúlik a hang, elég szokott lenni egy "systemctl --user restart pipwire". 

Abban lehet igazad van, hogy esetleg egy ki/bejelentkezés is elég lehet, ezt még nem teszteltem.

Egyenértékű kell legyen a restartal, ha elmúlt az utolsó user session is, megállítja a dolgait (hacsak nincs linger). Mondjuk azt nem tudom, hogy van kezelve az egy-egy grafikus session, nem lehetetlen, hogy azok külön vannak még szeparálva valahogy.

De a daemon-reload a systemd daemont konfigurációt tölti újra, csak olyenkor kell, ha az megváltozik (kb, ha hozzányúltál egy unit filehoz), attól, hogy valami, amire egy unit file hivatkozik, megváltozik, attól nem kell... semmi köze a managelt daemonokhoz a parancsnak.

Egyrészt, akkor panaszkodik, másrészt félig meddig kulturált OSek csomagkezelője, ha frissíti a unit filet, akkor meghívja a daemon-reloadot, biztos kell minden update után kézzel nyomkodni. Teljesen felesleges csak úgy hobbiból hívogatni. Tőlem nyugodtan, csak ne írd már le, hogy "kell", mert hülyeség.

Érdekes, de még sosem használtam csak az új hang rendszer telepítésekor a daemon-reload-ot és nem volt vele gondom.

"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 

0.3.83 tartalmaz egy regressziót, az echo-cancel modul hibákat dobál folyamatosan, hangja pedig állandóan szakadozik, és hörgő lesz. Wim már javította, a git repóban már jó a kód, de release még nincs belőle, tehát a 0.3.84-ben már jó lesz. Én forrásból fordítottam magamnak, így nálam is jó már.

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

Szerkesztve: 2023. 11. 19., v – 07:45

Következőket csinálta: Lejátszás Freetube (desktop yt kliens) -> hangkártya ->  fejhallgató  --- minden oké. Bedugtam egy bluetooth -os usb dongle-t és egy fejhallgatót konnektáltam hozzá. qpwgraph -ban szépen megjelent. Összedrótoztam a  Freetube-al mergszólalt. Űvöltött mint állat. Hangerőt a normál módon nem lehett állítani hanem a pavukontrollban csak. Ahogy megnyilt a pavukontrol qpwgraph -ban hirtelen annyi összeköttetés generálódott, h a vonalaktól nem lehetett látni semmit. Beállítottam hangerőt pavukontrolt bezártam. A sok vonal eltünt, hangerő maradt a jó szinten.  Véget ért yt videó. Ez azzal járt h Freetube eltünt qpwgraphból. Elindítottam egy másik yt videót akkor újra megjelent, de korábbi összehuzalozás a bt fejhallgatóval nem állt helyre. 

Na most ez pl jack-nél is probléma, de van rá megoldás. pl az aj-snapshot  - de pw esetében az semmit nem ér.

Tehát Freetube nem lett bezárva csak videó ért véget benne. Nem lehet minden videónál újra összehuzalozni! Nem értem h session kezelő (wireplumber v. mi)ezt miért nem oldja meg?

amúgy: Debian 12 és pipewire 0.3.65

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

A wireplumber 0.4.15-nél, míg a pipewire 0.3.85-nél jár. Elképesztő mennyiségű commit került bele a 0.3.65 óta, az sem kizárt, hogy már rég úgy működik, ahogy szeretnéd.

A hangerő állításnál szerintem nem muszáj a pavucontrol, csak a default sink-et kell a bluetooth fülesre állítani, ekkor annak a hangereje állítódik a szokásos módon.

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

Nem értem miért lenne érdemes. Egyszerű átszámozás, a 0.3.85-öt nem 0.3.86 követte, hanem az 1.0.0. Kb. mint mikor Torvalds átszámozza a kernel főverzióját, 4.20 után nem 4.21 jött, hanem 5.0, de épp azok a fejlesztések kerültek bele, mintha 4.21-ként adták volna ki, az 5.19-et pedig a 6.0 követte. Vagy mikor a Gnome váltott 3.3x-ről 40-re, meg most a LibreOffice fog a 7.6 után jövőre 24.2-re váltani (év.hó számozás).

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

Ebben neked tökéletesen igazad van. Ugyanakkor értelemszerűen a fejlesztői csapat úgy érzi, már van annyira jó, hogy késznek tekinthető. Ami azt jelenti, a legfontosabb funkciók benne vannak, meg azt is, hogy a felhasználók többsége nem találkozik olyan bugokkal, amelyek által használhatatlan az egész. Nem jelent hibamentességet, s azt sem jelenti, hogy a jövőben ne kerülnének bele újabb funkciók.

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

Egyre ritkábban fordítom forráskódból, s csinálok belőle rpm csomagokat. Azért ma megtettem. Már ez a változat fut nálam. :)
 

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

Méteres ragtapasz kell az ignorálandó szövegek kitakarására.

10-féle lény van:
-- aki ismeri a bináris számrendszert,
-- és amelyik nem.

Nekem továbbra sincs vele bajom, a v.1.0 is bugmentesen fut, azon kívül, hogy rohadt bloat cucc. Számomra átment a hangrendszerek systemd-jébe.

Egyszer volt csak, hogy elment a hang, de azért, mert frissült a PW, és újraindítás kellett neki, még a régi verzió futott, de már az új fájlokkal akart dolgozni, és az ütközést okozott. Meg a hang akadozott egy pár hétig, amiről a topikban már írtam pár hónapja, de arról meg kiderült, hogy AMD CPU-kat érintő RNG kernelbug volt, és köze sem volt a PipeWire-höz. Szóval eddig problémamentes, de a bloatsága révén nem a szívem csücske. Tipikus Red Hat / Poettering cucc.

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