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.
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.
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.
Én értem a release early release oftent, csak nem szeretem a nyakamba, hogy én vagyok a QA.
A többiben meg kevered a szezont a fazonnal, amikor a "szar a saját vackomat" hasonlítod a "nem fogom kerülgetni más szarjáthoz". De ezt már beszétük, akkor se értetted.
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.
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.
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.
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.
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.
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.
Á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.
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.
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.
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.
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.
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.
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.
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.
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.
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é.
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.
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
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. :)
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.
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:
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.
Ú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.
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)
Hm, érdekes. Tegnap megnéztem egy 51 perces YT videót, 2-3-szor beletekertem, nem volt baj. Mondjuk én visszatekertem, nem előre, mert valamit nem értettem.
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.
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.
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.
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.
Arch csomag history alapján ez történt, igen. Cherrypickelt bele javításokat, plussz egyszer rebuild volt lib függőség verzió ugrás miatt, egyszer meg meglévő feature bekapcsolása miatt volt relbump.
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. :)
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. :)
Ryzen CPU-t használok, de nem tapasztaltam akadozást. Nem sok kedvem van BIOS frissítéshez, de ezek szerint meg kellene néznem, van-e újabb az alaplapomhoz.
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)
Fedora jelenleg őskövület kernelt használ, 6.1.14 fut rajta. Az újat jellemzően *.2-től fordítják le, szóval majd 6.2.2 környékén. Bár ahogy írtam, nem tudok arról, hogy nagyon várnom kellene ezt a kernelt. :)
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.
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!”
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.
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!”
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?
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.
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.
Hozzászólások
Vannak benne gyöngyszemek, optimalizálások.
(Máshol már tettem említést róla.)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
sub.
sub
Oldschool Computer - http://oscomp.hu
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:]' <<<locsemegeLOCSEMEGE
Köszönöm az infót, akkor legalább erre nem kell gyanakodjak.
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:]' <<<locsemegeLOCSEMEGE
0.3.55
Igazából ez a patch is kell hozzá, csak kiadás után lett javítva.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
bíztató QA :)
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:]' <<<locsemegeLOCSEMEGE
Én értem a release early release oftent, csak nem szeretem a nyakamba, hogy én vagyok a QA.
A többiben meg kevered a szezont a fazonnal, amikor a "szar a saját vackomat" hasonlítod a "nem fogom kerülgetni más szarjáthoz". De ezt már beszétük, akkor se értetted.
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:]' <<<locsemegeLOCSEMEGE
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
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:]' <<<locsemegeLOCSEMEGE
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
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:]' <<<locsemegeLOCSEMEGE
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)
Az fstab-ban lehet user opciót használni. Nem kell mindenhez root jog.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
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)
Azért ezt árnyalnám. Ha bedugok egy pendrive-ot, fényképezőgépet, a filemanagerből root jog nélkül tudom használni, mint Windows alatt.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
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:]' <<<locsemegeLOCSEMEGE
Á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)
Ez miért baj? Az a nyomtató alrendszer. Baj, hogy egy szerver? Ahhoz, hogy lásd a képet, kell monitor, neked meg szem. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Vagy az apcupsd. És milyen jól is jön, ha több gép megy egy UPS-ről.
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:]' <<<locsemegeLOCSEMEGE
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)
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.
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
via @snq-
FYI:
PDQ
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
Mikor a minimalizmusoddal már magadat szopatod, de azt hiszed hogy az rendszer sajátosság 😅
Ezt mondom :)
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:]' <<<locsemegeLOCSEMEGE
Könnyen belátható, hogy ez egy orbitális marhaság. De inkább hagyjuk, tisztán látszik megint, hogy szerinted a mérnök gányol.
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:]' <<<locsemegeLOCSEMEGE
hagyjuk, úgyse fogod az életben megérteni.
Ez eddig nettó személyeskedés, miközben a hozzászólásodból épp az nem derül ki, mire gondolsz. Bátran magyarázd el közérthető módon!
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
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:]' <<<locsemegeLOCSEMEGE
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:]' <<<locsemegeLOCSEMEGE
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:]' <<<locsemegeLOCSEMEGE
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:]' <<<locsemegeLOCSEMEGE
Másnál is van úgy, hogy nem veszi észre, ha bedugom a fülest, csak egy pkill pipewire; pkill pipewire-pulse után?
Nem dugdosok füleseket. Biztos, hogy erre nem inkább a systemctl --user restart wireplumber.sevice a korrektebb megoldás?
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
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)
nem, erre az a korrekt megoldás így 2022ben, ha megismeri a bedugott fülest.
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:]' <<<locsemegeLOCSEMEGE
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:]' <<<locsemegeLOCSEMEGE
nekem az egész vackot szokta időnként elhagyni a francba, míg oldalba nem rúgom a pipwire socketet meg a pipwire-pulse-t
(bár mostanában nem csinálta, kopp kopp)
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
via @snq-
0.3.56
Nem tudom, ez segít-e itt bárkin is:
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
0.3.57
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
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:]' <<<locsemegeLOCSEMEGE
Ez tetszik, fordítottam is egyet forrásból, már ez szól. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
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:]' <<<locsemegeLOCSEMEGE
0.3.59
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
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:
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:
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:]' <<<locsemegeLOCSEMEGE
Elnézést, rossz helyre küldem a választ.
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.
Remélem, úgy törölted a file-okat, hogy előbb leállítottad a pipewire-t és a wireplumber-t.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
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.
A hangerőszabályozó megoldódott? Én pavucontrol-t illetve pasystray-t használok, ezek menni szoktak.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
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.
Nekem az a gyanúm, hogy az xfce hangerő szabályozó pluginjét használod. Válj meg tőle! :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
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.
wireplumber 0.4.12
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Na, ők is kezdik a verzióugrándozást, 0.3.59-ről ugrottak mindjárt 0.4.12-re. Semmi 0.3.91 meg 0.4.0 vagy ilyesmi.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
wireplumber vs pipewire
Ja, bocs, figyelmetlenül olvasok. Valóban, ez az eltérés oka. Csak azt néztem, hogy PipeWire topik meg wire...
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
0.3.60 rengeteg módosítással.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Ú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:]' <<<locsemegeLOCSEMEGE
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)
Hm, érdekes. Tegnap megnéztem egy 51 perces YT videót, 2-3-szor beletekertem, nem volt baj. Mondjuk én visszatekertem, nem előre, mert valamit nem értettem.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
0.3.61
Fedora 37-re.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
0.3.62
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
0.3.63
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
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:]' <<<locsemegeLOCSEMEGE
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:]' <<<locsemegeLOCSEMEGE
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)
pw-top esetleg, illetve ha bugreportot küldenél, a configodat részletesen elárulja a pw-dump.
Szerk.: Esetleg még pw-mon.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
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:]' <<<locsemegeLOCSEMEGE
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:]' <<<locsemegeLOCSEMEGE
Arch csomag history alapján ez történt, igen. Cherrypickelt bele javításokat, plussz egyszer rebuild volt lib függőség verzió ugrás miatt, egyszer meg meglévő feature bekapcsolása miatt volt relbump.
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:]' <<<locsemegeLOCSEMEGE
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:]' <<<locsemegeLOCSEMEGE
Úgy néz ki, hogy nem a Pipewire vagy a Wireplumber a ludas, hanem az AMD proci és az fTPM. Állítólag nemsokára jön a fix a kernelhez.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
Ryzen CPU-t használok, de nem tapasztaltam akadozást. Nem sok kedvem van BIOS frissítéshez, de ezek szerint meg kellene néznem, van-e újabb az alaplapomhoz.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
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)
Fedora jelenleg őskövület kernelt használ, 6.1.14 fut rajta. Az újat jellemzően *.2-től fordítják le, szóval majd 6.2.2 környékén. Bár ahogy írtam, nem tudok arról, hogy nagyon várnom kellene ezt a kernelt. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
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)
Pár perce lefordult. :)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
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:]' <<<locsemegeLOCSEMEGE
Az volt. Wim már javította is.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
0.3.64
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
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?
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:]' <<<locsemegeLOCSEMEGE
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”.
dzsolt
Az /etc/portage/package.use/whatever állományba:
Ekkor csak a libet fordítja ami viszont mindenképp kell ahogy locsemege írta is.
Ma 44 commit érkezett bele, bár én 50-nek számoltam. Természetesen lefordítottam, működik.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
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:]' <<<locsemegeLOCSEMEGE
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:]' <<<locsemegeLOCSEMEGE
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:]' <<<locsemegeLOCSEMEGE
0.3.65
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
0.3.66
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
pipewire-0.3.67
wireplumber-0.4.14
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE