PipeWire - mi ez?

Multimédia

Kezdetben volt az ALSA. (A korábbiakat hagyjuk, az ALSA-nak a kernelben van jelenleg a folytatása.) Lett a Pulseaudio, amely egy felsőbb réteg az ALSA fölé, bár nem teljesen, csak részben. Most meg azt olvasom, jön a PipeWire framework, egyelőre a Pulseaudio fölé, de talán lesz ez natívan a Pulseaudio helyett is.

Valaki tájékozottabb nálam, miről is van szó, mire jó, hogyan kell használni?

https://pipewire.org/

"We are planning major changes for Fedora Workstation 32 though, where we in fact plan to ship Pipewire as a tech preview for both Jack and PulseAudio users. The way it will work is that the system will still default to PulseAudio, but we will provide either a script or a UI option to switch over to Pipewire (and back again). There is also a plan to have a core set of ProAudio applications available as Flatpaks for Fedora Workstation 32 tested and verified to work perfectly with Pipewire, the current apps planned to be included are Ardour, Carla, a2jmidid, Hydrogen, Qtractor and Patroneo, but if there is interested contributors joining the effort we could have even more. Then for Fedora Workstation 33 the idea is to ship with Pipewire as the default audio handler, but with some way for users to switch back to PulseAudio if they have a need."

(Forrás)

Olvass el!

A téma folytatása a PipeWire #2 topikban található!

( dap | 2019. 10. 19., szo – 14:55 )

Hát ez ez ez.. Valami, ami még a PulseAudiónál is rosszabb és végképp váltani kell miatta BSD-re!! :D

:D

Én inkább azt remélem, hogy mindaz megjavul, ami a Pulseaudio-ban rossz volt. Ott valami nagyon el van szúrva. Elhiszem, hogy nem bugos abban az értelemben, amennyiben a programozó egy ideális világba képzeli magát, amikor is neki mit sem kell tudnia arról, hogyan működik a számítógép, továbbá arról sem kell semmit tudnia, amire a programot írja, elég, ha van egy specifikáció, majd azt szemellenzősen implementálja, ignorálva a gyakorlati problémákat.

Tehát lehet, hogy nem bugos a Pulseaudio, csak nem veszi figyelembe a Linux kernel ütemezőjének tulajdonságait, az ALSA driver-ek egy részének adottságait, s így tovább. A tapasztalatom így a 13-as verziót használva még mindig az, hogy ha valamiért - például resampling - viszonylag sok futásidőt eszik, akkor recseg-ropog a hangja, buffer underrun lesz.

Talán egy új megközelítés, egy más elképzelés és implementáció jobb, robosztusabb, megbízhatóbb kódot eredményez. Most úgy vagyok vele, hogy a Pulseaudio-t nehéz alulmúlni minőségben, noha nyilván nem lehetetlen.

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

Még sose próbátam a PipeWire-t, írhatnál róla tapasztalatokat. Bár lehet tényleg simán jobb lesz, mint a Pulseadio, mivel ezt legalább nem Poettering jegyzi, úgyhogy ki tudja.

Nekem egyébként a Pulseaudio-val sem volt soha bajom, sose recsegett, ropogott, mindig működött, de nem szeretem, mert túl bloat, az én igényeimet egy egyszerű ALSA is kiszolgálná.

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

Meglepődtem a hozzászólásodon. Nem kezdem visszaolvasni magam, de ebben a topicban szerintem írtam a tapasztalataimról. Röviden: jó. :) Tetszik, hogy van alsa, jack, pulseaudio és természetesen natív pipewire interface-e, s ezeket szimultán, egy időben is használhatod. Megfelelő jack klienssel - pl. Carla - grafikus felületen kötözgetheted a bemeneteket, kimeneteket, mintha kábeleznél egy keverőpultot. Kicsi az erőforrásigénye, jóval kevesebb futásidővel beéri, mint a pulseaudio. Számomra egyetlen hátrány jelenleg, hogy a visszhangelnyomás még nincs implementálva. VoIP-hoz kellene.

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

Szerintem maga a PulseAudio, mint eszköz jó lenne. Mármint itt a megvalósítás valahol nagyon hibásra sikerült, de ha tényleg tudná hibátlanul azt, amire kitalálták, akkor szeretnék az emberek.

Akinek mondjuk két mikrofonja is van a gépen, és azt szeretné, hogy az egyik program csak az egyik hangját rögzítse, a másik meg a két mikrofont egyben, sztereó sávban, azt a PulseAudio előtt nem nagyon tudtam összehozni, mert ha az egyik program már figyelt egy eszközt, akkor a többi nem tudta használni. Emlékszem, hogy egy időben azzal is gond volt, hogy valamelyik programból már szólt a zene, így a másik program nem tudott ugyanazon az eszközön hangot lejátszani, mert éppen foglalt volt.

Remélem második nekifutásra sikerül megcsinálni tisztességesen.

Nagy Péter

Azzal kiegészítve, hogy a pipewire jack interface-ének felhasználásával akár grafikusan is kötözgetheted még lejátszás közben is a jelfolyamot. Közben persze az audio kliens lehet, hogy pulse illetve alsa interface-en csatlakozik hozzá, akár vegyesen.

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

A pulseaudio olyan mint az abszolút nulla fok a termodinamikában. Nem lehet alul múlni. :) 

Eredetileg "pulsevideo"-ként indult, volt valami vita névvel mert mert volt olyan. Majd audio résszel is kiegészült. Hasonló szerver stream elven működik ez is. Sandboxolt programokhoz hasznos ha kell gui. Tudtommal pulseaudio felett is tud működni. Szóval nem kizárólag _vagy_ kapcsolat van a két hangrendszer között, illetve ez nem csak hangszerver. Reményteli dolog, hogy Lennart Poettering nincs a fejlesztői között. 

Az úgy nem ér ám hogy az ábrán hagyjuk a legacy fosokat, amiket már egyik Linux se telepít, legalábbis nem defaultból :) Például az ESD valamikor a pubim környékén jött ki, azóta se weboldala, se létjogosultsága, se semmije :)

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nexus5_hammerhead

Megpróbáltam megnézni ezt az egyetlen francos png képet amit belinkeltél. A kép helyett megjelent egy üzenet hogy engedélyeznem kell a jávaszkriptet. Engedélyeztem. Erre jön hogy ő valamiért ellenőrzi a browseremet...

MI A TÖKÖM...?!

De jól van ellenőrizze. Ez kb 5 teljes másodpercig tartott, a faszom tudja miért...

Ezután jött valami fura oldal, hogy valami captcha-t kéne kitöltenem...

Hát bassza meg az oldal meg a tervezője ahol van! Visszavontam minden temprary engedélyt tőle, és otthagytam a picsába... velem ennyit ne szórakozzon egy oldal egy tetves png kép megnézése érdekében! Inkább lemondok róla!

Köszi.

Nekem a képből az jön le, a helyes megoldás egyelőre az ha maradunk az ALSA mellett, mert az egyrészt közvetlen kapcsolatban áll az aktuális output audio device-vel, másrészt amúgyis eléggé megkerülhetetlen mert az ábra központi helyén látható és nagyjából minden kapcsolódik hozzá amúgyis.

E kép megerősít abban az érzésben hogy jól döntöttem amikor a magam LFS-based disztrójába csak az ALSA-t telepítettem és nem a pulseaudiót meg más efféle izémizéket.

( batyu v | 2019. 10. 19., szo – 16:21 )

Azért ez kicsit más mint a pulse, nem csak hang, hanem multimedia framework.
Ami nagyon nem tetszik benne az az, hogy gnome/gstreamer kötődést látok benne, de majd meglátjuk. Elég sokat ígérnek (Capture and playback of audio and video with minimal latency. Real-time Multimedia processing on audio and video. Multiprocess architecture to let applications share multimedia content.), ami ha rendesen megvalósulna, azért elég jó lenne.

( Sas66 | 2020. 03. 27., p – 10:57 )

Üdv ! Ritkán szólok, de most megérkezett a tegnapi Manjaro frissítéssel a Pipewire. Úgy vettem észre, hogy minden frissítés után ellenőrzök néhány alkalmazást, hogy rendben van-e. Elindítottam a Virtuálboxban egy W7-t és rövid időn belül  (2-3 perc) a gép, nem a program, kiakadt.  Megismétlem, újra.  Deepin elinditva: egy exec nevü valami már 60% ra viszi a CPU-t, ás 8,3 GB-nál tart a memória foglalása. Mi ez ? pipewire-media-session . Kilövöm, minden oké. Újraindítás: kezdődik elölről. Mindez viszont csak Plasma alatt, Gnome -al nem. 

Más. Kb decemberben kíváncsiságból telepítettem a manjaro-gnome-ra a plasma desktopot. Korábban valahányszor ránéztem a KDE-re, hanyatt homlok menekültem belőle, hogy finom legyek. Most azonban azonnal ott ragadtam. Egyszerűen lenyűgözött.  A tegnapi manjaro frissítés szépen széttúrta a gnome asztalt, katasztrófálisnak érzem a visszafejlődést, már azt is el tudom képzelni, hogy ez szándékos....

Kérdésem most csak annyi: másnál is előfordul, hogy ez a pipewire nevű újabb izé megeszi a teljes memóriát vagy csak nálam van a hiba?

Itt van róla egy  https://archive.fosdem.org/2019/schedule/event/pipewire/attachments/slides/2826/export/events/attachments/pipewire/slides/2826/PipeWire.pdf

Én nem tudom ti mit futtattok, mit hallgattok, milyen vájt-fűlűek vagytok, de nekem a KDE-vel és a Pulseaudioval nincsen semmi bajom Mageia Linuxon. Nem recseg, nem zabál. S mindez az alaplapi MCP72XE/MCP72P/MCP78U/MCP78S High Definition Audio-val. Igaz, nem vagyok zeneszerző.

Valószínűleg Lennart Pöttering is a works for me miatt nem kereste és nem találta a bugot. Ha olyan alkalmazást futtatsz, mint a Seren peer to peer VoIP alkalmazás, amely nem csak lejátszik, hanem kétirányú az audio stream, nem bufferelhet egy másodpercet, mert akkor szétesik a beszélgetés, kell visszhang elnyomás, amelyet a Pulseaudio biztosít, továbbá resampling, mert a Seren fix 48 kHz mintavétellel dolgozik, a hangkártya meg 44.1 kHz-en, valamint a Seren az Alsa kompatibilitási rétegen keresztül kommunikál a Pulseaudioval - tudom, mert megnéztem a forráskódját -, szóval ebben a nem legegyszerűbb esetben bizony sokszor buffer underrun-nal illetve overflow-val térnek majd vissza azok a függvény, amelyik átadják, átveszik az audio buffereket. Ezt is tudom a Seren debug üzeneteiből, konkrétan megnéztem, mikor írja ki ezt a hibát, s ez bizony Pulseaudio bug. Ekkor lezárja a Pulseaudio a stream-et, majd azt újra meg kell nyitni, ez idő, majd folytatni a lejátszást. Hidd el, gorombán recseg-ropog, annyira, hogy érthetetlenné válik a beszélgetés.

Workaround valamelyest, ha kikényszerítem, hogy a hangkártyát hardware-esen 48 kHz-en használja, akkor nem kell resampling. Viszont a kernel ütemező nem feltétlenül úgy osztja a futásidő szeletkéket, hogy az a Pulseaudionak kényelmes legyen, ekkor a kliens és a szerver egymásra várnak a bufferek átadásakor, mindkettő sok futásidőt visz el, vergődik az egész, és kegyetlenül recseg-ropog a hang.

Ez az, amit végre pipewire használata esetén nem tapasztalok. A pipewire törekszik arra, hogy nem mozgat adatot, csak a pointereket adja át, így a működése amíg csak lehet, copyless.

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

plasma nalam akkor lett felejtos, amikor a hulladek electron appok terheleset megduplazta valami kde-s process (talan naplozo, vagy hasonlo). Sajna az appot melo miatt nem tudom megkerulni, maradt a desktop csere. De van tobb ilyen is, pl slack call nalam nem szerette a tilingWM-eket (i3/sway), szoval back to basics = openbox.

( st3v3 v | 2020. 03. 27., p – 11:45 )

miért érzem azt, hogy valaki már megint nekiáll csillaghajót építeni oda, ahova a csónak is pont tökéletes lenne, csak a víz fölött maradjon :)

( Szenti v | 2020. 03. 27., p – 15:11 )

Szerkesztve: 2020. 03. 27., p – 15:11

(nem ide, törölhető)

( locsemege v | 2020. 09. 09., sze – 00:29 )

Szerkesztve: 2020. 09. 09., sze – 00:34

Már vagy három perce pipewire-on keresztül hallgatok zenét. Ez még kevés ahhoz, hogy blogoljak róla. Kevés futásidőt eszik, úgy tudom, a tervezésnél szempont volt, hogy nem másolgat buffereket, csak a pointereket adja át. Persze nyilván van, amikor kell futásidő, például resampling esetén.

pactl info | grep ^Server
Server String: pipewire-0
Server Protocol Version: 33
Server Name: pipewire-0
Server Version: 0.3.10

Szerk.: Ami borzalmas, nekem úgy tűnik, hogy a hangerő szabályozás lineáris. A fülünk amplitúdóban - és frekvenciában is, de ez itt nem érdekes - logaritmikusan hall.

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

Hihetetlen, hogy a modern programozó nem hallott életében a B-s potméterről. Van egy Samsung LED TV-m ... ott is mindig felb*sz a hangerőszabályozó. Lineáris. Elejét nem tudod finoman szabályozni, 15..100% között pedig alig ér valamit.
Pedig ...  gain = pow(10, decibel/20) lenne C-ben és a skálát máris decibelskálán lehetne húzni. Tehát abszolut nem rakétatudomány.

Néha úgy érzem, hogy visszafejlődtünk bizonyos dolgokban az elmúlt néhány évtizedben. Vagy csak elfelejtjük és majd újra feltaláljuk mindazt, amit már egyszer tudott a világ.

( locsemege v | 2020. 09. 09., sze – 22:24 )

Szerkesztve: 2020. 09. 09., sze – 22:53

No, mondom az eddigi tapasztalataimat, amelyek erősen szubjektívek. Feléleszteni nagyon könnyű, a függvényei többé-kevésbé pulseaudio és jack kompatibilisek, így ezek az alkalmazások elvileg működnek majd minden nehézség nélkül. Aki kísérletezni szeretne vele, itt nézzen körül.

Ha bluetooth-szal is játszani szeretnénk, mentsük a /etc/pipewire/pipewire.conf file-t például oda, mellé pipewire.conf.orig néven, majd szerkesszük a /etc/pipewire/pipewire.conf file-t. A végén a -d bluez5 részt  kell törölni, talán így világosabb:

diff -u pipewire.conf.orig pipewire.conf
--- pipewire.conf.orig	2020-08-18 13:41:17.000000000 +0200
+++ pipewire.conf	2020-09-09 20:23:42.908433936 +0200
@@ -74,4 +74,4 @@
 # Execute the given program. This is usually used to start the
 # session manager. run the session manager with -h for options
 #
-exec /usr/bin/pipewire-media-session -d bluez5 # -d alsa-seq,alsa-pcm,metadata
+exec /usr/bin/pipewire-media-session # -d alsa-seq,alsa-pcm,metadata

Viszont azt tapasztaltam, hogy a bluetooth csak olyan alkalmazással megy pipewire-en keresztül, amelynek van közvetlen alsa interface-e, ott meg is fog jelenni eszközként a pipewire média szerver. Ilyen alkalmazás például az audacious, ha alsa-t mondunk neki audio kimenetként, azon belül meg pipewire-t. Így hát a firefox bizony nem képes bluetooth interface felé lejátszani. Ugyanakkor a pipewire pulseaudio interface-ű alkalmazásokkal egész jól működik, ha valamilyen hangkártya, vagy usb-s audio interface-ünk van.

Ha például online rádió hallgatása közben leszakad egy kis időre az audacious a hálózatról, s nem tudja tunkolni az audio buffert, akkor nem elakad a lejátszás, nem záródik le a stream, hanem jár tovább a read pointer, s a buffer underrun miatt ciklikusan ismétli az utolsó buffer tartalmát, ami legfeljebb néhány tized másodperc. Olyan, mintha megfagyott volna az egész, pedig nem. :)

Legnagyobb meglepetésemre a seren nevű p2p terminálos/konzolos ncurses VoIP alkalmazás is megy pipewire-rel. Külön izgalmas volt, hogy a seren warningban jelezte, hogy nincs implementálva egy általa hívott függvény. Ahhoz képest működött. :)

Hangerő szabályozására, a stream-ek kezelésére érdemes használni a pasystray nevű alkalmazást. Ez egy keretrendszer, jó ha van pavucontrol, pavumeter, paman, mert ezek kellenek hozzá.

Nagyon karcos, kidolgozatlan még a project, de ígéretes. Ami hihetetlenül tetszik, hogy a pipewire futásidő igénye igen alacsony. Míg a seren-t használva a pulseaudio megeszik 15 %-ot, a seren, ugyanennyit, a pipewire használatával a seren 16 %-ot, a pipewire 1.8 %-ot, de többször 1 % alatt. Ráadásul a pulseaudio hangja teljesen szétesik, recseg-ropog, buffer underrun, ha a kernel ütemezője rossz fázisban ad futásidőt a pulseaudio hangszervernek és a seren kliensnek. Ez a probléma úgy tűnik, pipewire használatával végre orvosolódni látszik.

Carla nevű klienssel grafikusan lehet huzalozgatni akár valós időben, lejátszás közben a stream-et, mintha dugdosnánk a drótokat a keverőben. Így például fel lehet cserélni a bal és jobb oldalakat.

A hangerőszabályozó linearitása meg az a pont, ami végtelenül elszomorít. Egy programozónak nem csak programozni kell tudni, hanem annak az eszköznek a fizikáját is ismernie kell, amelyre a programot írja.

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

( locsemege v | 2020. 09. 09., sze – 23:41 )

pgrep -l 'pulse|pipe'
1909 pipewire
1931 pipewire-media-

Tehát nem megy a pulseaudio, megy a pipewire és szól. Mondjuk még egy rakás váratlan hibával, az igaz.

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

( locsemege v | 2020. 09. 10., cs – 14:05 )

Ma kijött a 0.3.11-es pipewire. Ezzel már mennek a pulseaudio interface-szel rendelkező kliensek bluetooth-on is, bár egy-egy rövid pillanatra elakad a hang, de ezt csak bluetooth eszköznél tapasztalom. Viszont pl. YouTube video esetén a kép siet a hanghoz képest. Úgy látom, szépen fejlődik, ha még messze is van a tökéletestől.

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

( locsemege v | 2020. 09. 12., szo – 10:29 )

Tegnap jött még egy patch hozzá ezzel az általános megjegyzéssel:

- Add some patches to improve pulse compatibility

Azóta megy az audacious pulseaudio interface-en keresztül. Meg SDL-en is. Amúgy jack-en és alsa-n szintén. Egyedül annyi, hogy jack interface esetén a resampling-et a kliensnek kell elvégezni, így több futásidőt eszik. A legkevesebb futásidőt akkor eszi, ha a pipewire-hez alsa interface-en csatlakozik. Kicsivel több futásidőt eszik, ha a pulseaudio vagy SDL interface-t használjuk.

Van egy bosszantó jelenség. Amikor megjelenik egy új kliens, az éppen lejátszás alatt lévő stream egy pillanatra elakad.

Csináltam egy olyat, hogy audacious online rádió hangját játszotta le USB-s mikro-HiFi erősítőn, míg a Firefox egy bluetooth fülhallgatóra küldte a klip hangját. Mivel a bluetooth sajnos még nincs jól implementálva, akadozott a hang.

Tegnap néztem néhány videót a YouTube-on, s azt vettem észre, a video kicsit siet az audio stream-hez képest.

Mindezen gyermekbetegségek ellenére az látszik, hogy ez a cucc sokkal jobb lesz, mint a pulseaudio.

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

Eleinte szkeptikus voltam, és még nem is mertem kipróbálni - igaz ez most leginkább időhiány miatt vár. De kösz, hogy megosztod a tapasztalataid!
Ugyan nálam a pulse régóta teszi a dolgát gond nélkül, de emlékszem még, hogy anno mennyi nyűg volt vele, ez meg már most ígéretesebbnek tűnik.

A pulseaudio addig teszi a dolgát, amíg úgy használod, hogy nem jön elő egy mindig is fennálló bugja. Kap valamennyi futásidőt a kliens, valamennyit a pulseaudio szerver. Az ütemező a kernelben van, a kernel számára a kliens és a szerver is csak egy program, s aszinkron kerülnek ütemezésre. Igaz, hogy a szerver magasabb prioritással és nice-szal fut, de ez sem old meg mindent. Aztán van, hogy olyan ügyetlenül jönnek ki a dolgok, mint a közlekedésben egy „piros hullám”. Az egyik arra vár, hogy átadjanak neki egy buffert, a másik, hogy elvegyék tőle. Ez csak sejtés, de az már tapasztalat, hogy ekkor a pulseaudio - és jellemzően a kliens - futásideje megnő, majd a hang elkezd recsegni, ropogni. Külön jó, ha az audio stream két irányban megy pl. egy VoIP alkalmazás esetén. Akkor ennek a jelenségnek nagyobb az esélye.

A pipewire sem jó még, messze nem, de több esélyt látok arra, hogy megjavuljon, mert még nagyon az út elején jár. A seren VoIP klienst mindkét oldalon - távoli asztal eléréssel a távoli gépen - néhányszor újra kellett indítanom, hogy felépülhessen a kapcsolat. Zenét hallgatni tudok vele, bár bluetooth-on még nem. Értem, hogy erre nagyjából a kernel fölött az alsa-lib is elég volna, de a szándék látszik. Egyszerre képes pulseaudio, alsa és jack API-t nyújtani a kliensek felé.

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

Kap valamennyi futásidőt a kliens, valamennyit a pulseaudio szerver. Az ütemező a kernelben van, a kernel számára a kliens és a szerver is csak egy program, s aszinkron kerülnek ütemezésre

Azert az milyen szep mar hogy egy durvan megabites adatfolyam max ~10k-nyi bufferelest igenylo kvazi valosideju manageleset egy kasznin belul 2020-ban nem lehet hatekonyan megoldani es kiscsilliard "audiorendszer" kell ahhoz hogy egyatalan valami menjen. Ugyahogy. Vagy lehet hogy mindenki azt hiszi hogy "ah, ez milyen egyszeru problema, nosza irjunk egyet mert epp van egy szabad delutanom?" ;) 

Nem trivi'lis probléma, hiszen ha az ütemezőt meg tudjuk fűzni közel valósidejű futásra, akkor ezt más processzek is igényelhetik, s ugyanott vagyunk. Nem ismerem annyira a kernelt, hogy erről sokkal értelmesebbet mondhassak.

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

( locsemege v | 2020. 09. 18., p – 14:02 )

Van már 0.3.12-es pipewire. Egy gyöngyszem a changelog-ból:

* The sink/source format_info array is now filled up completely,
    this is actually not implemented yet in the real PulseAudio.

Hány éves a PulseAudio? És mikori a PipeWire? Ezek szerint a pulseaudioban a mai napig nincs rendesen kitöltve a formátum infó tömb, miközben a pipewire-ben ez épp elkészült. Vicces.

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

( nullptr | 2020. 09. 20., v – 21:33 )

Tehát apt remove pulseaudio && apt install pipewire után menni fog minden, vagy ennél azért többet kell mókolni?

Psszt, elárulom az IP-címemet: 192.168.0.14

Van a bevezetőben egy Olvass el! link. Olvasd el! :)

Szerk.: Nem kell eltávolítani a pulseaudio-t. A pipewire telepítése után kell csinálni talán 6 db symlinket, és kell egy ldconfig parancs.

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

( locsemege v | 2020. 09. 28., h – 23:35 )

Már van 0.3.13. Még nem volt időm megtapasztalni, a gyakorlatban mitől jobb az előző verziónál. A pasystray még belepusztul, ha találkozik a pipewire-rel. Bár nem minden esetben, és nem tudom, ez mitől függ.

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

( locsemege v | 2020. 10. 06., k – 22:17 )

Csináltam egy git clone-t az aktuális forrásából, aztán lefordítottam, rpm csomagot csináltam belőle, majd frissítettem, hiszen már öt napja nem készült belőle friss build, ami már-már tarthatatlan. :) Persze, működik ez a legfrissebb házi build.

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

( locsemege v | 2020. 10. 08., cs – 21:30 )

Nagyon sok commitot tolt bele Wim, az aktuális állapotot kihúztam a git repóból, lefordítottam, feltelepítettem. Érzékelhetően javult.

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

Kérdés: Mennyire drop-in replacement ez most a pulseaudio-ra nézve? Egy csomó szoftver van, amit azért száműztem a gépemről, mert pulse kellene neki, de ha ez tényleg működik (nem eszi meg reggelire a CPU-t, nem leakel, nem recsegteti kiszálláskor a fel nemszabadított buffereit - mint teszi a PA), akkor berakhatom helyette ezt.

Oldschool Computer - http://oscomp.hu

Nagyon. Na jó, egyre jobban, folyamatosan implementálódnak az esetlegesen még hiányzó részek. Elég, ha annyit mondok, hogy már ezt használom pulseaudio helyett? A vicces, hogy egyes alkalmazásokat alsa, másokat pulseaudio interface-én keresztül, miközben a Carla segítségével jack interface-en grafikusan lehet kötözgetni, mi mivel legyen összekötve, bár ezt pulseaudio interface-en például a pasystray segítségével is megteheted. Tetszik a játék, mert noha messze nincs még kész, napról napra egyre jobb. Egyelőre nagyon hiányolom a visszhang elnyomást. A bluetooth nagyjából működik, de Wim szerint az még munkás, hogy korrekt legyen. Ezt értsd úgy, hogy munkahelyen már tudok zenét hallgatni pipewire-en keresztül bluetooth-on.

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

top -p `pgrep -d, 'pipewire|audacious'`

top - 17:30:02 up 30 min,  1 user,  load average: 0.24, 0.30, 0.44
Tasks:   3 total,   0 running,   3 sleeping,   0 stopped,   0 zombie
%Cpu(s):  3.8 us,  2.1 sy,  0.8 ni, 89.9 id,  2.1 wa,  0.8 hi,  0.7 si,  0.0 st
MiB Mem :   7953.2 total,   3215.9 free,   1543.8 used,   3193.6 buff/cache
MiB Swap:   8300.0 total,   8300.0 free,      0.0 used.   5857.8 avail Mem

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   2835 *****     20   0 1188292  77460  53076 S   3.0   1.0   0:07.57 audacious
   2265 *****     20   0  112080  13100   8324 S   0.3   0.2   0:00.76 pipewire
   2269 *****     20   0   21720   9460   6848 S   0.0   0.1   0:00.28 pipewire-media-

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

( locsemege v | 2020. 10. 09., p – 18:47 )

A mai nap nem sikerült olyan jól Wimnek. A mai build-em eredményeképp 100 % CPU időt eszik a pipewire. Viszont így is tiszta a hangja. Visszatettem a tegnap este készített fordítást.

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

Virtuális gépben egy 12 éves host ócskavason beletelik talán három percbe is. :)

Mivel Fedorát használok, letöltöttem a disztribúcióhoz adott pipewire source rpm-jét, majd feltelepítettem. Utána a spec file-ban növeltem a build verziót és kigyomláltam a patch-eket. Kihúztam git clone-nal a legfrissebb forrást a project oldaláról. A forrásból töröltem a .git alkönyvtárat, mert ez nagy, és csak a verziókezeléshez kell. Ezt követően átneveztem a legfelső szintű, pipewire könyvtárat pipewire-0.3.13 nevűre, mert ezt várja a spec file. Összetömörítettem tar.gz formátumba, mert a spec így várja. Nyilván lehetne tar.xz is, de akkor módosítani kellene a spec file-t. Bemásoltam a tömörítvényt a forrás alkönyvtárba. Ezután rpmbuild -bb pipewire.spec, majd meg is vagyunk néhány perc múlva.

Ezt követően ssh-n keresztül a host-ra másolom, ezekkel a csomagokkal frissítek, majd sima felhasználóként

systemctl --user daemon-reload
systemctl --user restart pipewire
systemctl --user status pipewire

Nyilván az utolsó sor elhagyható, de szeretem látni, ha valami baja van.

A függőségét kiírja az rpmbuild, ha valami hiányzik. Épp ezért fordítok virtuális gépben, hogy egy rakás devel csomagot ne kelljen feltennem a hostra. De úgy emlékszem, nem sok. Azt hiszem, ANSI C-ben íródik, hogy gyors legyen.

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

Nem a sebesség miatt rühellem elsősorban a Pythonos buildkörnyezeteket, hanem a spagettiság és a szemetelés miatt. Szeretnék leforgatni egy akármilyen programot és a fél világot fel kell rakni hozzá a gépre, mert mezon, meg ninnya, meg mittudomén.

Mindenesetre a hangsúly nem ezen volt, hanem azon, hogy mi kell neki. Nyomsz egy objdump-ot a legenerált .so-n?

Oldschool Computer - http://oscomp.hu

Inkább a pipewire.spec file-ból idézek, szerintem beszédes, ki tudod belőle hámozni:

BuildRequires:  meson >= 0.49.0
BuildRequires:  gcc
BuildRequires:  pkgconfig
BuildRequires:  pkgconfig(libudev)
BuildRequires:  pkgconfig(dbus-1)
BuildRequires:  pkgconfig(glib-2.0) >= 2.32
BuildRequires:  pkgconfig(gio-unix-2.0) >= 2.32
BuildRequires:  pkgconfig(gstreamer-1.0) >= 1.10.0
BuildRequires:  pkgconfig(gstreamer-base-1.0) >= 1.10.0
BuildRequires:  pkgconfig(gstreamer-plugins-base-1.0) >= 1.10.0
BuildRequires:  pkgconfig(gstreamer-net-1.0) >= 1.10.0
BuildRequires:  pkgconfig(gstreamer-allocators-1.0) >= 1.10.0
%if 0%{?enable_vulkan}
BuildRequires:  pkgconfig(vulkan)
%endif
BuildRequires:  pkgconfig(bluez)
BuildRequires:  systemd-devel >= 184
BuildRequires:  alsa-lib-devel
BuildRequires:  libv4l-devel
BuildRequires:  doxygen
BuildRequires:  xmltoman
BuildRequires:  graphviz
BuildRequires:  sbc-devel
BuildRequires:  libsndfile-devel

Requires(pre):  shadow-utils
Requires:       %{name}-libs%{?_isa} = %{version}-%{release}
Requires:       systemd >= 184
Requires:       rtkit

%description
PipeWire is a multimedia server for Linux and other Unix like operating
systems.

%package libs
Summary:        Libraries for PipeWire clients
License:        MIT
Recommends:     %{name}%{?_isa} = %{version}-%{release}

%description libs
This package contains the runtime libraries for any application that wishes
to interface with a PipeWire media server.

%package gstreamer
Summary:        GStreamer elements for PipeWire
License:        MIT
Recommends:     %{name}%{?_isa} = %{version}-%{release}
Requires:       %{name}-libs%{?_isa} = %{version}-%{release}

%description gstreamer
This package contains GStreamer elements to interface with a
PipeWire media server.

%package devel
Summary:        Headers and libraries for PipeWire client development
License:        MIT
Requires:       %{name}-libs%{?_isa} = %{version}-%{release}
%description devel
Headers and libraries for developing applications that can communicate with
a PipeWire media server.

%package doc
Summary:        PipeWire media server documentation
License:        MIT

%description doc
This package contains documentation for the PipeWire media server.

%package utils
Summary:        PipeWire media server utilities
License:        MIT
Requires:       %{name}%{?_isa} = %{version}-%{release}
Requires:       %{name}-libs%{?_isa} = %{version}-%{release}

%description utils
This package contains command line utilities for the PipeWire media server.

%if 0%{?enable_alsa}
%package alsa
Summary:        PipeWire media server ALSA support
License:        MIT
Recommends:     %{name}%{?_isa} = %{version}-%{release}
Requires:       %{name}-libs%{?_isa} = %{version}-%{release}

%description alsa
This package contains an ALSA plugin for the PipeWire media server.
%endif

%if 0%{?enable_jack}
%package libjack
Summary:        PipeWire libjack library
License:        MIT
Recommends:     %{name}%{?_isa} = %{version}-%{release}
Requires:       %{name}-libs%{?_isa} = %{version}-%{release}
BuildRequires:  jack-audio-connection-kit-devel >= 1.9.10
# Renamed in F32
Obsoletes:      pipewire-jack < 0.2.96-2

%description libjack
This package contains a PipeWire replacement for JACK audio connection kit
"libjack" library.

%package jack-audio-connection-kit
Summary:        PipeWire JACK implementation
License:        MIT
Recommends:     %{name}%{?_isa} = %{version}-%{release}
Requires:       %{name}-libjack%{?_isa} = %{version}-%{release}
BuildRequires:  jack-audio-connection-kit-devel >= 1.9.10
Conflicts:      jack-audio-connection-kit
Conflicts:      jack-audio-connection-kit-dbus
Provides:       jack-audio-connection-kit

%description jack-audio-connection-kit
This package provides a JACK implementation based on PipeWire

%package plugin-jack
Summary:        PipeWire media server JACK support
License:        MIT
BuildRequires:  jack-audio-connection-kit-devel
Recommends:     %{name}%{?_isa} = %{version}-%{release}
Requires:       %{name}-libs%{?_isa} = %{version}-%{release}
Requires:       jack-audio-connection-kit

%description plugin-jack
This package contains the PipeWire spa plugin to connect to a JACK server.
%endif

%if 0%{?enable_pulse}
%package libpulse
Summary:        PipeWire libpulse library
License:        MIT
Recommends:     %{name}%{?_isa} = %{version}-%{release}
Requires:       %{name}-libs%{?_isa} = %{version}-%{release}
BuildRequires:  pulseaudio-libs-devel
# Renamed in F32
Obsoletes:      pipewire-pulseaudio < 0.2.96-2

%description libpulse
This package contains a PipeWire replacement for PulseAudio "libpulse" library.

%package pulseaudio
Summary:        PipeWire PulseAudio implementation
License:        MIT
Recommends:     %{name}%{?_isa} = %{version}-%{release}
Requires:       %{name}-libpulse%{?_isa} = %{version}-%{release}
BuildRequires:  pulseaudio-libs-devel
Conflicts:      pulseaudio-libs
Conflicts:      pulseaudio-libs-glib2
Provides:       pulseaudio-libs
Provides:       pulseaudio-libs-glib2

%description pulseaudio
This package provides a PulseAudio implementation based on PipeWire
%endif
 

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

Igaz is. Gondolom, hogy az udev kell ahhoz, hogy feltérképezze, milyen audio és video eszközöket lát a kernel. Mondjuk valaki létrehoz egy bluetooth kapcsolatot, bedug egy usb-s hangkártyát, akkor ezt működés közben is látnia kell.

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

Kihúztam git clone-nal a legfrissebb forrást a project oldaláról. A forrásból töröltem a .git alkönyvtárat, mert ez nagy, és csak a verziókezeléshez kell.

Biztos vagyok benne, hogy git esetén is van olyan lehetőség, hogy ne kelljen a fél világot leszedni csak a forráskód kedvéért - ha minden igaz, ezt a git clone --depth=1 paranccsal lehet megtenni.

Ez jogos, csak nagyobb a tanulási görbéje, mint bután kihúzni git clone-nal azt is, ami nem kell, törölni a felesleget, majd tar -czf-fel összecsomagolni. Ez olyasmi, mint amikor cat file | grep pattern formát használ valaki a grep pattern file helyett. Nyilván az első pazarló, de az esetek jelentős részében ennek semmi jelentősége nincs.

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

cat file | grep pattern formát használ valaki a grep pattern file helyett.

naná hogy cat file|grep pattern!

Mert pattern változtatásához csak felfelé nyíl, pár backspace kell és lehet azonnal átírni a patternt?

grep pattern file esetén:

  1. felfelé nyíl
  2. home
  3. 5 jobbranyíl pattern p betűjéhez
  4. pattern karakterszámával egyenlő mennyiségű delete megnyomása
  5. új pattern beírása

vagy goto 2:

  1. felfelé nyíl
  2. home
  3. X darab jobbranyíl amíg pattern végére érünk
  4. Y darab backspace amíg pattern végéből visszatörlünk Y karaktert
  5. pattern átírása
  6. enter (megint elírtam patternt) - >goto 1.

A Ctr + W kombó az előző whitespace-ig töröl, nem kell annyiszor backspace-et nyomni. (Ez tudtommal minden shellben megy.)
Egynémelyik shell pedig tud a Ctrl + B és Ctrl + F vagy a Ctrl + Left és Ctrl + Right kombókkal a szavak közt ugrálni.

Oldschool Computer - http://oscomp.hu

Feltételezem 2Geza arra célzott, hogy Linuxon azért van szükség ilyen extra hangkezelő rétegekre az ALSA felett, mert az ALSA nem támogat olyan dolgokat, amiket ezek megoldanak, illetve a PA esetében inkább próbálnának megoldani. Az OSS4 az egyik legfejlettebb hang-alrendszer, valószínűleg ezeknek a hiányosságoknak egy jelentős részét pótolná. Részleteket ne kérdezz, mert sem az ALSA, sem az OSS4 belső működését nem ismerem annyira, hogy adekvát választ tudjak adni.

Oldschool Computer - http://oscomp.hu

Ja, értem. Csak sejtem, hogy amikor Linus írni kezdte a kernelt, nem egy minden esetre felkészülő modell alapján kezdett kódolni, hanem nagyjából a mielőbb legyen látványos eredmény vezérfonal mentén. Ha a pulseaudio kínjait nézem, talán ott lehet a gond, hogy az ütemező nagy szabadságot enged meg magának, a valós idejű feladatok elhasalnak azon, hogy hamarabb kiszalad az adat a bufferből, mintsem megkapná a vezérlést az a process, amelyik azt megint feltölti.

Ha kellő távolból szemléled, ez egyáltalán nem triviális probléma, mert versenyhelyzet alakulhat ki. Lehet ugyan priorizálni a feladatokat, de mi van, ha egy másik process szintén roppant fontosnak gondolja magát? Egész egyszerűen adott futásteljesítménybe nem lehet végtelen sok feladatot bepakolni. A pipewire ígéretes project, mindhárom gépemen már ez a multimédia szerverem.

A fentiekhez visszatérve. Ha általános operációs rendszered van, amin bármi futhat, szerintem nem lehet garantálni, hogy egy általános audio stream, egy bármilyen általános audio hardware-en akadozás nélkül lejátszódjon. Más a helyzet, ha embedded környezetben eldöntöd, hogy ismert mennyiségű feladatot adsz a processzornak, s így garantálod, hogy a stream lejátszása belefér a futásidőbe.

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

( locsemege v | 2020. 10. 19., h – 23:28 )

Wim pénteken és ma egy rakás bluetooth a2dp patch-et tolt bele. Alakul ez, örülök neki. :) Természetesen csináltam belőle rpm csomagot, így használni is tudom.

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

Még sajnos pár hét mire lesz időm kísérletezni. Lehet addigra lesz visszhangelnyomás is :D Szoktam néha telegramon beszélni "kihangosítva", az lehet használja. Meg talán a browserek is, mert pl jitsi meetingek sem szoktak visszhangzani. De tesztelni ezek nélkül is lehet ;)

( locsemege v | 2020. 10. 21., sze – 22:54 )

A legutóbbi forráskód épp rossz, nálam csinál egy loopback-et az input stream-ről a kimenetre. A d55bc1eb az utolsó olyan patch, amivel nálam még jól működik.

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

( locsemege v | 2020. 10. 23., p – 10:37 )

Ezt a patch-et nem értem.

static inline uint32_t volume_from_linear(float vol)
{
	uint32_t v;
	if (vol <= 0.0f)
		v = VOLUME_MUTED;
	else
		v = SPA_CLAMP((uint64_t) lround(cbrt(vol) * VOLUME_NORM),
				VOLUME_MUTED, VOLUME_MAX);
	return v;
}

static inline float volume_to_linear(uint32_t vol)
{
	float v = ((float)vol) / VOLUME_NORM;
	return v * v * v;
}

Az egyik irányban köbgyökös, a másikban köbös. De miért? A hangerő decibelben hangzik lineárisnak, ami logaritmikus, nem pedig köbgyökös. A másik, amit nem értek, hogy miért float és miért nem double. Tudtommal C-ben a double jól definiált, szabványos típus, míg a float valami talán kompatibilitási okokból megtartott, architektúra függő képződmény.

De a köbös, köbgyökös konverzión jobban fennakadtam.

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

Lefordítottam, kipróbáltam. Mindenképp jobb a lineárisnál így a hangerő, de természetellenes, hogy nem logaritmikus. Most átestünk a ló túloldalára. Az alsó hangerő tartományokban alig van változás, nagyon halk az egész, a felsőben viszont elég meredeken nő a hangerő.

A programozók tényleg nem hallottak arról, hogy mi a fene az a decibel, s hogy a szubjektív hangintenzítás érzet éppen logaritmikus? Pedig Wim nem fiatal, kezdő programozó.

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

Itt igazából az a kérdés, mi a bemeneten az értelmezési tartományunk, s ehhez a kimeneten az értékkészletünk. Az, hogy ln(), vagy 10-es alapú logaritmus, lényegtelen, mert csak konstanssal szorzás, s úgyis a kívánt értékkészletbe kell transzformálni az eredményt, tehát a kettő ekvivalens. Majd elgondolkodom rajta, aztán lehet, fordítok egyet, s ha tetszik, még az is lehet, elküldöm Wim-nek a patch-et.

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

Eredetileg így nézett ki:

volume = (int)round(pow(1.0 + (progression / 100.0), volume) / pow(1.0 + (progression / 100.0), 100) * volume);

Csak itt nem láttam semmiféle "progressziót", így kiszedtem, viszont az le se esett, hogy akkor az egy lesz hatványozva... Fel kéne már ébredni. :/

Oldschool Computer - http://oscomp.hu

( locsemege v | 2020. 10. 23., p – 18:11 )

Most ezzel próbálkozom, de nem tökéletes:

diff -ur pipewire-0.3.13/src/modules/module-protocol-pulse/message.c pipewire/src/modules/module-protocol-pulse/message.c
--- pipewire-0.3.13/src/modules/module-protocol-pulse/message.c 2020-10-23 16:52:07.426393834 +0200
+++ pipewire/src/modules/module-protocol-pulse/message.c        2020-10-23 17:44:19.524043313 +0200
@@ -32,7 +32,7 @@
        if (vol <= 0.0f)
                v = VOLUME_MUTED;
        else
-               v = SPA_CLAMP((uint64_t) lround(cbrt(vol) * VOLUME_NORM),
+               v = SPA_CLAMP((uint64_t) lround(log((exp(1.0f) - 1.0f) * vol + 1.0f) * VOLUME_NORM),
                                VOLUME_MUTED, VOLUME_MAX);
        return v;
 }
@@ -40,7 +40,7 @@
 static inline float volume_to_linear(uint32_t vol)
 {
        float v = ((float)vol) / VOLUME_NORM;
-       return v * v * v;
+       return (exp(v) - 1.0f) / (exp(1.0f) - 1.0f);
 }

 struct descriptor {

Ugye a nehézség abban van, hogy a log(0) = -inf., s ez egy cseppet sem könnyíti meg a becsületességre törekvő honpolgár életét, mert valahol csalni kell. :)

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

( locsemege v | 2020. 10. 23., p – 19:12 )

Ez a patch-em jobbnak tűnik, azt hiszem, ennél maradok:

diff -ur pipewire-0.3.13/src/modules/module-protocol-pulse/message.c pipewire/src/modules/module-protocol-pulse/message.c
--- pipewire-0.3.13/src/modules/module-protocol-pulse/message.c 2020-10-23 16:52:07.426393834 +0200
+++ pipewire/src/modules/module-protocol-pulse/message.c        2020-10-23 17:44:19.524043313 +0200
@@ -32,7 +32,7 @@
        if (vol <= 0.0f)
                v = VOLUME_MUTED;
        else
-               v = SPA_CLAMP((uint64_t) lround(cbrt(vol) * VOLUME_NORM),
+               v = SPA_CLAMP((uint64_t) lround(log2(vol + 1.0f) * VOLUME_NORM),
                                VOLUME_MUTED, VOLUME_MAX);
        return v;
 }
@@ -40,7 +40,7 @@
 static inline float volume_to_linear(uint32_t vol)
 {
        float v = ((float)vol) / VOLUME_NORM;
-       return v * v * v;
+       return pow(2.0f, v) - 1.0f;
 }

 struct descriptor {

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

> A programozók tényleg nem hallottak arról, hogy mi a fene az a decibel, s hogy a szubjektív hangintenzítás érzet éppen logaritmikus?

A programozók...úgy általában??? Nem. Azok sincsenek sokan, akik ismerik az exponenciális függvény tulajdonságait, pl. hogyan függ össze a hatványozással. Amúgy az említett patch sehol sem szól decibelről.

> Pedig Wim nem fiatal, kezdő programozó.

És tudja, hogy a köbös számítás (adott intervallumon) jó közelítése a logaritmikusnak, miközben a cpu-igénye jelentősen kisebb.

> a nehézség abban van, hogy a log(0) = -inf., s ez egy cseppet sem könnyíti meg a becsületességre törekvő honpolgár életét, mert valahol csalni kell.

A b.t.h.-ok tényleg nem hallottak a programozáselmélet, számítástudomány alapjairól? :) A megfelelő csalás annyi, hogy egy if...else kizárja a log(0) lehetőséget. És ez benne is van a vonatkozó forráskódban.

> Az alsó hangerő tartományokban alig van változás, nagyon halk az egész, a felsőben viszont elég meredeken nő a hangerő.

Próbáltad csak ALSA használatával? Az amixer-rel lehet min...max, %, dBFS értékeket használva hallgatni, hogy a driver/hardware mennyire természetesen szabályozza a hangerőt.

> a float valami talán kompatibilitási okokból megtartott

Erről tudnál linkelni valami dokumentációt?

A fentiekben jórészt igazad van, bár itt a futásidő nem igazán érv, ezt nem minden hangmintán kell elkövetni, csak hangerőállítás alkalmával az új lineáris szorzót kell kiszámolni.

Doksit nem tudok, de szigorúan szerintem a double egy IEEE szabvány, míg a float olyasmi, mint az int, csak lebegőpontosan: architektúrától függ, mekkora. Arra gondolok, hogy fiatalabb korában az int 16 bites volt, de ma egy 64 bites CPU-n szerintem legalább 32 bites. Fix 16 bitre ott az int16_t.

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

( locsemege v | 2020. 10. 31., szo – 10:50 )

Szerkesztve: 2020. 10. 31., szo – 10:53

Megjelent a 0.3.14-es változat. Nekem nem újdonság, mert napi szinten csináltam build-et, így folyamatosan érzékelhetően javult. Viszont 0.3.13-hoz képest nagyon sokat fejlődött, most már egész jól használható. Mindhárom gépemen kidobtam a pulseaudio-t, pipewire fut rajtuk.

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

( locsemege v | 2020. 11. 04., sze – 18:12 )

Szerkesztve: 2020. 11. 04., sze – 18:13

Van már 0.3.15. Tekintve, hogy Wim ideiglenesen kikapcsolta a bluetooth működését, ha valakinek mégis kell a bluetooth, érdemes ezzel a patch-csel lefordítani:

diff -ur pipewire-0.3.15/src/examples/media-session/media-session.c pipewire/src/examples/media-session/media-session.c
--- pipewire-0.3.15/src/examples/media-session/media-session.c	2020-11-04 17:37:16.104106646 +0100
+++ pipewire/src/examples/media-session/media-session.c	2020-11-04 17:41:07.629885757 +0100
@@ -2067,6 +2067,7 @@
 				"alsa-acp,"		\
 				"alsa-seq,"		\
 				"v4l2,"			\
+				"bluez5,"		\
 				"suspend-node,"		\
 				"policy-node"
 #define EXTRA_ENABLED		""

Nem sejtésről beszélek, természetesen a saját gépemen kipróbáltam, teszteltem, működik.

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

Azt írja az újság, hogy nem kell megpatkolni, megy ez config file-ból is:

# The bluetooth module is disabled by default because it causes
# conflicts with PulseAudio. If you disable PulseAudio or don't
# load its bluetooth module, you can enable it here with -e bluez5

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

( kubi | 2020. 11. 05., cs – 08:39 )

Szerkesztve: 2020. 11. 05., cs – 08:40

Ma lattam meg tok veletlenul, hogy fut a gepemen. Debian testing.

Ugy tunik, hogy valamiert behuzta maganak a gnome. Ezt megint csak nem ertem, hogy mit keres a gepen.

#apt purge pipewire

The following packages will be REMOVED:
  chrome-gnome-shell* gdm3* gnome-session* gnome-shell* gstreamer1.0-pipewire* pipewire*

 

# dpkg -l pipewire*
ii  pipewire:amd64 0.3.12-1     amd64        audio and video processing engine multimedia server
ii  pipewire-bin   0.3.12-1     amd64        PipeWire multimedia server - programs

# ps xfa

   971 ?        Ss     0:00 /lib/systemd/systemd --user
    991 ?        Ssl    0:00  \_ /usr/bin/pipewire
    996 ?        Sl     0:00  |   \_ /usr/bin/pipewire-media-session -d bluez5

 

Ugy tunik, vissza kell ternem a heti nagytakaritashoz. Nem lehet mar a Debian se megbizni.

Nem biztos, hogy magával a PW-vel van a baja, lehet, hogy csak azon húzta fel magát, hogy a Debian csak úgy rolling-release módra kéretlenül feltelepítget neki olyan függőségeket, amik eddig nem voltak jelen egy állítólag stabil csomagkészletű rendszerben. (Mondom ezt úgy, hogy ha a GNOME3 azért húzta le a PW-t, mert a PA-t helyettesítik innentől vele, azt én egy nagyon üdvözölendő lépésnek tekintem, mert a PW-ben ugyan még nem vagyok biztos, hogy tényleg olyan nagyon jó lesz, de a PA-t alulmúlni aligha fogja.)

Oldschool Computer - http://oscomp.hu

Tekintve, hogy nagyon rákaptam az ízére, napi szinten csinálok pipewire build-et, s ez a default multimédia szerverem, megváltam a pulseaudio-tól, látom, hogy már most nagyon jó. Egyfelől a pipewire kevés CPU-t eszik, működik egyszerre a pulse, alsa, jack interface-e, a natív pipewire felületét meg szerintem még nem nagyon van alkalmazás, amelyik használná. Egyedül a visszhangelnyomás hiányzik nekem belőle, viszont nem recseg-ropog a hangja, mint bizonyos körülmények között a pulseaudionak.

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

Jó, megértem. Nem azt mondtam, hogy elkészült, semmi munka vele. A pulseaudio kompatibilis rétegben vannak még nem implementált függvények is, tehát például a pulse-effects nem működik vele. Az alapok, mint felvétel, lejétszás, a stream-ek ide-oda kötözgetése, működnek. Meg valamennyire videót is tud átvinni, de ezt még nem próbáltam.

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

Értem, hogy a pulse szar, és resource hog és egyébként is pötterix, tehát pfujj, de őszintén szólva én ebből nem sokat vettem észre, nekem nem recseg ropog, voipon se, biztos volt már olyan, hogy fejbe kellett verni, de nagy általánosságban megy. Ha ennél többször kéne belerúgni, akkor sem szívesen cserélném le valamire, ami ugyan nagyon szuperül tud lejátszani, csak hiányzik belőle a feature, amit használnék, ha épp úgy jön. Pulseal is annyi bajom volt, ami komoly, hogy a klassz céges füles mikrofonja nem megy, mert nem támogat valami új bluetooth profilet. Szóval ha lehet, majd akkor cseréljék ki, amikor már észre se veszem, hogy más van ott :)

> és egyébként is pötterix

locsemege pont nem tartozik azok közé, akik utálják Pötyi bátyót; jópár vitában védte már eddig a systemd-t. Szóval, ha még ő is azt mondja a PA-ra, hogy good riddance to bad rubbish, akkor ott már komoly baj kell, hogy legyen a PA-val.

Oldschool Computer - http://oscomp.hu

Nálam is jól teljesít - és még sok más felhasználónál,akik nem kukorékolják tele a netes fórumokat hogy "jól működik" - ergo az, amit látsz róla véleményeket (de bármi  másról is), jellemzően negatív irányba torzított képet ad.

A két halmaz aránya a releváns, márpedig a "működik" halmaz számosságáról csak khalovány becslésed lehet, a sokkal hangosabb "nem működik" viszonz jól látható és érzékelhető vélemnéyhalmazt fogalmaz meg - egyoldalú lesz a kép, ami kialakul róla, ha a "tömeges tapasztalatokat" - hibásan - többséginek tekinted. 

Igazából az összes csoport számosságáról (szereti/utálja/gőze sincs mi az) csak halovány becsléseink lehetnek. Lehet mondani, hogy a nem működik csoportot lefedik a systemd-mentes disztrók userei, de ez is torz képet ad, mert vannak olyan userek, aki utálják, de nem vállalták be a mainstreammel való szembemenés kompromisszumait és váltottak systemd-re, annak ellenére, hogy bajaik vannak vele. Továbbá az sem feltétlenül igaz, hogy akinek baja van a systemd-vel, az annak hangot is ad. Nézd meg a legutóbbi HOVD szavazást, a systemd csak 8%-os többséget szerzett a többiekhez képest, de a systemd-t mégsem szidja a HUP 42%-a.
A csöndben lévők systemd-hez való hozzáállásáról leginkább gőzünk nincs, hogy működik nekik, vagy csak lenyelték a békát és tűrnek, vagy azt sem tudják, hogy mi az és hogy egy probléma, amivel épp szembesülnek, az a systemd sara-e, vagy sem.

Amire viszont reflektálni szerettem volna, hogy nem mindegy, hogy tíz ember mondja, hogy nem jó, vagy tízmillió. Az előbbi ugyanis nem egyszerűen kisebbség, hanem marginális kisebbség, míg az utóbbi az ha kisebbség is, de tömeg. Ha ennyi embernek van vele baja, akkor ott valami baj van. (És azért az elég sokatmondó, hogy a distrowatch népszerűségi listájának a tetején egy systemd-mentes disztró (MX Linux) van, ill. az is, hogy a számontartott élő disztrók 30.8%-a (77/250) systemd-mentes.)

Oldschool Computer - http://oscomp.hu

Játszol a számokkal:

8%-os többséget szerzett a többiekhez képest

inkább 8%-os többséget szerzett az összes többihez képest, de aki megnézi a linket tudja értelmezni ha akarja :)

a systemd-t mégsem szidja a HUP 42%-a

hát ebben se vagyok biztos, HUP-on bárhol felmerül a téma lelkes ekézésbe kezd a közönség a hszekben. Nem beszélve arról, hogy aki nem használja, nem feltétlen érez kényszert arra, hogy foglalkozzon vele ;)
Én csendben használom már régóta, elég sok helyen, sokféle vason fut, és nem érzem, hogy sok gond lenne vele, pláne nem, hogy több, mint bármelyik másik inittel. Tanulni kellett kicsit hozzá, mert más, mert új, kukázni kellett a megszokott megoldásokat, ez bizonyára nem mindenkinek esik jól. De vessetek meg nyugodtan, én pl a hozadékai közül a journalt kifejezetten kedvelem.

Félreértés ne essék, nem szeretném, ha a systemd lenne az egyetlen, jól van ez így, hogy létezik több init, mint ahogy a systemd előtt is jó volt. Eltekintve az olyan helyzetektől amikor munka közben át kellett venni egy gentoo-s servert üzemeltetésre, és addig nem láttál a sysviniten túl :D

Nem játszom semmivel, a "többiekhez képest" az pontosan azt jelenti, hogy az összes többihez képest. Aki tud szöveget értelmezni az azt is tudja értelmezni, amit mondtam. Aki nem, annak marad a belemagyarázás. Jó kis szalmabáb sose rossz, igaz?

> hát ebben se vagyok biztos, HUP-on bárhol felmerül a téma lelkes ekézésbe kezd a közönség a hszekben.

Mind a 353 ember, aki ellene szavazott? Mert szerintem ugyanaz a 10-15 ember szokta szidni. És kb. ugyanannyi védeni.

Oldschool Computer - http://oscomp.hu

Aki szavaz valamire, az a többi ellen szavaz és ennek megfelelően aki nem szavaz valamire, az ellene szavaz. (Ez alól kivételt képeznek természetesen a tartózkodók, de ők a szavazásban csak akkor jelennek meg, ha van "tartózkodom" opció, itt pedig nem volt.) Ez nem systemd-specifikus, ez generikus logika, ami mindenféle szavazásra igaz. Ennyit a szalmabábokról; megint csak gondolkodni nem sikerült.

A másikra csak annyit tudok mondani, hogy szerintem ezen a portálon én voltam az, aki a legtöbb műszaki érvet felsorakoztatta a systemd ellen, úgyhogy ezt nagyon rossz embernek mondod.
Az meg nem az én hibám, hogy a systemd pártiaknál az "ellenérvelés" többnyire kimerül a személyeskedésben és a szalmabábok püfölésében (ld. még: "Nem sikerült megtanulni?", "Persze, mert ami új az rossz, ugye...", "De ezt egy systemd-hater írta!!!4", "Mert a SysVInit az olyan jó, mi?!" és még sorolhatnám). És az sem az én hibám, hogy a systemd pártiak többségénél a systemd kritizálása és ekézése közé tripla egyenlőségjel van téve. Ezek ugyanis vallásos hozzáállást tükröznek, ami a legkevésbé engem minősít.

Oldschool Computer - http://oscomp.hu

Szavazás:
Melyik a kedvenced az alábbiak közül:
-Mákostészta
-Lekváros tészta
-Diós tészta
-Sajtos tészta
-Káposztás tészta porcukorral
-Káposztás tészta borssal

Szerinted tehát az, aki a fenti hat közül például a sajtos tésztára szavaz, az utálja és rossznak tartja a többi ötöt (a lekváros tésztát pláne...), sőt a döntő többségüknek hasmenése és heveny lábrázása lett a lekváros tésztának még az említésétől is?

 

Mindkettőtöknek: ti keveritek az "ellene szavaz"-t az "ellene van"-nal (azaz azzal, hogy utálja). Ha szavazol a saját választottadra, akkor azt akarod, hogy az győzzön és nem a többi, tehát a többi ellen szavazol, hiszen nem akarod, hogy győzzenek, de ez nem azt jelenti, hogy utálod a többit. Az egész posztom arról szólt, hogy aki csendben van, annak a véleményét nem tudhatjuk. A systemd 8%-os többséget szerzett, de nem szidja a másik 42% egésze, aki nem a systemd-re szavazott, csak egy része. Nem lehet tudni, hogy pontosan mi volt a szavazatuk oka, ebben benne van az is, hogy simán mást favorizálnak, meg az is, hogy bajuk volt a systemd-vel, de nem adtak neki hangot. A lényeg az volt, hogy aki csöndben van, annak a véleménye nem ismert.

Oldschool Computer - http://oscomp.hu

Mivel nincs preferencia megadva a szavazásnál, így lehet a te értelmezésedben is valami, de én a "másik irányból" közelítem meg a dolgot: valami _mellett_ az nem azt jelenti, hogy az összes többi _ellen_. Nekem pl. a jól használt(!) sysvinit-tel nincs igazán bajom - viszont látva a korlátait és a hibáit mondom azt, hogy ugyan az n+1 féle (disztribúciónként és azon belül főverziónként is) eltérő toldozása-foltozása lehetne jó is, de célszerűbb volt az egészet újragondolni, újratervezni, és más elvek mentén felépíteni.

Nem. Attól, hogy azt mondom, hogy a kedvencem a lekváros tészta, még közel ugyanúgy szeretem a káposztásat (szigorúan csak borssal - sok-sok borssal) is meg a sajtosat is - csak épp ha egyet és csak egyet kell kiemelni, akkor az a lekváros lesz. Tehát nem a káposztás _ellen_ sőt egyik tészta ellen sem szavazok (mert nem az a kérdés!), hanem a lekváros mellett. Te lehet, hogy "minden ellen, kivéve a ..." módon szavazol, azonban ezzel nem a feltett kérdésre (meliyket kedveled leginkább) válaszolsz. Mert  pl. abból, hogy "behúzod" a sysvinit-et, még nem következik, hogy a BSD-stílusút utálod-e jobban, vagy a systemd-t, vagy épp valamelyik egzotikus init-rendszert, hanem csak és kizárólag az következik belőle, hogy a leginkább a sysvinit-et kedveled, semmi több, hiába képzelsz oda bármi mást is.

Hogy került már megint az utálat a képbe? Ezt ti látjátok bele folyamatosan, pedig itt csak arról van szó, hogy ha választottál valamit és az mellett voksolsz, akkor az automatice a többi ellen egy szavazat. Ha leülsz megnézni egy meccset, akkor is, ha az egyiknek drukkolsz, akkor a másik ellen drukkolsz, de ez nem azt jelenti, hogy utálod a másikat. Ezt ti látjátok bele folyamatosan.

Oldschool Computer - http://oscomp.hu

Akkor mondjuk a fizikában az ellenerő azt jelenti, hogy utálja az egyik erőt és nem azt, hogy szemben áll az egyik erővel? Ami pedig a magyar nyelvet illeti: https://www.arcanum.hu/hu/online-kiadvanyok/Lexikonok-magyar-etimologiai-szotar-F14D3/e-e-F1E41/ellen-F1ECD/

‘‹valakivel, valamivel› szemközt; ellentétes irányban; ‹valakinek› ártalmára’; ‘‹főnévként› ellenség’. Származékai: ellenség, ellenséges, ellenségeskedik, ellenébe, ellenkedik, ellenez, ellenző, ellenkezik, ellenkező, ellenkezés, ellenkezőleg, -ellenes, ellenzék, ellenzéki, ellenzékieskedik.
Alighanem az elő főnév el-, illetve ele- tövéből jött létre -n locativusi raggal; a szó tövének l-je utólag nyúlt meg intervokális helyzetében. Eredeti jelentése tehát ‘előtte’, majd ‘vele szemben’ (pl. átellenben); később ‘feléje’, végül ‘támadólag valaki felé’ irányban fejlődött névutóként. Főnévként nyelvújítási elvonás, talán az ellenség, ellenkezik származékokból; ebben az értelmében régies, irodalmi szó. Összetett szavak előtagjaként, illetve igekötői szerepben is sok szó eleme, többnyire latin (contra-) és német (gegen-) előtagú összetett szavak mintájára: ellenáll, ellenvetés, ellenszél, ellenfél, ellenméreg, ellenőriz, ellenérzés, ellenvélemény stb. Lásd még ellenszenv.

Oldschool Computer - http://oscomp.hu

Micsoda? Az, hogy az ellenszavazat ellenérzetet vagy ellenségeskedést jelent? Hol? Amit beidéztem, az az ellen szó jelentése volt, amiben világosan leírták (mindjárt az első szóban), hogy ez elsősorban azt jelenti, hogy valamivel szemben, átellenben, csak lehet használni úgy is, ahogy ti teszitek, de az még mindig a szótő (ellen) és nem pedig az ellenszavazat.

Ha választottad X-et, akkor azt akartad, hogy X győzzön, tehát nem akarod, hogy a többi győzzön, tehát a többi ellen szavaztál, de ez nem jelenti, hogy utálod őket. Mit nem lehet ezen érteni?

Oldschool Computer - http://oscomp.hu

"eredeti jelentése ... később fejlődött..." Világosan leírták, hogy miből fejlődött ki a jelenlegi jelentése, de tényleg nem egy magyar nyelvet beszélünk :)

> Ha választottad X-et, akkor azt akartad, hogy X győzzön, tehát nem akarod, hogy a többi győzzön, tehát a többi ellen szavaztál, de ez nem jelenti, hogy utálod őket. Mit nem lehet ezen érteni?

Engedd el az utálatot, mint konkrét szót. "tehát nem akarod, hogy a többi győzzön, tehát a többi ellen szavaztál". Ez egy negatív értékítélet. Azt mondtad, ilyet az ellen nem jelent.

Nem, ez nem a jelenlegi jelentése, hanem jelenleg lehet így is értelmezni, a szótövet, de ettől az ellen szónak a jelentése az azt jelenti, hogy valamivel szemben. Szerinted az ellenszél pl. mit jelent? Nem szembeszelet? Az ellenpólus? Az ellenhatás? És még sorolhatnám. Ezek melyike hordoz negatív érzelmi töltetet?

Ez nem negatív értékítélet, ennyi erővel ellenfél == ellenség, holott nem. Ez egyszerűen versengés, ebben az esetben a szavazatokért. Az ellen pedig nem hordoz semmilyen negatív érzelmi töltetet.

Oldschool Computer - http://oscomp.hu

Az lehet, hogy marginális hobbiproject, de sokat beszélek rajta, így nekem fontos. És rögzítsük, nem a kliens rossz. Olyannyira, hogy kínomban megnéztem a forráskódját. Pipewire-rel szép a hangja.

Poetteringnek vannak jó meglátásai, csak nem tud programozni. Inkább nevezném elméleti szakembernek, mint mérnöknek. Amikor a pulse nagyon bugzott az elején, bebizonyította, hogy egy rakás alsa driver bugos, vagy nincsenek implementálva olyan függvények, amelyeket a pulse használ, így ujjal mutogatott az alsa fejlesztőire, miközben alkalmazhatott volna workarond-ot. De nem, mert nyilván rétegek fölött átnyúlás. Inkább legyen sz.r, de elvileg legalább tökéletes, szépen hozza az OSI-modellt. Szóval idegesítő a fazonnak az idealizmusa, amiből akkor sem tudod kibillenteni, ha emiatt nem működik valami, noha javítható volna. Ha rajta múlna, nem volna DirectX sem, meg olyan huncutságok, hogy néha megkerülik az X szervert, hogy gyors legyen.

A másik, hogy szerintem a pulseaudio-ban van elvi bug. Nincs belekalkulálva, hogy nem realtime a kernel, s bizonyos esetekben a kliens és a szerver egymásra várnak, talán egymás callback függvényeit hívva azok nem térnek vissza, amíg át nem tudnak adni vagy venni egy buffert, így mind a kliens, mind a szerver futásidő igénye az egekbe szökik. Ez persze csak sejtés, sohasem néztem a forrását. Ez az, amit viszont a pipewire szépen megoldott.

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

> Az lehet, hogy marginális hobbiproject, de sokat beszélek rajta, így nekem fontos. És rögzítsük, nem a kliens rossz. Olyannyira, hogy kínomban megnéztem a forráskódját. Pipewire-rel szép a hangja.

Természetesen lelked rajta, nem bántani akartam én, fogalmam sincs, hogy egyébként jó vagy rossz, és teljesen reális, ha ez neked megfelel, és a pipwireel jól megy, akkor csinálod az early adoptert. Egyszerűen csak arra akartam utalni, hogy ez egy kvázi ismeretlen valami, az ismertekkel a legtöbben tudnak voipozni úgy, hogy nem recseg nekik elviselhetetlenül, mint neked. Aztán hogy ez azért van, mert mégiscsak a siren nem olyan jó szoftver, vagy azért, mert a többiek körbekerülgették, hogy egyébként szar a pulseaudio, az passz. Bár élnék a gyanúperrel, hogy nem fog minden ismertebb cucc csak a pa hülyeségeivel megküzdeni, tehát vagy a siren szar, vagy a paval együtt az összes audiobackend "szar", és ki kell kerülgetni a használó appnak. Akkor viszont ennek jó eséllyel oka van, nem egyszerre béna mindenki ugyanúgy.

> Poetteringnek vannak jó meglátásai, csak nem tud programozni. Inkább nevezném elméleti szakembernek, mint mérnöknek

Minden tiszteletem mellett, de az a HUPos megnyilvánulásaidból teljesen egyértelmű, hogy neked esélyed sincs megállapítani valakiről, hogy ő tud-e programozni, mert fogalmad nincs a területről. Még ha legalább a hardware közeli programozásról beszéltél volna, ott esetleg. De az, amit itt összehordtál mérnökségről az jézusom. FYI, sokkal inkább az a mérnök, aki a helyén próbálja meg korrigáltatni a dolgokat (ugyanis a probléma forrása az volt, hogy egy rakás ALSA driver ezek szerint egy félkész trágyadomb volt), mint az, aki jön, és kifújja az összes lukat purhabbal, az ugyanis a kőműves. És megint tisztán látszik, hogy fogalmad sincs, hogy egy szoftver projektben miért kiemelten fontos, hogy ne purhabozzunk. A fal ugyanis jó eséllyel úgy marad, a sw viszont bizony feljesztjük tovább, és pontosan az ilyen megworkaroundoltamoktól esik szét hosszú távon a francba. (Arról már nem is beszélve, hogy opensource projekten workaroundolgoassa más szarját, aki akarja, elvárni kissé naivitás)

Mást értünk a fogalmakon. A programozó-matematikus nem mérnök, viszont egy villamosmérnök, vagy akár gépész az. Legalább is az én felfogásomban. Az nem mérnöki hozzáállás, amikor valaki implementál egy szabályozót, csak éppen fogalma sincs a korlátairól, a problémáról. Sohasem vallottam magam programozónak. Akkor programozó volnék, nem pedig mérnök. :) Mindamellett igen, alacsony szinten assembly-ben és C-ben szoktam programozni mikrokontrollerekre, de mindig látom magam előtt a hardware-t, a limitációkat.

Egyébként azt, hogy Lennart mennyire tud programozni, igazolja a gyakorlat. A pulseaudio majdnem 14 főverziót megélt, s a mai napig nem működőképes, ez az időzítési probléma nincs megoldva. A pipewire tart 0.3.15-nél, és szépen szól. Igaz, nem Lennart írta, hanem Wim.

A programozás egyébként nem azonos a magas szintű nyelveken történő programozással, és tudom, hogy egyesek szerint a C++ az assembly picivel közérthetőbb formája. :)

A pulseaudio működése erősen függ attól, milyen alsa driver-t használ az alsó rétegben. A gépteljesítménytől is függ, a választott resampling algoritmustól is. Mert ez a VoIP kliens fix 48 kHz-en dolgozik, a hangkártya meg sok esetben 44.1 kHz-en.

A pulse csak bizonyos konfigurációk esetén lesz használhatatlanul rossz. Nem mindig az. De a hardware-től ez döntően függ.

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

> Mást értünk a fogalmakon. A programozó-matematikus nem mérnök, viszont egy villamosmérnök, vagy akár gépész az.

Ja, hogy elitistázkodnunk. Rossz hírem van, az én papíromban pl az van, hogy mérnök informatikus, szóval sajnos mérnök lesz az. (És egyébként a szobatársam, akinek az lett a papírjában, hogy villamosmérnök,  nagyjából ugynazt tanították neki, más hangsúlyokkal, meg néhány más szaktárgyi ismerettel, szóval nem nagyon látom be, hogy mitől lenne egy informatikus kevésbé az)

> Az nem mérnöki hozzáállás, amikor valaki implementál egy szabályozót, csak éppen fogalma sincs a korlátairól, a problémáról. 

Jaja, én pedig azt próbálom neked elmagyarázni, hogy neked fogalmad sincs, hogy pulseaudio méretű projektben mik a valódi konkrét problémák és korlátok, amiket egy szoftvermérnök megold, ezért a saját magad fele hajló békanézetből megállapítod, hogy ...

> Egyébként azt, hogy Lennart mennyire tud programozni, igazolja a gyakorlat. A pulseaudio majdnem 14 főverziót megélt, s a mai napig nem működőképes, ez az időzítési probléma nincs megoldva

... hogy nem tud programozni, mert valahol van benne egy bug vagy egy rosszul implementált darab valahol egy levélen*, ami egyébként különösen vicces egy olyan ember szájából, akinek saját bevallása szerint sincs fogalma arról, amit az elmúlt 20-30 évben megtanultunk arról, hogy hogyan lehet jól szoftvert tesztelni.

Ezzel szemben a gyakorlat az igazolja, a pulse audio a világ linux desktopjainak igen jelentékeny részén kielégítően teszi a dolgát.

Abban egyébként igazad van, hogy ezt többnyire már nem is programozónak szokás hívni, hanem szoftvermérnöknek :)

Szóval TLDR: mérnökölni alapvetően ugyan úgy kell áramot vezető dolgokon, betonnal kiöntött vas dolgokon, és absztrakt szofver komponenseket összekötögető dolgokon, nagyrészt a domain ismeretek különböznek, illetve a domainek sajátosságai miatt más módszereket használunk és mások a hangsúlyok --  pl mert míg ha egyszer valami bele van öntve a betonba, akkor azzal már nem nagyon lesz semmi, meg (ahogy ezt ti állítottátok) ha egyszer valami microcontrolleres dolog készen van, ahhoz többet hozzá nem nyúl senki, ellenben egy szoftverrel, -- de a megközelítés az ugyanaz.

 

*illetve ne menjünk el amellett, hogy most ugyan irányt váltottál, mert látszik, hogy az előzővel nem értél célba, de az előbb még azért nem volt mérnök, mert nem volt hajlandó körbetaknyolni a bugos ALSA drivereket.

Ha  jó a pulseaudio, akkor

- miért eszik egy rakás futásidőt a pipewire-rel szemben?
- miért recseg-ropog a hangja, miközben a pipewire hangja jó?

Mindez ugyanazon a hardware-en, ugyanazon az operációs rendszeren vizsgálva. Mindez úgy, hogy a pipewire API-nak van egy pulseaudio kompatibilis interface-e. Továbbá biztos, hogy kizárólag az új feature-ök adják a pipewire létjogosultságát?

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

A recsegéssel kapcsolatban meg sem próbáltad értelmezi a mondottakat, a cpu idő meg egyrészt max a saját kiragadott szempontodból fontos, másrészt pedig az, hogy a pipwirenek sikerül kevesebb cpu időből megoldani saját bevallásod szerint is egy kis részhalmazát a pulsenak, az kb semmit nem jelent.

Harmadrészt meg nagyon cuki vagy, hogy amikor te mész össze vissza, akkor természetesen el lehet térni a témától, bezzeg ilyenkor visszaérünk oda, hogy te egészen konkrétan mit állítottál

(ráadásul nem azt állítottad, hogy a pulse szar, hanem azt, hogy pötyi nem jó programozó)

Ja, ha nem számít a futásidő, nem számít a hangminőség, akkor jó a pulseaudio. Télen különössképp, mert így legalább fűteni lehet általa a CPU-val a lakást. Az meg a másik, hogy gondolom, attól jó egy programozó, hogy jó programokat ír, és attól rossz, hogy rossz programokat ír.

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

Csak ismételni tudom magam, próbált értelmezni amit írtam, addig addig meg légy oly mérnök, és ne fektess görbét egy pontra.

Továbbá ne sarkíts. Nem azt mondtam, hogy nem számít a futásidő, hanem azt, hogy az egyetlen paraméter a sok közül egy szoftverben, és egyáltalán nem biztos, hogy a legfontosabb. De köszönöm, hogy megerősíted, hogy mivel a többiről lövésed sincs, ezért ezen rugózol.

Igen, árnyaltabban fogalmaztál, mely szerint nem ez a legfontosabb. Mi a fészkes fene lehet fontosabb egy hangszerver esetében, mint az, hogy folyamatosan szóljon a hang, valamint ne vigye el a CPU futásidejét, amikor - mint kiderül -, ez nem elengedhetetlenül szükséges a helyes működéshez?

De, agyon csapnám az összes programozót, aki terjengősen kódol, mondván, RAM és futásidő van számolatlanul.

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

+1 Egyetértek locsemegével, hogy egy ilyen program esetén, ami kb minden desktop Linuxon fut, igenis számít hogy hatékonyan használja a CPU-t! Az meg, hogy jól működjön az pláne számít! (Bevallom nekem működött a Pulse mióta feladtam az ellenállást, de elvben egyetértek, hogyha nem működik az baj.)

> Egyetértek locsemegével, hogy egy ilyen program esetén, ami kb minden desktop Linuxon fut, igenis számít hogy hatékonyan használja a CPU-t!

Mennyire? Számít, hogy egy alsó középkategóriás gépen egy audiostream 10%? Hogy 1? Hogy fél? Hogy egy tized? Meddig számít? Mennyi plusz cpu fér bele, hogy valamit lehessen generikusan kezelni, és ne kelljen emiatt egy rakás eszközhöz kb ugyanazt leimplementálni kicsit másképp? Mennyi CPU fér bele, hogy kevesebb setupban legyen recsegő hang? Mennyi CPU fér bele, hogy emulálhass featureöket, amiket adott esetben nem támogat valami hardware, és egyébként nem lenne? Meddig éri meg a CPU spórolás miatt miatt sokkal nagyobb, nehezebben karbantartható, olvashatatlanabb, nehezebben portolható, potenciálisan bugosabb, potenciálisan mindenféle hardweren változó minőségű kódot csinálni?

> Az meg, hogy jól működjön az pláne számít! (Bevallom nekem működött a Pulse mióta feladtam az ellenállást, de elvben egyetértek, hogyha nem működik az baj.)

Persze hogy számít. Csak it is az a kérdés, hogy meddig? Szar lesz a PA, mert locsemege pont talált egy olyan setupot, ahol épp recseg? Annak ellenére, hogy pl nálad -- meg még egy nagy nagy rakás -- embernél nem recseg? Hány hiányosan megírt ALSA drivernél éri meg beleszarni az architectúrába (képzeld ide az összes következményt fentről)? Biztos, hogy az a jó, ha ezeket elkezdik workaroundolni, ezzel jó eséllyel bebetonozva a status quot, hogy azok az örök életre ott maradjanak, és sose javuljnak, potenciálisan új driverekből is hiányozzanak, meg szép lassan szaporodjanak? Biztos nem jobb hosszú távon azt mondani, hogy javítsátok meg a szart ott, ahol van, addig akinek peche van, recsegni fog, meg nem fog szólni?

És ezek csak azok a minimális kérdések, amiket az ember a domain ismerete nélkül a gépelés sebességével fel tud tenni.

Na, ebből lát lócsemege annyit, hogy pötyi nem jó programozó mert nála recseg, és egyébként is eszi a CPUt, és mivel ő olyan területen dolgozik, ahol a resourceok hatékony használata kiemelten fontos, ezért békanézetből megszokta, hogy ütné, aki nem baszakszik ezzel a végletekig, miközben nem gondol bele, hogy mások a keretek, és rohadtul más a cél, ha az ember nem egy konkrét hwre ír dolgokat, hanem egy olyan szoftveren dolgozik, aminek lehetőség szerint a világ összes audio hw-vel kéne menni.

> Mennyire? Számít, hogy egy alsó középkategóriás gépen egy audiostream 10%? Hogy 1? Hogy fél? Hogy egy tized? Meddig számít? Mennyi plusz cpu fér bele, hogy valamit lehessen generikusan kezelni, és ne kelljen emiatt egy rakás eszközhöz kb ugyanazt leimplementálni kicsit másképp? Mennyi CPU fér bele, hogy kevesebb setupban legyen recsegő hang? Mennyi CPU fér bele, hogy emulálhass featureöket, amiket adott esetben nem támogat valami hardware, és egyébként nem lenne? Meddig éri meg a CPU spórolás miatt miatt sokkal nagyobb, nehezebben karbantartható, olvashatatlanabb, nehezebben portolható, potenciálisan bugosabb, potenciálisan mindenféle hardweren változó minőségű kódot csinálni?

Itt vegyük elő a Hajbazer énünket! Relatíve nem nagy a Linux penetrációja, de összesen mégis nagyon sok gépen fut. Mennyi áramot fogyaszt, menyni CO2 kibocsátással jár egy 5%->10% növekedés? Mennyivel csökken a notebookok üzemideje akksiról? Mivel az a pár százalék CPU is összesen nagyon sok, ezért igenishogy indokolt a spórolás. Ráadásul locsemege infója szerint nem arról van szó, hogy 10-20%-ot lehetne faragni, hanem hogy többszörös a CPU használata, mint muszáj volna.

