Co nového přinese Fedora Workstation 34 (diskuse)

[Marťan]

A bude to umět přehrávat po téměř 30 letech mp3 OOTB?

[RB]

Dobré ráno, Marťane, MP3 už umí přehrávat 4 roky.

[Marťan]

Out of the box (feature) From Wikipedia, the free encyclopedia Jump to navigationJump to search An out-of-the-box feature or functionality (also called OOTB or off the shelf), particularly in software, is a feature or functionality of a product that works IMMEDIATELY after or even without any special installation WITHOUT ANY CONFIGURATION or modification.[1][2]

Skutečně?

[RB]

Ano, skutečně.

[Marťan]

Příloha:

• dukaz.png (10247 bytů)

Ale ve Firefoxu mi mp3 seká a celej ten Firefox je hroznej. Trvalo mi 2 minuty než se ten krám spustil, mezitím jsem musel odkliknout 10 oken s textem firefox běží ale neodpovídá. A mp4 neotevře vubec a přikládám foto jako dukaz.

[Dušan]

Si si tým istý že vieš o čom hovoríš?

h264 nieje mp3

ps.Sťažuj sa na patentové právo.

[RB]

Ale ve Firefoxu mi mp3 seká a celej ten Firefox je hroznej. Trvalo mi 2 minuty než se ten krám spustil, mezitím jsem musel odkliknout 10 oken s textem firefox běží ale neodpovídá.

Schválně jsem si tu Fedoru kvůli tobě stáhl. V livku, tedy naprosto out-of-the-box prostředí, dám v prohlížeči vyhledat "sample MP3 file", Firefox přehrává, dám stáhnout, poklikám, otevře se v GNOME Videos, přehrává se, dám otevřít ve výchozím hudebním přehrávači (Rhythmbox), přehrává se. Všude úplně bez problémů a sekání. A to prosím na roky starém počítači s i3 a 2 GB RAM. Jestli se ti to seká a Firefox nereaguje, tak to musí být nějaká 486, ne?

A mp4 neotevře vubec a přikládám foto jako dukaz.

O MP4 snad nebyla řeč, ne? Ale ok, předpokládám, že v tom MP4 se schovává ten nejrozšířenější kodek - H.264 (protože tam může být téměř cokoliv). Dám vyhledat "sample H.264 file", stáhnu, otevřu v GNOME Videos a ano, dostanu onu hlášku o chybějícím kodeku, kliknu tedy na "Find in Software", tam kliknu na "Install" a video se mi přehrává. Není to úplně OOTB, ale na dvě kliknutí. Úplná tragédie.

[Jardík]

Nevíte, jestli ten jejich nový zvukový server dokáže správně přepínat mezi sluchátky a line out, i když jsou sluchátka zapojena?

[petr_p]

Když si pořídíte orákulum do PCI-E sběrnice a zavede pro něj 64bitový zásuvný modul do nového zvukového serveru, tak samozřejmě že dokáže uhádnout, jestli chcete poslouchat na sluchátkách, nebo line-out.

[Monarcha]

Jako třeba používat externí zvukovku na dedikované kartě přes DisplayPort kde je externí monitor a přes jeho IN zapojené repro a nezavisle poslouchat přes interní přes sluchátka a to oboje s rozdílnou hlasitostí a k tomu mít možnost nastavit hlasitost pro aplikaci?

Tohle používám na Windows 10. Nebo jinak?

[Monarcha]

jeho OUT

[Josef Kufner]

PulseAudio takovéto šílenosti zvládá. Měl jsem tak puštěné efekty hry lokálně na reproduktor notebooku a hudbu po síti na pořádné reproduktory jiného počítače. Také není problém používat na vstup mikrofon z bluetooth headsetu, ale zvuk přehrávat na reproduktory. Pipewire by toto měl umět také.

[Martin Mareš]

S tím, jaké šílenosti PulseAudio zvládá, bych byl opatrný. Podle dokumentace by je zvládat mělo, ale už roky se mi děje, že kdykoliv si vymyslím nějakou složitější konfiguraci, to skončí pádem daemona na nějaký assert. Chvíli jsem bugy zkoušel lovit, ale dospěl jsem k tomu, že při tom, jak je to celé napsané, je to naprosto sysifovská práce.

Tak se velmi těším na Pipewire, snad je navržený lépe.

[Josef Kufner]

Poslední dobou (posledních pár let) se ta stabilita docela zlepšila. To, co popisuju, je jen přehazování streamů sem a tam, nic komplikovaného.

[Martin Mareš]

Přehazování streamů funguje dobře. Ty mé problematické konfigurace byly obvykle věci typu "vezmi 2-kanálový stream, rozdvoj ho na dva 2-kanálové, na každý z nich aplikuj jiné filtry, a pak to pospojuj do 4-kanálového streamu a ten pošli do zvukovky". A PA se nebylo schopné smířit s tím, že různé cesty se stejným začátkem a koncem mají různou latenci. (Aneb takhle to dopadá, když se jeden pokouší používat 4-kanálovou zvukovku jako dvě 2-kanálové :) )

[trekker.dk]

Instaluju nový desktop, který nebude můj, tak se o to nechci moc starat. Tj. ideálně všechno výchozí tak, jak je to v distribuci. Debian, instalátor nabízí Xfce desktop, pulseaudio je výchozí. Akorát je potřeba duplikovat výstup jak na integrovanou zvukárnu, tak na HDMI. Hledám na netu, je na to nějaký plugin combine-sink. Přidám do konfigurace, dokonce to i hraje, teda aspoň na té integrované, HDMI teď nemůžu vyzkoušet. Následuje pár kliknutí v pluginu na správu hlasitosti, pulseaudio padá a poroučí se, ticho.

Nic moc.

[Monarcha]

A je nutné číst vývojářskou dokumentaci a následně editovat soubor?

[Monarcha]

Vím teda, že nešlo používat VLC a Kaffeine na stejne zvukovce s jininou hlasitostí protože obě visely na stejné libvlc, to libvlc se přímo ukazovalo u šoupátka v systemovem nastavení zvednuti hlasitosti ve VLC pulse zvedlo i hlasitost Kaffeinu a protože externí repro mají i dosti výkonný zesilovač .. navíc byla skoro všední noc.

[Josef Kufner]

Vůbec ne. Dá se to naklikat v pavucontrol. Jen ten tunel se musí spustit z shellu, na to GUI není.

[Josef Kufner]

... Tedy pokud se nezapne zero-conf autodiscovery, pak se okolní počítače objeví automaticky jako další zvukovky.

[Jardík]

Já mám prostě problém to rozumně rozchodit. Co potřebuju je, abych měl normálně použitelný line out výstup z integrovaný zvukovky zároveň se zapojenými sluchátky na předním panelu (taky vyvedený z desky).

Pokud mám vypojený sluchátka, line out normálně hraje. Pokud zapojím sluchátka, PulseAudio přepne default výstup na sluchátka (o tuto automatiku nestojím, neustále to i po restartu přepíná na sluchátka a nepamatuje si, že poslední byl line out). Alsa zároveň udělá při zapojení sluchátek automute na line out. Vypnul jsem tedy v alsamixéru automute a přepnul zpět na line out v pulseaudiu. Line out pak normálně hraje. ALE. Když pulseaudio přepnu na sluchátka, tak mi provede to, že nastaví hlasitost, co byla naposledy nastavená na sluchátkách, zároveň nastaví tuto stejnou hlasitost na line out, přepne default na sluchátka, ale výstup zároveň duplikuje do line out. To nechci. Chci jen, aby "default" výstup hrál jen na sluchátkách a v line out jen to, co explicitně na line out nastavím. A pak zase naopak. Když přepnu default na line out, chci, aby mi vše hrálo v line out a na sluchátkách zároveň to, co explicitně nastavím na sluchátka.

