KiCad (Wikipedie), sada svobodných softwarových nástrojů pro počítačový návrh elektronických zařízení (EDA), byl vydán v nové major verzi 10.0.0 (𝕏). Přehled novinek v příspěvku na blogu.
Letošní Turingovou cenu (2025 ACM A.M. Turing Award, Nobelova cena informatiky) získali Charles H. Bennett a Gilles Brassard za základní přínosy do oboru kvantové informatiky, které převrátily pojetí bezpečné neprolomitelné komunikace a výpočetní techniky. Jejich protokol BB84 z roku 1984 umožnil fyzikálně zaručený bezpečný přenos šifrovacích klíčů, zatímco jejich práce o kvantové teleportaci položila teoretické základy pro budoucí kvantový internet. Jejich práce spojila fyziku s informatikou a ovlivnila celou generaci vědců.
Firefox 149 dostupný od 24. března přinese bezplatnou vestavěnou VPN s 50 GB přenesených dat měsíčně (s CZ a SK se zatím nepočítá) a zobrazení dvou webových stránek vedle sebe v jednom panelu (split view). Firefox Labs 149 umožní přidat poznámky k panelům (tab notes, videoukázka).
Byla vydána nová stabilní verze 7.9 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 146. Přehled novinek i s náhledy v příspěvku na blogu.
Dle plánu byla vydána Opera GX pro Linux. Ke stažení je .deb i .rpm. V plánu je flatpak. Opera GX je webový prohlížeč zaměřený na hráče počítačových her.
GNUnet (Wikipedie) byl vydán v nové major verzi 0.27.0. Jedná se o framework pro decentralizované peer-to-peer síťování, na kterém je postavena řada aplikací.
Byly publikovány informace (technické detaily) o bezpečnostním problému Snapu. Jedná se o CVE-2026-3888. Neprivilegovaný lokální uživatel může s využitím snap-confine a systemd-tmpfiles získat práva roota.
Nightingale je open-source karaoke aplikace, která z jakékoliv písničky lokálního alba (včetně videí) dokáže oddělit vokály, získat text a vše přehrát se synchronizací na úrovni jednotlivých slov a hodnocením intonace. Pro separaci vokálů využívá UVR Karaoke model s Demucs od Mety, texty písní stahuje z lrclib.net (LRCLIB), případně extrahuje pomocí whisperX, který rovněž využívá k načasování slov. V případě audiosouborů aplikace na
… více »Po půl roce vývoje od vydání verze 49 bylo vydáno GNOME 50 s kódovým názvem Tokyo (Mastodon). Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře.
Článek na stránkách Fedora Magazinu informuje o vydání Fedora Asahi Remixu 43, tj. linuxové distribuce pro Apple Silicon vycházející z Fedora Linuxu 43.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
while(! konec){
aktualizuj_model_sceny();
renderuj_screen_do_bufferu();
prohod_buffery();
}
A to opravdu sezere veskery vykon procesoru at to piste v cemkoli.
A co se trhani tyka .. proste to nestiha (alpha blending a antialiasing si zadaji sve) - coz ovsem nestihaji ani nativni C dema (viz gl 2D xscreensaver renderovany pres MESA), pokud nemaji k dispozici HW akceleraci.
-server, jsem zvedav, jak se to projevi na vykonu 
.
Malý testík -- mám dva miniprográmky, které se připojí na můj MySQL server spustí jeden (stejný) SELECT, uvolní zdroje a skončí -- jeden v C, druhý v Javě. Ten v C běží při opakovaném spouštěním (time mysql_pokus) asi real 0.004 s, Ten v Jave asi real 0.52 s). Věřím, že většinu času zabere start JVM a samotný kód se vykoná už vcelku rychle. Ale ošetřování vyjímek, tvorba objektů, volání virtuálních funkcí je prostě _pomalejší_ než volání běžných funckí, kontrola návratových hodnot apod.
Program je sice v Javě hezčí, lépe se spravuje a dodává se mu nová funkčnost, ale platí se za to.
Nicméně -- nic proti Javě -- osobně ji mám rád a s potěšením kvituji, že takový jazyk je (JSP, aplety, java.net.*).
| Test | GCC | SUN | SUN -server | SUN -client | IBM |
| Composite score | 301.74 | 118.5 | 170.3 | 137.3 | 230.9 |
| FFT | 257.26 | 57.6 | 131.9 | 58.0 | 190.5 |
| SOR | 272.17 | 247.8 | 240.1 | 273.9 | 267.6 |
| MonteCarlo | 91.0 | 24.2 | 45.8 | 24.3 | 55.6 |
| Sparse matmult | 393.61 | 63.2 | 109.1 | 130.5 | 220.2 |
| LU | 494.69 | 199.6 | 324.3 | 199.7 | 420.5 |
Verze 1.5 má mít rozsáhlou podporu procesorů AMD Opteron.
| Test | ICC | GCC | SUN | SUN -server | SUN -client | IBM |
| Composite score | 524.6 | 493.3 | 189.7 | 436.2 | 195.5 | 390.3 |
| FFT | 306.0 | 281.3 | 49.6 | 249.0 | 73.1 | 261.6 |
| SOR | 582.2 | 365.0 | 324.6 | 601.4 | 324.5 | 360.6 |
| MonteCarlo | 58.1 | 136.3 | 37.4 | 58.2 | 41.1 | 63.6 |
| Sparse matmult | 593.1 | 782.5 | 126.0 | 404.7 | 127.8 | 373.5 |
| LU | 1083.6 | 901.2 | 410.6 | 868.0 | 411.2 | 892.1 |
.
Muj zaver je, ze az bude mit java dostatecne kvalitni (rozumej rychle) knihovny pro praci s GUI tak bude pouzitelna i pro normalni programy a ne jen na server, nebo jednoucelove konzolove aplikace.
pro gcc jsem pouzil tyto parametry:
-O3 -ffast-math -fomit-frame-pointer -march=athlon -mcpu=athlon
Na stroji v tu chvili nebezelo nic jineho, co by mohlo zatezovat CPU a swap byl vypnuty. Kazdy test jsem udelal 2x a vysledna hodnota je prumer.
3.10.2003 13:03
CIJOML | skóre: 58
| Praha
3.10.2003 13:16
CIJOML | skóre: 58
| Praha
3.10.2003 13:29
CIJOML | skóre: 58
| Praha
3.10.2003 14:13
CIJOML | skóre: 58
| Praha
Kdyby se tým rozhodoval takhle, tak bude dodnes programovat v pascalu, protože učit se nový jazyk by se během nejbližšího projektu nezaplatilo.
Sam pouzivam Javu na desktopu i serveru uz hezkych par let, stejne jako se profesionalne venuji programovani v tomto jazyce (takze jsem "zaujaty"). Rozhodne si nemyslim, ze se Java vykonostne vyrovna reseni v kompilovanem jazyce. Je skvele, ze se ten rozdil kazdy rok snizuje, ale existuje.
Podle mne je nejvetsim problemem narocnost na pamet. I ta nejmensi aplikace zabira nekolik megabajtu, co teprve XML editor XXE ci moc hezke IDE IntelliJ IDEA? To jde do desitek mega. I kdyby samotny beh byl srovnatelne rychly, tak naroky na spravu pameti budou Javu vzdy srazet dolu.
JDK 1.5 ma pry prinest sdileni VM, takze kazda nove spustena aplikace nebude vyzadovat novy VM. To bude fajn, ale stejne - Sun by se mel spise nez na pridavani novych vlastnosti soustredit na snizeni narocnosti na pamet. A dalsi optimalizace na rychlost. (Nove jazykove vlastnosti jako generics vypadaji skvele a uz se na ne tesim).
Nicmene abych se vratil zpet, tak hlavni bodem je efektivita programatora a ta je IMHO v Jave nejlepsi. Proto se velka cast serverovych aplikaci realizuje prave v ni. Vsichni, kdo mame mobil nebo bankovni ucet, jsme de facto uzivateli Javy. Oskar, Eurotel, T-Mobile - Java. Pocet bank (s castmi nebo celymi IS implementovanymi v Jave) take rychle roste. Na strane serveru Java dominuje, to je fakt (tim nemyslim SMTP, HTTP apod, ale enterprise reseni).
To ovsem neznamena, ze Java je nejlepsi jazyk a ostatni jsou spatne. Napriklad jsem rad, ze KDE ci Mozilla neni napsano v Jave Kazdy pouzivejme, co nam vyhovuje a neurazejme se navzajem, jak to predvadi Cijoml.
BTW, zarovnavani v Pythonu je mozna divne, ale pokud srovnate citelnost s treba s Perlem tak je to naprosto genialni napad.
Hrozne se mi libi cistota navrhu (vetsiny rozhrani java.*). napriklad takovy InputStream ci Collection - parada. I to, ze vsechno je potomkem tridy Object - matne si vzpominam, ze C++ spolecneho predka nema.
Taky se mi libi, ze java developeri (ktere znam) se snazi o sebevzdelavani, hledaji best practices, nasazuji patterny .. Ach jo, kde jsou ty casy 12snap, to byl skvely tym!
Upozornuji na prisny zakaz pouzivani sprostych slov (kam aspon ja "sracky" zarazuju). Takove prispevky budou bez ohledu na relevantnost zbytku textu smazany!
Jinak k tvemu prispevku: pausalne shazujes vsechny javisty do jednoho pytle. Kdyby sis precetl poradne tuto diskusi, najdes tu spoustu reakci programatoru v Jave, kteri tak necini. Takze jsem matematicky dokazal, ze tvuj konstrukt neni pravdivy (dukaz sporem)
* _velmi silna_ a rychla std. knihovna (napr. String ma cca 100 metod, vsechny v C), takze 99% programu vykonavaji rychle C metody.
* binding na vsechny mozny C knihovny
* velka komunita uzivatelu
* docela jednoduse by sel preklad Ruby kodu -> C kod pouzivajici libruby.so -> gcc -> spustitelna binarka (kdyby o to nekdo stal ;)
Rychly start, rychly beh i u hodne slozitych projektu (mam v nem napsany server o nekolika tisici radcich kodu a beha jako vino), opravdu jednoduse rozsiritelny pomoci C kodu (mozne tedy psat cast kodu v Ruby, cast v C/C++), podpora threadu i v DOSu (kdyby o to nekdo stal , atd.
Zda se mi to jako systemovejsi pristup - pouzivat co nejvic knihoven, ktere uz existuji, nez si vsechno psat znovu - pro Javu. Napr. existuje temet 100% binding na vsechny gnome knihovny. A hodne z tech knihoven vam pobezi i na Widlich, takze porad pisete multiplatforme .
). Navic dokumentace (online) a knizek je myslim dost a dost ...
Dokonce s verzi 1.8 je uz i nativni Ruby celkem rychly A stejne pokud by nebyl, je prevod Ruby->extenze_v_C jednoduchy (jak uz tu bylo zmineno).
) ale v praxi se potkávám s výsledky takového programování - s hotovými produkty. A jako systémák vidím, kolik to potřebuje systémových zdrojů a jak rychle to funguje. Stejně tak vím své o čistotě kódu v java aplikacích, se kterými se setkávám. (Jejich tvůrci jsou např. Oracle.) Často je vůbec problém najít odkud se berou vstupní parametry.
Také se potkávám s mnoha lidmi, kteří o sobě tvrdí, že jsou programátoři (v javě) a já přitom vidím jejich kód. Jak snadné je "splácat" pár tříd a nemít ani ponětí o časové či paměťové náročnosti. To vám nemusí souviset článkem, ale dává to další střípek k odpovědi na otázku o rudém praporu. Daň za módnost. Doufejme, že se to časem upraví.
Proto článek beru spíše informativně a z tohoto pohledu autorovi děkuji za dobrý nápad ukázat nové možnosti javy. Rozhodně stojí za to zamyslet se, jak java aplikace urychlit, když jsou opravdu skoro všude kolem nás.
))))))))))
Tiskni
Sdílej:
