Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Zkrátka PC šlo cestou, vše řeší CPU, místo cestou spec. hw na různé oblasti.Specializace je dobra vec, ale jsou situace, kdy pomuze a kdy ne. Zejmena by bylo nevhodne zamenit 'specializaci' a 'vyhrazeni' - tedy pripad, kdy je vec urcena na konkretni vec, ale neni k ni zvlast prizpusobena. Uvedu to na prikladu grafiky. Vykreslovani grafiky se sklada z hromady algoritmu, nektere jsou charakteru, ze ti na ne specializovany hardware moc nepomuze a potrebujes na ne rychly general-purpose procesor, jine jsou takoveho charakteru, ze se skaladaji z mnoha nezavislych jednoduchych kroku a je mozne na ne nasadit masivni paralelizaci (a specializovane obvody). Pokud bys chtel, aby graficka karta zpracovavala kompletni grafickou scenu, pak by na ni krome specializovanych obvodu pro paralelizovatelne cinnosti musel byt jeste vykonny general-purpose procesor pro obecne algoritmy. Ten by vsak nebyl prilis specializovan , byl by jen vyhrazen a jedine zlepseni proti alternative (dat ho jako druhy procesor na mainboard) by byla rychlejsi komunikace s grafickou pameti a specializovanymi cipy. Dalsi nedostatek prilisne specializace trochu souvisi s jednim kredem Linuxoveho kernelu - 'mechanism, not policy' - pokud by hardware prevzal zodpovednost za celou oblast vykreslovani sceny, pak by danou oblast svazal svou koncepci. Pokud nabidne jen obecne pouzitelne mechanismy (skalovani, vykreslovani polygonu, shader language), tak koncepci muzou zvolit vyvojari software. Vyvoj v oblasti PC sel smerem, ktery je logicky - specializace na cinnosti, kde specializace prinese vyznamny pokrok proti obecnemu reseni (a ten pokrok jsou ochodni lidi zaplatit
S prvními gr. akcelerátory pro PC se mluvilo o tom, že tyto grafiky budou zpracovávat kompletní scénu.Je otazka, zda to mluvili lidi, kteri dane oblasti opravdu rozumeji, nebo jen redaktori pocitacovych casopisu.
Tohle je věc názoru. Dokázal bych si představit GK, která by uchovávala celou scénu a CPU by jen posílal změny mezi jednotlivýmy framy. Tím by odpadla šílená komunikace mezi kartou a cpu/ram. Hlavní CPU by pak nemusel řešit jednotlivá primitiva, ale poslal by příkaz do GK (kde by klidně mohl být general purpose cpu, proč ne), která by zbytek provedla místo hlavního CPU.Pokud by byl ten general purpose cpu na graficke karte programovatelny, tak bys z toho dostal v podstate dvouprocesorovy NUMA system (s procesorama propojenyma pres PCI/AGP). Je otazka, zda by tohle reseni melo nejake podstatne vyhody proti beznemu dvouprocesorovemu systemu s oddelenou grafickou kartou. A ohledne silene komunikace - i dnes je mozne napriklad ulozit do graficke karty pole souradnic jednotlivych trojuhelniku a pak to jednim prikazem cele vykreslit, neni nutne rvat je tam porad dokola.
K tomu SoundBlasteru. Někde jsem četl (takže to může být výmysl nějakého redaktoraAFAIK se jedna o bezny programovatelny DSP procesor (v Linuxu je pro nej dostupny assembler, viz http://emu10k1.sourceforge.net/as10k1-manual/index.html), nicmene je pravda, ze DSP procesory jsou specializovane a neni na nich mozne snadno implementovat to, co jde snadno na general-purpose procesorech (a naopak).), že SB Live!, tedy EMU10k1, mel výkon jako Pentium 90. To je výkon jako hrom věnovaný pouze zvukovce. Jenže on nejde použít. Je to DSP procesor, který má "zadrátovaných" pár efektů, a přes všechen výkon nelze použít třeba na dekódování mp3-streamu.
Dnešní PC grafika přijme trojúhelníky od CPU a pouze je vykreslí (s texturou a nějakým tím shader efektem). Nic víc.Obávám se, že nemáš tak úlpně pravdu. Grafika se například stará o to, kterou část scény vidíš a kterou ne (je schovaná za něčím).
O HW raidech, co se integrujou na desky raději ani nemluvím.Jak tady už kdysi padlo, HW raid integrovaný na desce je většinou SW raid, jenom místo OS se sestavuje v BIOSu. A důvodem, proč použít SW raid místo HW raidu může být například to, že když ti chcípne řadič, tak můsíš často sehnat ten samý, abys z těch disků dostal data
Jenom castecne, graficka karta ma z-buffer, ktery umoznuje rozhodnout pri prekryvani dvou trojuhelniku, ktery pixel z ktereho se ma zobrazit, nicmene pouziva se spousta algoritmu, ktere na zaklade znalosti sceny urcuji, ktere polygony do graficke karty vubec pujdou a ktere nikoliv.Dnešní PC grafika přijme trojúhelníky od CPU a pouze je vykreslí (s texturou a nějakým tím shader efektem). Nic víc.Obávám se, že nemáš tak úlpně pravdu. Grafika se například stará o to, kterou část scény vidíš a kterou ne (je schovaná za něčím).
Jeste k tomuto - nevim, jak moc bez podpory ze strany CPU si to predstavujes
Například typu přehrávání Audio CD v CD-ROM mechanice.
Takove reseni je IMHO prespecializovane - nedalo by se vyuzit na prehravani MPEG2 streamu na disku ci MPEG2 streamu prichazejicho ze site. Lepsi je mit genericky MPEG2 dekoder na graficke karte, jehoz cinnost je rizena CPU.Jeste k tomuto - nevim, jak moc bez podpory ze strany CPU si to predstavujes
Například typu přehrávání Audio CD v CD-ROM mechanice.
Takove reseni je IMHO prespecializovane
Pravda, taky mi to připomíná řešení: uprostřed nějaký mikrokontrolér (jako bývalé CPU), které by ovládalo tuhle SGI grafický server (bývalá grafika), támhle nahrávací studio (zvukovka), stříhací putl (tuner / střižna) atd .
Ne, nebudu to hnát ad absurdum. On je problém především v tom, že PC se zaměřuje HLAVNĚ na minimální cenu (no jako všechno, co má být masově rozšířené), nikoliv na kvalitu, výkon atd. No co, asi to chce změnit architekturu.
Kde jsou ty časy General Midi, který hrály stejně jako (dnešní) profesionální klávesy.To byl doufám pokus o nějaký bizarní humor, který jsem zřejmě nepochopil.
Kde jsou ty časy General Midi, který hrály stejně jako (dnešní) profesionální klávesy. To je sice pravdaHmm, nicmene me neni jasne, co tim myslis. General MIDI je AFAIK jen standard, ktery rika, ktere cislo nastroje v posloupnosti MIDI prikazu odpovida kteremu skutecnemu nastroji. Standard sam o sobe nehraje, ale zrovna tohle jsem myslel vážně.
jeden klávesista mi kdysi ukazoval asi 8 DVD jen se vzorky. Což se pochopitelně na zv. kartu taky nevleze, ale pro jeden nástroj se místo najde. Bohužel si nevzpomenu na tu zvukárnu, (jen tuším M-Audio, ale možná si to pletu) a cena něco přes 30tis.Zase špatně. Nikde se žádné místo nenajde, protože se s tím pracuje výhradně na straně CPU a RAM a zvuková karta slouží pouze jako DAC.
Jenže celý den se tu bavíme o tom, jestli to tak má být.IMHO je těžké rozhodnout, co je nejlepší. Například wavetable syntéza, pro jednoduchost jsou soundfonty v RAM. Je výhodnější, když všechny zvuky natáhne procesor, smíchá je dohromady a hotové to odešle na zvukárnu k přehrání, nebo když se všechny zvuky přenesou po pomalejší sběrnici do zvukárny a tam se teprve vytvoří výsledný zvuk? Takhle obecně to nejde rozhodnout, protože záleží i na celkové zátěži procesoru (dělá ještě něco, nebo jenom míchá ?), sběrnice (netahá se něco ze sítě nebo z SCSI či raid řadiče?) atd.
SBLive! sice má syntézu, ovšem zase nemá paměť (cache) na vzorky. K SBLive se dodávají soundfonty, největší má tuším 16M. A protože karta nemá vlastní paměť, umístí je driver kam? Ano správně, do RAM (a to ještě v tom lepším případě).Se SB Live! je mozne pouzivat i vetsi soundfonty. Nicmene mas pravdu, ze se pouzivaji ze systemove RAM
Pokud mas na mysli karty s wavetable syntezou, tak ty samozrejme hraji srovnatelne s profesionalnima klavesama (ktere take obvykle delaji wavetable syntezu). Myslim ze rozdily jsou zejmena v kvalite vzorku, se kteryma wavetable synteza pracuje.Tak příště nemyslete a jděte si nastudovat něco o technologii běžně používáných syntezátorů za posledních řekněme 10-15 let. A pak si jděte někam poslechnout pár kousků, klidně i historických, syntíků. Například něco od Kurzweil, JV/XP řadu od Rolanda, starší Kawai... Pak teprve něco pište.
Tiskni
Sdílej: