HollowByte je zranitelnost typu Denial of Service (DoS) v kryptografické knihovně OpenSSL. Útočník může odesíláním škodlivého payloadu o velikosti pouhých 11 bajtů zaplnit paměť serveru. OpenSSL před ověřením dat vyhradí nepřiměřený blok paměti (až 131 KB). Server pak čeká na data, která nepřišla. Zranitelnost je opravena ve verzích OpenSSL 4.0.1, 3.6.3, 3.5.7, 3.4.6 a 3.0.21.
Ve španělské A Coruñě probíhá GUADEC 2026, tj. letošní konference vývojářů a uživatelů desktopového prostředí GNOME. Videozáznamy přednášek jsou k dispozici na YouTube.
Společnost Collabora ve spolupráci s Valve vyvíjí Holo Core, tj. port Arch Linuxu pro ARM64 procesory (AArch64), který bude pohánět VR headset Steam Frame. Pro testování Arch Linuxu pro AArch64 jsou k dispozici binární balíčky, zdrojové kódy i kontejner pro Docker nebo Podman.
Mikroprocesor Zilog Z80 byl oficiálně uveden na trh před 50 lety, tj. v červenci 1976. Výroba mikroprocesoru skončila v roce 2024.
Výzkumníci ze společnosti ESET objevili 11 zapomenutých UEFI shim zavaděčů, které byly podepsány společností Microsoft, a které umožňují útočníkům obejít ochranu UEFI Secure Boot na většině zařízení. Microsoft je zneplatnil (přidal jejich hash do databáze dbx) v rámci aktualizace Patch Tuesday dne 9. června 2026. Uživatelé Linuxu mohou databází aktualizovat pomocí LVFS. Ověřit zneplatnění zavaděčů lze pomocí skriptu uefi-dbx-audit. Jedná se o CVE-2026-8863 a CVE-2026-10797.
pico-usb-wifi je open source firmware pro Raspberry Pi Pico W, který jej promění v USB Wi-Fi adaptér. Po připojení k počítači se objeví jako zařízení USB CDC-NCM.
Americká společnost Google ze skupiny Alphabet bude muset podle nových požadavků Evropské unie umožnit společnosti OpenAI i dalším konkurentům v oblasti umělé inteligence (AI) a internetových vyhledávačů přístup ke svým službám. Ve svém rozhodnutí o tom včera informovala Evropská komise (EK). Opatření má zajistit dodržování pravidel, jejichž cílem je omezit v EU tržní sílu velkých technologických firem. Google s tím nesouhlasí.
… více »Nové verze webových prohlížečů Chrome a Firefox jsou vydávány každé 4 týdny. Aktuální verze Chrome je 150. Aktuální verze Firefoxu je 152. V březnu bylo oznámeno, že od září přejde Chrome na dvoutýdenní cyklus vydávání verzí. To by znamenalo, že Chrome v číslování verzí Firefox brzy přeskočí. Vývojáři Firefoxu proto také od září přecházejí na dvoutýdenní cyklus vydávání verzí. :-)
Microsoft Comic Chat (Wikipedie), tj. grafický IRC klient z devadesátek, který převáděl konverzace na IRC do podoby komiksových panelů, a který zpopularizoval font Comic Sans, je dnešním dnem open source. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Byla vydána (𝕏) nová verze 26.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 26.7 je Xenial Xenops. Přehled novinek v příspěvku na fóru.
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.
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: