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 »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
Tiskni
Sdílej:
Tady je trochu jiný pohled:
spousta vývojářů má tendenci nadužívat vlákna (dokonce jako všelék různé problémy), místo aby to vyřešili pořádně v jednom vlákně (někdy to nejde, ale to je poměrně malá množina případů).Cokoliv, co "zasekne" uživatelské rozhraní na více než desetinu vteřiny, má běžet ve vlastním vlákně. Ono se s takovým softwarem o poznání příjemněji pracuje.
This traditional [prefork] Apache design works well up to quite high loads on modern UNIX systems. On Linux in particular, context switches and forking new processes are cheap, and accordingly this simple design is nearly optimal. One drawback, however, of the isolation between processes is that they cannot easily share data, and consequently sharing session data across the server takes a little work.
Another approach is to serve each request in a separate thread: this is the model used by most NT-based web servers. Although this approach eliminates most of the protection between tasks, it allows the module programmer more flexibility and it can be faster on systems where threads are cheaper than processes, such as Windows NT and AIX.
clone()
a používají stejné plánovače jako procesy (normální a real-time). Ovšem není pravda, že by vytvoření vlákna bylo stejně náročné jako vytvoření procesu. Protože se mi nepodařilo rychle vygooglovat žádný benchmark, udělal jsem primitivní prográmek, který 1000x za sebou vytvoří vždy 100 procesů nebo vláken a čeká na jejich skončení. Vytvořený proces/vlákno nic nedělá a hned skončí.
Uvedená činnost trvala na stejném stroji průměrně 2,1 s reálného času pro vlákna (vytvářená pomocí pthread_create()
, tedy i s režií libpthread
) a 13,5 s pro procesy. Přepočteno 21 μs na 1 vlákno, 135 μs na 1 proces. To není zanedbatelný rozdíl. Navíc vlákna byla v testu mírně handicapována tím, že se na ně čekalo v pořadí, v jakém vznikala.
Nejsem programátor a tak sem nikdy nepochopil proč to vlastně nejde.Ono to jde. Ale musí se chtít, a většinou se nechce. Například takové GUI toolkity jsou velmi žravé, a pak už se samotný program ani nemusí moc snažit. Stačí si porovnat rychlost prakticky totožné aplikace napsané s Xlib nebo FoxToolkitem, a té samé aplikace s GTK+ nebo Qt. Bude to zatraceně znát. A tak je to se vším. Když si vzpomenu na to, jaké krásné hry se kdysi vešly to 50, nebo třeba jen 10 KB...
A tak je to se vším. Když si vzpomenu na to, jaké krásné hry se kdysi vešly to 50, nebo třeba jen 10 KB...
Není potřeba to K zvýrazňovat, ono totiž není potřeba vůbec: 256B tetris
A co je možný v 96KB dneska nad tím zůstává rozum stát: kkrieger. (Celej Farbrausch stojí vůbec za zhlédnutí). Umí tohle Vaše Java?!
Jenomže na tohle má jenom pár borců a opravdovejch programátorů, takoví ale dneska SW už prakticky nepíšou. Software dneska píše kdekdo (třeba já...) a podle toho taky vypadá. Že je to pomalý a náročný na paměť nikoho netrápí. Dneska vládne Java, protože v ní něco zbastlí každej (podle toho to taky vypadá) a interpretovaný jazyky se používaj i na věci, kde by i C bylo pomalý. Největší diskuze o programovacích jazycích se nevedou o tom, jak efektivní kód z nich leze (o potřebách virtuálních strojů či interpretrů ani nemluvě), ale jak ideově čistej ten kterej jazyk je.
Že si ten SW někdo nakonec stejně koupí je daný jednak tim, že jinej stejně nesežene (o "free" alternativách darmo mluvit - například cokoliv používající GTK(2) je proti Windows v oblasti GUI nekonkurenceschopný) a jednak právě proto, že HW je dneska tak levnej, že i průměrná PR mrdka SW firmy (nebo GNU fanatik - vyjde to nastejno) Vás dneska přesvědčí, že problém není v jejich programátorech, ale ve vašem (rok starém) zastaralém počítači...
A tak je to se vším. Když si vzpomenu na to, jaké krásné hry se kdysi vešly to 50, nebo třeba jen 10 KB...Tehdy se programátoři snažili šetřit s prostředky hlavně proto, že jich byl nedostatek. Dneska, když si alokuju 2MB pole, skoro to nepoznám, ale v dobách 286 to bylo něco nepředstavitelného. Udělej dneska 50kB hru* a budeš mít requesty na lepší grafiku, podporu pro multiplayer, lepší umělou inteligenci, více jednotek, více scénářů... a jakmile to tam nakóduješ, tak těch pár kB prostě chtě nechtě překročíš. Dnešním požadavkem na software je, aby uměl hromadu funkcí a pokud nebudeš dělat nějaké jednoúčelové demo, tak se do 50kB nikdy nevejdeš. Viz třeba i unixové utilitky. Jejich GNU verze toho umí víc a to proto, že už nebylo třeba tak úzkostlivě šetřit každý byte. Místo
sort | uniq
napíšeš sort -u
a tak dál ...
* budeme tiše ignorovat fakt, že si na dnešních systémech bez sdílených knihoven ani neškrtneš ...
Trochu mi to připomíná, jak jsem psal jednu semestrálku v OpenGL na notebooku, kterému nefungovala 3D akcelerace. Když to pak jeden kolega pustil u sebe, tak se divil jak to mám rychlé.Jenže tohle je úplně něco jiného (jak řekl thingie). Program v OpenGL je rychlý, protože tam za tebe práci udělá grafická karta specializovaná na daný typ operací. Navíc, se software renderingem se stalo spíš jen to, že jsi mohl rovnou zapomenout na libovolnou pokročilejší techniku, která by na té grafické kartě stejně jela jako z praku. I když ti jede akcelerace, tak poznáš i prostý double buffering, natož pak věci jako display listy, nebo podobně ...
Jinak, značná část velikosti OpenOffice je prostě daní za multiplatformnost a za to, že si sebou tahá skoro všechno sám.KOffice je také multiplatformní (nebo bude v rámci KDE 4) a pomalý není. Sice mu chybí dost funkcí, ale ty ho už nezbrzdí. Tady je asi špatně opravu něco jiného :-/
Není fér srovnávat dnešní OpenOffice a tehdejší WP. Nebo by ti tehdejší verze stačila i dnes? Otevřela by ti to, co otevře OpenOffice? Jak je na tom dnešní verze WP? Myslíš, že je pořád tak rychlá, jako byla kdysi tehdejší verze?
Jsem přesvědčenej, že funkcema by ta historická verze WP i dneska stačila víc jak 90% uživatelů, vždyť se podívej kolem sebe, co většina lidí dělá ve Wordu, kterej je funkcema ještě nabytější než zmiňované OpenOffice. Že jí lidi nepoužívaj, protože na novém OS už nefunguje a není kompatabilní s novými formáty je už jiná pohádka...
Jinak jak už tady bylo zmíněno, problém nejsou programy, které nabízejí novou (potřebnou) funkčnost, ale ty co umějí to samé co předchůdci akorát při 100x větší náročnosti na HW. A že těhle programů se dneska produkuje většina, (a většina zcela zbytečně, protože je ve skutečnosti nikdo nepotřebuje) je po krátkém pozorování co vlastně lidi na počítači dělají dostatečně zřejmé.
Otázkou tak jenom zůstává, kdo tohle kolečko roztáčí. Jestli výrobci HW, kteří potřebují vnutit zákazníkům svůj křemík a tak vyvýjí technologie které ten křemík budou potřebovat (příklad Sunu s jeho Javou), nebo výrobci SW, kteří potřebují co nejrychleji chrlit další a další verze SW aby měli z čeho žít k čemuž potřebují čím dál tím jednodušší frameworky (Příklad Microsoft a jeho "hype" okolo .NET)...
To ještě nepočítám rychlost disku, protože i tehdy to zběsile swapovalo.Zrovna právě s diskem je problém. Rychlost disků se totiž nezvětšila zdaleka tolik, jako stouply přenášené objemy dat. Disky mají sice poměrně velké přenosové rychlosti (ovšem, běžné IDE disky měly v roce 2000 teoretickou přenosovou rychlost 100 MB/s (ATA 100), dnešní disky mají 300 MB/s (SATA 300), tedy jen trojnásobné zrychlení), nicméně mechanické parametry zůstaly víceméně stejné. Například seek time se stále pohybuje okolo 8-9 ms, stejně jako před těmi 7 lety. Stačí pak, když je při startu programu potřeba provést 100 přesunů hlav (u velkých programů, jako je třeba OO.org, to bude ještě mnohem více), a už jen samotné přesuny sežerou vteřinu času. To je také důvod, proč stále doporučuji používat co nejvíc fyzické paměti a hovořil jsem také o chytrém přednačítání á la microsoftí SuperFetch.
Kdyby někdo vzal ty zdrojáky, tak zjistíš, že je to starý děsivý nepoužitelný bastl který je ti dneska úplně nanic.Pokud to umí RTF a jede to pod wine, tak to nemusí být pravda.
Vývojáři her?Otázkou tak jenom zůstává, kdo tohle kolečko roztáčí.
...zdroj ma 500W a libi se mi ze na rozdil od predchoziho prezije drobne vykyvy na siti pri bource...Přesně tak! Ne, že by na to bylo dobré spoléhat, ale občas se "prostě zadaří". Jsem velmi rád, že to tady někdo zmínil, protože kolem zdrojů panuje spousta mýtů a pověr - především není pravda, že zdroj sežere tolik, "kolik je na něm napsáno" (záměrně zjednodušuji). Zdroj si za chodu vezme jen tolik, kolik je opravdová spotřeba, není tedy důvod zdroje poddimenzovávat (ale samozřejmě, cokoliv nad, řekněme, 500W -ať nežeru- jsou rovněž vyhozené peníze a často i nad 400W). To je móda, která periodicky přichází každých pár let - jen aby pak hrdí uživatelé úsporných zdrojů zjistili, že úsporný zdroj zdechne, kdykoliv se na něj někdo obrazně řečeno, křivě podívá. Protože vlastnosti zdrojů se v průběhu doby zhoršují a u dnešních velkosériových konzumních výrobků to platí dvojnásobně! Značkové počítače mají zdroje často velmi slabé, ale to má dva důvody - jednak mají značkoví výrobci přístup ke komponentám s nižší spotřebou (na rozdíl od nás, obyčejných smrtelníků, ke kterým se dostanou jen tehdy, když jich má výrobce opravdu nadbytek) a druhak, slabý zdroj zde plní úlohu příslovečného ku*viče, který se má postarat, aby počítač vydržel celou záruku, ale už ne moc dlouho po ní.
ja si myslim ze celej ten kolotoc je jenom kvuli hram, ktery sajou rok od roku vic a vic. zachvili se uz bez dvou grafik v SLI ani nenainstalujou ne?
goldenfish@xxx:~$ cat /proc/acpi/processor/CPU1/throttling state count: 8 active state: T0 states: *T0: 00% T1: 12% T2: 25% T3: 37% T4: 50% T5: 62% T6: 75% T7: 87%a zkuste si schvalne menit rychlost CPU na Vasem PC (tedy pres obsolete procfs, guru pres sysfs) takto a klidne spustit htop: echo 6 > /proc/acpi/processor/CPU1/throttling a pak vratit na nulu. A mente si cislo za prikazem echo v dame rozsahu(treba 0-7). Zjistite, ze vykon CPU (a tedy i nakup nove desky, RAM) az tak neni dulezity. samozrejme, ze pokud nestrihate video, neenkodujete jeden film za druhym a neparite nove hry(neni nad knihu) nebo neprovozujete windows. Doporucuji si to zkusit se svoji vlastni aplikaci. Klidne i ty javove. Hodne veci je totiz okolo hw nafoukntuta bublina. Anebo si vzpomenout, jak jsou dnes aplikace napsany a jaka 3D dema se zvladali bez problemu na slabsich strojich a kolik vlastne dnes aplikace zbytecne zerou vykonu, kdyz prakticky obcas jenom zobrazuji. Hodne bych na vine videl programatory(i sebe), ze jaksi dneska jsou nejvetsi optimalizace ve vyrobe aplikaci a ne jinde. Pak se ale nemuzeme divit, jak to vypada. Bohuzel mam dnes casto pocit, ze programator umi maximalne vkladat nekam nejake struktury a neco volat. Ale uz nevi vubec, jak to cele pracuje a jak s tim pocitac ci jeho cast vubec pracuje. Ano, usetrilo se. Jenomze obcas trochu na spatnem miste. Osobne mi to pripada vyvoj stylem: zadej nejak struktury a pak spust generator srotu/zdrojaku a pak to zkompiluj a deployuj. Tak nejak jsem si ozkousel, ze dneska se da hodne veci po ruznych programatorech radove nebo i bezne desetkrat [zalezi dle ulohy] zoptimalizovat na rychlost. Pripadne, jednou z chyb je to, ze architektura klient-server||terminal-server se jaksi opomiji. Je zbytecne mit na stole mainframe nebo vypocetni stredisko, kdyz to muze[a mel by] resit server. Podle me bych videl v soucasne dobe jako jednu z velkych veci prave ty optimalizace. Jo, ale kdo to zaplati.... bye gf
Dovolím si jen něco vypíchnout ...
... nebo neprovozujete windows. ...