Společnost Teufel nedávno představila svůj první open source Bluetooth reproduktor MYND.
Byla vydána verze 4.2 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Anton Carniaux, právní zástupce Microsoft France, pod přísahou: Microsoft nemůže garantovat, že data z EU nepředá do USA bez EU souhlasu, musí dodržovat americké zákony.
Byl vydán Mozilla Firefox 141.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Lokální AI umí uspořádat podobné panely do skupin. Firefox na Linuxu využívá méně paměti. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 141 je již k dispozici také na Flathubu a Snapcraftu.
NÚKIB upozorňuje na kritickou zranitelnost v SharePointu. Jedná se o kritickou zranitelnost typu RCE (remote code execution) – CVE-2025-53770, která umožňuje neautentizovaný vzdálený přístup a spuštění kódu, což může vést k úplnému převzetí kontroly nad serverem. Zranitelné verze jsou pouze on-premise verze a to konkrétně SharePoint Server 2016, 2019 a Subscription Edition. SharePoint Online (Microsoft 365) není touto zranitelností ohrožen.
Společnost Valve zpřísnila pravidla pro obsah, který je možné distribuovat ve službě Steam. Současně řadu her ze Steamu odstranila. V zásadách a pravidlech přibylo omezení 15: Obsah, který by mohl porušovat pravidla a normy stanovené zpracovateli plateb a souvisejícími sítěmi platebních karet a bankami nebo poskytovateli připojení k internetu. Sem spadají zejména určité druhy obsahu pouze pro dospělé.
Dle analytics.usa.gov je za posledních 90 dnů 6,2 % přístupů k webových stránkám a aplikacím federální vlády Spojených států z Linuxu.
Jak si zobrazit pomocí Chrome a na Chromiu založených webových prohlížečích stránky s neplatným certifikátem? Stačí napsat thisisunsafe.
V repozitáři AUR (Arch User Repository) linuxové distribuce Arch Linux byly nalezeny a odstraněny tři balíčky s malwarem. Jedná se o librewolf-fix-bin, firefox-patch-bin a zen-browser-patched-bin.
Dle plánu by Debian 13 s kódovým názvem Trixie měl vyjít v sobotu 9. srpna.
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.