Chci, aby oba výstupy byly nezávislé jeden na druhém, co se týče hlasitosti i výstupu zvuku a libovolně měnit default bez změny hlasitosti obou výstupů najednou. A to je hrozný problém.

[Dušan]

Uvidíme či to pipewire vyrieši.

[Josef Kufner]

Tohle je reálně neřešitelný. Když to opraví tobě, tak to rozbijí někomu jinému. Asi se budeš muset ponořit do zdrojáků a opravit/nastavit si to sám

[frufru]

Fedora 34 Beta jsem zkoušel. Nainstaloval RPM ovladače tiskárny a jako jediný linux netisknul ani neskenoval. A si 5x něco spadlo při startu. Chtělo to odeslat nějakou zprávu do bug... Byl jsem pro. 2x už to bylo hlášeno a 3x ne. Bohužel nutnost přihlášení zamezila nahlásit ty tři problémy.

[Frank]

To nejsou pády, ale ve většině případů warningy, třeba z kernelu. Ten jich generuje hromadu. Něco nefunguje optimálně, ale uživatel by to ani nepoznal, kdyby si toho ten hlásič problémů nevšiml.

[AsciiWolf]

Byl tam menší problém, ale v upstream kernelu i aktuální F34 je již opraven.

[Monarcha]

To nejsou pády, ale ve většině případů warningy, třeba z kernelu.

Omlouvám se za BFU dotaz, to značí něco shnilého u kernelu (zastaralost) nebo u aplikace (nedozralost)? Jinak z meho poznání, jsem nezažil že by po čerstvé instalaci jakéhokoliv stable linuxu se neplnily log soubory nějakými warningy, jakoby to nikdo vlastně neopravoval v době před vypuštěním.

[petr_p]

B je správně. Autoři Gnome zásadně vydávají nové Gnome a okamžitě je začleňují do Fedory pár týdnů před vydáním Fedory. V případě Fedory 34 se jedná o aktualizaci s Gnome 40, která vznikla před pouhými 2 týdny.

[AsciiWolf]

Zatímco třeba takové Ubuntu je již v době vydání v mnoha ohledech zastaralé a ještě hůře je na tom většina balíků v universe, které se často nikdy nedočkají žádné aktualizace ani opravy zásadních chyb. Ve Fedoře jsou oproti tomu všechny balíky aktivně udržované a chyby bývají opravovány poměrně rychle.

[petr_p]

Vaše a moje představa o rychlosti opravy je asi jiná. Moje zkušenost s gnomáckými balíky ve Fedoře je, že i když v chybovém hlášení ukážete konkrétní patch z upstreamu, který chybu opravuje, tak jim je to úplně jedno. Oni v podstatě jen přebalují upstreamové releasy. Backportování oprav je pro ně neznámý pojem. A když máte tu smůlu, že upstream vydává jen s novým Gnome jednou za půl roku, tak kdybych neměl právo šahat do každého balíku ve Fedoře a neudělal si to sám, tak bych se nedočkal. Příklad s glib2. Jestli v Ubuntu je to ještě horší, tak to jsem rád, že jsem Ubuntu nikdy nepoužíval.

[Frank]

Tak si ten nástroj otevřete a podívejte se. Máte tam seznam posledních událostí. U aplikací AFAIK ten nástroj žádné warningy neodchytává, u nich odchytává jen pády a k těm dochází zřídka (v porovnání s těmi hlášeními z kernelu).

[Monarcha]

Chtělo to odeslat nějakou zprávu do bug..

Tam se instalovaly i debug balíky?

[Jardík]

Toto je největší problém dnešní doby. Narazíte na padačku nebo jiný bug, chcete ho hlásit, ale nakonec to neuděláte, protože si prostě někdo usmyslel, že se pro hlášení chyby musíte registrovat a zapisovat si někam další složité heslo, aby vás mohli sledovat, nebo co. Proč v dnešní době nejde nic "anonymně".

[Michal Kubeček]

Anonymně nahlášené bugy jsou až na výjimky úplně k ničemu. Vývojář se obvykle potřebuje zeptat na dodatečné informace, potřebuje spustit další testy, otestovat potenciální opravu atd. Uživatel, který nemá ponětí o tom, co taková práce na opravě obnáší, si představuje, jak cenná je informace "když spustím program X, tak spadne" nebo rovnou "máte to úplně rozbitý, vždyť to ani nenabootuje", ale běžně to je tak, že ten progam spadne jen za určitých velmi specifických okolností a že "to ani nenabootuje" jen při použití konkrétní podverze konkrétního hardware - a ještě třeba jen s konkrétní konfigurací. Kdyby to totiž padalo pořád a všude, obvykle by si toho všimli sami vývojáři, kteří většinou daný program nebo distribuci sami používají. A ani vývojář nemusí vědět předem, co všechno bude potřebovat vědět, běžný uživatel to neví skoro nikdy.

Anonymní reporty typu "jsem vám to nahlásil, tak se starejte, měli byste mi líbat ruce, že jsem se obtěžoval" nic z toho neumožňují, takže se s nimi většinou nedá dělat nic jiného než zavřít jako WORKSFORME nebo NORESPONSE. (U Fedory je ještě oblíbená alternativa počkat, až to zavře bot po vydání nové verze.)

[joejoe]

To zavření po dvou letech se bohužel poměrně často děje i u dobře reprodukovatelných bugů, na které vývojáři prostě kašlou..

[RB]

Co se budeme..., většina správců balíčků prostě nejsou vývojáři, jen přebalují, s čím přijde upstream. Ti svědomitější to aspoň tomu upstreamu nahlásí nebo daného uživatele na upstreamovou bugzillu odkážou. Tady se prostě očekávání uživatelů a realita moc nepotkávají.

[Monarcha]

Anonymně nahlášené bugy jsou až na výjimky úplně k ničemu.

Mě by ta registrace tak nevadila (ale taky to považuju za klacek) ale oni očekávají, že se tím nějak dál budu zabývat a následně si nechám spamovat mail roky jako mi dodnes spamuji od KDE z nahlaseneho bugu u KDE4, dokud si neudělám čas a minimálně se z jejich systému neodhlásím.

Co ale považuju za nelogické ten nástroj je spuštěný od instalace i u lidí které to stejně jen nakonec zavřou a že je to otravné. U Windows vypnout službu je mnohem jednodušší.

[Michal Kubeček]

ale oni očekávají, že se tím nějak dál budu zabývat

A přesně tenhle přístup jsem měl na mysli. Děkuji za potvrzení.

[frufru]

Tohle ale nebylo po nějakém spuštění programu. Nainstaloval jsem fedoru 34 beta a provedl upgrade. Po aktualizaci hlásil system 5x problem při staru systemu. Ač jsem chtěl ty problémy nahlásit, tak se nehodlám někam hlásit. Zadal jsem nahlásit a program pro nahlášení chyb projel můj počítač a určitě důležitá data o těch chybách a mém PC si zaznamenal. Nakonec vyskočilo okno, že se mám někam hlásit, nebo se registrovat a hlásit. Shodil jsem to. Má vůle končí tam, kde se musím registrovat a přihlásit se. Chcete data o pádech? Prosím, tady je máte. Když děláte opruz přihlašováním, tak ty data asi nechcete. Mohli mít nahlášené 3 chyby, které se v nahlášených problémech nevyskytovaly. Aspoň se mohli kouknout, kde jim to drhne.

[frufru]

Možná by stačilo, aby se ta data poslala na nějaký email adresu. Pak by se rozhodli, že potřebují ještě něco dodat, tak bych vyhověl. Nesnáším se někde na netu stále hlásit. A bude hůř.

[Frank]

