Názory k článku
SUSE možná bude opět na prodej, za 6 miliard dolarů
-
Asi vsetko. Ked uz konecne zacalo bez problemov fungovat PulseAudio, tak sa to muselo prepisat na PipeWire a znovu absolvovat vsetku torturu. Inak ze nejde audio je asi najcastejsie co pocuvam od ludi co si instaluju Linux. Na mojom notebooku cca pri kazdom 5 zobudeni bolo treba restartovat PipeWire aby isiel zvuk. Staci si pozriet ako elegantne to ma vyriesene freeBSD cez OSS, nikto nebude zbytocne vymyslat nieco nove ked to overe funguje.
-
Jenže nefunguje.
1) OSS neumí blutooth. Takže s bezdrátovými sluchátky máte smůlu.
2) OSS není realtime, takže neumí nahradit Jack pro lidi co pracují se zvukem.
3) OSS neumí posílat výstup jedné aplikace do vstupu druhé, takže neumí nahradit PulseAudio ani Jack pro lidi co pracují se zvukem.4) Minimálně na linuxu OSS neumělo ani mixovat zvuk z několika zdrojů, proto taky mimo jiné vznikla ALSA.
A PipeWire řeší i synchronizaci s obrazem a spoustu dalších věcí. Neříkám, že nebyly bugy, ale jelikož zachovává API jak PulseAudia, tak Jacku, tak je to velice užitečný kus software.
-
Michal ŠmucrStříbrný podporovatel
Není úplně nemožné rozjet na FreeBSD bluetooth sluchátka, ale je to mírně řečeno docela opruz. Musí se použít emulace OSS rozhraní přes software virtual_oss, což běží jako normální proces. Takže pokud se všechno dobře povede, skončí to např. jako /dev/dspNĚCO, kam se pak pošle z aplikace zvuk.
A podle hardwaru se ještě můžeme dál bavit o alternativních kodecích nebo používání celého headsetu s mikrofonem, opakovaném připojování atp.
V rámci zachování duševního zdraví bych spíš volil ten 3.5 mm jack :)Rozhodně je to za mě spíš mimózní debata, OSS se řešilo tak před 25 lety zpátky. Vůbec by mě upřímně nenapadlo dávat to jako nějakou referenci použitelnosti nebo audio subsystému, co vyhoví nějakým soudobým požadavkům. A hlavně to OSS má úplně jiný fokus (je to nízkoúrovňové) než framework typu PipeWire s dynamickou konfigurací přes WirePlumber.
-
Notebook možná 3.5' jack má ale velká část uživatelů už dnes sluchátka s jackem nepoužívá. Osobně mám dvoje -- Pixel Buds Pro 2 a jedny AKG (něco) -- oboje jsou špunty a oboje mají akorát BT. S tím, jak se BT výrazně zlepšil a mobily přestaly jack mít, přešlo hodně lidí na bezdrát. Kabelová sluchátka dnes (dle mého) spíš používají spíš audiofilové (nemyšleno ve špatném). Pro běžného uživatele rozdíl mezi Bluetooth a kabelem většinou není zásadní a tahat někde něco jiného než špunty a kabel k tomu je akorát zátěž navíc.
-
Kabelová sluchátka (nebo záložní kabel k bezdrátovým) používám naprosto pravidelně, když se zase Teamsy rozhodnou stávkovat. Je to evidentně softwarový problém, protože sluchátka v některých softwarech fungují a v jiných ne.
Naproti tomu kabel funguje naprosto spolehlivě. V jednoduchosti není jen síla, ale hlavně spolehlivost.11. 3. 2026, 17:32 editováno autorem komentáře
-
Michal ŠmucrStříbrný podporovatel
Jak píše Kate, byl opravdu rozdíl mezi OSS implementací, která byla v Linuxu někdy před těmi mnoha lety, co ji nahradila následně ALSA, a pak tou proprietární verzí OSS 4. Ta měla pak víc funkcí, včetně toho míchání, šla na více různých unixových systémech, ale stejně to bylo brzy passé.
A stran toho současného FreeBSD, tam je audio subsystém, co je s OSS kompatibilní, ale také nevychází přímo z téhle původní implementace.
https://man.freebsd.org/cgi/man.cgi?sound
Umí i míchání. Při přístupu z každého klienta na devnode se vytvoří interní virtuální kanály a pokud je tam odlišná vzorkovací frekvence, vřadí se dynamicky resampler atp.
Celé to běží jako kernelový modul (což má logicky své výhody i nevýhody). A ovládá se, pro BSD typicky, přes sysctl a systémový nástroj mixer. Virtuální zařízení a případné složitější věci se dají řešit právě přes nástroj virtual_oss, který to dokáže audio dostat z a do userpace přes další vytvořené devnody, což je pak přesně ta volba např. pro integraci s bluetooth zařízeními.Takže taková evoluce "klasického" přístupu (Strana mírného pokroku v mezích zákona). Což samozřejmě může i někomu vyhovovat. Ale s většinou současných požadavků to prostě začne dřív nebo později narážet. Ať už právě v souvislosti s bluetooth zařízeními, různými síťovými audio streamy (AoIP), synchronizací z různých zařízení atp. Dál se u tohohle low-level přístupu relativně spatně řeší různé vcelku běžné hot-plug situace, které prostě nutně vyžadují další mezivrstvu a veškerý plumbing okolo.. (ano, FreeBSD má devd, což je ekvivalent udev na Linuxu, a dají se napsat různé helper skripty okolo.. ale dost často to stejně znamená znovu spustit X uživatelských procesů a aplikací, aby zjistily, že nějaké zařízení přibylo nebo naopak zmizelo).
Neřkuli jakmile se zabrousí do nějaké izolace a řízení přístupů z více klientů (což byla jedna z hlavních věcí při přechodu z PulseAudio na PipeWire).Nakonec stejně i na FreeBSD je hromada současných aplikací, které prostě už nepodporují OSS zařízení, takže je tam stejně nutné - "drumroll please" - nainstalovat jako závislost port PulseAudio nebo PipeWire, co pak použije OSS backend.. :)
-
Byly distribuce, kde PipeWire ze začátku blbě fungoval, ale nebylo to ani tak PipeWirem, ale tím, že to měly blbě integrované. Ve Fedoře to dělal přímo Wim Taymans, autor PipeWire, takže tam s tím byly minimální problémy od začátku.
Jsem celkem překvapený, že se najdou lidi, kteří na PipeWire nadávají. Přitom to byl ukázkový přechod z PA, když implementovat jeho API a byl to prostě drop-in replacement, který nic nerozbil. Navíc velmi dobře nahrazuje i JACK a řeší plno věcí, které se dnes po zvukovém serveru chtějí. Četl jsem dost názorů od lidí z branže, že tímto se Linux dostal na špici peletonu. Ale asi se prostě nedá zavděčit všem... -
aliumBronzový podporovatel
stejně tak to mám i já v archlinuxu. naprostá spokojenost, funguje úplně bez problémů. přechod bych úplně triviální a hlavně vše fungovalo bez nutnosti nového nastavování. Jak jsem se pipewiee děsil, co zase nového, tak jsem spokojený.
-
Nějaké problémy s přechodem jsem zaznamenal, ale to bylo nejspíš tím, že jsem v té době používal testing/unstable balíky, takže se to dalo očekávat.
Nechci to zakřiknout, ale teď s PW není problém. Naopak s PA jsem měl (s Bluetooth sluchátky, na kabelu ok) problémy furt, co chvíli to nehrálo, nebo to hrálo jinam než mělo, nebo se sekal zvuk. -
Mozno je problem ze v zivote ma nenapadlo pouzivat na notebooku bluetooth sluchatka, staci ze to musim pouzivat na hnusnom iPhone :-) Inak kablovych sluchatiek musi mat doma kazdy mnozstvo, kedysi sa to pribalovavo ku kazdemu mobilu. Bola to krasna doba clovek dostal peknu krabicku, navod, nabijacku a sluchatka...
-
Já nemám třeba ani jedny, protože to co chodilo s mobilama nebyly sluchátka. Možná tak dobrý na hovory, ale hudba se na tom fakt poslouchat nedala ;-). Jinak za mě to byla doba zbytečného plýtvání -- nabíječky používám už pár let GaN (ještě dřív než to bylo in v ČR) s více portama (protože z toho můžu nabít prakticky cokoli a nemusím sebou tahat 5 nabíječek), sluchátka mi vydrží několik let a návod mě přijde v dnešní době jako plýtvání papírem (u mě většinou letí, protože místo toho abych tu skladoval někde fyzicky to radši skladuju v PDF kde mi to nezabírá fyzický prostor)
-
> Mozno je problem ze v zivote ma nenapadlo pouzivat na notebooku bluetooth sluchatka
Na hlavním PC mi jde zvuk Pipewire -> M-Audio Air 192/6 -> Austrian Audio Hi-X60 sluchátka :) A fakt si to nedovedu vynachválit. Občas potřebuju low latency a patchbay, a zatímco nastavit Jack byl porod, Pipewire "Just works". K tomu EasyEffects a možnost snadno přidat ekvalizér, přihodit potlačení hluku k mikrofonu...
-
PipeWire rozbilo některé PulseAudio pluginy, protože prostě nebyly. Ale to byla záležitost spíš speciálních zařízení a power userů. Myslím, že jsem na to narazil, když jsem zkoušel autodetekci DLNA endpointů a pouštění zvuku do nich, jako by to byla normální zvukovka (z hlediska aplikace).
Ale jinak jsem taky problémy neměl. Na Fedoře.
-
V podstatě všude mám SELinux, ale v čem byl AppArmor lepší, že by byl přechod Leapu na SELinux problém? S PipeWire jsem též problém extra nezaznamenal proti PulseAudio.
YaSTu je škoda, tam mě mrzí, že než aby ho zkusili nějak modernizovat, dají jako alternativu Myrlyn + Cockpit (kterej jinak u EL systémů používám). Zase pokud nemají lidi / zdroje na údržbu v komunitě a není tam poptávka ze strany zákazníků SLESu, asi se těžko dá čekat velký rozvoj věcí jako YaST.
-
Michal ŠmucrStříbrný podporovatel
Měl jsem to i u předchozích verzí skoro přesně naopak :)
YAST jsem používal víceméně jen při instalaci a pak opravdu výjimečně, protože jsem to spíš ručně editoval v /etc/sysconfig a na na balíčky používal buď Zypper nebo nějakou graf nadstavbu (GNOME Software přes PackageKit nebo teď Myrlyn). AppArmor jsem na serverech přepínal na SELinux a místo Wicked pak stejně používal NetworkManager.Ale AppArmor je pořád podporovaný a součástí jádra, jen se musí explicitně povolit.
https://en.opensuse.org/How_to_switch_from_SELinux_to_AppArmor_in_Leap_16
Jinak docela chápu, že to přehodili ve výchozím stavu. Je to podle mě lepší i přeneseně pro SLES jako platformu na software od externích dodavatelů, kteří dost často cílí právě na SLES a RHEL. Takže je poměrně velkou výhodou, že je tam společná a kompatibilní systémová MAC vrstva pro kterou se dají psát společná pravidla a mnohem jednodušeji udržovat balíčky na obě platformy.Z obnovováním ze snapshotu jsem problémy nezaznamenal a to Leap používám na některých testovacích strojích v podstatě, co se objevily první image 16. Pokud tedy myslíme totéž - Btrfs a Snapper navázaný na Zypp a následné bootování a případný revert.
A ano ten začátek Leap 16 byl divoký. Jak s buildováním a aktualizacemi balíčků (což trvalo několik měsíců, než se to usadilo), tak třeba s migračním nástrojem z 15.6. Ale už mi to přijde v pohodě.
Ten unifikovaný webový instalátor Agama je docela omezený, takže třeba pokročilejší rozložení disků a mdraid jsou problém (v podstatě se musí řešit manuálním bootstrapem bez UI), ale uvidíme, kam se to případně posune.Pipewire+Wireplumber je standard a v oblasti audia výrazně lepší než kdy bylo Pulseaudio, které už se stejně nevyvíjí, takže změna byla stejně potřeba (a bylo to výchozí už 3-4 roky i v předchozích Leapech).
11. 3. 2026, 11:08 editováno autorem komentáře
-
si nic ine nazasluzia...
Nechci vám kazit škodolibou radost, ale tohle není žádná "jobovka", jak si asi představujete. (Pokud se to tedy potvrdí.) EQT není softwarová firma, je to fond, který nakupuje firmy z různých oblastí, aby je po pár letech zase prodal za vyšší cenu. Od začátku jasně deklarovali, že tohle mají v úmyslu i se SUSE, takže tahle zpráva by neznamenala nic jiného, než že všechno jde podle plánu.
-
Ja naopak SuSE nikdy moc nemusel, byla to vzdy takova spatna kopie RedHatu s divnym YAST co rozdrbal co mohl ;-)
AppArmour co si vzpominam delal vzdy spise problemy a to i na Ubuntu.
Zajimave bylo, ze SuSE se pak pripojil do iniciativy delat klon RedHatu vcetne updatu pote, co se zmenil CenOS - i kdyz jsme to ve firme nechapal, nebot oni porad, ze pry rolling updates nejake beta verze, ja jimriakl, ze i bveta by byla stabil;nejsi nez Ubuntu ;-)
Ale hlavne se toho tolik nezmenilo - jen ze nejsou sub-verze - coz temer nikdo nepotrebuje, tedy ze v9 je vzdu posledni v9 a ne 9.x - stejne jsev vzdy davat dnf/yum upgrade a ne update - ja vzdy posledni release chtel - vim ze jen nektere Oracle hodne davno vyzadovaly pockat na opatchovani Oracle.
Nakonec nevim jak to dopadlo, asi nijak, Oracle ma dele svuj klon centosa, a posilila se alma linux a rocky linu ... s tim ze Alma je vice RHEL a Rocky je vice OracleLinux - vcetne Oracli verze zdileneho FS mezi nody a podpora BTRFS
-
BuldrZlatý podporovatelMinimálně Německo mělo SUSE (STIG) nasazené u multidoménové obrany (Hensoldt). Jestli i dnes, netuším, ale dá se to víceméně předpokládat.
ČLÁNKY DO MAILU