Vlákno názorů k článku Příští revoluce linuxového desktopu: dosáhl vrcholu nebo je ještě kam jít? od Heron - Díky za tvůj pohled na věc, tady je...
-
Díky za tvůj pohled na věc, tady je můj:
PulseAudio by správně neměl nikdy vzniknout. Tj. nehodnotím ten projekt jako takový, ale vůbec jeho potřebu. To, že nemáme zvukové karty schopné hw mixování streamů a dohání se to v SW, rozhodně nepovažuji za výhru. Tohle jsem vyřešil více kartami a mixážním pultem.
Wine apod. Tohle má být výhra? Že místo nativních programů máme více méně skvělou emulaci? Tedy, že autoři her budou o to více kašlat na linux, protože: "to tam stejně nějak pojede"?
Flatpack apod. na tohle téma už jsem před časem napsal článek k sobě, nebudu se tady opakovat. Tohle je důkaz tragédie, jak se vyvíjí software. Prostě se to zabalí do kontejneru se vším bordelem (kontejner je nádoba na odpad), který k tomu ta appka potřebuje a je to.
Proto jsem taky přešel na FreeBSD (ne na desktopu), kde přece jen trochu více a trochu déle přemýšlí a potom to udělají většinou správně.
-
> nemáme zvukové karty schopné hw mixování ... nepovažuji za výhru
ale penazenka ludi mnohych ano> WINE ... více méně skvělou emulaci
WINE - Wine Is Not Emulator> do kontejneru se vším bordelem
Nie, zabalia sa iba verzie okolitych kniznic tak aby aplikacia bezpecne fungovala a nemusel sa 'bordel' instalovat do OS> Proto jsem taky přešel na FreeBSD
Isteze ten ma tisice hotovych programov ktore mate vo FlatPacku. Vyborne, nasli ste spravne riesenie na nespravny problem. -
WINE - Wine Is Not Emulator
To jsem čekal ;-) A něco k tématu by nebylo?
Nie, zabalia sa iba verzie okolitych kniznic tak aby aplikacia bezpecne fungovala a nemusel sa 'bordel' instalovat do OS
Instalace knihoven v balíčkách dané distribuce nepovažuji za bordel, ale za standardní způsob instalace už od roku 1998, kdy jsem takto instaloval poprvé.
Isteze ten ma tisice hotovych programov ktore mate vo FlatPacku.
O tom nic nevím, kompiluju z portů.
-
> něco k tématu
nazvat nieco co priamo v nazve obsahuje ze nie je emulator aj tak emulator - co by ste chceli aby som vam odpovedal. Mylite sa.> standardní způsob instalace
Ja podobne, flatpack nepouzivam, debian obsahuje zatial vsetko co som kedy potreboval. Ale garantujem vam ze na vela veci ktore su aj vo Flatpacku 'porty' mat nebudete.No a to ze ste koli tomu presli na FreeBSD je samozrejme opat nezmysel. To ci existuje Flatpack alebo port alebo predpripraveny balik nema nic s FreeBSD alebo Linuxom. Prechodom na FreeBSD ste si iba odrezali vela SW. Nema to s tym ako vo FreeBSD premyslaju aby to urobili spravne nic spolocne.
-
nazvat nieco co priamo v nazve obsahuje ze nie je emulator aj tak emulator - co by ste chceli aby som vam odpovedal.
V mém komentáři je to jasně napsané. Nejsou to hry pro linux. To je téma. Ne to, jestli je wine / proton / cokoliv emulace nebo ne. Zkratku wine znám už asi 15 let. Opravdu není potřeba vyzobávat slovíčka.
Ad flatpack a freebsd. To jsou dva odstavce. O problematice kontejnerů jsem psal u sebe na webu. Pokud autor programu musí pro jeho distribuci používat kontejnery, je něco špatně se způsobem vývoje toho programu. A tohle je na širší diskusi. Prostě máme hromadu nástrojů na to, jak uklidit nepořádek, ale prakticky nemáme nástroje na to, jak vyvíjet bez nepořádku. A tím, že nepořádek zameteme pod koberec (docker, flatpack, snapd), tak nezmizí, ale naopak bude více narůstat. Už musíme mít dokonce nástroje na ty kontejnery. Přitom ještě před pár lety bohatě stačily standardní balíčky.
Odstavec o FreeBSD nemá souvislost s FlatPackem.
-
> Ad flatpack a freebsd
Ale mozno nie je problem vo vyvoji toho SW ale vo vyvoji roznych OS na ktorych ich chceme prevadzkovat. Kazda verzia kazdej distribucie ma inu verziu kniznice ktoru potrebujem a s kazdou dalsou kniznicou komplexita rastie kvadraticky.> Odstavec o FreeBSD
OK co potom hovorite napriklad na taketo:
https://papers.freebsd.org/2022/EuroBSDCon/pizzamiglio-naive_FreeBSD_container.files/EuroBSD%202022.pdf
FreeBSD nie je momentalne ziadnym driverom noveho vyvoja v oblasti OS. -
Ale mozno nie je problem vo vyvoji toho SW ale vo vyvoji roznych OS na ktorych ich chceme prevadzkovat.
Jo, to je také možné. Já na to odpověď nemám. Nejsem programátor, jsem admin. A moc se mi nelíbil způsob distribuce python prográmků, tak jsem se naučil golang a výsledek je jedna (i klidně statická) binárka. Pro linux, freebsd, widle. Tedy nemusím řešit žádný problém s instalací modulů, kontejnery apod.
Kazda verzia kazdej distribucie ma inu verziu kniznice ktoru potrebujem a s kazdou dalsou kniznicou komplexita rastie kvadraticky.
Otázkou je, proč potřebujete nějakou přesně specifickou verzi dané knihovny. Nebo dokonce více knihoven.
Když si vzpomenu na moji oblíbenou (a už dávno mrtvou) Gallery 2, tak ta byla vyvinuta v době php 5.1.6 a postgresql něco jako 7.4. Provozoval jsem to na php 7.x a postgresql 11. Moje 15 let staré prográmky v javě stále jedou. Přesnou verzi JRE fakt neřeším.
OK co potom hovorite napriklad na taketo
Tak on tam popisuje v podstatě stav, jak se běžně používají jaily. Nic nového nebo zvláštního tam nevidím. Hned na začátku píše, že je to ze studijních důvodů, tak ok.
-
Program a programek je podstatny rozdiel. A presne preto sa Java tak uchytila lebo sice nie je to 100% ale programy su RADOVO viac prenositelnejsie. My tu mame aj produkcne systemy ktore su funkcne este aj na Java 1.6 a dnes bezia na JRE 11 bez zasahu.
> podstatě stav, jak se běžně používají jaily
Ja som to pochopil tak ze tam riesi preco nemate nieco co je uz uplne bezne na Linux-e.Dependcy postgres-u a to je command line ziadne GUI:
linux-vdso.so.1 (0x00007ffe046f4000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f2f5433f000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x00007f2f54319000)
libxml2.so.2 => /lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f2f5416d000)
libpam.so.0 => /lib/x86_64-linux-gnu/libpam.so.0 (0x00007f2f54d2c000)
libssl.so.3 => /lib/x86_64-linux-gnu/libssl.so.3 (0x00007f2f540c2000)
libcrypto.so.3 => /lib/x86_64-linux-gnu/libcrypto.so.3 (0x00007f2f53c00000)
libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f2f53bad000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2f540a3000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2f53ace000)
libldap-2.5.so.0 => /lib/x86_64-linux-gnu/libldap-2.5.so.0 (0x00007f2f53a6f000)
libicui18n.so.72 => /lib/x86_64-linux-gnu/libicui18n.so.72 (0x00007f2f53600000)
libicuuc.so.72 => /lib/x86_64-linux-gnu/libicuuc.so.72 (0x00007f2f53200000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f2f5398e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2f5341e000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f2f5395e000)
libaudit.so.1 => /lib/x86_64-linux-gnu/libaudit.so.1 (0x00007f2f531ce000)
libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f2f530f2000)
libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f2f530c5000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f2f54d20000)
libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f2f54095000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2f54d58000)
liblber-2.5.so.0 => /lib/x86_64-linux-gnu/liblber-2.5.so.0 (0x00007f2f5394e000)
libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f2f530a9000)
libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f2f52e00000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2f52a00000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2f53085000)
libicudata.so.72 => /lib/x86_64-linux-gnu/libicudata.so.72 (0x00007f2f50c00000)
libcap.so.2 => /lib/x86_64-linux-gnu/libcap.so.2 (0x00007f2f54089000)
libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f2f52cb9000)
libcap-ng.so.0 => /lib/x86_64-linux-gnu/libcap-ng.so.0 (0x00007f2f53946000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f2f5393f000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f2f5340d000)
libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f2f50a62000)
libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x00007f2f53052000)
libunistring.so.5 => /lib/x86_64-linux-gnu/libunistring.so.5 (0x00007f2f508b2000)
libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f2f5303d000)
libnettle.so.8 => /lib/x86_64-linux-gnu/libnettle.so.8 (0x00007f2f52c67000)
libhogweed.so.6 => /lib/x86_64-linux-gnu/libhogweed.so.6 (0x00007f2f50869000)
libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f2f507e5000)
libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f2f529d8000)
libffi.so.8 => /lib/x86_64-linux-gnu/libffi.so.8 (0x00007f2f53031000) -
Ja som to pochopil tak ze tam riesi preco nemate nieco co je uz uplne bezne na Linux-e.
Jaily jsou na FreeBSD od 1999. On si (podle té prezentace) chtěl jen napsat obslužné skripty pro zacházení s jaily. To jsem si psal taky, ale nakonec je pro mě lepší vše dělat sám, ručně. Jak se zfs, tak s jaily, tak s pf. Ale tak to prostě je, někdo má rád obslužné skripty, já se vždy vracím přímo k jednotlivým příkazům, které stejně musím znát i z jiných důvodů, než jen pro jaily. Takto jsem to dělal i s nspawn a btrfs na linuxu.
dependcy postgres-u a to je command line ziadne GUI
A přitom není žádný problém psql klienta distribuovat jako klasický balíček, že?
-
> A přitom není žádný problém psql klienta distribuovat jako klasický balíček, že?
Ano ale skuste si predstavit ze to mate dostat na 2 rozne distribucie Debianu, 2x RedHat, Ubuntu, Suse, ... security updaty, vsade nejako drzat tie verzie kniznic a to nie je ziadne burlive prostredie ako napriklad GUI, GNOME, ...
-
Ale tohle přece není žádný problém už 20+ let.
A pokud to je problém, tak by se před ním nemělo utíkat a měl by se vyřešit.
Proto jsem se zmínil o golangu. Prostě se mi nechtělo řešit distribuci python (resp. ani jedno používané řešení se mi nelíbílo), tak jsem si vybral jazyk, kde tohle řešit nebudu muset.
Tohle je snad základ každé činnosti. Chci něco dělat pro nějaké linuxové distribuce, tak by si na začátku měl najít nejvhodnější řešení. Je to prostě součástí práce.
-
Golang je svet sam o sebe. Preto je aj napr. tolko GUI aplikacii v golangu, vsak? Na a golang aplikacie dependencies riesia ako? No predsa vendoringom...
No a to je ten isty problem aj inde. Akonahle zacnem pouzivat ci uz systemove kniznice/sluzby, alebo kniznice/sluzby tretich stran, tak potrebujem mat nejaku stabilnu zakladnu, nemoze to byt v nahodnej verzii. Vo svete apple a windows mame verzionovane sdk, takze ked je nieco zbuildovane voci danej verzii sdk, viem na akom systeme vysledok pobezi a na akom nie.
V linuxe taketo nieco mozem dosiahnut len s flatpak runtime (a hry zase mozu targetovat steam runtime). Lubovolna ina distribucia je v stave "co je prave nahodou na systeme nainstalovane" a na 99% neprenosne inde. Preto napr. aj Google si do Chrome staticky zalinkuje kopec veci, co inak riesi distribucia.
-
Jan HrachStříbrný podporovatelJeště to pomůže při opravách když se najde chyba v něčem co používají všichni, z nedávné doby libcurl, openssl nebo libpng.
-
Opravdu? Takže třeba budete k té statické libc linkovat třeba i SecurID PAM modul, pro případ, že ho target podporuje? Jinak z toho vznikají dost ošklivé věci, jako že staticky přilinkovaná libc si dynamicky linkne pam nebo nss modul, kterej si pak opět dynamicky dolinkuje libc z cílového systému...
Ono je to docela složitější než to vypadá.
-
> To, že nemáme zvukové karty schopné hw mixování streamů a dohání se to v SW, rozhodně nepovažuji za výhru. Tohle jsem vyřešil více kartami a mixážním pultem.
My sme mali zvukove karty, ktore robili hw mixovanie streamov a prestali sme s nimi. A preco? Pretoze je efektivnejsie zmixovat streamy na CPU a cez PCI (vtedy) / PCIe (dnes) prehnat jeden stream, ako ich nemixovat a cez zbernicu prehanat vsetky streamy. Navyse je to vo vysledku jednoduchsi/lacnejsi hardware a flexibilnejsi vystup (nevie karta mixovat 32 bit float? takovyhle nestesti... . softver s tym problem nema).
-
Nevím, jak je do dnes, ale už první karta SB Audigy uměla mixovat 64 streamů.
U těch SW mixérů typu Pulse Audio je / byl ten problém, že se kvalita (samplerate, bitrate) nastavil podle prvního streamu a potom se vše převádělo na tento formát. Takže první stream je dejme tomu systémový zvuk 44.1/16, k tomu si pustíte hudbu a máte to přesamplované do 44/16. Ano, dá se nastavit na jeden default typu 96/24 a potom se vše sampluje do vyššího formátu. Jenže s tím jsem měl ten problém, že kvalitní resampler zase často realtime nestíhal. Takže na nějaký default typu 192kHz jsem mohl rovnou zapomenout. Nakonec vyřešeno třemi kartami a analogovým mixákem. Resp. jedna zvukovka vyhrazená pouze pro sluchátka.
-
Original GUS (s ISA zbernicou) vedel 32 streamov, ale s kompromismi: 44.1 len so 14 streamami, potom s poctom streamov klesala frekvencia. Plus bolo treba najprv uploadnut cast streamu do jeho RAM a az z nej sa mixovalo, co zvysovalo latenciu. Mal podporu v hw pre circular buffer, takze sw si mohol vyladit, aky velky ma byt ako kompromis medzi latenciou a dropoutami a ci mam na zbernici dost miesta.
Pulse Audio pokial si dobre pamatam, nastavovalo frekvenciu podla vystupu. V tom case mali karty problem s hodinami, nedalo sa na ne spolahnut, tak sa pouzival systemovy timer a ignoroval na strane vystupneho zariadenia. V tej dobe som mal pocitac s atomom (pineview) a ion2, ktory tvrdil, ze vie 44.1 kHz, ale realne nevedel a mal som dropouty. Po nastaveni fixneho vystupu na 48 kHz uz bolo vsetko v poriadku a aj original atom stihal vsetko resamplovat bez nejakej vyznamnej zataze.
Samozrejme, pokial si niekto zapne zbytocne "kvalitny" resampler urceny na offline processing, tak bude mat problem. Zbytocny.
-
Jan HrachStříbrný podporovatel
> To, že nemáme zvukové karty schopné hw mixování streamů
Já PA používám hlavně kvůli tomu, abych mohl nahrávat zvuk nějaké aplikace jinou aplikací. To v Alse šlo pomocí snd-aloop modulu, ale pak jsem ten zvuk současně nemohl slyšet. To nějak souvisí se zvukovkou? Přijde mi to jako plně softwarová věc vyžadující přesně takového démona. (nevyznám se v tom)
-
1. Já bych také byl raději, kdyby karty hw-mixovaly a nemuselo se to šudlit softwarově. Ale tak to holt je, funguje to pro mě přijtelně a vedlo to ke zlepšení uživatelského komfortu.
2. Wine není a nikdy nebude výhra. Výhra by byla, kdyby Mrkvosoft nebyli pitomci a s příchodem Vulkanu (tehdy se jmenoval tuším AMD Mantle) neuhňácali vlastí uzavřený sajrajt jménem D3D12. Ale dostatečně dobře kompenzuje tuhle mizérii.
3. Sorry, ale "diskový" prostor už DÁVNO není problémem, takže mě flatpak nevadí. Jasně že to není optimální či elegantní řešení, ale je elegantní pro určité situace. Opět vede ke zlepšení komfortu.
Bytheway dneska jsem na jednom stroji s wokenicemi potřeboval GIMP a nemám tam admina. Jak krááásně pohodlné bylo jej tam nahodit přes MS Store. Vůbec nevím, co/jak/kam to udělalo a jestli to šlape o něco pomaleji než nativní aplikace od GIMPu, ale hlavně že to funguje a sátlo mě to přesně 5 sekund času.
Ke FreeBSD nemám co dodat. Krásnej systém, dokumentace, pořádek. V Linuxu je neustále se měnící bordel, to víme. Ale pro desktop imho lepší varianta než FreeBSD / openIndiana / cojávím.
-
Ad 2. Bohužel Vulkan přišel pozdě. Jako poslední, po Apple i Microsoftu. A zrovna v Linuxu se nemají čím chlubit, kdy pro spoustu GPU byly ovladače funkční pozdě, pro některé bez chyb nikdy. Jinak podle mě je WINE výhra, protože hry jsou typ software, který se po krátkém čase přestane aktualizovat. Takže nakonec stejně skončíš s konverzní vrstvou. Dnes v Linuxu i třeba kvůli Waylandu.
-
Sorry, ale pokud D3D12 přišlo o pár měsíců před Vulkanem, tak to neberu jako argument. Microsoft do toho začal šlapat až když viděl tu low-overhead věc od Apple (Metal?) a AMD (Mantle), což bylo tak rok 2013. Tady prostě nelze udělat nic jiného, než naprosto adorovat zejména AMD, zhruba podobně jako za Freesync.
Microsoft se možná zlepšuje, ale přesto si pořád drží monopol záměrně uzavřenými a vendor-locknutými formáty jako právě D3D12 či novější verze OOXML (které mají s tou ISO/ECMA věcí minimum společného).
-
To nie je celkom tak pravda.
Prvy prisiel ako pracovna verzia Mantle, s tym, ze skoncil ako Vulkan. Aj Apple, aj Microsoft videli, ze musia rychlo urobit nieco alternativne, a aj urobili. Metal vo v1 bol nedorobok, minimum viable product, ktory nevedel ani obsluzit GPU bez UMA (a o manazmente bufferov je vlastne to API). Az vo v2 poskytoval to, co Vulkan v 1.0.
-
Ad 2) MS má Direct X od Windows 95. Opravdu nemají důvod se vzdávat vlastního řešení. Herní vývojáři si mohou vybrat, jestli DX nebo OpenGL / Vulkan. Opravdu bych nevyčítal MS, že se snaží vylepšovat svůj vlastní systém.
Mimochodem, autor Falloutu, Tim Cain, má vlastní YT kanál, kde vysvětluje co jak a proč dělal. Převést Fallout na jiný OS ho stálo přepsání jedné knihovny. Ve stejné době John Carmack své hry vyvíjel na zcela jiné platformě, než byla ta cílová. Takže klidně na NextStepu psal pro DOS. A dělal to právě proto, aby se zbavil závislosti na konkrétní platformě.
Ad 3) Já to ale vůbec nepsal vzhledem k místu nebo velikosti disků. Jedná se mi o systémový pohled na věc. Kontejnery jsou prostě blbé řešení nějakého problému. Je to stejně blbé řešení, jak v MS světě, kdy si appky tahají konkrétní dll s sebou.
MS Store používám od přechodu na W11 a prostě funguje. Instaluje nativní appky. Je to prostě jejich verze balíčkovacího systému.
A nejsme ve sporu. Ty se na to díváš z hlediska uživatelské přívětivosti a to já beru. Já jsem myšlením technik a mě zajímá, jak ty věci fungují za oponou. A nejsem spokojenej s řešením typu "zavřeme to do pěkně vypadající krabičky a je to, dovnitř nikdo neuvidí".
