- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Ajjaj, ezzel a Lisp-es szintaxissal nem tudom, fognak-e barátokat szerezni.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
Ezzel mit akartál mondani? A Lisp-nek nincs szintaxisa. 😉
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
meg natív C, [...] bináris szintjét nem üti meg
Nem mondod! :) Annál kb. az assembly lehet gyorsabb, bár igen jók a C fordítók, szóval az sem biztos, hogy minden esetben.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Mi a kicsit bloat? A szintaxis vagy a Lisp runtime?
A nagyobb Lisp implementációk mind tudnak natív kódra fordítani...
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
Nem, nem random. S-expression minden. A Sheperd ráadásul ugye Scheme, ahogy te is írtad, ami meg még "tisztább".
- A hozzászóláshoz be kell jelentkezni
Ez mitől nagyobb öröm, mint a systemd?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Annyival minimum, hogy nem egy arrogáns multi erőlteti.
- A hozzászóláshoz be kell jelentkezni
Erőlteti? Gyakrán csenget hozzád a Red Hat kommandó?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
Pont most nyitottam topicot, hogy hogyan is rajzolhatunk tavolra Waylanddal. Kifejthetned ott egy picit :)
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Kellene most ide egy libasound vs. pipewire fature list, hogy bebizonyosodjék a pipewire értelmetlensége...
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Hát az nem én leszek, mert egyiket se használom, mindkettőt túlbonyolított bloated fosnak tartom :-)
Az igazi programozó direktben használja az ALSA ioctl interfészt, bármiféle függvénykönyvtár nélkül. :P
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Miért? Végső soron a pipewire is az alsa ioctl interfészt használja.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Ezt értem. Arra reagáltam, hogy alsa ioctl-t használva csak egy hangforrás szólaltatható meg egyszerre.
- A hozzászóláshoz be kell jelentkezni
Igen. Csak a pipewire egy közbenső réteg, ő rátelepedhet a kernel interface-re kizárólagosan, mert a kliensek a pipewire-hez csatlakoznak, s a pipewire sok más mellett megoldja a mixelést.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Na annyira nem ismerem a Linux audio rétegeit, de meg lennék lepődve, ha a mixelést nem tudná kezelni pipewire, vagy pulseaudio nélkül. Az alsa korában is volt mixelés. alsamixer, amixer
- A hozzászóláshoz be kell jelentkezni
Tudja, ha akarja, de szerintem az már nem a kernel interface lesz. Lehet úgy is, de akkor csak annyi történt, hogy az alsa függvénykönyvtáraiban megvalósították mondjuk a pipewire funkcionalitásának 0.3 %-át. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
É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 hozzászóláshoz be kell jelentkezni
Így van. De ez olyan, mintha azt mondaná valaki, nem kell neki WC kagyló, mert bele tud hugyozni a lefolyócsőbe is. :)
Szóval valóban, a pipewire az alsa driver fölötti réteg, amire szükség van.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
A megoldás: dmix vagy jobb esetben hardveres mixing, ami nem zabál CPU-t sem.
Jé, akkor hát mégis kell oda valami? Miért nem hívhatjuk akár pipewire-nek azt a valamit?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Miért nem hívhatjuk akár pipewire-nek azt a valamit?
Mert a pipewire szar és hatalmas a latency overhead-je?
- A hozzászóláshoz be kell jelentkezni
Pötteringnek is működött™ a pulseaudio, meg a systemd 2014-es bétaminőségű bughalmaza is. Sőt sok esetben így "érvelt" ő is, ahogy most te.
- A hozzászóláshoz be kell jelentkezni
Mert már 20 éve készen van az a valami és semmi értelme odaimplementáltni egy kerékújrafeltalált bloatware szutykot.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
ALSA szintén képes ezekre
Pontosítsunk, az ALSA nem képes rá, a libasound (vagy más néven alsa-lib) viszont igen.
- A hozzászóláshoz be kell jelentkezni
Egy jól átgondolt és GUI-s konfigurátor kellett volna az ALSÁ-nak
Így van, ez borzasztóan hiányzott.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
É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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ez kezd hitvitává alakulni. Nagyon másképp látjuk ezt.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Lehet, jó a tapasztalatom a pipewire-rel, nem? Szemben a pulseaudio-val, szerintem jól sikerült mind feature set, mind implementáció szempontjából. Egyszerű használni, s meglepő, de még működik is.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
Az előre-hátralépési szintek nagyjából:
0 OSS
1 ALSA
-1 Pulseaudio
0 PipewireFejlődés™ 🤡
Hint: Nem a pulseaudio-nál kell jobbnak lennie. ;)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Neked nem mesélte még Lócsemege, hogy 24 csatornás audio interfészeket használ 4 dinamikusan felcsatolt-lecsatolt bluetooth-eszközzel párhuzamosan? 🤡 Ilyen setup mellett nyilván feltétlenül™ szükséges™ a pipewire.
- A hozzászóláshoz be kell jelentkezni
Mindenképpen lesz latency, mert nem az van, hogy a kliens abban a pillanatban adja a hangmintát, amint azt a DAC teszi a kimenetre.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
É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
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
... 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.
- A hozzászóláshoz be kell jelentkezni
Újabb? Poettering még takonnyal ette a zsíroskenyeret, mikor a Sheperd alapja a dmd megszületett! 😆
- A hozzászóláshoz be kell jelentkezni
Akkor ezek szerint már rég elavult. Mégis mi a fene tart egy ilyennek a fejlesztésén ennyi ideig?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
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ú.
- A hozzászóláshoz be kell jelentkezni
Igen, szóval én is nagyon örülök annak, hogy végre kész lett. :) Hiányzott már nagyon.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
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ó :)
- A hozzászóláshoz be kell jelentkezni