Pokud to chcete nahlásit jako chybu, tak holt účet do bugzilly potřebujete. Nicméně i bez přihlášení to odesílá mikroreporty, na základě kterých to vytváří statistiky nejčastějších problémů, podle kterých můžou vývojáři prioritizovat. Stačí, když to nahlásí jeden člověk a zbytek pošle mikroreporty a vývojáři budou mít k dispozici logy a backtrace a taky informaci, že se ten problém týká třeba 10 tisíc uživatelů. Warningy v kernelu (kernel oops) jdou přímo upstreamovým vývojářům. Pokud člověk nechce být otravovaný těmi hlášeními, může si v nastaveních vypnout notifikace z toho nástroje. Případně úplně ho zakáže příkazem sudo systemctl disable abrtd.service.

[frufru]

Já jsem chtěl zaslat a přispět k lepšímu linuxu. Ty 3 události ještě nikdo nehlásil. Ty dvě už někdo hlásil, ale bylo tam upozornění, že se mají stejně nahlásit, aby se vědělo jak velký je to problém. A to nemám starý stroj. Sestavil jsem si ho v listopadu 2020. Ještě jsem to stačil za levno.

[ajtacka]

Poslušne hlásim, že se behěm mé služby nic nestalo(a nic neopravilo)... :D

Babka k babce, budú kapce.

Alebo strakonický dudák(od slova malé dudy) :D

[Martin Tůma]

Dodatečné informace ale nemají nic společného s anonymitou, nebo dokonce registrací. Ten problém můžu aktivně sledovat a doplňovat i bez registrace.

U svých projektů fakticky taky vyžaduju pro bug reporting registraci, protože jsou hostovány na GitHubu a prostě využívají jeho infrastrukturu, kde to bez registrace nejde. Ale některé korporace - zářným příkladem je SUSE - se vyloženě vyžívají v systému různých samostatných obskurních registrací. Někdy je to až bizarní, například OBS má jiný účet pro projekty, nefunkční, zcela zapadlý, mailing list pro službu a GitHub pro systém jako takový. Přičemž veškeré reporty ještě typicky nějaký nekompetentní SUSE manager ihned zavře a řešit se začínají teprve po reakci na zavření...

[ajtacka]

Má to už aspoň (ako tak v rámci možností) štandard Debianu alebo Ubuntu alebo tento štandard prekračuje?

[ajtak]

Myslíš ten štandard Debianu že ti nefunguje wifi lebo súdruhovia sa tak rozhodli? Tak ten našťastie nie. Čo keď sa nabudúce z pomäteného ideologického dôvodu rozhodnú že nebudú podporovať USB lebo non-free?

[ajtacka]

V dnešných autách je posilňovač riadenia, ale dá sa fičať aj bez toho, ale nie je to pre slabé nátury. Lenže napríklad pri lietadlách je to dosť o hubu bez posiľnovača a ďalších serepetičiek, ale pilot má zvládať aj bez toho.

Lenže v istých situáciách pri lietadle to vyžaduje priam nadľudské schopnosti nielen pilota, ale aj toho stroja. Sú isté typy lietadiel, ktoré sú konštrukčne tak navrhnuté, že sa bez počítača vôbec nezaobídu, hoci isté situácie v leteckom priemysle priam volajú po inom prístupe. Lenže letecký priemysel je zo svojej podstaty vyžaduje isté štandardy. Historicky to tak nie je, ale sú to tragédie(ale aj bez toho).

Lenže pri autách sa to až tak nerieši a niekedy si človek žiaľ nepomôže.

[koroptev]

nova verze?

nove nalosovane bugy, nove regrese starych bugu, nove nepouzitelne ficury zanesene s cilem otestovat RHEL na armade neplacenych libtardu, proste to, na co je clovek u Fedory zvyklej od zacatku

nova verze?

nove nalosovane bugy, nove regrese starych bugu, nove nepouzitelne ficury

To si pleteš s Windows 10, trolle.