Megjelent a GNU Shepherd 1.0.0

FSF/GNU/GPL

Bejelentés itt.

( Zsugabubus | 2024. 12. 10., k – 14:51 )

Ajjaj, ezzel a Lisp-es szintaxissal nem tudom, fognak-e barátokat szerezni.

A Lisp-nek nem a szintaxisával van baj, hanem hogy kicsit bloat, de annyira nem vészes, mint egy Java.

Ennek a Shepherd-nek így sem a Lisp a baja, hanem sok ponton nem követi a unixos szabványokat, kicsit ilyen kerék-újrafeltalálásos megoldás.

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

Azért kvázi van, nem csak zárójelekből áll, be kell tartani a RPN jelölést, meg vannak azért foglalt nyelvi szavak, pl. defun, if, list, nil meg hasonlók, így azért valami nagyon kevés szintaxisa van, sőt, még ennek számít, hogy a zárójelek lezárására is ügyelni kell, ami nem kis kihívás, ha durva mélységben vannak egymásba ágyazva. Amit mondani akartam, hogy interpretált nyelv, emiatt a teljesítménye a Pythonhoz hasonlóan nem a legjobb, bár talán nem is annyira szar, de pl. egy JIT-es Perl, Lua, meg natív C, C++ bináris szintjét nem üti meg. Emiatt számítani kell rá, hogy több erőforrás kell neki, de ez a helyzet a legtöbb klasszik funkcionális nyelvvel, a Haskell pl. fordított, de ott is számítani lehet többlet erőforrásokra.

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

Perspektívába helyeztem csak a dolgokat, írtam példának nálánál gyorsabbat és lassabbat is, így el lehet helyezni. A lényeg lényege, hogy a Lisp nem arra való, hogy teljesítménycentrikus alkalmazást írjanak benne.

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

Nem kell mindjárt mellre szívni fórumtárs! Amiket írtál, az alapján nekem olybá tűnik, hogy nem túl frissek a Lisp nyelvvel kapcsolatos információid. Természetesen mikor Lisp-ről beszélünk, elég sokféle implementáció létezik. A leginkább "ismert" és fejlesztett talán az SBCL. De létezik belőle fizetős is pl.: LispWorks, bár ennek is van hobbi és nem üzleti felhasználásra ingyenes verziója, kisebb korlátokkal. Ott a Clojure, ami ugye JavaVM-en megy. És még sorolhatnám napestig. Természetesen mindegyiknek megvannak az erősségei és a gyengeségei is.

Ha nagyon érdekel, szerintem te is találsz olyan forrásokat, ahol összehasonlítják más nyelvekkel is.

Azért csak nem random írogatsz zárójeleket, meg egyéb kifejezéseket benne.

Ez egyébként a Scheme nevű "Lisp-variánst" használja:

https://www.cs.cmu.edu/Groups/AI/html/r4rs/r4rs_6.html

XML-nél valamivel jobb azért (attól hülyét kapok, ha konfig fájlban van), de ebből a szempontból a systemdben az INI formátum használata inkább való ilyen célra (szerintem).

"The Shepherd is a service manager written in Guile Scheme ... The Shepherd is configured in Guile Scheme and can be extended in the same language."

„Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat.”
"Az Antikrisztus ledarálja Mészáros Lőrincet."

( locsemege v | 2024. 12. 10., k – 15:05 )

Ez mitől nagyobb öröm, mint a systemd?

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

Nem gondoltam volna, hogy ilyen hamar felszállunk a "kényszeríteni csak pisztollyal lehet" menetrendű vonatra. 🤡

Egyébként igen, pontosabban erőltette, 2014-ben. Ahogy két éve (aktív influenszerkedéseddel) a pipewire-t, ahogy most igyekszik a wayland-ot. Csupa olyan megoldások, amik multis felhatalmazással való torkokon lenyomás nélkül az életben nem tudnának elterjedni az open-source világban, a szuboptimális mivoltuk miatt.

A pipewire legalább funkcionális és jó, a Red Hat a pulseaudio fiaskót köszörülte ki vele. A systemd nálam jól működik annak ellenére, hogy eredendően azt is Lennart Poettering írta. Szerencsére Lennart már a Microsoft kódjaiban igyekszik kárt tenni.

A wayland annyiban jó gondolat, hogy az X lassú és biztonságtalan, ugyanakkor az funkciótlan, hogy épp a hálózaton keresztül történő rajzolgatást nem tudja, illetve X klienssel tudja, de akkor meg minek van.

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

Ezt rosszul tudod. Mindenki kedvenc Pöcsteringje most is systemd-s, és linuxos kódokon dolgozik, csak annyi változott, hogy az irodája, e-mailfiókja, fizetése már az MS-nál van, és nem a Red Hat pénzeli. Felesleges azt hinni, hogy bárki is megszabadult tőle, áldásos kezének a fejlesztéseit továbbra is meg fogod kapni, akkor is, ha nem használsz Windowst.

A Waylanddel nekem sem lenne bajom, ha nem erőltetnék annyira az X-et elavultandó.

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

A pipewire legalább funkcionális és jó, a Red Hat a pulseaudio fiaskót köszörülte ki vele.

Hát ezt nem mondanám, de az tény, hogy a pulseaudio sokkal szarabb. Komoly munkára (pl. stúdió, ahol a line-in és a visszacsatolása között nem megengedett a latency) továbbra is teljesen alkalmatlan mindkettő.

A systemd nálam jól működik

A systemd na az tényleg lassú, erőforrás zabáló, és akkor van a gond vele, amikor valami nem megy. Journalctl -lmbtq több képernyőnyi kimenet, de semmi értelmes benne, hogy mi szart be és miért. Csak zaj.

A wayland annyiban jó gondolat, hogy az X lassú és biztonságtalan

30 éve használok X-et, soha nem tapasztaltam, hogy lassú vagy "biztonságtalan" lett volna. Sőt!
Sosem volt problémám a hardveres gyorsítással alatta, anno a GLX is remekül működött, manapság meg nem is érdekel, mi a driver vagy extension, egyszerűen csak megy. Rég volt már, hogy X configba nyúltam volna.
Az egyetlen kifogásuk ellene, hogy "régimódi az APIja", de ez engem egy csöppet sem zavar, már megszoktam, és ismét, sőt, előny, mert Just Works (C) (TM).

hogy épp a hálózaton keresztül történő rajzolgatást nem tudja

Meg semmi mást se.

Próbáltál már képernyőképmentést csinálni vele? Lehetlen. De legalább önmagával sem kompatíbilis, fordításonként újratervezik az API-ját, a helloworld példaprogramjuk sem fordítható le a legfrissebb libbel, ami azért elég durva (az "újraírt" meg még xdg protokollt is kell, hogy beszéljen, meg direktben osztogat meg memóriát shm bohóckodással, na gratulálok, ez aztán biztonságos lett!).

Fontkezelés nuku, minden appnak magának kell szívnia a legegyszerűbb szövegkiírással is, de hát mit nekünk kódduplikáció, ugye, hadd pazaroljuk az erőforrásokat. (Nem azért, az X fontkezelése is egy förmedvény ha nem csak Latin-1-et akarsz, de legalább van XDrawString, és egy Hello World appnak nem magának kell a glifeket kirenderelnie.)

Igazából semmi olyant nem nyújt a Wayland, amit az X ne tudna, de legalább felét sem tudja annak, amit az X. Kompozítor? 10 éve xcompmgr-t használok, tökéletesen megy. Egyszer volt vele gondom, amikor RPi2-n próbáltam futtatni, és kevés volt neki a GPU RAM, de ott bármi más kompozítor is beszart volna.

De olyanom is volt már, hogy azért nem tudtam SDL-t fordítani, mert a Wayland XML2C konvertele épp bebugzott. Igen, jól olvastad, XML-t konvertálna C-vé, de hogy mi a f*sznak, aztatat nem tudom, mert értelme nem sok, a lib fix. Ja persze, ilyen f*szságok nélkül nem lenne "modern". Nem baj, legalább van, ami el tud romlani benne már wl app fordításkor is (sem az SDL-t, sem a wl XML konvertáló szottyát nem bántottam, gyári volt mindkettő forrása, mégis elhasalt az SDL fordítása. "./configure --diasble-wayland" és aztán minden más ment pöpecül.)

Ez mitől nagyobb öröm, mint a systemd?

Hát, annál bármi csak jobb lehet... Kevésbé bloat és nem akkora biztonsági szita, mint a systemd. Manapság már EFI rootkit is telepíthető systemd-vel...

Komoly munkára (pl. stúdió, ahol a line-in és a visszacsatolása között nem megengedett a latency) továbbra is teljesen alkalmatlan mindkettő.

Ezt ugyan elfogadom, de komoly munkára maga a PC és egy rajta futó operációs rendszer is alkalmatlan, tekintve, hogy a kiszolgálás adott időn belüli reményét adja, nem pedig annak garanciáját.

Wayland kínjaidat örömmel olvasom, azzal nincs tapasztalatom azon túl, hogy sok évvel ezelőtt kb. fél órát próbálgattam. Abból, amit írtál, arra következtetek, hogy semmi szükségem rá, jó lesz nekem a Xorg.

A Shepherd-et meg akkor fogom kipróbálni, ha Fedora hivatalosan támogatni fogja, de az a gyanúm, erre várhatok. Meglehetősen systemd-re épül itt minden. A gyakorlatban engem nem zavar, 32 GiB RAM-nál nem veszem észre a bloat-ságot, szappantartón - értsd, otthoni router - pedig nem systemd van.

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

komoly munkára maga a PC és egy rajta futó operációs rendszer is alkalmatlan,

Most ugye csak trollkodni próbáltál? Ezt te sem gondolhattad komolyan.

Konkrétan zenei stúdiónak lőttem már be PC-t, amit profi zenekar használt (talán még használ most is). ALSA-val önmagában simán megoldható a epszilon hibaérték alatti latency, ami a stúdiózás alapkövetelménye. Ha beiktatsz egy audio szervert, akkor ez felejtős.

Abból, amit írtál, arra következtetek, hogy semmi szükségem rá, jó lesz nekem a Xorg.

Igen, én is erre jutottam. Még mindig nem tudott semmi olyant villantani a Wayland, amit az X ne tudna, ellenben egy csomó mindent nem tud, amit az X igen. A régi kódbázis ügyét meg alapvetően megoldotta, hogy lecserélték az Xfree86-ot Xorg-ra, ami egy komplett rewrite volt anno, úgy hogy az API és a protokoll kompatíbilis maradt (egy-két specifikus XF86* függvénytől eltekintve).

A pipewire legalább funkcionális és jó

Amellett, hogy ritka nagy bloat, túltervezett és ismét olyan problémákat akar megoldani, ami egy audioszervernek nem lenne feladata és amúgy átlagfelhasználás mellett egy szofisztikált ALSA configgal is megoldható lenne, ami pedig nem, arra meg két évtizede ott a jackd.

a Red Hat a pulseaudio fiaskót köszörülte ki vele

Amit csak úgy tudott meglépni, hogy újraírta. 🤡 Kérdem én, hogy miért kellett erőltetni a szarul-húgyul implementált, instabil szar pulseaudio-t annyira, hogy fiaskó legyen belőle? Aztán eladják (te meg influenszerkeded), hogy hűdejó a pipewire, miközben azzal maximum a béka segge alól jutottak vissza oda, ahonnan a pulseaudio előtt elindultak.

A systemd nálam jól működik annak ellenére, hogy eredendően azt is Lennart Poettering írta.

Captain WorksForMe strikes again. Igen, 10 évvel a beerőltetés után már valamennyire működik mindenkinél, bár azóta még 3x akkora bloat lett, mint volt. Akkor legalább megvárták volna, míg stabil lesz és stabil állapotban erőltetik be.

A wayland annyiban jó gondolat, hogy az X lassú és biztonságtalan

Igen, a Red Hat más influenszerkéi is csak ezt tudják elsőként felhozni mellette, mivel saját értékei nem nagyon vannak. A Wayland-ot az X bemocskolásával, pszichológiai elavultatásával, félelemkeltéssel szeretnék elterejeszteni, mert 15 év kevés volt ahhoz, hogy valódi funkcionalitásban, stabilitásban, időtállóságban (tudod, ami a tudatosabb felhasználóknak számít) felülmúlja az X-et.

A Wayland-nak nincs semmiféle létjogosultsága a Linux desktopon az X helyettesítésére, és ha nem lenne mögötte a Red Hat, eltűnt volna már rég a süllyesztőbe, ahová való. Ha pedig valakit zavar az X biztonságtalansága™, akkor ne futtasson keyloggert a gépén, vagy írjon rá patcheket, ami belerak némi jogosultságkezelést. Egyetlen enterprise vendortól, vagy szabadúszó fejlesztőtől sem születtek ilyen patchek a 40 év alatt. Ja, tudom, legacy™ kódot nem patchelünk, mert ott nincs meg a fejlődés illúziója. 🤡 Meg hát ugye véletlenül sem a rablógyilkos bejutását kell megakadályozni a házba, inkább legyen mindenkinél álmában is fegyver a párnája alatt, meg aludjon golyóálló mellényben. 🤡🤡

ugyanakkor az funkciótlan, hogy épp a hálózaton keresztül történő rajzolgatást nem tudja, illetve X klienssel tudja, de akkor meg minek van

Pulseaudiot a hálózaton keresztüli audioszerverkedéssel influenszerkedték be a hozzád hasonlók a disztrókba. 🤡 Tudod, az a feature, amire 1000-ből 999 user közül az ég világon senki nem akarta használni és ami még annyira se működik out-of-the-box, mint az alapfunkcionalitása.

A bloat, mint érv cseppet uncsi, amikor GB-okban mérjük a RAM-ot, GHz-ekben az órajel frekvenciát, sok magban, több thread-ben, pipeline-okban, DMA-kban, L1, L2, L3 cache-ekben, queue-kban, nagy buszszélességben a CPU-t. Lehet, nem egy PIC16F84-en kellene Linuxot futtatni, oda assembly kódolás való oprendszer nélkül. :) Mindamellett én is szeretem az egyszerű, sovány kódokat, de saját magamból kiindulva tudom, hogy egy program mindig hízik. Jönnek az újabb ötletek, imlementációk, feature request-ek és azok megvalósításai. Sokszor ellenérvelsz a bloat-sággal, de mindig elfelejted megemlíteni, hogy ezek moduláris szolgáltatások, lehetőségek csupán, nem fog minden kód egyszerre futni. Nagy választék, amelyből pontosan azt és annyit használsz, amire és amennyire szükséged van.

Az ALSA config jó lenne, ha dinamikus lenne, nem pedig egy hosszasan megálmodott, odaszögelt valami. Messze nem tudja azt, amit a pipewire és a wireplumber az alsa driver-ek fölött. Apróság, hogy tudtommal az alsa-nak nincs jack és pulse interface-e.

már valamennyire működik mindenkinél, bár azóta még 3x akkora bloat lett, mint volt

Tehát fejlődött.

Hálózaton történő hang áttolásának van létjogosultsága, az más kérdés, hogy erre a pulseaudio nem volt képes.

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

Az ALSA config jó lenne, ha dinamikus lenne, nem pedig egy hosszasan megálmodott, odaszögelt valami. Messze nem tudja azt, amit a pipewire és a wireplumber az alsa driver-ek fölött. Apróság, hogy tudtommal az alsa-nak nincs jack és pulse interface-e.

Te itt most iszonyatosan kevered a dolgokat.

a) az ALSA az egy kernel interfész, a jack és a pulse nem, azok függvénykönyvtárak (amik egyébként végső soron szintén az ALSA kernel interfészt használják, mert nincs más a kernel felé).
b) a libasound függvénykönyvtár hivatott azt nyúltani, amit a jack és a pulse, és tudja is, csak az már nekem bloat a sok dinamikus konfigurálási lehetőségével
c) az ALSA config alatt nem tudom, mit értesz, maga az ALSA egy szöveges fájlból nyalja fel a beállításait, amit bármiféle dinamikus módon kigenerálhatsz
d) a libasound ugyancsak, és iszonyat dinamikus kismillió paraméterezési lehetőséggel (túlontúl is, ha engem kérdezel), számtalan plugin van hozzá mindenfélére, mindnek újabb kismillió kapcsolója van

Hálózaton történő hang áttolásának van létjogosultsága, az más kérdés, hogy erre a pulseaudio nem volt képes.

ALSA-val simán megy, csak egy mezei socket proxy-t kell ráállítani. De egyébként írni egy proggit, ami minden dsp fájlba küldött adatot netre rak, és egy másikat, ami meg minden netről kiolvasott adatot a helyi megnyitott dsp-be küld, kb 5 perc, a tankönyvi TCP/UDP példaprogramok felhasználásával meg kb. 1 perc. Talán még az nc-t is fel lehet kellően paraméterezni ehhez. Az ALSA kernel interfész ugyanis egy szabványos device fájl, nincs benne semmi extra. Ez a jackről és a pulseról ugyanakkor nem mondható el (utóbbinak még egy futó daemonra is szüksége van).

A Wayland-nak nincs semmiféle létjogosultsága a Linux desktopon az X helyettesítésére

Ezt aláírom, mindmáig senki nem tudott egyetlen egy kézzelfogható funkciót sem mondani, amit a Wayland tudna, az X meg nem. A hardveres gyorsítás és a kompozítor nem probléma már évtizedek óta, és konfigot sem kell matatni már 20 éve X alatt, szóval...

Ez rendben, de amikor arról beszélsz, hogy az ALSA config bármikor generálható, akkor ez csak a lehetőség. Vedd úgy, hogy a pipewire és a wireplumber az a valami, ami nem csak álmodozik erről, hanem megvalósítja azt, mintha röptében, élő stream-en, dinamikusan új configot generálnál és azt fel is olvastatnád. Ahogy írod, az ALSA egy kernel interface, nem pedig egy audio - pipewire esetén multimédia - szerver. Olyan ez, mintha arról beszélnél, felesleges a moserial terminal, amikor simán tudsz írni a device file-ba, meg olvasni is tudod. Ez igaz, de a soros terminál egy réteggel - illetve többel - feljebb van, és megoldja az ergonomikus használhatóságot, mert mondjuk lehet, hogy az echo 'Hello' >/dev/ttyACM0 azért annyira talán mégsem kényelmes, meg nem biztos, hogy minden egyes alkalmazáshoz programot írnék rá.

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

Továbbra is kevered a dolgokat. Nem hasonlíthatod az ALSA interfészt (ami egy device/ioctl interfész) a pipewire-höz, mert nem egy pályán fociznak.

Ha mindenképp hasonlítani akarod, akkor a libasound-dal kell hasonlítanod (snd_* függvényeket adó .so-k, debianos csomagnevük alsa-lib, alsa-plugins, alsa-topology-conf stb.), ez viszont simán hozza mindazt, amit itt felsoroltál. Dinamikusan betölthető és konfolható filterek, effektek, csatornaátirányítás, stb. miegymás, ezek mind-mind nem a kernelben, hanem futásidőben linkelődő függvénykönyvtárakban lettek megvalósítva (pont ahogy a pipewire is teszi), semmi device fájl matatás.

Az igazi programozó direktben használja az ALSA ioctl interfészt, bármiféle függvénykönyvtár nélkül.

És ezzel sejtésem szerint az igazi programozó lehetetlenné teszi, hogy bármely más program hangot adjon ki azon a gépen ezzel egyidőben. Meg olyan nincs is, hogy az igazi programozó nem programot ír, hanem afféle csacskaságokra vetemedik, hogy zenét hallgat, filmet néz, VoIP telefonál.

De legalább hamisítatlan, igazi programozó. :P

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

Igen, csak a pipewire a különböző mintavételi frekvenciájú kliensek hangját mixeli, stream-enként hangerőt állít, globálisan az egészet, bárhogyan route-olhatod a a jack, alsa, pulse klienseidet az audió kimeneteidhez - alaplapi, USB, Bluetooth például - akár egyszerre az összeset, visszhangelnyomás, meg a többi. Ha közvetlenül a software-edet kötöd a kernel interface-re, akkor szerintem az kizárólagosan az övé, minden más kliensnek ígyjárás, mert nem fér hozzá az audio interface-hez.

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

Én nem vagyok ellene amúgy a pipewire-nek, csak azt mondom, hogy a legalján ugyanúgy alsa ioctl-ek, videó esetén meg gondolom v4l2 ioctl-ek vannak, azokra húz egy egységes réteget ennek minden előnyével, meg hátrányával. Aztán kinek melyik fontosabb, úgy áll hozzá :)

Meg azt is mondom, hogy a közvetlen ioctl-ekkel is lehet élni, NetBSD esetén tapasztalom :)

A hasonlatod helyesen: A pipewire nem más, mint egy kifogástalanul működő hagyományos WC-kagylóra ráépített, 3x akkora WC-kagyló, amit azért kellett odaépíteni, mert a családban van egy 256 kilós piroskalapos bácsi, aki állítása szerint máshogy nem tud kényelmesen szarni. Cserébe mindenki más szarásélménye szuboptimális, hisz nekik a hagyományos WC-kagyló lenne megfelelőbb és még a mosdóban is jobban elférnének.

Ja™ igen™, mint systemd- és Wayland-mentes fősodratú disztróra is van, mert véletlenül sem akarja kedvenc multikád a szutykait beerőltetni mindenhova is, lehetőleg úgy, hogy ne maradjon széleskörben használt/támogatott alternatívája. 🤡

Tudom, hogy az a bánatod, hogy a kliens oldalon kikopik az alsa interface használata, helyette szinte mindenhol pulse van. Senki sem kényszerítette a programozókat erre, éppen ezért azt bátorkodom gondolni, hogy sokkal kisebb szívás pulse interface használatával hangot csinálni egy kliens által, mint alsával. Tehát akkor mégis csak valós igényeket elégített ki a pulse interface, más kérdés, hogy ehhez nem sikerült szervert írni elsőre. Semmi baj, megírták másodjára jól.

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

Senki sem kényszerítette a programozókat erre

Ja, senki. Bizonyára akkor is implementálták volna a pulseaudio-t, ha valami jöttment hobbiprojektje ugyanebben a formában és nem multis felhatalmazással van erőltetve, meg industry standard-dá téve az által, hogy a Red Hat a legnagyobb enterprise linux vendor. 🤡

Tehát akkor mégis csak valós igényeket elégített ki a pulse interface, más kérdés, hogy ehhez nem sikerült szervert írni elsőre.

Ez annyira valós™ igény™, amennyire a GNOME valós™ igénye™ millióknak úgy, hogy a rendszergazda azzal telepíti a gépeket a cégnél és elveszi a root jogodat, hogy mást eszedbe se jusson telepíteni. Vagy ugyanígy százmillióknak igénye™ a Microsoft Office. A konformizmus nem valós igény.

Semmi baj, megírták másodjára jól.

Helyesen: Megírták szarul-húgyul implementálva, bloated, erőforráspazarló, túltervezett szutyoknak. Helyette magát, az OSS időkből ránk maradt audioszerver koncepcióját kellett volna elengedni. Nem most, már úgy 20 éve. Elvégre az ALSA is valami ilyesmi miatt készült, amikor még minden desktop env saját audioszerverrel nyomult. Az ALSA fejlesztői ott baszták el, hogy nem dokumentálták fossá-húggyá az egészet és nem írtak rá GUI-s konfigurátort. Dehát nem gondolhatták szegények, hogy 20 év múlva babzsákfejlesztők és influenszerek fogják meghatározni a Linux-világot, akik lusták megismerni egy már kész komponenst, ami képes az igényeiket kielégíteni.

Egyébként többször feltűnt, hogy mélyen kussolsz a jack-ről, pedig többször említettem. Az is velünk van már több évtizede. Miért is nem volt jó az ilyen 24 csatornás scenariokra, amikkel nyüszítve véded a pulseaudio/pipebloat létjogosultságát? 🤡 Csak azért kérdezem, mert az a néhány homokszem a sivatakban, akiknek fétisük Linuxon audioszerkeszteni, pont ezt használták és nekik még extrémebb igényeik voltak, latency, meg eszközválaszték szempontjából.

Pipewire-nek van jack interface-e is.

Brawndo's got electrolytes.

A pipewire a feature set-en túlmenően abban is jó, hogy mindhárom audio interface-szel rendelkezik.

Szóval amikor majd ismét a haladás illúzióját kell kelteni, írnak egy negyediket, aminek az lesz az egyik létjogosultsága, hogy a jack-kel, az ALSÁ-val, a pulseaudio-val és a pipewire-rel is kompatíbilis. 🤡

Azonkívül, hogy jó szokásod szerint felmondod a Red Hat marketing bullshitet, esetleg válaszod is van arra a kérdésre, hogy azokra az igényekre, amikkel a pipewire mellett influenszerkedtél, és amúgy amiket az ALSA is tud megfelelő konfiggal, meg a jack is tud teljesen dinamikusan, miért nem volt jó a jack?

Miért kellene egy negyedik? Nincs natív pipewire audio interface. Van pulse, jack és alsa.

Milyen az a megfelelő config? Mutatnál egy ilyet? Fontos volna, hogy a hardware ismerete nélkül, akár jack interface-en változtatható route-olással, véletlenszerűen különféle interface-ekkel - a példádnál maradva megengedően elég lesz a jack és alsa, amúgy kellene a pulse is - megjelenő majd kihaló kliensekkel is működjön ez a config. Nem úgy, hogy mindig más config kell, és nem úgy, hogy minden új helyzethez nyissunk meg egy text editort.

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

Miért kellene egy negyedik?

Én is ugyanezt kérdezem, csak én nem 4-től indítom a számlálót.

Nincs natív pipewire audio interface. Van pulse, jack és alsa.

Nagyszerű, vagyis sikerült még egy bloated réteget felhúzni a meglévők fölé. Sokadszori gratula érte!

Milyen az a megfelelő config?

Ami van annyira absztrakt és dinamikus, hogy ne kelljen editálgatni, mikor épp felcsatolsz egy új eszközt.

Mutatnál egy ilyet?

Keresgélj ALSA-only disztrókban, akár régebbiekben és láss csodát, hogy valahogy megoldották.

Ha nem találsz ilyen configot, se jelenti azt, hogy nem létezhet ilyen. Nem véletlen mondogatom már régóta, hogy a pulseaudio kiváltható lett volna egy jól megírt ALSA config generatorral.

Fontos volna, hogy a hardware ismerete nélkül, akár jack interface-en változtatható route-olással, véletlenszerűen különféle interface-ekkel - a példádnál maradva megengedően elég lesz a jack és alsa, amúgy kellene a pulse is - megjelenő majd kihaló kliensekkel is működjön ez a config.

Fontos volna, hogy a régi újrafeltalált kerékkel működjön az új újrafeltalált kerék, sőt a legújabb újrafeltalált kerék működjön a régi újrafeltalált kerékkel, az új újrafeltalált kerékkel guruló autókon, sőt a legújabb újrafeltalált kerékkel guruló autókon is. 🤡

Az egész hóbelebancra nincsen szükség, de ha mégis (stúdiózásnál) azt megoldotta volna a jack.

a pipewire a különböző mintavételi frekvenciájú kliensek hangját mixeli, stream-enként hangerőt állít, globálisan az egészet, bárhogyan route-olhatod a a jack, alsa, pulse klienseidet az audió kimeneteidhez

ALSA szintén képes ezekre, amiket felsoroltál. Attól még, hogy nem ismered eléggé az ALSÁ-t, nem lesz alkalmatlan audiomegoldás. Mondom, arról van szó, hogy te is, meg a Red Hat babzsákfejlesztői is lusták voltatok megismerni az ALSÁ-t, ezért feltaláltátok újra a kereket és csináltatok belőle egy, a pulseaudio-nál is nagyobb bloatware-t. Egy jól átgondolt és GUI-s konfigurátor kellett volna az ALSÁ-nak, meg egy minden rendszeren működő alapconfig, semmi más. Pulseaudio előtt is voltak már bluetooth headset-ek, meg USB-s fejhallgatók. Valahogy azok is működtek pl. Ubuntun, volt rá rendes ALSA alapkonfig.

Ha közvetlenül a software-edet kötöd a kernel interface-re, akkor szerintem az kizárólagosan az övé, minden más kliensnek ígyjárás, mert nem fér hozzá az audio interface-hez.

A megoldás: dmix vagy jobb esetben hardveres mixing, ami nem zabál CPU-t sem.

Az, ami 20 éve készen van, valahogy mégsem volt készen. Nem volt nekem készen VoIP klienshez visszhangelnyomás, nem tudtam GUI-n megcserélni a jobb- és baloldalt, nem tudtam Firefoxon Youtube hangját bluetooth kimenetről lokális hangszóróra átdobni aktívan lejátszott stream esetén, miközben bluetooth-on szólt tovább a zene. Az, ami 20 éve készen van, az egy funkciótlan valami. Nézd, nekem is van készen biztosan olyan programom 20 éve, ami 1-től 10-ig elszámol a képernyőn a természetes számok halmazán, csak nem túl funkcionális. De legalább készen van.

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

Az itt leírt use case is megvalósítható ALSÁ-val, csak nem 1-től 10-ig számoló ALSA konfig kell hozzá.

Attól még, hogy te 20 évvel ezelőtt csak egy 1-10-ig számoló programot voltál képes írni, most meg már sokkal szofisztikáltabb megoldásokat készítesz, az ALSA 20 éve is készen volt és nem csak 1-10-ig tudott számolni, hanem átgondolt ALSA konfiggal minden megvalósítható volt benne akkor is, és most is az.

Csak valahogy erről a Linux felhasználók mégsem tudtak, mégis állandóan gond volt a hanggal, nem volt megoldás a problémáira. Az nem megoldás, hogy ha bedugsz egy fülhallgatót a gépbe, akkor végy egy text editort, nyisd meg a dokumentációt, szerkessz meg egy config file-t a doksi és a hardware topológiád, valamint az elvárt eredmény alapján, olvastasd fel a géppel, majd használd.

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

Igen, csak a pipewire a különböző mintavételi frekvenciájú kliensek hangját mixeli, stream-enként hangerőt állít, globálisan az egészet, bárhogyan route-olhatod a a jack, alsa, pulse klienseidet az audió kimeneteidhez - alaplapi, USB, Bluetooth például - akár egyszerre az összeset, visszhangelnyomás, meg a többi.

Ezt mind tudja a libasound is...

Ha közvetlenül a software-edet kötöd a kernel interface-re, akkor szerintem az kizárólagosan az övé, minden más kliensnek ígyjárás, mert nem fér hozzá az audio interface-hez.

Azt hiszed, hogy pipewire esetén ez nem így van? Dehogynem. A mixelés a device-t megnyitó szoftver dolga, és nem a kernel interfészé (hardveres mixer talán utoljára még a Gravis UltraSound kártyákon volt, azóta sehol sem, most már csak szoftveres mixer létezik, a pipewire is az és a libasound is).

De mégegyszer, szándékosan összemosod az ALSA interfészt (ami device/ioctl) és az alsa-lib + alsa-plugins + alsa-stb. függvénykönyvtárak által nyújtott funkcionalitást. Ez nem frankó. Ez utóbbiak nagyon is tudják mindazt, amiket itt kifogásolsz (csatornánkénti hangerő, átirányítás, mixelés, blútötty stb. stb. stb.), a kernel interfész meg akkor sem tudja, ha a pipewire nyitja meg a device-t.

Értem, de ne ezen rugózzál, mert a vitának nem igazán ez a lényege. Van a kernel interface, buta, mint a tök, tolod bele a hangot, aztán szól, vagy ömlik belőle a hang, aztán jól van. És van fölötte az alsa-lib vagy pipewire, s most ezen megy az izmozás vallási hovatartozástól függően.

Az alsa-lib nem tudja azt a funkcionalitást, amit a pipewire és wireplumber. Elhiszem, hogy neked nem is kell, de szerintem nem rúgja rád a TEK az ajtót, ha alsa-lib-et használsz, s nem pipewire-t, és valószínűleg én sem kapok nagyobb csokimikulást pipewire használat miatt a Jézuskától. :)

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

Van a kernel interface, buta, mint a tök, tolod bele a hangot, aztán szól, vagy ömlik belőle a hang, aztán jól van.

Örülök, hogy megértetted.

És van fölötte az alsa-lib vagy pipewire, s most ezen megy az izmozás vallási hovatartozástól függően.

Semmi vallás. Mérési eredmények miatt mondom, hogy a pipewire szar.

Az alsa-lib nem tudja azt a funkcionalitást, amit a pipewire és wireplumber.

Mégsem értetted meg. Már megint ugyanott tartunk, az ALSA nem tudja, de az alsa-lib igen. Nincs olyan funkcionalitás a pipewire-ben, ami ne lenne a libasound-ban vagy valamelyik pluginjában benne. Nincs, nyista, nada. És ha bepakolod az összes alsa-plugin-t (csatornaátirányítás, visszhangszűrés, blútötty, stb. stb. stb.) akkor az is pont ugyan olyan bloated lesz, mint a pipewire és pont ugyanúgy hatalmas lesz a latency-je, mint a pipewire-nek alapból.

Mégsem értetted meg. Már megint ugyanott tartunk, az ALSA nem tudja, de az alsa-lib igen.

Direkt figyeltem, alsa-libet írtam, szóval örülök, hogy jóról jóra javítottál feleslegesen. :)

ha bepakolod az összes alsa-plugin-t (csatornaátirányítás, visszhangszűrés, blútötty, stb. stb. stb.) akkor az is pont ugyan olyan bloated lesz, mint a pipewire és pont ugyanúgy hatalmas lesz a latency-je, mint a pipewire-nek alapból

Aha, tehát akkor mégsem rossz a pipewire, hanem a megvalósíthatóságnak vannak objektív korlátai.

A funkcionalitásra azért nem reagálok, mert noha meggyőződésem, hogy nincs így, nem tudom bizonyítani. Ja, de, tudom. Van az alsa-libnek pulse illetve jack interface? Ha van, akkor miért nincs? Automatikus routing?

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

A bloat, mint érv cseppet uncsi, amikor GB-okban mérjük a RAM-ot, GHz-ekben az órajel frekvenciát, sok magban, több thread-ben, pipeline-okban, DMA-kban, L1, L2, L3 cache-ekben, queue-kban, nagy buszszélességben a CPU-t.

Te ebben méred, de azok nem, akiknek épp azért akadozik a hang, vagy telítődik ki egy magjuk, mert a Red Hat babzsákfejlesztői is így gondolkodtak. Majd a mikrokontrolleres munkád kapcsán mondd meg a főnöködnek/megrendelődnek is ezt az uncsiszöveget. Elvégre nyugodtan lehet oda is bloat-ot írni, majd lecseréli a paraszt az Arduino-t/PIC-et Raspberry PI-re igaz? 🤡

Tényleg, a megrendelőidtől miért nem várod el, hogy álljanak már át ARM-ra, hiszen fillérekbe kerül és a fogyasztása is alacsony. Nyomhatnád rá a bloat-abbnál bloat-abb Linux disztrókat, meg programozhatnál Assembly helyett Pythonban.

Lehet, nem egy PIC16F84-en kellene Linuxot futtatni, oda assembly kódolás való oprendszer nélkül. :)

Nem is azon futtatják, de egy 20 éves gép is erősebb egy PIC16F84-nél és ami ALSÁ-val működik X teljesítménymutatóval (memória, CPU stb.), annak pipewire-rel is illik ugyanilyen teljesítménymutatóval, máskülönben a pipewire egy szarul-húgyul implementált, erőforráspazarló szutyok.

Sokszor ellenérvelsz a bloat-sággal, de mindig elfelejted megemlíteni, hogy ezek moduláris szolgáltatások, lehetőségek csupán, nem fog minden kód egyszerre futni.

Pont, hogy minden egyszerre fog futni egy "Linux for human beings" típusú disztrón.

Nagy választék, amelyből pontosan azt és annyit használsz, amire és amennyire szükséged van.

Ilyen az ALSA a ladspa pluginjaival, ilyen a jack. A pipewire meg olyan, hogy minden is akar lenni egyszerre, még videószerver is.

Messze nem tudja azt, amit a pipewire és a wireplumber az alsa driver-ek fölött

Messze nincs is rá szükség, ráadásul megfelelően "odaszögelt" ALSA configgal még kiváltható az a dinamizmus is, ami minimálisan szükséges egy bluetooth fejhallgatóhoz.

Apróság, hogy tudtommal az alsa-nak nincs jack és pulse interface-e.

Pulse interface-e minek legyen? A pulse idealizmus erőltetése előtt minden Linux-ra írt programnak volt ALSA interface-e, csak aztán jött az innováció™, meg a nemérimegmaintainelni™. Jack-nek meg van ALSA interface-e.

Tehát fejlődött.

Csak növekedett. Tehát összességében visszafejlődött.

Hálózaton történő hang áttolásának van létjogosultsága, az más kérdés, hogy erre a pulseaudio nem volt képes.

Van létjogosultsága, csak nem az audioszerver dolga, hanem léteznek 20 éve megoldások, amik erre képesek és még működnek is, nem úgy, mint a Red Hat szutykai.

Ez csak nálad hit kérdése.

Valamilyen elbaszott oknál fogva bele vagy buzulva a Fedorába és a Red Hat-ba, olyannyira, hogy még influenszerkedsz is a szutykaik mellett. Ha ez nem lenne, akkor te is belátnád és hasonló véleményen lennél, mint Raynes kolléga.

Szerintem beláthatnád, hogy csak azért, mert te filmnézésen, zenehallgatáson kívül semmi másra nem használod, ezért nem jön elő nálad a probléma, az még nem azt jelenti, hogy a pipewire mindenre és mindenkinek jó. Konkrét példát írtam, stúdiónak használhatatlan.

Egy egyszerű teszt: indítsd el az Audacity-t, rakj be egy sávot, és egy másik sávnak add meg az audio bemenetet. Semmi csodára (visszhangszűrés stb.) nincs szükség, mert ezeket az Audacity magától tudja, ami viszont fontos, hogy a lejátszott sáv és az audio bemenet sávja egyszerre szóljon, különben felejtős az egész és alkalmatlan stúdiómunkára.

Pulseaudio-val, pipewire-el ez lehetetlen, a bementi sáv és visszacsatolása között túl nagy a latency; libasound-al is szívás beállítani és nem triviális, de legalább ott megoldható ez.

Mindenképpen lesz latency

Na de nem mindegy, hogy mennyi. Létezik egy epszilon hibaérték rá.

nem az van, hogy a kliens abban a pillanatban adja a hangmintát, amint azt a DAC teszi a kimenetre

De, libasound-dal és direkt ALSA programozással igen, ez megoldható.

Egész konkrétan ha a mintavételezési frekvenciád 44.1kHz, akkor (kissebb szívás árán ugyan, de) a libasound beállítható úgy, hogy a latency 1/44100*frameszám másodpercnél kevesebb legyen, így ugyanabban a tikkben, amikor beérkezik a hangminta, az ki is kerül a visszacsatolt kimenetre, így nem érzékelsz csúszást (nyilván bufferelt, így még a buffer méretével is játszani kell, hogy mennyi is legyen a hívásonkénti frameszám, ha túl nagy, az tovább növeli a latency-t, ha túl kicsi, akkor meg a túl sok kernel ioctl hívás overhead-je amiatt fog csúszni). De a lényeg, hogy létezik vele egy arany középút, amit ha nem is egyszerű, de lehetséges beállítani.

Pulse, pipewire meg a többi túlimplementált fostalicskával ez a cél nem elérhető, egész egyszerűen azért, mert a "dinamikusságuk" meg a sok csatorna átirányításosdijuk miatt eleve túl nagy az alap overhead. Még a legoptimálisabb beállítás mellett is meghaladja a latency-jük az epszilon hibaértéket.

saját magamból kiindulva tudom, hogy egy program mindig hízik

Ez nem érv, és főleg nem pozitívum. A program akkor van kész, amikor már nincs mit elvenni belőle.

Amit te mondasz, az az, hogy egy program soha nincs kész, illetve hogy a fejlesztők nem tudnak nemet mondani. Na, az a baj.

Főleg az előbbi pont ("soha nincs kész"), párosítva azzal, hogy lehet interneten keresztül frissítést kiadni, meg párosítva azzal, hogy a gyártónak jövedelmezőbb az előfizetés, mint az egyszeri vásárlás, azt eredményezi, hogy ma már a gyártó meg sem próbál kész, teljes terméket eladni. Nagyon szomorú.

moduláris szolgáltatások, lehetőségek csupán, nem fog minden kód egyszerre futni. Nagy választék, amelyből pontosan azt és annyit használsz, amire és amennyire szükséged van

A konkrét témától elvonatkoztatva: ez egy tévhit. A modularitásért, általánosságért, konfigurálhatóságért akkor is fizetsz, ha nem használod ki az általuk nyújtott lehetőségeket. Ezek a tulajdonságok extra infrastruktúrát igényelnek, bonyolítják a szerkezetet, emelik a hibalehetőségek számát, nehezítik a használatot.

Én egyáltalán nem vagyok híve a meglévő dolgok folyamatos lebutításának, és a rugalmas, nagyon sokoldalú szoftvernek is van helye. De az egy illúzió, hogy a kiterjesztésért, általánosításért nem fizetünk. Nagyon is fizetünk érte. Van, akinek ez megéri (mert alig várta az új funkciókat, amelyek az új architektúrára épülnek), van, akinek meg nagyon nem éri meg.

Az asztali számítógépem 14 éves, RHEL8 fut rajta, 6G RAM van benne, Athlon II X2 B22 CPU, és 3db HDD (nem SSD), meg egy DVD író. Most van folyamatban a csere, egyedül azért, mert már aggódok, hogy a diszkek be fogják adni a kulcsot, egyébként semmi baj nincs vele. Az új gép minimálkonfig (Ryzen 3 3200g, 16GB RAM), a 3db új diszket (otthoni körülmények között!) is élettartamra hegyezem ki, nem sebességre vagy kapacitásra (WDS500G1R0A). A DVD írót megőrzöm, megy át az új gépbe. Minimum egy évtizedig szándékozom használni az új gépet is; RHEL9-et fogok rá tenni.

(A kocsim is 18 éves, 304K km-t tettem bele eddig, az első autóm, szalonból vettem 0km-esen. Tökéletesen karban van tartva, cserének még a gondolatát is elvetem -- már csak azért is, mert vezettem modern csereautókat, nem kellene egyik sem. Szoktam benne zenét hallgatni: CD-ről, amiket magam írok, a fent említett DVD íróval ;))

A "bloat, mint érv" sokunknak nem "uncsi", hanem a lényeg.

Én is sokáig hajtok egy számítógépet. Előző gépem AMD Phenom II X4 mit tudom én, mi volt, úgy emlékszem, 13 és fél évig hajtottam, de az élettartam kádgörbéjének végén szaporodtak az instabilitásai. Aztán 3 éve raktam össze egy Ryzen 7 5700G 8 magos CPU-val, 32 GiB RAM-mal egy gépet, SSD-k és HDD-k is RAID1-ben, azóta ezt hajszolom nagy megelégedettséggel, s hidd el, nem tervezem a cseréjét, mert már elmúlt 3 éves.

Azzal, hogy egy program soha sincs kész, szerintem nincs baj. Ne mondd nekem, hogy egy függvénypointeres vezérlésátadásban újabb parancsokat, és újabb implementációs függvényeket hozol létre, akkor ettől el fog romlani, vagy lassabb lesz az, ami eddig jó volt. Évek óta írom egy műszer firmware-ét - ez nem félreértendő, nem ennyi ideig tart, mert közben kap újabb hardware modulokat, amelynek a kezelését bele kell írni a firmware-be, s a hardware-t is én tervezem -, kollégák újabb igényekkel állnak elő, néha nekem jut eszembe, hogyan tudnám segíteni a munkájukat, s akkor beleírom az ötleteimet, szóval folyamatosan fejlődik. Kb. akkor lesz kész, ha kiveszik a kezemből, mindenféle bevizsgálásra elvisszük, megkapja a gép a papírokat, s eladjuk, azaz sorozatgyártásba kerül. Folyamatosan működő állapotban tartom a firmware-t, de ha van új igény, ötlet, akkor azt beleírom.

a gyártónak jövedelmezőbb az előfizetés, mint az egyszeri vásárlás, azt eredményezi, hogy ma már a gyártó meg sem próbál kész, teljes terméket eladni

Ez az üzleti modell, amelyet jellemzően nem a mérnökök találnak ki, inkább a sales, marketing, vezérigazgató, tervzsűri, fene tudja. Meg ez termékfüggő, műszerben jellemzően piacrakerülés után nem is nagyon van lehetőség firmware cseréjére. Technikailag lehetséges, de jogilag aggályos, mert ha a műszerről kiállították a különféle bizonyítványokat, az arról szólt, amit bevizsgáltak, nem pedig a módosítottról. Amúgy kellemetlen, mert ha egy bugot fedezel fel, emiatt lehet, kénytelen vagy benne hagyni, s nem javíthatod ki, bár erre azért vannak kiskapuk. Nagyobb változtatásra viszont már biztosan nincs lehetőség.

A program akkor van kész, amikor már nincs mit elvenni belőle.

Ha látok lehetőséget egyszerűsítésre azonos funkcionalitás mellett, azt én is meg szoktam lépni, de a funkciók szűkítését nem.

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

( lacesz v | 2024. 12. 10., k – 22:35 )

Szerkesztve: 2024. 12. 10., k – 22:36

A legjobb init rendszer amit eddig használtam. Mint ahogy a nevéből is kiderül csak terelget, nem akar mindent is irányítani...

( sigellef | 2024. 12. 11., sze – 10:31 )

... mire már félig elfelejtettük a sys-v init-et és félig megszoktuk a systemd-t, most jön egy újabb :D

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Mégis mi a fene tart egy ilyennek a fejlesztésén ennyi ideig?

AFAIK nem old meg semmi olyan problémát, ami mainstream felhasználót érintene (akár céges, akár magán), innentől kezdve valószínűleg a fejlesztés is valakinek a hobbija csak. Ami nem feltétlenül gond, csak hát nyilván lassú.

Hát, én most csak átfutottam, ez a herd command ez ránézésre abban különbözik a systemds társától, hogy nincs a végére írva, hogy ctl, mert ki kb ugyanaz jön belőle. Örömködnek annak, hogy van beépített logservice  -- ugye a systemd itt kezdett el patásördög lenni -- kb ugyanazzal az érveléssel, van valami timer service, ami kb mint a systemd timerek, vannak transient servicek, amik még szerintük is olyanok mint a systemd-run.

Ami lényegesen különbözik, az ez a konfigurációs izé, ami... hát mondjuk, hogy én inkább maradnék az ini-nél :)

Ja, meg hogy a dependencia kezelés egy fos, de legalább meg van magyarázva :)

Szóval jó kis cucc ez, hiánypótló :)