Ez a karbantarthatóság, portolhatóság gyenge kifogás, mert a jó megoldás sokszor egyáltalán nem bonyolultabb, vagy nehezebben karbantartható. (Ez saját tapasztalat a munkáimból, amikor valamit újraterveztünk eredetileg teljesítmény okokból, akkor sokszor még egyszerűbb is lett a megoldás. De tény, hogy létezik mikor teljesítmény miatt komplexebb lesz a megoldás, ilyenkor mérlegelni kell.) Persze nem néztem a Pipewire implementációját, de gondolom nem kézzel optimalizált X86 assembly az sem, hanem hordozható C. Ugyanis az ilyesmi nagyságrendileg nem mikoroptimalizáláson múlik, hanem architekturális kérdéseken. Abból, hogy egy ember ilyen rövid idő alatt működő programot állított elő, arra következtetek, hogy éppenséggel inkább egyszerű ez a program, mint bonyolult. A mikrooptimalizációnak is létezik még tere, de döntően nem ilyenekről van szó.

A programok teljesítménye fontos, és egy programozó aki ad magára, az számol vele. Nyilván sokmindentől függ, hogy mit mennyire érdemes optimalizálni, de a hangszerver már pont az a kategória amit kellene. A programozó által kiadott program teljesítménye felhasználható a programozó értékelésére. Hiába működik egy program, ha többszörös az erőforráshasználata, mint muszáj lenne, akkor az szar, és az a programozó hibája. Tapasztalatom az, hogy egy 10-100-1000-szeres lassulást simán hanyagságból bele lehet tenni egy programba úgy, hogy még nem is skálázódási a probléma, csak sima lineáris elbaszás. Prototípusnál még belefér, de egy elvileg kész programban ne maradjon ilyen!

> A programok teljesítménye fontos, és egy programozó aki ad magára, az számol vele. Nyilván sokmindentől függ, hogy mit mennyire érdemes optimalizálni, de a hangszerver már pont az a kategória amit kellene.

Természetesen. Vegyük észre, hogy én sem mondtam mást. Csak lócsemege előadta, hogy szar, mert nála recseg, és a pipwire sokkal jobb, mert kevesebb cput eszik. Egy pontból extrapolálva, majd teljesen kisarkítva olyan baromságokkal, hogy azt mondom, hogy nem számít a felhasználó. Úgy, hogy a sok mindentől függöt egyáltalán nem ismeri, fogalma sincs arról, hogy milyen szempontok szoktak még egy nagy szoftveben lenni, Meg azt sem, hogy a pipwire most még csodálatosan gyors implementációja hogyan fog kinézni, ha majd "nem csak az alap dolgok működnek".

A hajbazer énem meg majd kielégítem egy peccsel, hogy akkor se lehet emberi hangnál hangosabbra venni egy kimenetet, ha egyébként kilówattos hangfal van :P

"Mennyire? Számít, hogy egy alsó középkategóriás gépen egy audiostream 10%? Hogy 1? Hogy fél? Hogy egy tized? Meddig számít?"

Amint nem egy pc-n, hanem teszem azt egy arm-es board-on szeretnéd használni, vagy bármi máson, igenis sokat. Vagy amikor a laptopon azt látod, hogy a PulseAudio miatt a cpu nem megy alvó állapotba, hanem 3 GHz-en pörög, neked meg az akkuidő éppen fontos lenne, olyankor. És igenis, addig kéne baszakodni vele, amíg annyira jól nem működik, hogy el is felejted hogy a gépen ott van.

Hat-hét éve szereztem egy HP t5720 vékonykliens gépet, amiben egy 1GHz AMD Geode NX 1500 CPU, 512Mb DDR SODIMM RAM és 1 Gb IDE Flash háttértár volt. Erre akkor fel tudtam telepíteni egy aktuális Debian-t Xfce4-el, és használható volt, filmnézésre, alap böngészésre. Egy ilyen gépre ma kb SEMMILYEN desktop disztribuciót nem tudnék feltelepíteni, mert az összes egy túlhízott, összecsapott, bloat vacak.

Egy ilyesmi gépen igenis számít a szoftver optimalizáltsága.

De egy most piacon lévő  laptopon, amiben valami ultramobil cpu van is lehet ám csodákat látni, mert a gyufásdoboznyi alaplapról minden le van spórolva, amit csak lehet, olyan akadások tudnak ám létrejönni, mert a pci/pci-express sávok a végletekig le vannak korlátozva, és mindent a cpu számol, hogy nagyon meglepődnél ám. Mentettem kijelzőhalott Lenovo Ideapadról le hanganyagot live linux-al, ahol bele kellett hallgatni, hogy mit mentek le, és baromira sistergett, meg recsegett. A végén alsaplayer-t tettem a live rendszerre és a pulseaudio-t megkerülve sikerült lejátszani a hangfájlokat. Igen, tudom, hardvert venni tudni kell, csak hát akkor szoftvert írni is tudni kéne, nemdebár?

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

Mondjuk van egy olyan opció is, hogy nem használunk olyan ritkán használt, bár az alsa API-ban definiált függvényeket, amelyeket egyes driver-ekben hiányosan, vagy hibásan implementáltak. Csak azért, mert kényelmesebb lenne használatával az életünk, még nem muszáj használni. Lehet úgy tekinteni, mintha nem is lenne. Teszem azt, nincs kedvünk kiszámítani a hw pointer helyét, mert azt vissza is kérdezhetjük az API-n. Igen, de ha van olyan driver, amelyik nem, vagy nem jól adja vissza, akkor inkább mérjük az időt, s a mintavételi frekvenciából számoljuk ki, hol tart. Megoldható? Igen. Bár, aki nem akarja megoldani, annak ez nem fog menni.

Példa volt, bár emlékeim szerint tényleg valami ilyen nyűgje volt a pulse-nak egyes driverekkel.

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

Igy van.

Ha kesz lesz, jobb lesz, es atter ra minden program (vagy kompatibilis, hogy eszre se veszem), akkor mehet felolem.

A szemetelest utalom. Sajnos felkell aldozzak ra egy orat, hogy kitakaritsam a sok hulladekot, amit felgyujtott magara a Debian. Semmi kedvem rendszergazdat jatszani. 10+ eve nem szorakoztat.

fixme, de az apt nem frissit olyan csomagot, ami valami ujat akarna felrakni. ezeket szepen felsorolja a keepback listaban, es kesz. ahhoz user beleegyezes/kikenyszerites kell, hogy valami ujat felrakjon. szal az illetonek csak ugy nem ment fel, hacsak nem nyomott ra valami "nemerdekel, frissits mindent" gombra 

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( locsemege v | 2020. 11. 14., szo – 00:34 )

Valamit nem teljesen értek. Van ez a patch, amelyhez fűzött a szerző némi megjegyzést:

Don't build by default, update the README
With pulse-server we are more flexible and compatible and we don't
have to (badly) reimplement libpulse anymore.

Most az egy dolog, hogy azóta nem tudtam lefordítani, de addig masszíroztam a pipewire.spec file-t, amíg ez sikerült. Ahogy ezt sejteni lehetett, a pulseaudio-t indította a pulse kliensekhez. No, de az egész pipewire project számomra azért érdekes, hogy megváljak végre a szutyok pulseaudio-tól.

Egyelőre nem frissítek, az utolsó valóban pipewire implementációt használom, nálam működik. Tény, hogy például a pulseeffects kliens nem megy vele. Remélem, hogy ez csak a fejlesztés egy közbenső stációja, amikor is inkább az eredeti pulseaudio intézi a hangot, amíg bolygatják az egész pipewire pulse interface-ét.

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

Azt gondolom erről, hogy ez ideiglenes, amíg kikalapálják a pipewire pulse interface-ét. De nem győzöm hangsúlyozni, ezt gondolom azok alapján, hogy nekem úgy tűnik, egy rakás commit pulse related, de ezt teljes bizonyossággal nem jelentem ki, mert én csak sejtek, következtetek, aki ezt tudja, az Wim Taymans.  Most még ilyen vicces elírások is vannak benne, amikor egy struktúra címének nullaságát vizsgálták tévedésből, nem egy tagjának nullaságát:

	pw_log_info("destroy %s", p->sample->name);
	spa_hook_remove(&p->listener);
	p->stream = NULL;
-	if (--p->sample == 0)
+	if (--p->sample->ref == 0)
		sample_free(p->sample);
	p->sample = NULL;
}

De legalább már ez is kijavult. :) Szóval átmenetileg a pulseaudio-ra húzott réteg lett, de azóta nem csinálok belőle build-et magamnak. :P

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

Én tartok tőle, hogy rosszabb a helyzet:

pw-pulse is part of pipewire-pulseaudio (the PA compatible library), which is just deprecated and no longer enabled by default since 346e35ee.

forrás: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/375

Psszt, elárulom az IP-címemet: 192.168.0.14

Dehát így az egész dolog értelmét veszti... Mi a francnak tegyen föl bárki egy olyan extra audiolayert az ALSA/OSS fölé, amit a saját interface-ével nem használnak a szoftverek? Azért, hogy feltegyük azt a hulladék library-t, amit kiváltani hivatott és annak a tetején ücsörögjön, feleslegesen, pluszban, amikor ennyi erővel az eredeti hulladékot is hívogathatnák a szoftverek?

Oldschool Computer - http://oscomp.hu

Ha így lenne, csalódott lennék. Bár a pipewire-nek akkor is lenne létjogosultsága, hiszen általános multimédia sharing szerver, de épp akkor van értelme, ha azt, amit láttam belőle, audio terén meg is fogja valósítani. Nevezetesen a kis erőforrásigény, pulse, alsa, jack interface-ek, jó minőségű hang.

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

Miféle létjogosultsága van valaminek, amit nem használ semmi? Ha ki tudja szolgálni a más hasonszőrű layerekre támaszkodó szoftvereket, akkor van, amennyiben jobban csinálja, mint azok, amiket imitál (és speciel a PA-t elég nehéz lenne alulmúlni). Nyilván, ha majd lesz, ami ezt natívan használja, akkor már más lesz a helyzet, de itt pont az lett volna a lényeg, hogy addig is lehet használni N féle másik helyett, ráadásul, ha jobban működik, mint azok, akkor az emberek rászoknak arra, hogy inkább ezt az egyet tegyék fel a többi helyett és akkor az még ahhoz is lendületet adhat, hogy a saját interface-ét is elkezdjék használni. PW PA helyett: jóra cserélni a fost, az jöhet; PW a PA tetején: a felesleges ül a foson, az a felállás kell a francnak...

Oldschool Computer - http://oscomp.hu

Egyetértek veled, ezért is a jelen csalódottságom. Azért vagyok mégis bizakodó, mert noha - szigorúan szerintem! - átmenetileg deprecated (itt majdnem azt írtam, hogy decrapeted, de akkor már jönne is értem a TEK, szóval nem jó, ha az ember nem tud angolul, mint én) lett a pulse közvetlen reimplementációja, továbbra, tehát azóta is létezik például ilyen patch. Vagy például ez.

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

Hát ja, de optimista vagyok, mert pulse specifikus fejlesztéseket továbbra is tolnak bele. Lehet, hogy csak sok nyitott bug volt, s nem akarja Wim ezek elszaporodását, miközben tudja, hogy a pulse csak részlegesen van implementálva. Mindez feltételezés részemről.

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

( Dwokfur v | 2020. 11. 14., szo – 16:00 )

Köszönöm: ami eddig kiderült, az alapján még jó ideig maradok az ALSA-nál apulse-al kiegészítve.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Az apulse oldaláról:

Not implemented functions, application crashes

Large portion of PulseAudio API is not implemented. There are functions that do nothing and return some arbitraty values. Often, if application tries to call something not implemented, it crashes while trying to dereference a NULL pointer. By default, tracing level is set to 0, which means no messages are printed to standard output. It's possible to increase that value to 1, which shows unimplemented function calls, or to 2, which shows all function calls.

Már bocs, de ennél szerintem a pipewire natív pulse interface-e most sokkal jobb és egyszerre tudja a a jack, alsa, pulse felületet.

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

Ezt a kérdést körül kell járni, egyelőre nem látok tisztán. Most nincs időm, dolgoznom kell. Ha valakiben van annyi lelkesedés, kurázsi, megkérdezhetné ezt Wim-től. Már csak azért is, mert amennyire én angolul tudok, simán lefejezést írok az elavulttá tett kód helyett. ;)

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

Annyira aranyos vagy, mikor láthatólag azt se érted, mit csinálsz, de fasza :)

Szóval, volt az a pipwire-pulseaudio, ami a pulse kliensek fele biztosította azt, hogy a pulse interfacen keresztül (libpulse ugye) tudjanak megszólalni. Na, a commit arról szól, hogy megpróbált implementálni egy alternatívot, de szar volt, ezért inkább ezentúl wrappelni fogja a libpulse-t a module-protocol-pulse nevű saját modulban.

A depracated meg azt jelenti, hogy ez nem átmeneti, hanem faja programozó barátod így gondolja ezt hosszú távon.

Nem a barátom, csak tetszik a project. Ami a többit illeti, írtam is, hogy nem látok világosan a kérdésben, és ha így van, ahogy írod, akkor a végletekig el vagyok keseredve. Egyet azért nem értek: ezen patch után miért van még egy rakás pulse related commit?

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

Ne haragudj, ennyire nem néztem meg, de ha tippelnem kellene, akkor a libpulse wrapperését csinálja?

Igazából nem nagyon látom, hogy miért olyan rettenetes tragédia, ami történik? Mármint ha jól értem (és ez pár perc nézelődés után simán lehet faszság) a libpulse gyakorlatilag csak a publikus api, magát a hangszerver részét nem fogja használni, szóval ha tippelnem kellene, akkor azokat a részeket amiket ti nem szerettek (hogy állítólag nincs hangja, miközben zabálja az erőforrást) ez nem hozza magával. Az apiból meg miért olyan rossz ötlet használni a pulse által adottat, ami definíció szerint az igazság arról az interfaceről. Egyrészt sokkal könnyebb nem elcseszni valamit a klienseknek, másrészt sokkal hamarabb észrevenni a változásokat, amiket le kell követni az illesztésnél.

Ezen én is gondolkodtam, és ezzel így nincs is bajom, ez a lépés üdvözlendő számomra. Magát az interface-t valóban felesleges újraírni. Annyira nem ismerem a pulseaudio-t, hogy tudjam, a klienstől milyen függvényeken át jut el a buffer tartalma a szerverig, illetve a szerver mit hív vissza a kliensből, s ez az egész hogyan működik, hol lehet az interface-t elvágni a szervertől. Bár van valami pulseaudio socket, de mondom, ebben nem mélyedtem el.

Szerk.: igazából az érdekel, hogy lehessen native pipewire-t használni audio alkalmazásoknak pulseaudio interface-en keresztül.

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

Úgy néz ki, fején találtad a szöget, és ez bizony igen jó hír! :) Csináltam egy build-et a 573e2afd commit-ig, már azt is beleértve. Most azt tegyük félre, hogy hogyan csomagoltam be lustaság okán. A hivatalosan megszüntetni vágyott pipewire-libpulse csomagba hánytam be minden új file-t, s dobtam ki belőle, ami megszűnt. :) Szóval ezt ne firtassuk, de semmi jelentősége, kutyafüle is lehetne a csomag neve akár. Felfrissítettem az új csomagokra, majd

systemctl --user daemon-reload

Maszkoltam a pulseaudio socketet, hogy eszébe ne jusson elindulni:

systemctl --user mask --now pulseaudio.socket

Itt lehet, hogy a --now a mask elé írandó, de azt hiszem, mindkét formát megeszi. Utána leállítottam a pipewire-t, engedélyeztem a pipewire-pulse socketet és elindítottam a pipewire-t:

systemctl --user stop pipewire.socket
systemctl --user enable --now pipewire-pulse.socket
systemctl --user start pipewire.socket

Persze minden lépésem eredményességét status olvasással ellenőriztem, ezt itt most nem írtam le. Aztán működik jól. :)

A futásidő felhasználása kicsit romlott, mert a pipewire-pulse szerver megeszik kb. 1.7 % futásidőt, de ezzel még együtt tudok élni. Ez csak egy audacious kliens esetén, nyilván sok kliens ronthat ezen.

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

( asch v | 2020. 11. 17., k – 21:45 )

A Manjaro-s gépemen megjelent a Pipewire. 0.3.15-1 lesz a 0.3.14-1-ből, ha rákattintok, hogy oké. Rákattintok. Ha nem jövök többet, akkor rossz ötlet volt.

A 0.3.15-ben eredetileg még nem a libpulse használatát vezették be, hanem a saját pipewire implementáció van benne. Az működik egy adott szintig, de szerintem Wim rájött, hogy bonyolultabb dolgok megvalósítására rossz a koncepció, s később dobta csak a saját kivitelezésű interface-t. Ebben a későbbiekben tért csak át az eredeti pulseaudio interface-éhez, ugyanakkor a szerver továbbra is saját megvalósítás marad, így tehát szerencsére a pipewire nem egy újabb vékony réteg lesz a pulseaudio fölé, hanem valóban saját implementáció. Egyedül az interface marad a pulseaudioból. De mindez téged csak a 0.3.16-ban érint majd, hacsak nem fordítasz forrásból, mint én. :)

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

( locsemege v | 2020. 11. 17., k – 22:06 )

A mai build tanulságai: működik továbbra is, a bloetooth engedélyezéséhez nem kell a forrást patch-elni, elég a /etc/pipewire/pipewire.conf file vége felé ez:

exec /usr/bin/pipewire-media-session -e bluez5

Annyi viszont van, hogy szól a bluetooth fülesen a zene, kikapcsoltam a bluetooth fülest, s azt vártam, hogy az audio stream átdobódik az USB-s mikro hifire. Ehelyett elvesztette az összes be- és kimeneti device-t. Egy

systemctl --user restart pipewire-pulse.socket pipewire.socket

parancs helyrehozta a lelkét.

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

( locsemege v | 2020. 11. 26., cs – 20:58 )

Sokat fejlődött, egyre jobb. Van már 0.3.17-es változat.

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

Ezt egyszer már megtették a Pulse-val, akkor is milyen jól sült el. A pipewire sokkal jobban van összerakva ugyan, de attól még nem kéne elsietni ezt szerintem, inkább szállítsanak kicsit később egy stabil rendszert, mint korábban egy félkészet.

Psszt, elárulom az IP-címemet: 192.168.0.14

Ez így van, csak ugye ezt írtad:

pont ott kell minel bugosabbnak lennie

Nem kell minél bugosabbnak lennie a kódnak Fedorán. Itt is minél hibátlanabbnak kell lennie, csak nem túl nagy baj, ha már itt kibuknak és javításra kerülnek a hibák, mielőtt széles körben el lenne terjesztve az adott megoldás.

Ha a minél bugosabb állapot lenne a cél, akkor szándékosan kellene bele bugokat írni. De nem ez a cél.

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

Értem, meg látom a Fedora szerepét az ökoszisztémában, továbbá a Pipewire nem a default multumédia szerver Fedorán, ennek ellenére jegyzem meg, a Fedora stabilitásával nincs baj, jól használható napi munkában. Mindhárom gépemen Fedora van, ebből az egyiket csak munkára használom minden nehézség nélkül. Apróbb nyűgök vannak, de az sokszor nem a Fedora sara. Például az, hogy az 5.9-es kernelsorozatban hazavágták a nouveau driver-t.

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

De nem erről volt szó, senki sem szidta itt a Fedorát, nem ez volt a lényeg. nullptr annyit mondott, hogy inkább várjanak vele, mintsem szállítsák le bugosan, golgota meg erre mondta, hogy a Fedora pont arra való, hogy bugosan is kijöhetnek vele, mert a Fedora egy testing site; inkább ott legyen bugos. Ez nem azt jelenti, hogy legyen csak bugos, és azt sem jelenti, hogy szükségszerűen bugos lesz, csak azt, hogy ha az, akkor ott legyen bugos és ne a longterm disztrókban. Kár ebbe többet belelátni, főleg rosszindulatot.

