Byla vydána (𝕏) nová major verze 17 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností i s náhledy a videi v oficiálním oznámení.
Sovereign Tech Fund, tj. program financování otevřeného softwaru německým ministerstvem hospodářství a ochrany klimatu, podpoří vývoj FFmpeg částkou 157 580 eur. V listopadu loňského roku podpořil GNOME částkou 1 milion eur.
24. září 2024 budou zveřejněny zdrojové kódy přehrávače Winamp.
Google Chrome 125 byl prohlášen za stabilní. Nejnovější stabilní verze 125.0.6422.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Textový editor Neovim byl vydán ve verzi 0.10 (𝕏). Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Byla vydána nová verze 6.3 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.15.
Dnes ve 12:00 byla spuštěna první aukce domén .CZ. Zatím největší zájem je o dro.cz, kachnicka.cz, octavie.cz, uvycepu.cz a vnady.cz [𝕏].
JackTrip byl vydán ve verzi 2.3.0. Jedná se o multiplatformní open source software umožňující hudebníkům z různých částí světa společné hraní. JackTrip lze instalovat také z Flathubu.
Patnáctý ročník ne-konference jOpenSpace se koná 4. – 6. října 2024 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áří všichni účastníci, se skládá z desetiminutových
… více »Program pro generování 3D lidských postav MakeHuman (Wikipedie, GitHub) byl vydán ve verzi 1.3.0. Hlavní novinkou je výběr tvaru těla (body shapes).
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 Pochopitelně takové ohýbání Javy vede na věci, které jsou popsány např. v Jaderných novinách
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.
Tiskni Sdílej: