Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za srpen (YouTube). Vypíchnuta je podpora Tabulek Google, implementace Gamepad API a Cookie Store API nebo také podpora WebGL na Linuxu.
openSUSE Leap 16, včetně Leap Micra 6.2+, nově nabízí 24 měsíců podpory pro každé vydání. To je dva roky aktualizací a stability, což z něj činí nejdéle podporovanou komunitní distribuci vůbec. Leap se tak stává ideální platformou pro všechny, kdo hledají moderní, stabilní a dlouhodobě podporovanou komunitní Linux distribuci.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) vydal dne 3. 9. 2025 VAROVÁNÍ před hrozbou v oblasti kybernetické bezpečnosti spočívající v předávání systémových a uživatelských dat do Čínské lidové republiky a ve vzdálené správě technických aktiv vykonávané z území Čínské lidové republiky. Varováním se musí zabývat povinné osoby podle zákona o kybernetické bezpečnosti.
Americká internetová společnost Google nemusí prodat svůj prohlížeč Chrome ani operační systém Android. Rozhodl o tom soud ve Washingtonu, který tak zamítl požadavek amerického ministerstva spravedlnosti. Soud ale firmě nařídil sdílet data s jinými podniky v zájmu posílení konkurence v oblasti internetového vyhledávání. Zároveň Googlu zakázal uzavírat dohody s výrobci mobilních a dalších zařízení, které by znemožňovaly
… více »Prvního září ozbrojení policisté zatkli na na londýnském letišti Heathrow scénáristu a režiséra Grahama Linehana, známého především komediálními seriály Ajťáci, Otec Ted nebo Black Books. Během výslechu měl 57letý Graham nebezpečně zvýšený krevní tlak až na samou hranici mrtvice a proto byl z policejní stanice převezen do nemocnice. Důvodem zatčení bylo údajné podněcování násilí v jeho 'vtipných' příspěvcích na sociální síti
… více »Studentská dílna Macgyver zve na další Virtuální Bastlírnu - pravidelné online setkání všech, kdo mají blízko k bastlení, elektronice, IT, vědě a technice. Letní prázdniny jsou za námi a je čas probrat novinky, které se přes srpen nahromadily. Tentokrát jich je více než 50! Těšit se můžete mimo jiné na:
Hardware – Bus Pirate na ESP32, reverse engineering Raspberry Pi, pseudo-ZX-80 na RISC-V, PicoCalc, organizéry na nářadí z pěny nebo … více »Google Chrome 140 byl prohlášen za stabilní. Nejnovější stabilní verze 140.0.7339.80 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 6 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
LeoCAD (Wikipedie) je svobodná multiplatformní aplikace umožňující také na Linuxu vytvářet virtuální 3D modely z kostek lega. Vydána byla verze 25.09. Zdrojové kódy a AppImage jsou k dispozici na GitHubu. Instalovat lze také z Flathubu.
RubyMine, tj. IDE pro Ruby a Rails od společnosti JetBrains, je nově zdarma pro nekomerční použití.
Český LibreOffice tým vydává překlad příručky LibreOffice Calc 25.2. Calc je tabulkový procesor kancelářského balíku LibreOffice. Příručka je ke stažení na stránce dokumentace.
Sám jsem člověkem více než cokoli jiného rozporuplným, a bohužel i mé texty jsou začasté plny rozporů. Když si jich někdy všimnu a snažím se o vysvětlování, čitelnost obvykle povážlivě klesá. Celé to je jen snaha zdokonalovat svoje vyjadřování, snaha vměstnat notně zkurvenou poezii do schémat hovorové řeči. A snad i já mohu věřit, že hledat krásná slova je lepší než zabíjet a vraždit.
Čili o tom, jak může i běžný smrtelník za běžných okolností pocítit, že dvaatřicet bitíků je zoufale málo. Předem upozorňuji, že celý text doslova přetéká výrazy z javovského světa, takže byste jej vlastně vůbec neměli číst.
Mějme aplikaci v Javě, která má nastavenou maximální velikost heapu na nějakých 1,6 GB (-Xmx1600M
). To máte na běžném 32bitovém stroji ještě celkem v pohodě. A nechť ta aplikace občas spadne na OutOfMemoryError
. To není v pohodě ani na miliónbitovém stroji, ale stanou se i horší věci (napadá mne v tuhle chvíli třeba to, že omylem kliknete na okiasův blog). Úkol je jasný: zdetekovat, vyladit, opravit, problém odstranit!
A protože jsme pokročilí drsňáci, první co provedeme před tím, než se pustíme do simulací, je nastavení automatického dumpování heapu do souboru při OOM (-XX:+HeapDumpOnOutOfMemoryError
). Ve skutečnosti problém najdete tak při druhém, třetím testu, ale to už není moc zajímavé, takže zkusme dál předpokládat, že se po chvíli nějakého toho heap dumpu dočkáme. Má sice asi 1,8 GB, ale po zabalení gzipem už se to po síti přenést dá.
Už tušíte, kde je zrada?
Tak dál: v Javě verze 6 jsme se dočkali pěkného nástroje pro analýzu heapu (jhat). Předhodíte mu heap dump, on ho pár minut chroustá –
A skončí na OutOfMemoryError
. Jak milé! Fakt je, že paměťové nároky takového nástroje jsou zvrhle vysoké, ostatně je zvrhle vysoce užitečný. Odhaduju, že pro zpracování našeho dumpu by potřeboval tak 6 GB – a můžete mít klidně 10 GB místa na swapu, virtuální adresní prostor procesu nezvětšíte. Na 32bitové architektuře zkrátka přes 4 GB nejede vlak, a to si gigabajt nebo dva uzurpuje jádro.
(Ehm. Mám za to, že nějaké způsoby existují, ale nic o nich nevím. Poučí mne někdo v diskusi?)
Štěstí v neštěstí? Jhat si poradí i s prvním půlgigabajtem dumpu, ale jak moc vypovídající údaje poskytne, to je otázka.
Poučení? I 64 bitů bude jednou málo. Jsem ostatně toho názoru, že nejmenší adresovatelná část paměti, říkejme třeba bajt, by měla být nejméně 64 bitů velká, ideálně 128. Výhoda by byla, že by se do jednoho bajtu vešla celá IPv6 adresa Nemluvě o Unicodu. A výrobci disků by určitě zajásali. Samá pozitiva, sociální jistoty a sexuální stimulanty.
A jaké máte vy důvody pro 64bitovou architekturu (nebo aspoň proč po ní toužíte)?
Tiskni
Sdílej:
Běžný smrtelník by se hlavně divil proč máš na hromadě 1,6 Velké Británie. Že by nějaké nové kolonie? Třetí světová?V podstatě jo. One ring to rule them all!
predstav si treba operacni system, kde by vsechny nainstalovane knihovny meli pevne misto v adresnim prostoruPřesně tohle dělá
prelink
- upravuje umístění binárních spustitelných souborů a knihoven tak, aby měly pevné místo v adresním prostoru. Znatelně to zrychluje start programů, i když to má také své mouchy.
Zvenku se to ale pořád tváří jako CISC kompatibilní s 386, což znamená spoustu elektroniky navícNe, neznamená. Téch tranzistorů na překlad z x86 instrukcí do mikrokódu nebude nejspíš ani 1% z celého CPU. Nemůžu teď najít citaci, ale někde jsem to četl.
Mám za to, že nějaké způsoby existují, ale nic o nich nevím. Poučí mne někdo v diskusi?No, způsoby jak využívat velkou paměť (> 4 GB) na 32bitovém stroji existují. Ale nevím o způsobu, jak s 32 bity přešvihnout 4 GB adresního prostoru na proces.
qemu-system-x86_64
, a na 32-bit hostu jsem úspěšně nainstaloval Arch64. :)
mmap()
? Vezmu 3 GB soubor, namapuju ho do paměti, a můžu s ním pracovat pohodlně pomocí ukazatelů s struktur. Jak si to zařídí OS mne jako programátora nemusí moc zajímat (pokud nemám nějaký zvláštní přístup k souboru, takže dokážu mapování mezi souborem a pamětí udělat daleko efektivněji, než to zvládne OS).
Ostatně, k čemu slouží třeba taková funkce mmap()? Vezmu 3 GB soubor, namapuju ho do paměti, a můžu s ním pracovat pohodlně pomocí ukazatelů s struktur. Jak si to zařídí OS mne jako programátora nemusí moc zajímat (pokud nemám nějaký zvláštní přístup k souboru, takže dokážu mapování mezi souborem a pamětí udělat daleko efektivněji, než to zvládne OS).Lze to také výhodně kombinovat s
madvise()
, aby jádro vědělo, jak se bude určitý úsek paměti používat (náhodně, sekvenčně, brzy, hned tak ne apod.).
To len tak, keď sa človek po večeroch nudí, von z okna na padajúce kvapky dažďa pozerá, aby si závity prečistil, premazal (nie namazal )
Kromě toho GC nemusí být vůbec nefunkční, ke katastrofě může dojít i jen tehdy, když se spustí v nevhodnou chvíli.K takové "katastrofě" by mohlo dojít snad jen v případě, že by GC zabral systémové prostředky, které by nemohl využít zbytek aplikace. Jenže to by pořád ještě nemělo skončit katastrofou, protože Java není určena pro realtime systémy
Java není určena pro realtime systémyMinimálně Sun by s takovým výrokem rozhodně nesouhlasil
Real-Time Specification for Java (RTSJ) **vyžaduje**, aby JVM poskytovalo třídy s funkcemi, které umožní přímý přístup k fyzické paměti; veškeré fyzické paměti.
You acknowledge that Licensed Software is not designed or intended for use in the design, construction, operation or maintenance of any nuclear facility. Sun Microsystems, Inc. disclaims any express or implied warranty of fitness for such uses.Realtimová Java je už trochu něco jiného, mimo jiné má právě další možnosti práce s pamětí, které umožňují obejít GC.
Javovský program ale nemá šanci, jak jinak zrušit objekt, než přes GC.TIMTOWDI asi "veľký návrhár javy" nepoznal
K takové "katastrofě" by mohlo dojít snad jen v případě, že by GC zabral systémové prostředky, které by nemohl využít zbytek aplikace. Jenže to by pořád ještě nemělo skončit katastrofou, protože Java není určena pro realtime systémyHmm, blbá otázka: ako má JVM (a GC) ošetrený deadlock vo finalize ?
finalize
může být voláno z libovolného vlákna, vláken pro finalizaci může běžet v systému několik. Takže případný deadlock by neměl ohrozit GC, ten si maximálně vytvoří další vlákno pro finalizaci. Takže z toho nejspíš vznikne "jen" klasický memory leak.
class Foo { private static List log = new ArrayList(); public void bar() { log.add(new LogItem(...)); } }
Předhodíte mu heap dump, on ho pár minut chroustá – A skončí na OutOfMemoryError. Jak milé!
Třeba je problém v tom jhatu - zkuste vzít jeho heap dump a zanalyzovat ho, dobrý nástroj na todle je jhat.