Oldschool Computer - http://oscomp.hu

pontosan....nem hittem volna hogy ennyire nem voltam ertheto.

Azt akartam mondani, hogy minel bugosabba  afedoraban annal jobb lesz, mert ott szet fogjak javitani. Minel bugosabb ott, annal jobb lesz a vegen, mert rebgeteget fognak rajta dolgozni ogy ne legyen az. Es ezaltal meg jobb lesz. Ezt akartam mondani. Szoval igenis legyen minel tobb bug megtalalva benne, azaz legyen tizsta bug az egesz. Hogy a vegen szuperjo legyen.

Noha értem, amit mondasz, a megfogalmazás még mindig kellemetlenül zavaró, sőt, szerintem pontatlan is. Ne legyen tiszta bug az egész, a fejlesztők törekedjenek arra, hogy elsőre minél kevesebb hibával írják meg a kódot! Én is arra törekszem a munkámban, hogy minél kevesebb hiba legyen benne már első gyártatásra, ha hardware. Ha meg firmware, akkor első futtatásra.

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

> Ne legyen tiszta bug az egész, a fejlesztők törekedjenek arra, hogy elsőre minél kevesebb hibával írják meg a kódot!

Ez nem azt jelentette, hogy szándékosan pakoljanak bele bugokat, hogy legyen mit kijavítani... :)
Csak az számít bugosnak, amiben meg is találják a bugokat, mert amíg nem fut bele valaki, az olyan, mint ha ott sem lenne. (Nyilván ott van és bugos a cucc, de ismert hiba nincs, tehát a szoftver jelenleg nem minősül bugosnak.) Magyarán értsd: találjanak meg benne minél több bugot. Erre való egy játszótér disztró. (Ez most külön, kötőjel, vagy egybe...?)

Oldschool Computer - http://oscomp.hu

Attól még, hogy nem volt benne rosszindulat, marhaság.

https://fedoraproject.org/wiki/Fedora_myths?rd=FedoraMyths#MYTH_-_Fedor…

Nem az a különbség a Fedora és a RHEL között, hogy a fedora nem lenne stabil és nyugodtan bele lehet tenni bugos dolgokat, hanem hogy gyorsan lehet rajta változtatni, bele lehet rakni mindenből a legfrissebbet, nem probléma ha valami nem kompatibilis visszafelé teljesen és nem kell rá évekig supportot adni, ezáltal régi kódot karbantartani.

Ettől még erősen tesztelve van és nem adnak ki olyan dolgokat benne amiben nem biztosak, hogy stabilan működik. Tehát biztos lehetsz benne, hogy addig nem lesz a pipewire a default audio server amíg nem biztosak benne, hogy működik, ugyanúgy, ahogy a waylandre sem álltak át addig, amíg nem teljesítette a feltételeket, és nem a userekkel teszteltették le.

> Ettől még erősen tesztelve van és nem adnak ki olyan dolgokat benne amiben nem biztosak, hogy stabilan működik. Tehát biztos lehetsz benne, hogy addig nem lesz a pipewire a default audio server amíg nem biztosak benne, hogy működik, ugyanúgy, ahogy a waylandre sem álltak át addig, amíg nem teljesítette a feltételeket, és nem a userekkel teszteltették le.

Akkor csak a systemd-re sikerült idő előtt átállniuk? :P

Oldschool Computer - http://oscomp.hu

Nem, a systemd működött kezdettől fogva. A pulseaudio volt az, ami valami elképesztő mértékben bugos volt, durván recsegett-ropogott a hang, néha 100 % CPU-t megevett és egyúttal szétfagyott. Azt a szörnyet - ami a mai napig nem jó - valóban így rakták a Fedorába.

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

> Nem, a systemd működött kezdettől fogva.

Hibás szórend; helyesen: a systemd kezdettől fogva nem működött. Kiegészítés: most se.

> A pulseaudio volt az

Is.

> ami valami elképesztő mértékben bugos volt, durván recsegett-ropogott a hang, néha 100 % CPU-t megevett és egyúttal szétfagyott

Nem érzem indokoltnak a múlt időt.

Oldschool Computer - http://oscomp.hu

Nem érzem indokoltnak a múlt időt.

Ezt még a 14-es Pulseaudio is csinálja? Remek.

Kiegészítés: most se.

Ez érdekesebb. Az ellenszenven túl vannak olyan dolgai, amelyek valóban nem a dokumentáció szerint működnek? Természetesen a legfrisseb változat érdekes, mert korábbinak a bugjait a friss javíthatta.

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

> vannak olyan dolgai, amelyek valóban nem a dokumentáció szerint működnek?

Hát, mintegy ezerháromszáz darabnyi (csak ma hat új darab)...plusz még húsz darab sérülékenység; bár ki tudja, lehet, hogy azok a dokumentáció szerint működnek.

> Természetesen a legfrisseb változat érdekes, mert korábbinak a bugjait a friss javíthatta.

Ez annál is frissebb, ez az upstream repository.

Oldschool Computer - http://oscomp.hu

> ~1300 issue azért nem ugyanennyi sérülékenység.

He? Ki mondta, hogy 1300 sérülékenység van benne? locsemege azt kérdezte, hogy vannak-e olyan dolgai, amelyek valóban nem a dokumentáció szerint működnek és erre írtam, hogy mintegy ezerháromszáz darab, lévén a bug azt jelenti, hogy nem a doksi szerint működik. Plusz még húsz darab sérülékenység. Nem ezerháromszáz plusz húsz sérülékenység, hanem ezerháromszáz bug plusz húsz sérülékenység. Legközelebb figyelmesebben olvass.

> Ennyi idős és ekkora projektben lazán van bárhol ennyi issue.

Ennyi nyitott, azaz javítatlan? Mert ezen felül még van több, mint ötezer lezárt...ami viszont nem ekvivalens a javítottal, lévén egy jó része WONTFIX-szel került lezárásra.

Oldschool Computer - http://oscomp.hu

Aha, bízzál benne, hogy más sem nézi meg, hogy igazat beszélsz-e? 1300 nyitott issue, és mind-mind javítatlan, azaz BUG! :D

És nem, nem állítom, hogy ez egy tutijól megírt cucc, csak nem értem mit kell itt (is) vergődni ezen, ráadásul egy olyan topicban, ami a PipeWire-ről szól.

> Aha, bízzál benne, hogy más sem nézi meg, hogy igazat beszélsz-e? 1300 nyitott issue, és mind-mind javítatlan, azaz BUG! :D

Micsoda? Nézd már meg jobban: ennyi nyitott issue van. Abban ugyan igazad van, hogy ez nyilván nem mind bug, de vajon hány lehet ebből feature-request? 100? 200? Változtat ez az eredményen? Nem, már csak azért sem, mert elegánsan figyelmen kívül hagytad, hogy a lezárt hibajegyek se mind javítottak, hiszen Pötyi bátyó tucatjával zár le hibajegyeket WONTFIX-szel... Felhívnám még arra is a figyelmedet, hogy ugyan még csak dél van, de már ma is két bugot reportoltak, valamint arra is, hogy százával hemzsegnek az olyan ticketek, amiket évek óta nem javítanak (csak 2015-ös ticketből 65 db van).

> És nem, nem állítom, hogy ez egy tutijól megírt cucc, csak nem értem mit kell itt (is) vergődni ezen, ráadásul egy olyan topicban, ami a PipeWire-ről szól.

Szóbakerült, mert related, már csak azért is, lévén a PW támogatja a systemd-t, szerencsére a jelek szerint opcionális a dolog. Itt konkrétan úgy jött képbe, hogy mivel a PipeWire a PulseAudio-t hivatott leváltani és ebben a szálban az volt a téma, hogy a Fedorában is tervezik a váltást és a Fedora játszótér mivolta kapcsán szóbajött, hogy mi mindent tett defaultá a Fedora idő előtt, többek között a PulseAudio-t is és a systemd-t is.

Oldschool Computer - http://oscomp.hu

Nem eszik olyan forrón a kását. A kernelben hány bug is van? Aztán mégis használja a világ. A systemd bugtrackerében is van olyan bug, amely mellé oda van biggyesztve, hogy voltaképpen az kernel bug.

A pipewire csak arra használja a systemd-t, hogy elindítsa a user session indulásakor a user jogaival. Nagyjából, illetve van függőség kezelés, a pipewire.socket triggereli a pipewire.service-t, valamint a pipewire-pulse.socket triggereli a pipewire-pulse.service-t. De ezt kb. egy kutya közönséges shell scriptben is megírod mondjuk az SysVinit keretein belül néhány sorban. Bár attól függ, mennyire akarod általánosra, minden hibát lekezelősre csinálni, mert ezekre a systemd fel van készítve. Ha jól emlékszem, van valami OnFailure vagy valami efféle benne.

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

> A kernelben hány bug is van?

Kb. 9000, de nem baj, hogy alma-körte? A kernel több nagyságrenddel bonyolultabb, mert több nagyságrenddel több dolgot kell tudnia, mert annyival több feladata van. Hol kell a pl. systemd-nek hatvannyolcezer féle hardware-t kezelnie? Csak érzékeltetésképpen (tömörítetlen TAR fájlban) a méretek:

-rw-r--r-- 1 root root 1011333120 nov   28 14:12 linux-5.9.11.tar
-rw-r--r-- 1 root root   58449920 nov   28 14:13 systemd-247.tar

A Linux kernel kódbázisa 17x akkora, mint a systemd-é, ehhez képest kevesebb, mint 7x annyi bug van benne. Ha megnézzük, hogy hány bug jut egy MB-ra a két projektben, akkor 9.45 bug/MB a Linux kernelnek és 24.13 bug/MB a systemd-nek. Ez azt jelenti, hogy arányaiban a systemd 2.5x olyan bugos. És mondom: mindezt úgy, hogy a kernelben található bugok egy nagyon jelentős része a hardwarekezeléssel kapcsolatos (ott a lista, lehet csekkolni) és asszem pont neked nem kell ecsetelnem, hogy mennyi olyan van, hogy a hardware maga is bugos, vagy csak dokumentálatlan, vagy épp máshogy működik, mint a doksi leírja...szerinted fair ilyen jellegű kernelbugokat pariba állítani azzal a taknyolással, ami a systemd-ben folyik?

> A systemd bugtrackerében is van olyan bug, amely mellé oda van biggyesztve, hogy voltaképpen az kernel bug.

Persze, a rm -rf /foo/.* meg "UNIX pitfall"... Pötyi bátyó előszeretettel hárítja másra a saját sarát.

Oldschool Computer - http://oscomp.hu

> Nem related, de szóba hoztad, és még mindig lovagolsz rajta.

De related és nem is én hoztam szóba először.

> Hogy neked mennyi felesleges időd van!

Hétvége van.

> Esetleg javíthatnál systemd bugokat!:D

1. A systemd koncepcionálisan törött, azt nem lehet javítani.
2. Ne akard beosztani az időmet, vagy megszabni, hogy mivel foglalkozzak.

Oldschool Computer - http://oscomp.hu

Hát ha neked elég, hogy kb említésre került a neve, akkor legyen related.

A systemd koncepcionálisan törött, azt nem lehet javítani.

Azt elfelejtetted odaírni, hogy: szerinted.

Szerintem meg a hibáival meg bugjaival együtt is sokkal inkább előremutató stuff, mint a klasszikus initek. És úgy tűnik, hogy ezzel a véleményemmel mintha nem lennék teljesen egyedül, szép lassan a mainstream disztrók bevezették, használják. Persze lehet, hogy mindenki hülye azoknál is. De majd az idő eldönti. Én mindenesetre szívesen látnék egy mondjuk a solaris SMF-re hajazó megoldást systemd helyett, nem pedig scriptekből összetákolt megoldásokat, amiket jelenleg fel szoktak sorolni alternatívaként.

2. Ne akard beosztani az időmet, vagy megszabni, hogy mivel foglalkozzak.

Kicsit figyelj már oda, mielőtt vagdalkozni kezdesz, ott a szmájli a végén. Egyébiránt meg ki vagy te hogy ezt megszabd nekem, majd én azt eldöntöm, hogy kinek mondok véleményt, és kinek nem! :D

> Azt elfelejtetted odaírni, hogy: szerinted.

Mert nem csak szerintem. Én sem vagyok egyedül ezzel a véleménnyel.

> Szerintem meg a hibáival meg bugjaival együtt is sokkal inkább előremutató stuff, mint a klasszikus initek.

És? Más újkori SCS nincs a systemd-n kívül? Még mindig csak a SysVInitre sikerül mutogatni?

> szép lassan a mainstream disztrók bevezették, használják.

A popularitás nem érv. Ha az lenne, a winfostíz lenne a legjobb desktop oprendszer a világon.

> Persze lehet, hogy mindenki hülye azoknál is.

Nem csak hülyeség lehet a háttérben.

> Én mindenesetre szívesen látnék egy mondjuk a solaris SMF-re hajazó megoldást systemd helyett

Ebben egyetértünk, de már vannak hasonlóak.

> nem pedig scriptekből összetákolt megoldásokat, amiket jelenleg fel szoktak sorolni alternatívaként.

Te miről beszélsz? Az s6 vagy a nosh mióta van scriptekből összetákolva?

> Kicsit figyelj már oda, mielőtt vagdalkozni kezdesz, ott a szmájli a végén.

És? Azt nem csak a komolytalanság jelzésre lehet használni, hanem kárörvendésre vagy hasonlókra is.

> Egyébiránt meg ki vagy te hogy ezt megszabd nekem, majd én azt eldöntöm, hogy kinek mondok véleményt, és kinek nem! :D

Nem szabtam meg semmit, főleg nem azt, hogy kinek mondhatsz véleményt. Azt mondtam, hogy te ne akard megszabni, hogy mit csináljak.

Oldschool Computer - http://oscomp.hu

Te miről beszélsz? Az s6 vagy a nosh mióta van scriptekből összetákolva?

Nos, ezek nincsenek összetákolva, csak még igen messze vannak a széles körben használhatótól. Persze ha valakinek elég sok ideje van init rendszerekkel kísérletezni VM-en pl, akkor tuti jó móka lehet.

A nosh egy tök jó ötlet, de kb one-man project, annak minden velejárójával. Kipróbáltam volna archon pl, de a 2018-as leírásokkal már nem igazán lehet egy az egyben haladni. Plusz elég érdekes, hogy van forráscsomag, de sehol egy git, issue tracker, etc... 

De legalább jó "UNIX-os" megjelenésű mindkét stuff honlapja, imádom a talpas betűket monitoron. :D

> Nos, ezek nincsenek összetákolva, csak még igen messze vannak a széles körben használhatótól.

Miért is? Mi hibádzik belőlük, amiért ne lehetne őket "széles körben" használni?

> Persze ha valakinek elég sok ideje van init rendszerekkel kísérletezni VM-en pl, akkor tuti jó móka lehet.

Ezek nem init rendszerek, ezek SCS-ek, ahogy a systemd is.

> A nosh egy tök jó ötlet, de kb one-man project, annak minden velejárójával.

A legtöbb opensource projekt kis létszámmal. A systemd-t is Poettering meg Sievers kezdték el csinálgatni.

> Plusz elég érdekes, hogy van forráscsomag, de sehol egy git, issue tracker, etc...

Hogyhogy sehol? Fent van githubon a nosh. Az s6 is.

Oldschool Computer - http://oscomp.hu

Honnan tudod, hogy egyetlen ember commitol? A git csak egy mirror. Kérdezd meg az írót, hogy mennyire aktív a tábor.
Ez a szakértőzés meg nagyon beakadt neked valamiért; az eszedbe sem jut, hogy minden ami nem mainstream, az egyre inkább a perifériára szorul? Ld. golgota válaszát egyel lejjebb.

Oldschool Computer - http://oscomp.hu

apro es talan lenyegtelen megjegyzesem a temahoz:

* nem egy program minosege dont arrol hogy tartalmazni fogja egy disztro hanem mondjuk a penzugyek. Marpedig a systemd-t karbantartani sokkal egyszerubb a disztro-kat kiadoknak, mint szamos kulon-kulon projektet.

Ez nem jelenti azt, hogy a systemd jol csinalna amit csinal, hanem hogy penzugyileg jobban megeri, mert kevesebb emberorat igenyel a cegeknek, azaz kevesebb penzbe kerul. (bar en ezt is ketlem a bughalmaz miatt, de hat ki vagyok en, hogy ezt megmondjam?) :D 

Na, de ha tegyük fel, hogy Wim hamarabb elkezdte a munkát, akkor ez a folyamat az IBM nélkül is végbe megy. Egyébként az IBM szerintem elsősorban a szerver piacra és a cloud-ra fókuszál, nem hiszem, hogy a desktop és azon belül a multimédia lenne az érdeklődése homlokterében.

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

> Na, de ha tegyük fel, hogy Wim hamarabb elkezdte a munkát, akkor ez a folyamat az IBM nélkül is végbe megy.

A munka hamarább elkezdése irreleváns, mert én nem azt állítottam, hogy az IBM mondta neki, hogy fejlesszen PA alternatívát, hanem azt kérdeztem, hogy vajon lehet-e, hogy az IBM adta ki az ukázt, hogy a PA-t cseréljék le rá, ha már kifejlesztette. Lehet, hogy nem, mert tényleg mindenképpen lecserélték volna, de az is lehet, hogy az IBM takarítani kezdett. Az első felállás is jó hír lenne, mert akkor fejlődőképesek.

> Egyébként az IBM szerintem elsősorban a szerver piacra és a cloud-ra fókuszál, nem hiszem, hogy a desktop és azon belül a multimédia lenne az érdeklődése homlokterében.

Lehet. De az RHEL világ nem csak szerver, hanem desktop felhasználásra is jó. Lehet úgy gondolták, hogy ha már megvették és hirtelen lett ilyenjük, akkor nem ártana, ha a legnagyobb hulladékokat kiszórnák belőle. De ez persze szigorúan csak feltételezés.

Oldschool Computer - http://oscomp.hu

Egyébként a systemd-t szerintem nem fogják, mert túl sokan használják a képességeit. A pipewire ebből a szempontból más. A pulse API nem olyan rossz, abban az esetben a pulseaudio implementáció az, ami fájdalmasan borzalmas. Tehát meg lehetett csinálni, hogy az alkalmazások felé megtartják a libpulse API-t, s csak a szervert írják teljesen újra és illesztik a pipewire-hez. Ez olyannyira így van, hogy a libpulse nem is lett újraírva - bár erre történt kísérlet az elején -, hanem az eredeti pulseaudio féle libpulse az, amit használnak.

A systemd-vel viszont nem implementációs bajok vannak, hanem koncepcionálisok. Az a baj vele, hogy szakít a Unix filozófiával, azzal, hogy egy jól definiált feladatot egy alkalmazás valósítson meg, de azt nagyon flexibilisen, jól. A systemd ezzel megy szembe, nem csak init rendszer, de session manager is, meg ntp kliens is, meg hálózati manager is, meg minden is. Ezen a koncepción viszont nem segít a reimplementálás, megválni viszont nem lehet tőle, mert vannak előnyei is, s ezeket az előnyöket aktívan használják az operációs rendszerek és a fejlesztők.

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

Sok igazság van abban, amit mondasz, de olyan nincs, hogy valamit nem lehet. Ha van kizárólagos előnye a systemd-nek (azaz olyan feature-je, amit más SCS-ek nem tudnak), az nem átemelhetetlen, hiszen a plusz tudásának zéró százaléka származik abból, hogy mindent egybeöntöttek. Egyszerűen csak sokan dolgoztak rajta és sok feature-t implementáltak. Ki lehet bökni valamelyik hasonlóan nagy tudású SCS-t, mondjuk az s6-ot, vagy a nosh-t és el lehet kezdeni felmérni, hogy mi hibádzik belőlük és mennyi munka lenne átemelni. (És zárójelben mondom, hogy ezeknek is megvannak a maguk előnyei, amit meg a systemd nem tud.) Vagy, fel lehet mérni teljesen, hogy mit tud a systemd, hogyan tudja, mi az ami koncepcionálisan törött benne, mi az, ami amúgy használható koncepció és nulláról újraírni, ezúttal nem a PID1-be beleöntve az egészet. (És Poetteringet és Sieverset minél távolabb tartani a projekttől.)

BTW, a systemd-vel implementációs bajok is vannak, nem csak koncepcionálisak; picit feljebb linkeltem be, hogy mennyi bugja van.

Oldschool Computer - http://oscomp.hu

Szervezz magad köré egy csapatot, akikel forkoljátok azokat a csomagokat a Fedora-ból, amiknek systemd függésük van, és pucoljátok ki a systemd-s függést mindegyikből, cseréljétek le a systmed-t tchinit-re :-P csináljatok saját repót ezeknek a csomagoknak, telepítőkészletet, usw. Meg lehet csinálni? Igen. Lehet hozzá erőforrást gyűjteni? Ha tényleg annyi hozzáértőnek nem tetszik, akkor lehet, csak valakinek fel kell vállalnia a szervezést. Akarsz valaki lenni? :-D

Azt arra írtam (csak neked úgy tűnik, nehezen esnek le a dolgok), hogy _valakinek_ fel kell vállalnia egy ilyen systemd-mentes csomaghalmaz forkolását és a karbantartásához szükséges erőforrások összeterelését. Erre írtam, hogy akarsz-e (ez a) valaki lenni? (direkt mindkét "valaki"-t kiemeltem dőlt betűkkel...)

Tekintve, az eddigi diskurzusaink lefolyását és a kiemelt részek áthallásos jellegét, lehet jobb lett volna, ha kiírod, hogy "ez a valaki", mert így nagyon is úgy nézett ki, hogy megint csak szurkálódni akartál. (Ld. még ezt a "leesős" kitételt is.)
A csomaghalmaz forkolására amúgy nincs szükség, mert ezt már több projekt is meglépte, számos systemd-mentes package repository van, elég csak a systemd-mentes Linuxokat megnézni. Itt igazából egy olyan systemd alternatíva kifejlesztése volt a kérdés - márhogy bejátssza-e ezt az IBM - ami tudja azokat a feature-öket, amik miatt a systemd-re esküszők a systemd-re esküsznek. Hogy ezt az s6, a nosh, vagy valamelyik hasonszőrű SCS forkolásával, vagy a NIH elve mentén from scratch oldják meg, az igazából mindegy.

Oldschool Computer - http://oscomp.hu

Ami működik, azt nem kell megjavítani. A RHEL7/8 vonalon pedig működik... Mivel a RHEL8-ban systemd van, amit főverzión belül biztosan nem fognak lecserélni másra (2029Q2 végéig, ha jól tudom), így legfeljebb az évek múlva várható RHEL9 hozhatna újat - de ahhoz nagyon sok melót kéne kukába dobni, amit meg pláne nem fognak. Szerintem...

Csak az a baj, hogy RHEL vonalon sem működik, ők is szívtak/szívnak vele. Egyébként senki nem mondta, hogy holnapra - vagy akár az RHEL9 érkezésére - kell lecserélni; ha az új SCS-t lóhalálában hányják össze, akkor ott vagyunk, ahol a part szakad. A gyors váltás meg a systemd minden bugja ellenére több kárt, mint hasznot hozna a keletkező káosz miatt. Meglátjuk, hogy egyáltalán egy induló tendenciával állunk-e szemben, vagy csak a PA-t dobják el.

Oldschool Computer - http://oscomp.hu

Lehet, hogy ez a ticket konkrétan 2018-as, de az utolsó kommentek ideiek, többen is reklamáltak még mindig a probléma miatt. Az utolsó kettő ugyan a fixálásról szólt, de:

fixed by https://access.redhat.com/solutions/3900301 works like charm after applying it

https://access.redhat.com/solutions/3900301 involves rebooting the server like a cheap PC.

És ha megnézzük a hivatkozott ticketet:

  • Since updating to RHEL 7.6, users need 25 seconds to login and messages such as the one shown below are seen in the journal:
    • [...] dbus[xxx]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out
[...] systemd-logind[xxx]: Failed to enable subscription: Failed to activate service 'org.freedesktop.systemd1': timed out
[...] systemd-logind[xxx]: Failed to fully start up daemon: Connection timed out
[...] systemd[1]: systemd-logind.service: main process exited, code=exited, status=1/FAILURE
[...] systemd[1]: Failed to start Login Service.
  • RHEL 7.6 periodically doesn't boot properly because polkit.service and tuned.service fail to start. This happens about 1 in 10 to 20 boots.

    • Tehát a probléma még csak nem is egyértelműen reprodukálható, mert stochasztikusan 10-20 bootonként egyszer jelentkezik.

    Oldschool Computer - http://oscomp.hu

    javistsunk ki mindent a vilagban, hogy a systemd jol mukodjon es kesz. :D

    Emlekszem egy ticketre, amikor a systemd-resolved megette az 53-as portot es kesz. Egyik sajat fejlesztoje csinalt is ra egy bugot. Pottering azt irta erre, hogy javistak ki a dns szervereket!!! A fejleszto szepen elmagyarazta neki, mint a reszeges apukanak, aki belepisalt az eloszobaszekrenybe, hogy mi is a baj. Szerencsere kepes volt felfogni. A srac javitotta, de par DNS szerver akkor sem ment, Pottering valasza: javistak ki a DNS szervereket!!! 

    Hat persze...muhahahaha

    Van egy (itt kettő) szolgáltatás, ami vagy elindul jól, vagy nem. Nomostan ha létfontosságú a szolgáltatás, akkor kezelje már le rendesen, hogy nem indult el, és legyen fallback, ha nem működik - például a PolicyKit... De ugyanez pepitában a NIS-es dolog is, aminél az rpcbind unit fájlt kellett megmókolni, hogy jó legyen.
    ha egy initscript sz@rul van megírva, vagy az abból indított motyó hibnásan indul el, akkor a scriptet futtató parancsértelmező a hibás?

    Ha a unit fájl van szarul megírva, vagy maga a szolgáltatás bugos, akkor az nem a systemd hibája.
    Viszont ha a unit fájl rosszul van megírva, az mindig rossz működést eredményezne, hiszen szarul paraméterezik fel a szolgáltatást, tehát stochasztikus start-fail esetében a unit-errort kizárhatjuk.
    A szolgáltatás pedig el sem indul, tehát ami bugja nem a startup részében van, az nem is játszhat közre, ami bugja meg esetleg a startup részében van, az meg mindig crasht eredményezne, ha azonos paraméterekkel indítod.
    Ennek megfelelően itt a hiba forrása kívülről jön. Lehet, hogy egy nem várt - és le nem kezelt - külső esemény miatt nem tudja elindítani őket a systemd. Ez azonban nem az el sem indult szolgáltatások hibája. A rendszer indulási mizériáinak reboottal történő javítása pedig nem lehet megoldás egy szerveren.

    (Kivételt képez az, ha valami hardwarehiba van a háttérben, vagy, ha egy harmadik software belekontárkodik a folyamatba. Ilyenkor sem a systemd, sem a szolgáltatás hibája. De ez lokális jellegű probléma, nem jelentkezhet egyszerre N helyen...)

    Oldschool Computer - http://oscomp.hu

    Tudom. De a párhuzamos indítás pláne kívül esik a szolgáltatások szkópján, mert azt maga a systemd intézi, tehát ha ott race-fail lenne, az csakis a systemd sara lehetne. De ha függőségi probléma miatt nem tudna elindulni a szolgáltatás, akkor a systemd ezt jelentené. Vagy legalábbis gondolom, hogy jelentené...

    Oldschool Computer - http://oscomp.hu

    Nem. En itt nem rossz unitfuleokrol beszelek. Hanem arrol, hogy Pottering szerint a DNS szervereket (pl. bind) meg kell fixalni hogy a megfeleloen mukodjenek, hogy ne utkozzenek a systemd-resolvd (akkori) faszsagaival. Most nincs kedvem megkeresni a ticketet, de gyonyoruen elmond mindent Potteringrol, ahogy eloszor kezelte a problemat. A systemd-s dev srac tok normalis volt es javitotta a systemd-resolvd fasz mukodeset, de Pottering eloszor be sem akarta fogadni, mondvan hogy won't fix. 

    Szoval itt nem is asystemd-resolvd a gaz, hanem ahogy ez kezelve volt a nagy Pottering altal. Azota is van par DNS szerver amit jobb ha nem futtatsz ott, ahol bekapcsoltad a systemd-resolvd-t a szervereden. :D

    Erdemes neha beleolvasni egy-egy ticketbe hogy az ember sirva rohogjon.

    ( locsemege v | 2020. 11. 30., h – 17:41 )

    Tisztelt Egybegyűltek! Ez a topic a PipeWire multimédia sharing szerverről szól, nem pedig a systemd előnyeinek és hátrányainak megvitatására szolgáló hely.

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

    Mármint a systemd-vel nem volt szétoffolva. Mert ha szigorúan vesszük, a pulse is off, mert ugyan lehet, hogy azt váltja és az még csak-csak related, hogy miben jobb a PW, de az már off, hogy a pulse-nak milyen önálló gyíkjai vannak...és a pulse fikázását biza te inicializáltad. ;) (Na, nem mintha nem értett volna benne egyet a fél közönség. :] )

    Oldschool Computer - http://oscomp.hu

    Bármiről lehet beszélni egy fórumon. A pulse abszolút related, hiszen a pipewire részint pulse API-t használ, illetve a pulse szervert implementálták újra. Szóba kerülhet a systemd is, hiszen ez indítja - vagy indíthatja - a pipewire-t. Az zavart, hogy szenvedélyes vita kezdődött a pipewire multimédia sharing szerverről szóló topicban arról, hogy miér nem jó a systemd, ha jó, akkor miben jó, Poettering meg bekaphatja, stb. Ez már elviszi a fókuszt, köze nincs a pipewire-hez, annak működéséhez.

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

    ( ricsipontaz | 2020. 12. 03., cs – 20:40 )

    Ubuntun már próbálta valaki? Bluetooth hogy áll? Itt is használhatlan videóhívásra a BT füles a hangminőség miatt, mint Pulseaudion?

    ( locsemege v | 2020. 12. 19., szo – 00:17 )

    Majd' elfelejtettem. Van már 0.3.18, illetve azóta egy csúnya memleak is javításra került.

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

    ( Alucard | 2020. 12. 21., h – 14:43 )

    Raspberry Pi Arch alatt vannak mar tapasztalatok?

    Arch Linux [Sway WM]

    Most van egy kis idom szoval elvileg mukodik, gyakrlatilag meg nincsen hang :D pedig:

    $ > pactl info
    Server String: /run/user/1001/pulse/native
    Library Protocol Version: 34
    Server Protocol Version: 34
    Is Local: yes
    Client Index: 56
    Tile Size: 65496
    User Name: alucard
    Host Name: rpi4
    Server Name: PulseAudio (on PipeWire 0.3.21)
    Server Version: 14.0.0
    Default Sample Specification: float32le 2ch 48000Hz
    Default Channel Map: front-left,front-right
    Default Sink: alsa_output.platform-fef05700.hdmi.iec958-stereo
    Default Source: alsa_output.platform-fef05700.hdmi.iec958-stereo.monitor
    Cookie: d769:1a3b

    A vas egy RPI4 fedélzetén egy Arch Sway WM-el. WIKI szerint kell neki a xdg-desktop-portal-wlr csomag aminek a telepitese megtortent, illetve az XDG_CURRENT_DESKTOP-ot betoltam az /etc/environment-be.

    Egyelőre itt tartok :)

    Arch Linux [Sway WM]

    alsa_output.platform-fef05700.hdmi.iec958-stereo

    Valóban ezen a lyukon várod a hangot? A beállításokban a pavucontrol lesz a segítségedre, jó eszköz még a pasystray. Ha esetleg forrásból fordítanád, tedd fel az SDL2-devel csomagot is hozzá. Ha systemd-t használsz, egy új verzió telepítése után az adott grafikus session-ön belül - tehát nem ssh-n - az alábbit érdemes tenni:

    systemctl --user daemon-reload
systemctl --user restart pipewire-pulse.socket pipewire.socket

