Portál AbcLinuxu, 11. května 2025 01:17
Nebo spíš nevytvářet zbytečné technologie, které lidem komplikují život a vrhají špatný obraz na Linux jako celek.Uvědomuješ si, že právě tento tradicionalismus (tipuju z použití slova zbytečné) a absence nového vývoje či řešení letitých prolémů a nepříjemností je důvodem, proč divoké inovátory bere vůbec někdo vážně?
Já si uvědomuju hlavně to, že PulseAudio je vůbec nejčastější problém, co musím lidem na Ubuntu a jiných distribucích řešit. Po jeho eliminaci vše funguje, jak má.Pamatuju si z cca doby vzniku Pulse, že tehdy skoro nikdy nefungovalo nic, jak má. Takže PA opět řešilo (i když třeba blbě) nějakou poptávku, kterou ostatní z nějakého důvodu neřešili nebo jim to přišlo zbytečné.
Třeba to bylo tím, že jsem uživatelem ubuntu a fedory, ale to už já tak mám, že do-do distribuce mě moc neberou.Klidně to mohla být jenom o něco jiná doba. Nicméně je to příliš dlouho na to, abych byl schopný vysypat z rukávu, co to bylo za distribuce. Ale Fedoru (core 2) jsem zkoušel a Ubuntu jsem taky nějakou dobu používal.
zlozitejsie situacieSpíš "nedodělané aplikace". Ale OK. Uznávám určitý přínos PA pro lidi s více zvukovkama, ale přesto bych raději viděl vylepšení ALSA než přidávání další vrstvy. A dokud je v jádře i NFS *server*, tak mi netvrďte, že funkčnost PA do ALSA nepatří
ALSA ani po letech neni schopna vyresit generickou enumeraci zarizeni, ktera se treba nerozbije po zasunuti USB zarizeni ci kabelu HDMITakže je lepšie postaviť nad rozbíjajúcim sa zvukovým systémom medzivrstvu, ktorá keď všetko dobre dopadne zabráni rozsypaniu sa? Mi to dosť pripomína ruskú ruletu.
Ja si ted postavil na bazi Raspberry Pi a PA jednoduchy streaming server. Vse v pohode chodi a uz jen treba integrace PA a zeronconf/mDNS je skvela, chodi to pak out of the box i na iPhonech.To je to, o čem Lennart psal, že k tomu není PA v žádném případě určené?
Může to mít jako systémový démon, jak se domnívášNedomnívám.
a nebo mu to může běžet v session automaticky přihlášeného uživateleÓ jak praktické.
Ale ani s tím systémovým režimem to není tak jednoznačné, jak píšeš.Psal jsem v minulém čase. A byla to taková poznámka bokem, ne námět k tomu, aby se to někdo snažil interpretovat po svém a následně mi oponovat v něčem, co vůbec netvrdím.
[Unit] Description=PulseAudio After=network.target [Service] Type=forking ExecStart=/usr/bin/pulseaudio --system --disallow-exit --disallow-module-loading -nF /etc/pulse/daemon.pa [Install] WantedBy=multi-user.target
Jo /dev/dsp, to je éra před alsou.A ještě hooodně dlouho při alse.
stejně jako PA i alsa sama umí oss emulovatOna ho emulovala včetně exkluzivního přístupu ke zvukovce, přestože měl člověk nastavený dmix jako default - a nevím o tom, že by tuhle megabugu spravili před rozšířením PA.
Nebyl spíš problém v tom, že v té době se ještě vyskytovala spousta aplikací používajících staré OSS, které už teď převážně vymřely? PA má s OSS aplikacemi AFAIK taky problém – musí se použít padsp, nebo ossp (který funguje ale i s ALSA).Lepší marketing :).
Tohle byl totiž ten hlavní důvod, proč jsem před lety přešel na PulseAudio...
A co třeba takové nastavení hlasitosti pro každou aplikaci zvlášť?V tomhle mě dnes PulseAudio přesvědčilo. Během telefonního meetingu jsem omylem dal reloadovat taby ve Firefoxu, čímž jsem aktivoval Youtube a začalo mi to řvát do sluchátek muziku. Než bych našel ten správný tab, tak jsem radši přes ovládání hlasitosti spustil GUI k PulseAudio a vypnul vstup z Firefoxu.
Udělej si v tom prosím pořádek, ano? ReiserFS (je v jádře) != Reiser4 (není v jádře). Linuxová distribuce není kolbiště, kde má být na konci jeden vítěz. Jeho největší předností je rozmanitost. Což ovšem některá jelita dodnes nepochopily.
Pokud jde o toho škodiče Miguela. Je mi celkem ukradený a je pěkné že se konečně našel. Já používám výhradně desktopové prostředí linuxu a nijak si nestěžuji. Nicméně apple rovněž doporučuji:
no niekedy mi to pripadá ako plytvanie silami na niečo čo tu už roky máme.Kdybychom to už tehdy měli, tedy ne naprogramované, ale nasazené v distribucích a denně používané, tak by pro PA nejspíš nebyla příležitost.
ale prečo sa vývojári orientujú na záchranu nejakých kvázi obľúbených vecíProtože jsou to opravdu vývojáři a ne integrátoři. A protože o tom, jak je něco lepší, všichni tlachaj v diskuzích, ale nikdo nejde a neintegruje to, nekomunikuje s distributory, nenapíše tunu článků, atd. Open source není jenom o tom, že napíšu pár řádek kódu a vylepím to na web, když to řeknu hodně ošklivě.
Jj, dotahovat věci do konce ... o tom to je.myslíš takové to dotahování, že to někam protlačím, pak se na to vpodstatě vyseru a jdu rozbíjet něco jiného, a za mnou aby byl nastoupené týmy lidí, kteří ty věci spraví a opravdu dotáhnou k použitelnosti?
OSSv4 považuji za v současnosti nejlepší řešení zvuku na LinuxuJsme technici, konkretne v cem je nejlepsi a proc?
1.) Zvuk sa mixuje v kernel space, je podľa mňa subjektívne čistejší.Mixer v kernel space umoznuje snizit latence; jenze na to je lepsi reseni Jack2 + kernel s RT patches; navic Jack2 lze jiz integrovat s PA. Cistejsi? Jako jak? Mensi zkresleni ci kvantizacni sum? Co to ma byt?
2.) Odpadnú vám problémy s prehrávaním videa vo flashi, alebo napríklad hráte staršiu hru pre OSSv3 a pritom máte pustené Mumble.Od flashplayeru 10, tedy jiz nekolik, let neni jiz zadny problem. PA je standard, podporuje ho temer vse v Linuxu.
3.) ALSA aplikácie fungujú naďalej výborne.Budiz. Mne pri uziti OSS a ALSA interface padal na Debianu i mplayer.
4.) Naozaj funkčný softvérový mix.A tim mate na mysli opet co? Vezmete si jednoduchou ulohu: jeden stereo stream 2 x 44100Hz, 16 bitu, jeden mono stream 1 x 16000Hz, 10 bitu a vystup na stereo zvukovku 2 x 48000Hz, 24 bitu, vsechno normalisovane. Pokud jste se nekdy zabyval signal processingem, je vam to co je nutne udelat asi jasne a pak mi reknete v cem je mixovani OSS lepsi. Nevidim to.
dává větší smysl začít nový projekt (PA)Ano, pokud tvurci OSS zacnou uzavirat projekt a chtit penize za podporu noveho HW.
kterému trvalo několik let, než se dostal do jakž-takž použitelného stavu,ALSA a PA byly ve stavu lepsim nez OSS velmi rychle, navic se neschodne o "jakz-takz pouzitelnem stavu".
ALSA a PA byly ve stavu lepsim nez OSS velmi rychle, navic se neschodne o "jakz-takz pouzitelnem stavu".O tomhle by se dalo polemizovat. Zatímco PA jsem poprvé viděl funkční asi tak před dvěma nebo třemi lety, OSSv4 jsem viděl funkční hned jak ho otevřeli (což byl tuším rok 2007).
ALSA a PA byly ve stavu lepsim nez OSS velmi rychle, navic se neschodne o "jakz-takz pouzitelnem stavu".s OSS nemůžu srovnávat, neznám aktuální stav (jo, to byly časy v devadesátých letech ...) nicméně PA pro mě osobně není v použitelném stavu doteď - hm, no "jakž-takž" asi jo, ekvalizér si můžu vyřešit na úrovni aplikace, a proti tomu, že to běží jen pro přihlášeného uživatele, jsou nějaké hacky tady okolo zmiňované, takže se skřípěním zubů to samozřejmě používat jde(*) (*) nó ... pak tu je ještě bug v Lingot, kdy s PA neumí správně spočítat frekvenci, resp. od PA se ji nedozví, což mi připomíná, že bych měl omrknout, jestli/jak to Íbán vyřešil (poslední hack byl tuším vzít čas ze systémového zdroje a spočítat, kolik za určenou dobu dostanu vzorků, oujé ...)
Na většinu těhle věcí bych si dovolil odpovědět jednou protiotázkou – dává větší smysl začít nový projekt (PA), kterému trvalo několik let, než se dostal do jakž-takž použitelného stavu, nebo opravit podporu pro suspend v OSS?tak naokraj, pokud se bavíme o novém projektu místo oprav starého, já jsem doteď nepochopil, co vlastně tak zásadního umí PA, co se nedalo vyřešit s JACKem, když už jít o level nad ALSA/OSS (nebo z druhé strany, aRts a ESD nám nebyly dost dobré, zmizly v propadlišti dějin jako špatný koncept, a když přijde PA s něčím dosti podobným, tak bez toho najednou nemůžeme žít?)
tak naokraj, pokud se bavíme o novém projektu místo oprav starého, já jsem doteď nepochopil, co vlastně tak zásadního umí PA, co se nedalo vyřešit s JACKem, když už jít o level nad ALSA/OSSPřesně o to mi jde. Asi jedinou věc, kterou s JACKem neuděláš a která je v PA je per application volume. Ale když se JACK použije nad OSS, máš i tohle. Tedy ještě je to automatické nastavování velikosti bufferů, ale to, zdá se, přináší víc problémů než užitku.
kdy v ALSE je několik možností přístupu ke zvukovce (přímo přes hw:x, přes emulaci /dev/dsp a přes alsalibTrochu chaoticky interface je problem ALSA, na ktery dojizdi i PA, ale tyka se to spise exotickeho HW, ktery nesleduje MS doporuceni.
U OSS je SW mixování jako dodatečná vrstva v jádřeSW zvukovy mixer nema v jadre co delat, tam je tisic a jedna moznosti jak to delat.
Konečně, už jsem se setkal s tvrzením, že OSS má nižší latenci než ALSA.To vychazi ze zamereni PA jako desktopoveho sound systemu, nizke latence nejsou zadarmo, ostatne ani potreba.
No, a obskurnější věci jako je zvuk přes síť, propojování vstupů/výstupů za běhu a nízkou latenci pak zbude JACK, který funguje.Integrace PA a Jack2 funguje a tam kde skutecne potrebuji nizke latence, i za cenu to co prinasi, to mohu pouzit; PA preda kontrolu nad zvukovkou Jack2. Odpoved na otazku proc je SW mixer OSS 'skutecne fungujici' jsem se opet nedozvedel.
Odpoved na otazku proc je SW mixer OSS 'skutecne fungujici' jsem se opet nedozvedel.GOTO 192
kdežto u ALSA (a čehokoli nad ALSA, tj. včetně PA) je velmi snadné dosáhnout toho, že si jedna aplikace uzme zvukovku a jinou k ní nepustí?Tedy chcete mi tvrdit, ze u PA muze aplikace velmi snadno uzmout zvukovou kartu a nikoho jineho k ni nepustit? Navic kolik aplikaci muze pracovat s ALSA a ne s PA?
Tedy chcete mi tvrdit, ze u PA muze aplikace velmi snadno uzmout zvukovou kartu a nikoho jineho k ni nepustit?Ano. Stačí vzít ALSA aplikaci a natvrdo jí nastavit nějaký hw výstup. Leda by se něco poslední dobou změnilo, ale nevěřím tomu, že by PA bylo schopné obejít tuhle limitaci ALSA.
Navic kolik aplikaci muze pracovat s ALSA a ne s PA?Nevím a je mi to jedno. Ale kdybych měl dělat nějakou aplikaci a chtěl bych, aby běžela na co největším množství počítačů s linuxem (třeba proprietární hru), volil bych ALSA a na PA už bych se vykašlal, protože je to zbytečná práce navíc.
To neni odpoved na otazku, ktera vzesla z vaseho tvrzeni.Tedy chcete mi tvrdit, ze u PA muze aplikace velmi snadno uzmout zvukovou kartu a nikoho jineho k ni nepustit?Ano. Stačí vzít ALSA aplikaci a natvrdo jí nastavit nějaký hw výstup. Leda by se něco poslední dobou změnilo, ale nevěřím tomu, že by PA bylo schopné obejít tuhle limitaci ALSA.
PA bylo schopné obejít tuhle limitaci ALSATo lze obejit pouzitim SW mixeru a tim je prave PA, a to je zde se jedina relevantni vyhoda OSS, jinak temer vse ostatni je problematictejsi. Neni zadny duvod, aby aplikace lezla primo k ALSA driveru a obesla PA, pokud nechce pracovat ve vyhradnim rezimu a zvukovku si chce nechat pro aplikaci.
aby běžela na co největším množství počítačů s linuxem (třeba proprietární hru), volil bych ALSANaopak bych volil PA, mozna jste to nevzal na vedomi, ale na Linuxu je to jiz defacto standard a pokud to neudelaji budou naopak resit tuny jinych problemu, treba az jim uzivatele zacnou dynamicky pripojovat USB ci Bluetooth zarizeni nebo HDMI, od vstupu po vystupy.
To neni odpoved na otazku, ktera vzesla z vaseho tvrzeni.Ale je. Protože PA používá ALSA, má i stejné problémy.
To lze obejit pouzitim SW mixeru a tim je prave PAA dmix taky. Tím jste tedy potvrdil, že PA je zbytečné.
Naopak bych volil PA, mozna jste to nevzal na vedomi, ale na Linuxu je to jiz defacto standardTo bych tedy netvrdil. Ze svého okolí neznám snad nikoho, kdo by PA používal. A třeba v Archu má podle aktuálních statistik PA jen 47 procent uživatelů.
A dmix taky. Tím jste tedy potvrdil, že PA je zbytečné.A k tomu jste dosel jak? Rozvedte to.
A třeba v Archu má podle aktuálních statistik PA jen 47 procent uživatelů.A to jste vzal kde? Navic, kolik to cini u Linuxu obecne, ci u jinych distribuci - zejmena Ubuntu a jeho derivatu, Mintu, Debianu, openSuse ci Fedory?
A k tomu jste dosel jak? Rozvedte to.Tvrdíte, že zmiňované problémy řeší SW mixer, kterým PA je. V tom případě je ale PA zbytečné, protože ALSA samotná už sw mixer obsahuje ve formě dmixu.
A to jste vzal kde?Package usage
Tvrdíte, že zmiňované problémy řeší SW mixer, kterým PA je. V tom případě je ale PA zbytečné, protože ALSA samotná už sw mixer obsahuje ve formě dmixu.Vy mate problem s analyzovanim psaneho textu. Psal jsem, cituji:
Zbytek je vas nesmyslny zaver.PA bylo schopné obejít tuhle limitaci ALSATo lze obejit pouzitim SW mixeru a tim je prave PA, a to je zde se jedina relevantni vyhoda OSS, jinak temer vse ostatni je problematictejsi.
Evidentně máte problém se vyjádřit, protože to, co tu tvrdíte, je, že když je tu problematická ALSA, je možné její problémy obejít SW mixérem v PA. To je ale naprostý nesmysl,Na taková kategorická tvrzení bych si dával pozor.
protože zaprvé ALSA už SW mix obsahujeTo ovšem nic neříká o tom, zda je v této funkci lepší alsa/dmix nebo PA a rovněž to nic neříká o tom, jak se tato funkce integruje s dalšími.
zadruhé to stále neřeší problém s zablokováním když se pokusím přistupovat přímo k hw.Nestačí přímý přístup aplikacím prostě nepovolit?
To ovšem nic neříká o tom, zda je v této funkci lepší alsa/dmix nebo PA a rovněž to nic neříká o tom, jak se tato funkce integruje s dalšími.O kvalitě mixování si netroufám diskutovat, protože to zavání audiofilskou diskuzí typu. Co se týče integrace, nejsem si úplně jistý, co tím myslíš. Pokud jde o integraci se klientskými aplikacemi (hudební přehrávač atd.), tak bych řekl, že tady má ALSA výhodu v tom, že je větší šance, že to bude fungovat. Tím chci říct, že když aplikace používá ALSA API, ale já chci používat PA, nastavím si v asound.conf výstup pomocí PA. Kdežto s aplikací postavenou nad PA mám na systému, který má jen ALSA, smůlu.
Nestačí přímý přístup aplikacím prostě nepovolit?Toť otázka. Když se teď nějaká aplikace rozhodne přistupovat přímo, dostane výhradní přístup ke zvukovce a všechno ostatní se rozbije. Na druhou stranu pokud se zakáže přímý přístup, aplikace, která ho doteď používala se rozbije. Tohle se s OSSv4 nestane.
O kvalitě mixování si netroufám diskutovat, protože to zavání audiofilskou diskuzí typu.O kvalitě mixování jsem nepsal a se mnou s audiofilskou diskuzí moc nepochodíš.
Tohle se s OSSv4 nestane.A co udělá OSSv4, když si ALSA aplikace řekne o výhradní přístup?
O kvalitě mixování jsem nepsal a se mnou s audiofilskou diskuzí moc nepochodíš.Pardon, myslel jsem, že pod lepší/horší chápeš kvalitu mixování.
A co udělá OSSv4, když si ALSA aplikace řekne o výhradní přístup?Teoreticky to bude mixovat, protože to v každém případě musí prolézt přes mixer v jádře. Reálně se to může rozbít, protože emulace ALSA není stoprocentní.
Pardon, myslel jsem, že pod lepší/horší chápeš kvalitu mixování.Spíše teoretickou ovladatelnost/konfigurovatelnost (která se za přítomnosti dobrého konfiguračního nástroje stává praktickou).
Teoreticky to bude mixovat, protože to v každém případě musí prolézt přes mixer v jádře. Reálně se to může rozbít, protože emulace ALSA není stoprocentní.Fajn. Nikde neříkám, že OSSv4 je špatně. Ale jak sám vidíš, tak jako rychlá spása to taky nemusí fungovat. Pokud nebude OSSv4 alespoň stejně ready jako PA a jedinou výjimkou je, že nebude v distribucích by default, tak má smysl si to zkoušet a bavit se o tom, zda je to jednoznačně praktičnější volba. Jenže pak je potřeba najít někoho, kdo to do těch distribucí dostane.
Spíše teoretickou ovladatelnost/konfigurovatelnost (která se za přítomnosti dobrého konfiguračního nástroje stává praktickou).Tak na to nedovedu odpovědět. Když jsem používal OSSv4, neměl jsem potřebu nic konfigurovat. U PA vlastně taky ne (to neznamená, že jsem nenarazil na problémy, jen mi jejich řešení nestálo za to úsilí).
Fajn. Nikde neříkám, že OSSv4 je špatně. Ale jak sám vidíš, tak jako rychlá spása to taky nemusí fungovat. Pokud nebude OSSv4 alespoň stejně ready jako PA a jedinou výjimkou je, že nebude v distribucích by default, tak má smysl si to zkoušet a bavit se o tom, zda je to jednoznačně praktičnější volba.Z mého pohledu jde spíš o takový postesk. Kdyby někdy v tom roce 2007, kdy bylo OSSv4 uvolněno pod OSS licencí, distribuce zařadili OSS, mohl tu být krásně fungující zvukový systém mnohem dřív, protože by v podstatě stačilo opravit jen suspend. A na pár zbylých věcí, které samotné OSSv4 neumí ale PA ano by tu zbyl v té době už funkční JACK. Krom toho v té době se ještě vyskytovalo docela dost aplikací, co používalo OSSv2, takže by to dávalo smysl i v tomhle ohledu.
O kvalitě mixování si netroufám diskutovat, protože to zavání audiofilskou diskuzí typu.Absolutne ne. Pokud se da nekde neco zprasit u signal processingu zvuku, a to poradne, tak je to prave mixer a ekvalizer. Pokud mate pocit, ze je to trivialni zalezitost, muzeme zacit rozebirat aspekty posledniho bodu zmineneho v #163.
Pokud mate pocit, ze je to trivialni zalezitost, muzeme zacit rozebirat aspekty posledniho bodu zmineneho v #163.Takový pocit nemám. Krom toho neznám implementaci, a tudíž by taková diskuze byla bezpředmětná.
co tu tvrdíte, je, že když je tu problematická ALSA, je možné její problémy obejít SW mixérem v PA.Znovu, nic takoveho jsem nepsal. Psal jsem:
Mluvim o jedne veci, navic ani nerikam, ze to je problem u ALSA. Naposledy. ALSA drivery nemaji v sobe zadratovany SW mixer, narozdil od OSS kde to strcili do kernelu, a to je duvod proc se ke zvukovce musi nekdy pristupovat bud exklusivne nebo pres vnejsi mixer (treba onen dmix ci PA ci cokoliv jineho). Nekdo to povazuje za nevyhodu, ja nikoliv a nebot cpat SW mixer do kernelu je nevhodne, moznosti jak to implementovat je rada a mixovat optimalne streamy s ruznou vzorkovaci frekvenci, kvantizaci a dynamickym rozsahem, treba i do limitovaneho vystupu, neni uplne trivialni . Aplikace bych bez arbitra resiciho konflikty k HW vubec nepustil.PA bylo schopné obejít tuhle limitaci ALSATo lze obejit pouzitim SW mixeru a tim je prave PA, a to je zde se jedina relevantni vyhoda OSS, jinak temer vse ostatni je problematictejsi.
Znovu, nic takoveho jsem nepsal. Psal jsem:A jak to chcete obejít pomocí SW mixeru v PA, když aplikace pořád mohou sahat na hw přes ALSA? Odpověď typu: „přepsat aplikace, aby používali PA API místo ALSA“ není řešení, protože se vždycky najde nějaká aplikace, která to API používat nebude. Ze stejného důvodu pořád existuje emulace OSSv2, i když už je dávno mrtvé.PA bylo schopné obejít tuhle limitaci ALSATo lze obejit pouzitim SW mixeru a tim je prave PA, a to je zde se jedina relevantni vyhoda OSS, jinak temer vse ostatni je problematictejsi.
Naposledy. ALSA drivery nemaji v sobe zadratovany SW mixer, narozdil od OSS kde to strcili do kernelu, a to je duvod proc se ke zvukovce musi nekdy pristupovat bud exklusivne nebo pres vnejsi mixer (treba onen dmix ci PA ci cokoliv jineho).Vždyť o tom mluvím od začátku. Tím, že je u OSS mixer v kernelu, bude mixování fungovat nezávisle na tom, jak se ke zvukového systému bude přistupovat. Když použiju PA, můžu jen doufat, že mi to nějaká jiná aplikace nerozbije.
A jak to chcete obejít pomocí SW mixeru v PA, když aplikace pořád mohou sahat na hw přes ALSA?Zakazu aplikacim pristup. Nevim jakou distribuci pouzivate, ale ve Fedore pokud uzivatel neni v group "audio", maji aplikace smulu a to je defaultni nastaveni.
protože se vždycky najde nějaká aplikace, která to API používat nebude.To nehraje zadnou roli. Pokud pouzivate PA plugin pro alsalibs, bude kazda aplikace fungujicici s ALSA chodit i s PA. Jinak receno, PA umi plne emulovat ALSA interface a k dispozici je i OSS wrapper pro historicke aplikace.
pokud uzivatel neni v group "audio", maji smulu aplikace a to je defaultni nastaveni.tady se musím zastat předřečníka: zvuk by se neměl rozbít ani tehdy, když se na zvukovku pokusí exkluzivně sahat nějaký program přes starší api.
zvuk by se neměl rozbít ani tehdy, když se na zvukovku pokusí exkluzivně sahat nějaký program přes starší api.Starsi API tohle neresi, takze z hlediska aplikace zadna zmena. Navic to neni zadne rozbiti, zejmena u PA, kdy aplikace muze pouzit ALSA plugin se stejnym API. Tech aplikaci, ktere takto nemohou fungovat, nebude uz po sesti letech v repositarich moc - vlastne uz neznam zadnou a vetsina mi chodila uz v prvni verzi PA. Pokud takova existuje, je na rootovi to povolit a zaradit uzivatele do skupiny audio, ale defaultne by to umozneno byt proste nemelo, jako u ostatnich device.
Starsi API tohle neresi, takze z hlediska aplikace zadna zmena.No právě. Proto PA nemůže řešit problémy způsobené ALSA, protože ALSA je podle mého nevhodně navržená.
Podle mého je tenhle design prostě špatnýZvukovy mixer v kernelu nema co delat.
Zvukovy mixer v kernelu nema co delat.Profesionálny hudobníci budú mať určite odlišný názor. Keď to zoberiem z aktuálnej politiky kernelu, tak tu máme monolit a zvuk je jednou zo základných funkcií systému tak nevidím dôvod ho tam nemať.
Profesionálny hudobníci budú mať určite odlišný názor.Profesionalnim hudebnikum je jedno kde to je, pokud aplikace splni jejich pozadavky. Kernel s RT patches uz dava dost moznosti jak vetsinu veci resit a pokud mate pocit ze ne, specifikujte mi prosim v cem je problem?
zvuk je jednou zo základných funkcií systémuSystemu ano, ale ne kernelu OS.
že tam ide o milisekundy aby to neskreslovalo muziku.Muzete objasnit pouziti? Vetsina zpracovani hudby se nedela realtime, veci se nasampluji a zpracuji pozdeji offline. Zkresleni a RT odezva jsou vetsinou nesouvisejici veci, pokud se neuplanuje zpetna vazba. Milisekunda neni v soucasnosti problem, jiz v roce 2000 byl na to Linux slusne pouzitelny a dnes jsme jiz upne nekde jinde. Pokud vam jde o to umistit Linux do retezce
mikrofon -> zvukovka -> zpracovani na pc -> zvukovka -> reprobednydo 20ms delay se vejdete s dostupnym HW, pokud budete chtit lepsi vyskedky, musite zainvestovat, protoze bezny HW na to neni delany, stejne jako PA audio.
Teda po vyskúšaní OSS mi fakt pripadá ten zvuk subjektívne čistejší.Tohle se da objektivne zmerit. Muzete mi specifikovat to 'cistejsi'? Sum? Dynamika? Harmonicke ci fazove zkresleni? Zpozdeni? Preslechy mezi kanaly?
01:06.0 Multimedia audio controller: C-Media Electronics Inc CMI8738/CMI8768 PCI Audio (rev 10) Subsystem: C-Media Electronics Inc CMI8738/C3DX PCI Audio Device Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 64 (500ns min, 6000ns max) Interrupt: pin A routed to IRQ 19 Region 0: I/O ports at d800 [size=256]
tak je tam problém s vyššími harmonickými frekvenciami, že ten fázový posun je tam počuť pri mixovaní.Pokud jim tam vznika nechtene harmonicke zkresleni maji problem s nelinearitou v prenosovem retezci, coz je prusvih a nesouvisi to s RT odezvou systemu, ani zpozdenim. Viz zde.
C-Media Electronics Inc CMI8738/C3DX PCI Audio DevicePokud se vyrobce nesnazi setrit na soucastkach okolo, jsou dobre. Na presne zpracovani vice analogovych kanalu to neni, interne maji jeden prevodnik spojeny s analogovym multiplexorem a tak nejsou schopni vzit vzorky ve stejny cas, u bezneho pouziti je to jedno.
Profesionálny hudobníci budú mať určite odlišný názor.Pokud nejsou zároveň špičkoví odborníci na operační systémy, tak je jejich názor zajímavý asi tak jako můj názor na japonskou kuchyni.
Keď to zoberiem z aktuálnej politiky kernelu, tak tu máme monolit a zvuk je jednou zo základných funkcií systému tak nevidím dôvod ho tam nemať.Aktuální politika kernelu se nepozná podle toho, co v kernelu už je, vzhledem k tomu, že se věci takřka nevyřazují. Pokud se při vývoji kernelu bude užívat takovéto argumentace, tak kernel brzo umře na přeplácanost. Už jsem někde upozorňoval na to, že v kernelu se neopravují chyby, pokud by to mohlo ohrozit stávající aplikace. Už jen to je obrovská zátěž na celý ten projekt. Ve výsledku to znamená, že cokoli, co se udělá v kernelu je mnohonásobě dražší než ta stejná věc v userspace.
Pokud nejsou zároveň špičkoví odborníci na operační systémy, tak je jejich názor zajímavý asi tak jako můj názor na japonskou kuchyni.Ako som už písal vyššie, že vraj je v tom veľký rozdieľ keď sa to mixuje real time, že je to počuť, ja toto nedokážem objektívne ohodnotiť. Jasne bratu, ale to bude stáť veľa síl a nepôjde zo dňa na deň. Treba presvedčiť množstvo vývojárov aby prešli do user space a ešte aby zabezpečili funkcionalitu na ktorú boli užívatelia zvyknutý. Teda vlatne zmenu monolitu ako ho máme dnes. Teraz je otázka kde má byť tá hranica, čo ešte v jadre má ostať.
Ako som už písal vyššie, že vraj je v tom veľký rozdieľ keď sa to mixuje real time, že je to počuť, ja toto nedokážem objektívne ohodnotiť.Nemá smysl to řešit bez specifikace, co se má mixovat realtime a co se stane, když se to nemixuje realtime. Tohle už opravdu zklouzává do JPP. Ale příklad. Když si pustím muziku a do toho mi přijde notifikace, že mám nový mail, tak je mi úplně jedno, jestli se to zmixovalo realtime nebo třeba s dvouvteřinovým předstihem/posunem/whatever. A to je typický use case mixování na desktopu.
Teraz je otázka kde má byť tá hranica, čo ešte v jadre má ostať.V tuhle chvíli zní krátká odpověď: „Všechno.“ Jednou za čas se objeví nějaká výjimka, jako se řešila ta podpora 386, i tak kolem toho byly velké diskuze. Jiná věc je ale přidávat do jádra něco nového. Tam je velký důvod si to rozmyslet. A vývojář to zpravidla udělá radši za týden v userspace než aby to psal tři týdny do jádra, čtyři týdny vysvětloval, proč to tam patří a dalších pět týdnů to vylaďoval, aby to bylo přijato.
Navic to neni zadne rozbiti, zejmena u PA, kdy aplikace muze pouzit ALSA plugin se stejnym API.Problém to byl v době, kdy především uzavřené aplikace podporovaly pouze OSS a ALSA místo toho, aby jim poskytla virtuální
/dev/dsp
s virtuálním hw mixérem nasměrovaným do dmixu - výsledkem pak bylo, že dotyčný program si zabral celou zvukovku pro sebe a _tenhle_ problém nevyřešilo ani PA. Vyřešila to až postupná smrt OSS aplikací, která ale trvala několik, pro problémem postižené docela bolestivých, let.
Wrapper jako řešení neberu.
Vyřešila to až postupná smrt OSS aplikací, která ale trvala několik, pro problémem postižené docela bolestivých, let.To chapu, osobne jsem na to narazil naposledy v 2007, to je ale uz davno mrtva zalezitost.
ty statistiky říkají, že to někdo stáhl, ale už nikdo nezjistí jestli s tím jsou potom spokojení, a jestli to za týden neodinstalují.To je pravda. Reálné množství uživatelů bude nejspíš ještě nižší než těch 47 procent (navíc někdo může mít PA nainstalované, ale nepoužívá ho)
Navíc z nějakého německého serveru.Tohle jsou „oficiální“ statistiky, akorátže oficiální vizualizace výsledků neexistuje.
mně v poslední době funguje zvuk v Linuxu jako nikdy před tím.Potvrzuju.
Já za poslední 2-3 roky neměl s PulseAudiem jediný problémSouhlasim.
No, nevím. Já za poslední 2-3 roky neměl s PulseAudiem jediný problém.njn, někomu to holt chodí, někomu ne :-/ (teda nevím, jestli už s tím od té doby něco neprovedli, nepoužívám to když to nefunguje, a tedy ani jen tak nezjistím, že to začlo fungovat ...) dlužno podotknout, že mbeq používám doma na Gentoo s čistou alsou k plné spokojenosti ...
for (i = 0; i < BANDS; i++) { gain_idx = (int)((gains[i] * 10) + 700); gains[i] = db_table[LIMIT(gain_idx, 0, 999)]; } // FFT ..... for (i = 0; i < FFT_LENGTH; i++) { out_accum[i] += 0.9186162f * window[i] * real[i]/(FFT_LENGTH * OVER_SAMP); }Prekvapuje me pouziti cosine window, cekal bych jine okno. Ja jsem to ted zkusil na svem HW (Behringer UCA202) a zisk je nastaven korektne, interne to pouziva PCM2902. Chtelo by to vygenerovat wav se sinusovkou nebo pomaly chirp signal (mohu obe dodat) a pak zaznamenat jak to vypdada v jednotlivych castech retezce, z toho lze usoudit kde se to mrvi.
Jestli rozumim dobre, vy zvysite gain v pasmu 50Hz- 100Hz o 10dB a pak vam to zacne orezavat vystup? Jedna se o audio clipping?ano
Koukaje do kodu amp_1181, tak to v podstate zmeni rozsah vystupniho signalu vynasobenim signalu konstantou, takze to v retezci nekde prestane orezavat a nespis zvukovka je schopna se s tim poprat.do kódu jsem nekoukal, koukal jsem na nějaké howto jak mít system-wide equalizer
Resenim muze byt adaptivni nastaveni zisku, jakasi obdoba analogoveho AGC, nicmene za to by vas audiofilove zabili.hehe, to mi připomnělo SP-210T (kdo nezažil, nepochopí ...
mbeq je uplne neco jineho, tento ekvalizer je zalozen na FFT a interne uz provadi normalizaci a nastaveni gainu:hm, nějak se mu to nastavení asi nedaří, když to potřebuje ještě snížit pregain
Ja jsem to ted zkusil na svem HW (Behringer UCA202) a zisk je nastaven korektne, interne to pouziva PCM2902.jako přesně ten testcase? - no, je několik možností ... buď už to spravili, nebo to z nějakého důvodu závisí na hardware, nebo ... já nevim
Chtelo by to vygenerovat wav se sinusovkou nebo pomaly chirp signal (mohu obe dodat) a pak zaznamenat jak to vypdada v jednotlivych castech retezce, z toho lze usoudit kde se to mrvi.hm, chtělo by ... jsou na to dobrovolníci? mě to momentálně moc netrápí, vpodstatě na tom stroji teď přehrávám akorát mptrosky přes qmmp, které má vlastní ekvalizér ale pokud někdo do toho bugu dodá know-how, konkrétní příkazy, co a jak zaznamenat, tak to klidně otestuju
do kódu jsem nekoukal, koukal jsem na nějaké howto jak mít system-wide equalizerPA ma v sobe zadelany equaliser implementovany jako modul, ktery je v jadre kopii toho z LADSPA, fakticky vylepseny (windowing function, overlapping). Poettering, stejne jako dalsi maintaineri, se ale podle me neorientuji v signal processingu. Vsechno to je copy-paste kod chaoticky upravovany bez znalosti veci, plny zakomentovaneho kodu a tenhle komentar me setrelil:
/* FIXME: Please clean this up. I see more commented code lines * than uncommented code lines. I am sorry, but I am too dumb to * understand this. */Ja sice rozumim tomu signal processingu, ale jsem 'too dumb' pochopit rychle ten nedokumentovany PA framework.
hehe, to mi připomnělo SP-210T (kdo nezažil, nepochopí ...K takovehle advanced veci jsem se nikdy nedostal a plotr ('tiskarnu') jsem stavel z Merkura.)
hm, nějak se mu to nastavení asi nedaří, když to potřebuje ještě snížit pregainJe tam fixni korekce, vetsinou to pomuze, ale ne vzdy.
jako přesně ten testcase? - no, je několik možností ... buď už to spravili, nebo to z nějakého důvodu závisí na hardware, nebo ... já nevimAno. Dokonce jsem pouzil i stejny song ... co kdyby - nekdy je tezke rici jestli je to zpracovanim zvuku nebo zpevakem
hm, chtělo by ... jsou na to dobrovolníci?Otestujte to, pokud je treba, jsem schopen vygenerovat potrebne signaly.
Mi zní dost zvláštně, že někdo může být na notebooku spokojený s PA při jeho nárocích na čas procesoru.Naroky na CPU nejsou zas tak velky problem. Plno lidi vycita PA latence, jenze spotreba CPU a nizka latence jsou protichudne pozadavky.
Já si uvědomuju hlavně to, že PulseAudio je vůbec nejčastější problém, co musím lidem na Ubuntu a jiných distribucích řešit. Po jeho eliminaci vše funguje, jak má.Mám dojem, že buntu a PulseAudio nikdy nešlo moc dohromady. Nicméně i pro takové vypínače PA existuje smysluplný důvod tohoto projektu. Masivní zlepšení kvality Alsa ovladačů. BTW: zrovna dneska jsem si PA na notebooku zapnul. Prostě chci mít integrované reproduktory pořád na mute a zvuk přehrávat pouze při připojených sluchátkách. S PA (a kernelem 3 a něco) je to otázka jednoho kliknutí v pavucontrol.
Nicméně i pro takové vypínače PA existuje smysluplný důvod tohoto projektu. Masivní zlepšení kvality Alsa ovladačů.
Jak? Tím, že se fixly a dodělaly featury, které nepoužívá nic jiného než PA? Sorry, ale vypínači PA jsou tyhle masivní zlepšení k ničemu.
Zasadni je, zda-li je mozne s nim diskutovat a zda-li je ochoten akceptovat technicky podlozene namitky, ale o tom vis vice ty.Bohužel. Třeba my máme teď na projektu dvě silné osobnosti, pokud můžu počítat sebe :) a navíc máme rozdílné zázemí (desktop, wifi a ppp versus standardy, servery a virtualizace). A i když to chvílema vypadá jako dva kohouti na jednom smetišti, tak ve výsledku si špatné nápady docela slušně korigujem. Teď se navíc daří do plánování projektu zahrnout širší spektrum lidí (většinou z redhatu).
A i když to chvílema vypadá jako dva kohouti na jednom smetišti, tak ve výsledku si špatné nápady docela slušně korigujem.Pak je to jak ma byt. Lennart, ostatne jako kazdy, potrebuje obcas korigovat.
Jenže tadyti exoti produkují odpad.Vybavuje se mi eudev.
Vybavuje se mi eudev.Já myslím, že po FOSDEMu není třeba už být tolik zlý
tak jejich jádro XNU je pomalá prasárna.Souhlas. Na dual bootu OS X - Linux je OS-X pomalejsi a to i grafika, pokud se v Linuxu pouziji Nvidia drivery.
Nevim o tom, ze by to s ELF formatem bylo mozne.Bylo a s formatem to zas tolik nesouvisi.
Nevim o tom, ze by to s ELF formatem bylo mozne.Na tohle jsem reagoval... Proč to není upstream píše Luboš
v podstate jsem zjistil, ze jsem z defaultnich aplikaci nic moc nepouzival a po instalaci spousty veci z homebrew a perlbrew jsem z toho udelal takovou trochu zplacanou distribuci :DAno. Pokud nepouzivate defaultni aplikace a jako developer nepouzivate vicemene jen skryptovaci jazyky (Ruby, Python, etc.) mate problem.
Ja osobne mu rozumim, protoze jsem na tom stejne. Linux na desktopu jsem pouzival od roku 1996 do roku cca 2009 vyhradne, pak castecne a ted uz jej pouzivam jen na NB od zeny a v jednom virtualu na Windows, kde to je proste mensi zlo. Zacal jsem pouzivat OS X a musim rici, ze to je jiny svet.Jiný svět už to byl před mnoha lety. Nevidím to samo o sobě jako validní důvod přejít zrovna teď.
Svet, kde neresim problemy toho, ze se kazdeho pul roku vse co jsem vypiplal a vyladil prestane fungovat a musim ladit znovu.Pochopitelné. Ale je tu pár stabilních distribucí, kde tento problém není. A zrovna teď je v linuxovém světě spousta novinek z posledních X let, které čekají na stabilizaci. Takže opět bych to viděl jako důvod, kdyby přecházel před lety.
Funguji automaticky a bez rucnich zasahu takove veci jako prepnuti displeje na dataprojektor apod.Minimálně s Gnome, na kterém se Icaza dost angažoval mi to funguje bez problémů už dlouho.
Pomoci dvou TimeMachine ulozist mam sva data zalohovane a kdybych o NB prisel, nebo ho chtel z nejakeho duvodu preinstalovat, tak jen pri instalaci vyberu z ktere zalohy chci obnovit a kliknu na OK. To je vse co musim udelat.Tohle je zrovna oblast, kde se dá udělat za málo muziky hodně peněz. Většina práce je hotová a mohli by se na tom zrovna teď vyřádit lidi, kteří nevidí úplně moc do hloubky, ale mají nějaké to nadání v oblasti user experience. Opět kvůli tomuhle bych přešel na Mac OS X v době, kdy si to pořizovalo hodně mých přátel, což je někdy kolem roku 2006. A nemyslím si, že by v tomhle bylo česko nějak zvlášť napřed.
Totez v okamziku, kdy si koupim novy NB a mam ho pripojeny do stejne site jako puvodni. Behem instalace jen reknu, ze chci data zmigrovat na novy stroj a on udela praci za mne. Ale to jsou veci, ktere clovek nedela kazdy den.Chápu.
Zato kazdy den clovek pracuje s OS jako takovym a OS X je hezky, rychly, nema zadne otravne chyby. Zato je to porad pod kapotou stary dobry Unix a neni problem na nej dostat vetsinu OSS programu v takove nebo makove forme.Taky.
Pro mne z toho plyne zaver, ze Linux ano, ale na desktop uz bych ho nemohl s klidnym svedomim doporucit. Zene az ji odejde NB do vecnych lovist poridim taky nejaky Mac.Pokud je alternativou Mac OS X, tak se o tom můžeme bavit. Ale když vidím, co se na desktopu děje, tak si stejně myslím, že postupem času vykrystalizuje skupina lidí (včetně placených vývojářů), kteří se budou snažit nad všemi těmi novinkami postavit stabilní a dobře fungující desktopový systém. A pak budou výhody opensource docela dobře poznat.
Kdyby dodavatele/vyrobci distribuci udelali to, ze nejaky release freeznou, daji si treba dva roky na to, ze vyladi ty otravne a hloupe bugy, ktere Linux na desktopu neustale obsahuje a doladili to k dokonalosti, pak bych uvazoval o tom ,ze bych ho zase zkusil, ale takhle by to byla cesta zpet.Takhle nějak se snaží fungovat komerční distribuce. Ale prioritu toho, co se vylaďuje, určuje převážně poptávka, která v oblasti supportovaných laptopů a desktopů nebude žádný zázrak. Obecně, nejen v linuxové oblasti.
Ja uz jsem stary na to, abych si na desktopu hral/ladil/tunil, ja chci na PC/Mac pracovat. A tady Linux selhava.Srovnej současný linuxový desktop/laptop s tím před pěti nebo deseti lety.
udělat za málo muziky hodně penězTo jsem neprohodil úplně schválně :).
Jo, tak tyto nářky taky nechápu. Problém s připojením externí obrazovky nebo projektoru už jsem neměl ani nepamatuju, prostě roky. Jezdím hodně po konferencích, připojuju to v zasedačkách do projektorů, televizí, monitorů, přes VGA, DisplayPort,... a prostě to funguje. Jediný krok, který dělám, je, že si přepnu mezi zrcadlením a dvěma displeji, podle toho, jak potřebuju.Funguji automaticky a bez rucnich zasahu takove veci jako prepnuti displeje na dataprojektor apod.Minimálně s Gnome, na kterém se Icaza dost angažoval mi to funguje bez problémů už dlouho.
Je to porad stejne, porad stejne otravne chyby.To jsou jen růžové brýle nebo rostoucí nároky. Linuxový desktop nikdy v minulosti nebyl tak funkční a tak málo zabugovaný, jako je dnes. Tedy nevím, jak ubuntu, ale i ta experimentální fedora nebyla nikdy v historii tak dobrá, jako dnes.
Je to o osobním přístupu k systému. Ségra si koupila Macbooka. Byla na něj celá natěšená, protože její kámoška do ní pořád hučela, že je to boží, jednoduché, intuitivní, prostě cool. No, výsledek byl takový, že se trápila i s instalací tak jednoduchých aplikací jako Transmission, vůbec netušila, kam se jí ukládají stahované soubory, kde najde nainstalované aplikace. Ve výsledku za mnou běhala častěji než, když měla před tím Linux. Jenže její přístup k těmto problémům byl zcela odlišný: Na Linuxu jí to nešlo, protože Linux je složitý (všichni to přece říkají). Naopak na Macu jí to nejde, protože je úplně blbá nebo musí dělat něco špatně, v systému přece chyba nebude, když všichni říkají, jak je to boží. Takže je s Macem vlastně "spokojená", i když s ním má stejně nebo i větší problémy jako s Linuxem.
Mimochodem tu kámošku, která jí to nakukala a slíbila jí, že jí všechno vysvětlí a pomůže, bych nakopal někam. Vykašlala se na ni a jako podpora jsem zůstal zase já.
No, musím říct, že jsem ji posadil před GNOME 3 a chytla se, aniž bych jí cokoliv řekl (samo mě to překvapilo). Něco jsem jí vysvětlil, ale fungovala. Problém byl v tom, že její předchozí notebook byl tak nevýkonný, že na něm měla Xfce, což z jejího pohledu nebyl etalon uživatelské přívětivosti. S Macem měla a pořád má problémy, ale jak říkám, má k tomu úplně opačný přístup, takže jí vlastně nevadí. Mně osobně na tom vadí jen to, že mě do toho nakonec taky zatáhla a musel jsem zjišťovat, jak fungují věci v systému, který mě nebaví. A ač některé vlastnosti Mac OS se mi líbí (např. integrace s hardwarem), hodně věcí mi pilo krev. Např. připojení NFS. I v ty Windows jsem ke svému NFS serveru připojil snadněji.
Ja mám s tým strojom kopec či už hardvérových ako aj softvérových problémov. Medzi hardvérové patrí to, že integrovaná wifi tu z nejakého dôvodu ruší bezdrôtovú myš u iného stroja, drôtová sieťovka nechce ísť, kábel sa musí dotlačiť nasilu, žiadna LED u sieťovky nesvieti, takže ladienie typu hľadanie kábla v switchi, kopec nedomyslených detailov, celkovo mi ten hardvér pripadá odfláknutý ... len aby to dizajnovo vyzeralo pekne.
Po softvérovej stránke je to jednoducho pre BFU. V poslednej dobe som si zvykol na dlaždicový WM, myši sa prakticky nedotýkam a zisťujem, že linux takto ovládam prakticky bez rozmýšľania. Je to ťažko popísateľné ale pripadá mi to ako keby medzi mnou a počítačom nebolo žiadne rozhranie v podobe klávesnice a myši ... skoro ako ovládať stroj myšlienkami, proste super. A zrazu mám robiť na OSX (teda nie tak zrazu, už je to pár mesiacov) a produktivita je jednoducho na zhruba nule.
Ešte za zmienku stojí, že po týždňovom ladení sme zistili, že potrebujeme pri kompilácii na staršie iOS downgradovať XCode. Akurát pri downgrade XCode sa prepíše libc a systém už nenabootuje (zostane v nekonečnej slučke) a jediným riešením je recovery tj. týždeň práce je v háji .
Samostatnou kapitolou sú vstupné zariadenia ... tie od apple mi vôbec nevyhovujú. Klávesové skratky s cmd a original apple klávesnicou sú tak na dolámanie prstov, ešte, že sa to dá zmeniť. Obrátené scrollovanie myši je ... no jednoducho človek má nejako uspôsobené prsty tak, aby pohyb k sebe bol ľahší. Jednoducho na prstoch nemáme silné svaly z vonkajšej, ale z vnútornej strany. Pri scrollovaní klasickou kolieskovou myškou teda otáčame kolieskom pohybom pri ktorom sa využívajú silnejšie svaly (ak hovoríme o scrollovaní dole, čo je najčastejší smer scrollovania). No v apple sa rozhodli, že to urobia opačne a ešte tá dotyková ... neznášam ju pravdu povediac.
Asi tak pred týždňom sme na OSX takto inštalovali tlačiareň. Mali sme 2 systémy s rovnakou verziou OSX. Drivery inštalovali kolegovia, vraj úplne rovnakým spôsobom, na jednom to išlo, na druhom vôbec. Riešenie: výmena tlačiarne. Mimochodom na Linuxe s ňou nebol problém.
Hardware je perfektni, tohle Apple umi.
Keby bol perfektný aspoň by na ethernetovom konektore bola taká drobnosť ako sú LED nech nemusím celú kabeláž po firme rozbiť aby som našiel príčinu.
Pokud mu nechces dat sanci, mas problem.
Čo znamená dať šancu? Trápiť sa s tým 2 mesiace a stále mať nervy z toho, že nedokážem ovládať počítač bez toho, aby som 5x za minútu šahal na myš? V linuxe bežne nešahnem na myš celý deň (dokonca momentálne ani nemôžem lebo nemám v práci pri linuxovom stroji funkčnú myš). Okienka ovládam klávesnicou, editor používam kompletne ovládaný klávesnicou, žiadna emulácia myši numlockom. Nepamätám si akú skratku mám stlačiť na to, aby som okná naskladal tak ako chcem, nepamätám si skratku ktorou prepínam medzi editorom a zobrazeným výsledkom práce, nepamätám si ktorou klávesovou skratkou zobrazujem dokumentáciu ani ako zobrazujem browser, všetko robím úplne automaticky. IT je môj život, IT je to, čo ma drží nad vodou, IT je to, čo chcem robiť od 9 rokov, IT je to, čo ma baví, IT je to, čo vieim robiť, nemám rodinu, prakticky nemám priateľov, robím 16h denne, chcem byť najlepší a verím, že to dokážem, lebo IT je to jediné, čo viem v živote robiť. Niekoľko rokov som si adaptoval prostredie tak, aby mi prinieslo úplne nový pocit z práce, niekoľko rokov som sa adaptoval ja aby som dokázal systém ovládať prirodzene. Niekto by ma mohol považovať za blázna, ktorý používa prehliadač neschopný zobrazovať taby, ovládaný podobným spôsobom ako VIM. Prostredie ovládané podobnými klávesovými skratkami ako VIM, VIM ovládaný ako VIM ...
Co se tyce Xcode. Vis o tom ,ze nemusi dongradovat, ale ze muzes mit vice verzi Xcode vedle sebe?
Nie som expert na apple, ak mi to niekto nastaví budiž, zatiaľ to riešime tak, že kompilovať sa chodí k niekomu, kto má starší systém lebo na novom to nikto nevedel rozbehať a vždy to skončilo tým, že systém už nenabootoval.
OS X podporuje kazdy.
Bola to Canon. Ovládače priamo od výrobcu. Mac sa tvári, že niečo nainštaloval, ale neviem čo a kam, takže neviem overiť či boli skopírované ppd, alebo došlo niekde k chybe. Proste uzavretý inštalátor z ktorého neviem nič zistiť. Postupovali sme presne podľa návodu kde nebolo možné nič iné než klikať na next. A predsa na jednom stroji to išlo, na druhom stroji s identickým OSX nie. Neviem v čom je problém, neviem prečo nastal, systém sa snaží byť tak user friendly, že neviem zistiť potrebné informácie a radšej vymením hardvér než by som mal toto riešiť.
Hardware je perfektni, tohle Apple umi.Ale blbost, tohle je zase přesně demagogie typu "nepotřebuješ maximalizovat okno." Sic ten hardware ve srovnání s ostatním na tom bude lépe (spíš z hlediska jednotlivých komponent), to samotné zpracování je dost tragické a je na tom vidět, že hlavní je nějaký úchylný design... viz přehřívání notebooků (hlavně že je tam hliník), stejně prťavé klávesnice i na 17" noteboocích, blbě klikací a drhnoucí touchpad, používání idiotských konektorů, a tak dále...
Kolik let jej pouzivas ty?Od roku 1995, od roku 2000 vyhradne. No a? To co to bylo tehdy a ted jsou jine svety, nebe a dudy, tehdy to bylo obecne mnohem slozitejsi.
A tak si predstavujem spickovy unixovy system.Spickovy unixovy system? Mluvite stale o XNU?
Většina sw je opensource.Navic casto v predpotopnich verzich, kdy i RHEL/CentOS/Debian Stable maji novejsi. Pak koncite instalaci verzi z MacPorts, nebot nainstalovat nektere balicky treba na stary Python je skoro nemozne a pak pro zmenu resite konflikty mezi novou a starou verzi a stejne plno veci nechodi. Lide se pak radsi vraci na Linux, tam je instalace takovych veci jeden prikaz, nakonec mnohem mene prace, veci funguji, nejsou tak zastarale a maji k dispozici rychle updaty. Apple nechava veci na desktopu bez security updatu i mesice a vubec se o tom nebavy a tvari se jako by problemy nexistovaly. Kazdy mame asi jine predstavy o "spickovem unixovem systemu", nekomu staci jen nalesteny povrch.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.