systemctl --user status pipewire-pulse.socket pipewire.socket
systemctl --user status pipewire-pulse pipewire

    Az utóbbi két sor inkább ellenőrzés. Nézhetsz várakozási időket, foglaltságot a pw-top paranccsal. Restartnál a daemonokat nem kell újraindítani, mert a socketek újraindítása egyben triggereli a daemonok újraindulását is.

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

    Noh, megint akadt egy kis időm foglalkozni a témával. Szóval ha indítok egy mpv-t ott teljesen jó a hang :) hurrá! :) ebből arra következtetek, hogy a böngészőkkel van valami baja őkelmének.

    Terminálból indítva Chromium elég szűkszavú:

    [7208:7208:0218/161151.830753:ERROR:pulse_util.cc(343)] pa_operation is nullptr.

    Kicsit googlizok, aztán ha nincs solution akkor még lehet jövök :D

    Arch Linux [Sway WM]

    Nekem Arch és Artix alatt van vele rövid távú tapasztalat, már ha lehet azt annak nevezni, hogy fent van a rendszeren, kernelmodulok be vannak hozzá töttve, de konkrétan nem használja nálam semmi, minden pulseaudio-val megy. Így persze bugot se tapasztalok. Csak úgy fent van a rendszeren, megjött a frissítésekkel és új kernellel. Azzal még nem játszottam, hogy ténylegesen is használatba vegyem és kikényszerítsem, hogy valami is használja.

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

    ( locsemege v | 2021. 01. 05., k – 22:57 )

    Szerkesztve: 2021. 01. 20., sze – 17:23

    0.3.19

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

    ( BehringerZoltan | 2021. 01. 18., h – 00:00 )

    Próbálgattam ma a zongorás gépen. A célom az lett volna, hogy Pulse Audiot eltávolíthatóvá tegyem, de mehessen egyszerre a zongi [Jack] és a YT browserből. Ugye ezt idáig a PA oldotta meg. Annyi működött most, h ment a hang a Yt-ról a böngészőből a PA nélkül. Azonban Jack-et nem engedte egyidejűleg hozzáférni a kártyához, csak h az eredeti jacklibek helyett a PipeWireos Jack libeket használta. Viszont akkor azokkal a beállításokkal indítja el amit a PIPEWIRE_LATENCY változóban állítok be, és nem azokkal amik a qjackctl-ben vannak beállítva. Lényegében nekem külön beállítások kellenének a latencyt illetően a zongihoz és a YT-hoz. További gond volt h jackdbus nincs implementálva és emiatt a session kezelők Claudia; Gladish el sem indulnak. Forrásból tettem fel Ubuntura, és máshova pakolta a dolgokat, mint a doksi írta. Kellet kissé nyomozni, h mi hol van. Végül most leszedtem, de majd próbálgatom még. 

    "antiegalitarian, antiliberal, antidemocratic, and antipopular"

    ( hajbazer v | 2021. 01. 18., h – 01:58 )

    Szerkesztve: 2021. 01. 18., h – 01:58

    Újrafeltalált kerék, kitől mástól, mint a Red Hat-tól.

    Akinek enterprise Linux vendorként semmi más dolga nem lenne, mint a jelenleg elérhető szoftvereket stabilan összeboronálni és karbantartani. Csak épp ezek pont nem az erősségei.

    Ez is ugyanazokkal az ígéretekkel indul, mint a PulseAudio és előreláthatólag ugyanazzal az igénytelenséggel lesz lefejlesztve, több évig bennmaradó bugokkal, feature ágas felhasználókon való bétateszteléssel és egyéb arrogáns módszerekkel megfűszerezve.

    Én bizakodóbb vagyok, pont azért, mert egyszer már próbálkoztak, így (remélhetőleg) ismerik már, hogy milyen hibákat kell elkerülniük. A fejlesztője sem Poettering-szemléletű.
    Újrafeltalált keréknek sem mondanám, tekintve, hogy ilyen célú ÉS architekturálisan nem elrontott szoftver nincs jelenleg ezen kívül.

    Psszt, elárulom az IP-címemet: 192.168.0.14

    Nem Poettering az egyetlen szélsőségesen idealista feljesztő a Red Hat-nál, csak arroganciája és a Linux-világ felforgatása révén ő a legismertebb.

    Vannak még jónéhányan.

    Peter Hutterer, a csotrogánnyá butított, újrafeltaláltkerék libinput fejlesztője, aki nem a (már deprecated) synaptics driverrel tökéletesen működő circular scroll-os laptopok használhatatlansága miatt aggódik, hanem amiatt, hogy mennyit kellene a libinputon módosítani, hogy beleférjen egy circular scroll, és ehhez mennyi tesztet kéne írnia. Egy olyan dolog, ami a leváltott synaptics-ban alap volt, és még mindig készülnek ilyen laptopok. Magyarul a saját lustasága, kényelmeskedése miatt aggódik, illetve hogy kurvára elfelejtette feature-paritással újrafeltalálni a kerekét és erre utólag, a felhasználók kell felhívják a figyelmet. [1]

    Matthias Clasen, GTK3-lead fejlesztőcske, akinek többnyire a minor verziók közti API-törések tömkelegét és a GTK3-témák utánhúzogatása által felemésztett többezer elpocsékolt munkaórát köszönhetjük világszerte.

    Emmanuele Bassi, akinek többek között köszönhető a GTK3 File Chooser rekurzív keresésének (korábban Alt-S) kötelezővé tétele, ami egyrészt felesleges I/O bloat, másrészt súlyos privacy-t érintő kockázat (osztott képernyőnél, előadásnál), harmadrészt nem lokális (vagy lassabb, HDD-s) fájlrendszereknél használhatatlan, negyedrészt a felhasználói szabadság lábbal tiprása, a kikapcsolhatatlansága miatt. Természetsen, hallani sem akar a kikapcsolhatóvá tételéről, a merge requesteket ignorálja, szélsőségesen idealista, lépjtovább, feljődésmániás indoklással. [2]

    we don't want typeahead. It's dead. It's pining for the fjords. It's an ex parrot.

    Ha ennyire hülyének tartod őket, és ennyivel okosabbnak magadat, miért nem pályázol hozzájuk, jól megmondani, hogy hogyan kell tervezni fejleszteni? Amilyen nagy szakmai tudásról és tapasztalatról meg kompromisszumkészségről tettél eddig itt tanubizonyságot, simán felvennének fejlesztési főatyaistennek.

    Mert soha nem volt vágyam egy arrogáns multinál dolgozni.

    Mert fejétől bűzlik a hal és az, hogy ezek ott lead fejlesztők lehetnek, egyvalamit jelent: olyannak kell lennem, ami én zsigerből nem vagyok (szélsőségesen idealista, fősodratú, elitista mérnök úr).

    Ha ennyire hülyének tartod őket, és ennyivel okosabbnak magadat

    https://a.te.ervelesi.hibad.hu/szalmabab

    Nem tartom magam okosabbnak és nem is mondam ilyet, csak te akarod rámolvasni, hogy könnyebben beleköthess a véleményembe. Csak véleményeztem a munkáikat, amik megannyi bosszúságot okoznak a Linux-világnak és ezért semmilyen szempontból nem tekinthetőek jó minőségű munkának. Ez nem feltétlenül a hülyeségüknek, inkább a rossz döntéseik sorozatának köszönhető.

    "Mert soha nem volt vágyam egy arrogáns multinál dolgozni." - pedig a habitusoddal beleillenél egy tetszőleges arrogáns társaságba... Sőt. te lennél a vezérökör. (csak véleményeztem a hup-os minkásságodat)

    "Nem tartom magam okosabbnak és nem is mondam ilyet," - Mindenkiről, aki nem te vagy, olyan lesújtó véleményt alkotsz, hogy tisztán következik belőle, hogy magadat mindenkinél okosabbnak és nagyobb tudásúnak tartod.
     

    pedig a habitusoddal beleillenél egy tetszőleges arrogáns társaságba

    Bagoly mondja, user error huszár multimosdatókám. Bagoly mondja.

    Mindenkiről, aki nem te vagy, olyan lesújtó véleményt alkotsz, hogy tisztán következik belőle

    Ezt te így következteted ki, tévesen, a szélsőségesen idealista, szűklátókörű skatulyalogikáddal. Ettől persze még nem igaz.

    > Akinek enterprise Linux vendorként semmi más dolga nem lenne, mint a jelenleg elérhető szoftvereket stabilan összeboronálni és karbantartani.

    Már miért lenne csak ez a dolga? Most lendüljünk már túl azon, hogy még mindig nem a te tiszted megmondani, hogy kinek mit kellene csinálni, de az opensource nagy részét bizony olyan cégek csinálják, mint pl az RH, nem random gyerekek apa pincéjében. És az RHnak általában egész jól megy, hogy valóban opensource szellemben csináljon dolgokat.

    > Csak épp ezek pont nem az erősségei.

    Hát pedig de, ez pont kifejezetten jól megy az RHnak

    >  feature ágas felhasználókon való bétateszteléssel

    1. A feature ág pontosan ezt jelenti: kapod a friss fejlesztést, korán gyorsan

    2. Mi is az open source mantra? Ja, igen. Release early, release often.

    Már miért lenne csak ez a dolga?

    Mert egy enterprise-disztróért elsősorban a stabilitásért és a kiszámíthatóságért fizetek. Nem azért, hogy kísérleti nyúl legyek. Ha a Red Hat semmi mást nem csinálna, mint meglévő open-source projekteket simítana össze, sokkal jobb Linux-világot élnénk, systemd, pluseaudio, gtk3, libinput, avahi-daemon stb. nélkül.

    Hát pedig de, ez pont kifejezetten jól megy az RHnak

    Ja, azért kellett szarrátörni mindent a systemd-vel, a pulseaudioval, a gtk3-mal 2-3 éven keresztül, még a saját API-jukat is.

    Release early, release often.

    Ez eredetileg a Linux-kernelfejlesztők mantrája, nem a teljes open-source közösségé. Később az agilis módszertant alkalmazó multik babzsákfejlesztői járatták csúcsra, csakhogy ők a mai napig nem rendelkeznek sem azzal a kompetenciával, sem azzal a mögöttes szemléletmóddal, amivel a Linux-kernelfejlesztők.

    > Mert egy enterprise-disztróért elsősorban a stabilitásért és a kiszámíthatóságért fizetek.

    Először is, szögezzük le, hogy ha kicsit is önazonos vagy, akkor ezért se fizettél sose egy fityinget, csak a partvonalról pofázol. Szóval fogalmad sincs arról, hogy tulajdonképpen miért fizet egy enterprise distro vevője. És bár ezek fontos pontok, a kérdés messze nem ennyire egyszerű. Pl egész sokat nyom a latban, hogy az enterpise bajaimra legyenek benne megoldások, szóval nem egy olyan elrugaszkodott gondolat, hogy a hiányzó lukakat a vendor megpróbálja betömni. Egyébként pedig:

    >  Nem azért, hogy kísérleti nyúl legyek

    Ja kérem, ha hajlandó lennél fizetni, akkor tudnád, hogy ilyen major izéket nem hoznak főverziók között. Azt is tudnád, hogy pl a systemdre átállásra még most is van időd 2024ig, addig lehet ugyanis extended supportal RHEL6ot csinálni. Ha esetleg nem lett volna elég időd kiszámítani az elmúlt ~10 évben, amióta a fedorában (tudod, a valódi kisérleti nyulaknál) default, vagy az elmúlt ~7-ben, amióta a firssebb RHEL már azzal jön. Mire a 2024 eljön, egy systemdvel szálított főverziót (7) már biztosan kihagyhatsz, és mivel egyrészt historikusan látszik, hogy 4-5 évente van release, másrészt jelenleg a 8 full support dátumának vége szintén 2024, csak kicsit korábban, mint a fenti, ezért jó esélyed van rá, hogy akár azt is kihagyhasd, és egyből a 9esre menj, szóval 2 releaseben lehettek mások a kísérleti nyulak. Ja, az RH nem kiszámítható.

    >  sokkal jobb Linux-világot élnénk, systemd, pluseaudio, gtk3, libinput, avahi-daemon stb. nélkül.

    Maradjunk abban, hogy szerinted.

    > Ez eredetileg a Linux-kernelfejlesztők mantrája, nem a teljes open-source közösségé. Később az agilis módszertant alkalmazó multik babzsákfejlesztői járatták csúcsra

    Hát, az igazi opensource projektek nem nagyon tudnak agilis módszertanok mentén fejlődni. Mármint azok, amik a "közösségé" és nem igazából valamelyik cég adományai. Pl mert nincs nekik főnökük, össze vissza ülnek, meg foglalkoznak vele, illetve mert nem igazán van okuk, hogy igyekezzenek az üzleti igényeket kielégíteni. Ezzel együtt, bár a mantra a kernel fejlesztőké, in practice így működött ez azokban a régi szép napokban a legtöbb dologgal :)

    Ezt az álláspontod kivételesen megint osztom. A Red Hatnak nem kéne ilyesmikkel előhozakodnia, már így is elég kárt okozott a Linuxnak a systemd-vel meg a pulseaudio-val. De pont azért, mert nagy cég, nem akar csak egy közönséges, n+1. összerakó vendor lenni, hanem aktívan bele akarnak szólni a linuxos inftrastruktúra fejlesztésébe, fejlődésébe, hogy ne őnekik kelljen igazodni a többiekhez, hanem a többiek igazodjanak hozzájuk, pont ezért dolgozik be a kernelbe a MS is, meg egy csomó más nagy cég, nem szívjóságból, meg piárból. Ennek mentén meg igyekeznek mindenből újra feltalálni a kereket. Próbálnak belőle egyfajta alternatív Windowst vagy alternatív MacOS-t gyúrni, amit nagyon nem kéne. A Linux addig volt jó, amíg magánhobbisták reszelgették maguknak, és igyekeztek a rendszer erőforrásait és átláthatóságát szem előtt tartani, az egyszerűséggel és a Unix-filozófiával egyetemben, igaz sokkal kevesebb dolgot is támogatott, de azt normálisabb minőségben. És nem csak a Red Hat, hanem a Canonical is ilyen, ők is rendre fel akarták találni a kereket, sysvinit helyett upstart, X.org és Wayland helyett Mir, Gnome2 helyett Unity (ami bukta lett), most jelenleg a Snap-bloatjaikat erőltetik bele a rendszerbe, hogy minden Snap legyen, ne natív .deb csomag, korábban meg az amazonos spylinkeket, ami a keresési eredményeket küldte az Amazon felé. Jobb lenne, ha ezeket a törekvéseket feladnák a multik, nem kell a Linuxból Windowst meg MacOS-t csinálni, arra már ott van ez a kettő, aki olyan szutykokat akar, az használhatta őket eddig is.

    És a systemd-vel meg a pulseaudio-val nem is az a baj, hogy van, meg hogy miilyen feature-ókkel és minőségben van implementálva, mert akinek erre van igénye, az használja felőlem, egyel több alternatíva. De ehelyett nem alternatívának van kezelve, hanem minden rájuk dependel, és ezzel rá vannak kényszerítve mindenkire, igaz ez nem a systemd, pulseaudio, Poettering meg a Red Hat hibája, hanem a sok szűk látókörű fejlesztőké, akik kényelemből rádependelik ezekre a szoftvereiket, holott senki nem kötelezi őket rá. Itt van a legnagyobb gond ezekkel az újrafeltalált innovációkkal, a multik csak elkezdik, de ha a fejlesztők nem harapnának rá, elhalnának ezek a corporate bloatosíási kísérletek.

    Ugyanez van az okostelefonoknál is. A Google az Androiddal az iOS-t másolja, az Apple nem enged SD kártyát, meg cserélhető akkut, a többi gyártó se engedi, az Apple elhagyja az audiojacket és bevezeti a notcht, a többi gyártó is azonnal másolja, nem ad töltőt a teló mellé, nem ad a többi se. Ilyen egy hülye a kútba ugrik, a többi ész nélkül ugrik utána, mert az a sikk. Vagy a laptopgyártók, akik szintén mindenben az Apple Macbookját utánozzák, vékonyságban, csatik szegényítésében, minden odaforrasztva, nem cserélhető, nem upgrade-elhető, stb.. Közben meg nem az Apple-t kéne utánozni, hanem egyedi alternatív innovációkkal jönni, és ezen nem a hajlítható meg összhajtható kijelzős baromságot értem, hanem hasznos feature-öket.

    És még mielőtt valaki azzal jönne, hogy sánta párhuzamokat írok, mert a Linux meg a Red Hat nem Apple, csak úgy mondom, hogy a systemd-t és a pulseaudio-t pont hogy a MacOS-ből leste el Red Hat és Poettering, azokat próbálták lekoppintani. Tehát a lejtőn a dolgokat itt is az Apple indította el igazából, szerintem a legkárosabb IT cég ever, pedig ezért a címért erős versenyben vannak még a MS, Google, Oracle, stb. is. De említhetném a Gnome-ot is, ami szintén a MacOS-t próbálja utánozni, vagy a flat dizájnosítást, tabletesítést, amit megint a MacOS-ből, meg iOS-ből próbáltak áthozni, az iPad és iPhone-ok sikerén felbuzdulva, erre a hájpvonatra még a MS is felszállt a Win8 Metro/ModernUI-jal, Surface-termékvonallal, meg egyfelé felület minden eszközre, mobilra és desktopra is, ami még a Win10-ben is érezteti a hatását. A MS szintén a MacOS-t utánozza, hogy egyféle OS főverzió legyen (ala Win10), de az félrolling alapon frissítve.

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

    " De ehelyett nem alternatívának van kezelve, hanem minden rájuk dependel," - Talán mert látják az előnyeit...? Erre még nem gondoltál? Ha és amennyiben tényleg annyira sz@r lenne, nem hiszem, hogy értelmes, nálam és nálad is vélhetően jobban képben lévő fejlesztők/architect-ek nem ebbe az irányba mennének. Igen, tudom, a prutymutyix disztró nem systemd és nem pulseaudio, sőt a mutyitrutyix sem, meg... Melyik nagy mainstream sorolható még ide?

    Erre még nem gondoltál? Ha és amennyiben tényleg annyira sz@r lenne, [...] irányba mennének. 

     

    Lehetene erre azt mondani, hogy 10 milliárd légy, de én is azt gondolom, hogy ha tényleg annyira szar lenne, akkor az "extraprofit maximalizálás" miatt rég ki lett volna már dobva, legkésőbb RHEL8-ra.

    Ha ennek az előnyei kellenek, használj MacOS-t. Abban már eleve egy olyan initrendszer és audio-alrendszer van, amiről a systemd-t és pulseaudio-t koppintották, épp ugyanazokat az előnyöket fogod élvezni. Ezt nem kell még egyszer kitalálni, meg a Linuxra kötelezően rátolni, akinek erre van igénye, az használ Mac-et, eddig is tudott már évtizedek óta. Épp így, akinek DRM-re, meg registryre, meg 4 vírusirtóra, 5 tűzfalra, mindenféle bloat absztrakcióra van igénye, az eddig is tudta használni Windows alatt, nem kell újra feltalálni Linux alatt, hogy abból is Windowst csináljanak. Arra már ott a Windows, azt kell feltenni, bárhol kapható, akár 5 dollárért is az eBayen lehet hozzá venni egy használható kulcsot, és lehet nyomatni, széleskörű driver és szoftvertámogatása van, határozatlan idejű support van rá, stb..

    A systemd-mentes disztrókkal meg az a baj, hogy hiába nem systemd az initrendszer bennük, épp úgy fut alattuk az elogind, libszutyokd, poetteringd, (esetleg apulse), mivel a csomagok meg rá vannak dependelve, és futtathatóak kell maradjanak, így lényegében a systemd egyes alrendszerei továbbra is futnak a háttérben, és a user csak saját magát hülyíti, hogy nem systemd-t, meg nem pulseaudiót használ, közben meg dehogynem.

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

    "a Linuxra kötelezően rátolni," - Nem kötelező, lehet saját, ezek nélküli forkot csinálni. Mainstream nem lesz belőle, az igaz, de ennyi.

    "épp úgy fut alattuk az elogind, libszutyokd, poetteringd, (esetleg apulse), mivel a csomagok meg rá vannak dependelve" - Jaaa, hogy sok-sok munka lenne midnent is átírni saját kedv és igény szerint... Ha megfelelő nagyságú fejlesztői és felhazsnálói bázist szedsz össze, menni fog. Nem azonnal, de mit számít 4-5-10 vagy több év, ha azzal a világot is megváltod...

    épp úgy fut alattuk az elogind, libszutyokd, poetteringd

    Azért ne essünk át a ló túlsó oldalára sem: attól még, hogy valamire ránézett Poettering, még nem válik rögtön patás ördöggé. A systemd-vel az a probléma, hogy a) egy hatalmas, monolitikus rendszer, b) PID 1-ként fut, tehát össze tudja dönteni az egész rendszert. Ezek egyike sem igaz az elogind-re.

    Psszt, elárulom az IP-címemet: 192.168.0.14

    Itt a környéken zeller kollégával értek egyet. Azért dependálnak rá a software-ek, mert egy jó API lett kitalálva. Az más kérdés, hogy a Pulseaudio implementáció vacak. Viszont a PipeWire egyik API-ja teljes egészében pulseaudio API. Olyannyira, hogy a kliens library-t nem is írták újra, az marad a pulseaudioé.

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

    Az más kérdés, hogy a Pulseaudio implementáció vacak.

    Tehát ha odaszarok a tányérra, tortát formálok belőle és ráírom, hogy ehető, akkor megeszed.

    A vacak implementáció, az instabil működés, a seregnyi bug, aminek egy része mai napig javítatlan, a sok tízezer debugolással, konfigolással töltött munkaóra mind-mind önmagában is egy nyomós érv a pulseaudio ellen. Ha ezt nem a Red Hat erőltette volna az ipari befolyásával, akkor már rég a süllyesztőben lenne - ahová való.

    Ugye, nem erősséged a programozás, csak szeretsz írni hülyeségeket? Elég szorosan követem a projectet, segítek a fejlesztőknek, egészen mást gondolok erről, mint te. Ettől persze még bátran írhatsz sületlenségeket, elvégre alanyi jogod. :)

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

    Pedig én örülnék a legjobban, ha nem lenne igazam.

    Elég szorosan követem a projectet, segítek a fejlesztőknek

    Akkor tietek a pálya! Cáfoljatok meg!

    Ne mondhassák 5 év múlva, mikor multiék már beleerőltették ezt is minden disztróba, hogy "hajbinak igaza volt".

    Nem erőltette a pulseaudio-t sem senki, viszont annak örülni fogok, ha minden Linux disztribúció multimédia sharing szervere - tehát a hangszervere is - a PipeWire lesz. Nem kényszerből, hanem mert jó.

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

    Egyrészt, ez önmagában épp elég baj vele.

    Másrészt, olvasgasd: http://web.archive.org/web/20140909093139/http://boycottsystemd.org/

    Vannak itt azért bőven szakmai érvek. Más kérdés, ha téged ezek nem érdekelnek, de ettől még corporate erővel lett torkokon lenyomva a systemd és továbbra is biztos vagyok benne, hogy ha Poetteringnek ez egy házi barkácsprojektje lett volna úgy, hogy nem a Red Hat-nál dolgozik, akkor most nem lenne systemd.

    ( mogorva v | 2021. 01. 18., h – 09:35 )

     De ehelyett nem alternatívának van kezelve, hanem minden rájuk dependel, és ezzel rá vannak kényszerítve

     

    Hát nem tudom, tarts te karban és supportálj gazdaságosan 2-3-4 féle init rendszert.

     

    az Apple nem enged SD kártyát, meg cserélhető akkut, a többi gyártó se engedi,

     

    Ez pontosan hogyan történik? A Xiaomi nagyon szerette volna, de az Apple odament és kést szorított a torkához? Ezt látva a Samsung meg inkább csöndben megette a kapcsolási rajzokat, amik a saját cserélhető SD kártyás megoldásához kellettek volna? 

    Nem lehet, hogy ez megint csak arról szól, hogy spórolnak 50 centet, de akkora tételben már számít és ha másoknál benyelték a felhasználók, akkor nekik nem kell erőlködni?

    Nem kell nekem 3-4 féle initrendszert fenntartani és támogatni. Azt megteszi minden initrendszerrel a saját fejlesztőgárdája. A lényeg, hogy nem kell a szoftvereket a systemd-re dependelni, és egyből szabadon cserélgethető lesz az initrendszer alatta, nem kell semmilyen extra támogatás semmihez. Ahogy pl. most X.org szerveren bármilyen WM-et le tudsz cserélni bármi másikra, épp úgy futnak az X-es programok, meg még Wayland protokollt használó WM/kompzitor alatt is XWayland emulációval, ilyen rugalmasnak kéne lennie az initrendszernek is. Hangrendszernek nem különben, ha minden sima ALSA-t használna, akkor mindegy lenne, hogy ALSA fut, vagy Pulsaudio is fölötte, vagy PipeWire.

    Az SD kártya, akku csak egy példa volt. Pont ezt írom én is, hogy senki nem tart kést senki torkához, egy hülye multi (tipikusan Apple) elkezdi a baromságot, a többi meg önszántából megy utána, mert kényelmes, meg az a cool, az a jövő. Közben meg egy nagy lila-kék-eres bránerség, de hájpolni kell, mert Apple. Ahogy pl. Poettering se kényszerít senkit, hogy a systemd-t vagy a pulseaudio-t használja, mégis rá dependelnek minden szutykot.

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

    ha minden sima ALSA-t használna, akkor mindegy lenne, hogy ALSA fut, vagy Pulsaudio is fölötte, vagy PipeWire.

    Ami csak azért nincs így, mert a pulse API lényegesen többet tud, mint az alsa API. Az egy dolog, hogy van a pulseaudionak és a pipewire-nek is alsa interface-e, de ez a fallback, ha úgy tetszik, csökkentett mód. Ráadásul éppen azért, mert van a pipewire-nek - és a pulse-nek is - alsa interface-e, kívánságod teljesült. Azt meg hadd döntse el az alkalmazás írója, hogy beleteszi az alsa és a pulse illesztést is, mint pl. az audacious-ban, vagy csak pulse interface-re illeszt, mert jó, kényelmes, egyszerű.

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

    pont irni akartam, hogy nalam jobban csak kevesek utaljak a systemd-t szivbol, de annyira azert nem vagyok hulye hogy ne ertsem meg, hogy miert terjedhetett el, akarcsak a pestis a kozepkorban. :D

    A disztributoroknak nem millio kis szart kell supportolni hanem csak egy nagy osszehanyt valamit

    A fejlesztoknek eleg egy valamire dependalniuk es nem kell millio programhoz illeszteniuk a termekuket, hogy mukodjon soundA-val meg soundB-vel meg loginA-val es loginC-vel, hiszen ott a systemD, ami mindent is tud, megha esetleg szarul is. Majd azt javitjak, de a sajat programmal nem lesz  gond. Ha csak a systemd nem tor el valamit, de az akkor is csak egy lehetseges tores es nem sok kis termek permutacioja :D

    Ettol meg nem fogom szeretni :D Szeresse az akinek penze van belole, hogy emiatt 20%-al kevesebb fejleszto beret kell kifizetnie :D  

    A disztributoroknak nem millio kis szart kell supportolni hanem csak egy nagy osszehanyt valamit

    Ezt sose értettem. Egy adott disztró választott (presystemd időkben) valamilyen init-rendszert, és ahhoz az egyhez gyártotta a az indítófájlokat. Miért kellene milliót szupportálni?

    fejlesztoknek eleg egy valamire dependalniuk

    Ez is szerintem így működött a premindenegységesésnagyonjó időkben. Minden program készítője kiválasztotta, hogy milyen hang- és grafikus rendszert, konfigfeldolgozó rutint, buildrendszert, stb. használ, és azt alkalmazta. Ha valamelyik disztró ezt a programot érdemesnek találta, készített hozzá és a (hiányzó) függőségeihez csomagot.
    Nyilván minél egyformábbak a programok igényei, annál kevesebb csomagot kell karbantartani - cserébe a választás és a változatosság lehetősége veszik el.