Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
Jak stahujete (větší objemy dat z HTTP)?
| FatRat |
|
3% (60) |
| SlimRat |
|
2% (35) |
| jDownloader |
|
8% (149) |
| Tucan |
|
1% (26) |
| wget |
|
51% (914) |
| přes prohlížeč webu |
|
61% (1084) |
| jinak |
|
10% (186) |
Celkem 1781 hlasů
Vytvořeno: 11.2.2010 23:54
Tiskni
Sdílej:
12.2.2010 00:47
Prcek | skóre: 43
| Jindřichův Hradec / Brno
12.2.2010 08:20
grubber | skóre: 6
| blog: grubber
| Břeclav / Brno
12.2.2010 10:39
kotyz | skóre: 25
| blog: kotyzblog
| Plzeň
12.2.2010 13:04
Rezza | skóre: 25
| blog: rezza
| Brno
12.2.2010 07:03
David Watzke | skóre: 74
| blog: Blog...
| Praha
12.2.2010 08:17
Konqui | skóre: 18
| blog: Konqui
| Rožnov pod Radhoštěm
12.2.2010 08:22
grubber | skóre: 6
| blog: grubber
| Břeclav / Brno
12.2.2010 12:53
kotyz | skóre: 25
| blog: kotyzblog
| Plzeň
12.2.2010 13:10
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
12.2.2010 08:22
jiri.one | skóre: 19
| blog: Jiriho blog
12.2.2010 09:06
Amarok | skóre: 33
| blog: blogoblog
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
wget v dnesni dobe neco stahovat, kdyz je na vetsine stranek CAPTCHA? Prijde mi, ze jinou moznost nez pres prohlizec ani nemam (Fatrat jsem nezkousel).
Nicméně osobně používám placený RapidShare, takže mě to netrápí...
12.2.2010 11:34
kotyz | skóre: 25
| blog: kotyzblog
| Plzeň
12.2.2010 16:39
Jendа | skóre: 78
| blog: Jenda
| JO70FB
Jde vubec pomoci wget v dnesni dobe neco stahovat, kdyz je na vetsine stranek CAPTCHA?Záleží na tom, co stahuješ
.
) je totiž v JDownloaderu dotažená k dokonalosti a neustále pravidelně updatovaná. Navíc je naprosto perfektní sdružování stahovaných odkazů do skupin (když se jedná např. o jeden film rozdělený do více RARů, jak je to běžné).
Kdyby tak FatRat dokázal používat stahovací pluginy z JDownloaderu (pro vždy aktuální podporu těch všech možných i nemožných úložných serverů) a přidal toto groupování odkazů, byl bych naprosto spokojen Ale bohužel teď jsem odkázán na Java aplikaci 
Není něco takového pro FatRat v plánu?
) jsem zapomněl - po stažení odkazy automaticky rozbaluje (díky groupování pozná kdy je stažen celý vícesouborový RAR archiv). Navíc lze předem nastavit heslo k archivu (už když ho člověk dává stahovat, zas pro celou skupinu odkazů), což je taktéž velmi důležité, protože pak člověk nemusí zpětně horkotěžko hledat odkud ty zaheslované archivy stáhnul, když si předtím zapomněl heslo poznamenat
12.2.2010 10:23
Saljack | skóre: 28
| blog: Saljack
| Praha
Ale je to opravdu extrémně kvalitní aplikace, takže jsem to schopen překousnout... nicméně kdyby existovala stejně kvalitní alternativa v Qt/KDE, neváhal bych s přechodem ani chvíli
12.2.2010 16:57
xkucf03 | skóre: 49
| blog: xkucf03
Jen kdyby to nebyla ta zpropadená JavaKvůli GUI? Nebo jen typický názor „Java je špatná protože… je to Java“. Co kdyby to bylo třeba v Pythonu? Taky špatně?
A proč Java ne? Zaprvé kvůli GUI, které absolutně nezapadá do systému, což mě osobně opravdu silně vadí.
Zadruhé kvůli rychlosti (neříkám že Java aplikace musí být nutně pomalé, ale JDownloader odezvu GUI rozhodně pomalou má, a to ho mám na dvoujádře 2,5 GHz).
A za třetí kvůli paměťové náročnosti Javy (když nepočítám browser s cca 30 otevřenými taby, tak je JDownloader paměťově nejžravějším procesem v celém mém systému). Aniž by cokoliv dělal sežere okolo 250 MB, přitom jsem si stoprocentně jistý, že třeba v PyQt by obdobná aplikace nesežrala víc jak 30 MB.
13.2.2010 19:12
Algi | skóre: 1
| blog: Sinner
13.2.2010 21:31
xkucf03 | skóre: 49
| blog: xkucf03
13.2.2010 19:38
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
14.2.2010 00:15
Algi | skóre: 1
| blog: Sinner
asi nebude moc případů použití, kdy program spotřebuje 1 GB RAM, pak se vrátí na využití 100 MB a poběží další tři roky s tím, že si vystačí s tou stovkou megabajtůVyužití paměti Javovým programem je v čase taková pilovitá funkce. Dá se tedy říct, že program, který po GC nějakou stránku nepotřebuje, ji nebude potřebovat ještě půl intervalu k dalšímu GC.
Za druhé správa dostupné paměti je záležitost operačního systému a není správné, aby to dubloval ještě samotný programPokud "není správné" podle vás == "jsem na to moc líný" pak jistě. Ale program nic dublovat nemusí, stačí, když řekne OS, že určité stránky už nepotřebuje a data z nich lze zahodit.
JVM by měla umět nevyužívanou paměť vynulovat, aby s ní OS neměl tolik práce (nemusel ji třeba odswapovat)To je blbost, nulování (ani jakékoli jiné měnění obsahu) ničemu nepomůže. I stránka, kterou program vynuloval, bude časem OS odswapována, a co hůř, před tím způsobí odswapování jiných stránky s potenciálně užitečnými daty. Dále, až ta halda znovu nakyne, a tato (odswapovaná) stránka bude potřeba, bude se muset znovu přečíst ze swapu (i když data z ní nebudou už nikdy čtena). Kdyby se v takovém případě jen namapovala nová stránka, může OS použít jakoukoli stránku, kterou má zrovna k dispozici.
Přidělování paměti má význam v případě, kdy se přiděluje opravdu fyzická RAMPřidělování a uvolňování má smysl, kdykoli jde o (množstvím) omezený prostředek. Virtuální paměť, jako cosi, do čeho si program (možná) může uložit nějaké data, a co garantuje, že se jednou zapsaná data neztratí, rozhodně není neomezený prostředek.
Využití paměti Javovým programem je v čase taková pilovitá funkce. Dá se tedy říct, že program, který po GC nějakou stránku nepotřebuje, ji nebude potřebovat ještě půl intervalu k dalšímu GC.A taky se dá říct, že po půl intervalu tu stránku opět bude potřebovat, a musel by ji od operačního systému znova alokovat.
Ale program nic dublovat nemusí, stačí, když řekne OS, že určité stránky už nepotřebuje a data z nich lze zahodit.A co jiného píšu? Alokace/dealokace nemusí být to samé, jako paměť se používá/nepoužívá.
I stránka, kterou program vynuloval, bude časem OS odswapována, a co hůř, před tím způsobí odswapování jiných stránky s potenciálně užitečnými daty.To záleží na OS, chytrý OS nebude vynulovanou stránku držet ve fyzické paměti ani odswapovávat na disk.
Přidělování a uvolňování má smysl, kdykoli jde o (množstvím) omezený prostředek. Virtuální paměť, jako cosi, do čeho si program (možná) může uložit nějaké data, a co garantuje, že se jednou zapsaná data neztratí, rozhodně není neomezený prostředek.V tomto smyslu však je omezeným prostředkem i tabulka alokací. A je pak otázka, co je lepší – zda mít v tabulce alokací málo záznamů, ale mít alokovánu paměť, kterou program nevyužívá, nebo alokovat jenom nutné minimum ale mít alokovánu spoustu jednostránkových bloků.
No a? Myslíte, že je to problém?Využití paměti Javovým programem je v čase taková pilovitá funkce. Dá se tedy říct, že program, který po GC nějakou stránku nepotřebuje, ji nebude potřebovat ještě půl intervalu k dalšímu GC.A taky se dá říct, že po půl intervalu tu stránku opět bude potřebovat, a musel by ji od operačního systému znova alokovat.
Jiného píšete přesně to, co jste napsal. Ve skutečnosti neexistuje jiný způsob, jak OS říct, že data v určité části paměti nebudete potřebovat, než ji dealokovat.Ale program nic dublovat nemusí, stačí, když řekne OS, že určité stránky už nepotřebuje a data z nich lze zahodit.A co jiného píšu? Alokace/dealokace nemusí být to samé, jako paměť se používá/nepoužívá.
Tohle už silně zavání Bohnicema (a tím nemyslím BLEK.a). Zkusil jste si to představit? Jak by asi OS zjistil, že je stránka vynulovaná? Myslíte, že by OS vždy čas od času přečetl celou paměť, aby zjistil, jestli náhodou něco nebylo vynulováno? Že by OS nemusel odswapovávat nulové stránky je pravda, ale neděje se to. Ostatně si to můžete vyzkoušet. V příloze je program v C. Pokud jsou vaše teorie správné, tak po jeho spuštění nebudete pozorovat žádné swapování (na systému se swapem, samozřjemě).I stránka, kterou program vynuloval, bude časem OS odswapována, a co hůř, před tím způsobí odswapování jiných stránky s potenciálně užitečnými daty.To záleží na OS, chytrý OS nebude vynulovanou stránku držet ve fyzické paměti ani odswapovávat na disk.
Vzhledem k tomu, že paměťová složitost struktur virtuální paměti je aspoň v Linuxu Theta(počet stránek), je tahle námitka bezpředmětná. Kromě toho nikdo nechce po JVM, aby do paměťové mapy dělala díry, naprosto by stačilo, aby po GC odstřelila celý konec haldy.Přidělování a uvolňování má smysl, kdykoli jde o (množstvím) omezený prostředek. Virtuální paměť, jako cosi, do čeho si program (možná) může uložit nějaké data, a co garantuje, že se jednou zapsaná data neztratí, rozhodně není neomezený prostředek.V tomto smyslu však je omezeným prostředkem i tabulka alokací. A je pak otázka, co je lepší – zda mít v tabulce alokací málo záznamů, ale mít alokovánu paměť, kterou program nevyužívá, nebo alokovat jenom nutné minimum ale mít alokovánu spoustu jednostránkových bloků.
a hobik snad pokud jeste nevidel v akci podobne monstrozni pripady typicky nasazeni "nevhodne" aplikace do x86 JVM - aplikace by byla vhodna pokud by se ovsem JVM dokazalo rozume chovat samo od sebe, ale kdyz tim "prasenim" se snazi schovat fakt, ze pokud ma byt schopne existovat v systemu jeste s dalsimi, tak bude ohrome nevykonne.
16.2.2010 21:23
Algi | skóre: 1
| blog: Sinner
A protože věřím v to druhé, tak se zeptám, zda můžete porovnat GC Javy a Objective-C 2.0 při použití GC (nikoliv klasického retain/release). Protože to je to, co mi ještě pořádně nikdo neobjasnil: jak je možné, že Java potřebuje mít své vlastní hřiště pro správu paměti (vezme si kus paměti od OS a pak si na něm sama alokuje/dealokuje objekty) a Objective-C 2.0 s jejich GC toto nepotřebují a chovají se jako normální nativní aplikace (co se týče paměti). Já vím, dalo by se to určitě někde dočíst v manuálu či příručkách... Ale pro mě jako laika co se týče programovaní v Obj-C by to byla velmi zajímavá informace.
16.2.2010 21:56
Algi | skóre: 1
| blog: Sinner
12.2.2010 11:10
glibc, tak JVM). Rozdíl je v tom, že když glibc zjistí na konci volné bloky, vrátí je OS, kdežto Sunovská JVM si je ponechá. Při příští alokaci pak JVM sáhne do „zásob“, glibc znovu alokuje paměť od OS. Alespoň by to tak mělo vypadat podle toho, co se o alokátorech běžně píše – nikdy jsem nezkoumal, jak to alokátory dělají doopravdy.
glibc i Sunovská JVM) alokují paměť po blocích, rozdíl je pouze v „agresivitě“ přístupu – glibc si od OS klidně alokuje jeden další blok a klidně jeden blok systému uvolní, JVM používá strategii „když už alokuju paměť od OS, nebudu to dělat opakovaně po troškách, ale alokuji rovnou víc paměti“, a stejně nevrací OS každou uvolněnou paměť, ale až teprve když má volné paměti „moc“. Přičemž parametry tohoto chování si můžete nastavit, pro nativní aplikaci si zase můžete napsat vlastní alokátor
určit maximum alokované paměti (to umí málokterý nativní program)
Runtime resources: RLIMIT_DATA. Proč by to měl umět program, když to lze nastavit přes ulimit(1)? Ostatně i v javě to nastavuje virtuální stroj, nikoliv program.
16.2.2010 22:30
Algi | skóre: 1
| blog: Sinner
a vy vite kolik informaci si kazdy produkt drzi ke ktere skupine zakazniku, aby slo nabidnout nejvhodnejsi podobny? tusite jak jak jsou zakaznici rozdelni?Nevím. Ale tuším, že to nebude tak, že tyto informace normálně zabírají 10 MB, a jednou za měsíc to naroste na 10 GB. Takže pořád nevidím důvod, proč by se ta aplikace měla chovat tak, že drží paměť, kterou k ničemu nepotřebuje. Nevím, čeho se týkají vaše 1 % a 30 % – podle mne ta aplikace normálně běží, má alokované určité množství paměti, které se nemění, a alokované paměť je přiměřeně využita. nevidím v tom žádný problém.
obdobne potom pod zatezi toho jvm kdyz dojde k vyrazne zmene chovani aplikace, aby doslo k odlehceni a zaroven aby to system ustal, tak takto nastavene jvm si potom pri beznem provozu s neomezenymi funkcemi vezme proti behu optimalizovanemu na tu mirnou zatez opet z hostitelskeho systemu treba az o 30% vice vykonu proti situaci, kdy bezi s jinym nastavenim parametru?Pořád nevím, k jaké výrazné změně chování dojde. To ta aplikace najednou potřebuje řádově více RAM? Proč ji nemá dostupnou i v okamžiku, kdy ta aplikace není zatížena? To na tom stroji spouštíte v době, kdy není zatížen, nějaké jiné paměťově náročné úlohy?
proc tak lpite na tom faktu, ze fixni nastaveni tech parametru jvm neni navrhova chyba, kdyz je to vice nez zrejme, ze pri extremnich vykyvech uvnitr a mimo jvm je to i podle vasich prohlaseni v dnes(17.2.) 13:41 Filip Jirsák" jde o chybne pouziti kombinace jvm-aplikace?Protože zatím nevím o jediném případu, kde by to způsobovalo problémy. Vy tvrdíte, že o nějakém víte, ale nedokážete popsat ani jaké problémy a v jaké situaci to způsobuje, takže pak těžko posoudit, zda je to chyba v návrhu JVM nebo v návrhu aplikace. I pokud by to byl problém na straně JVM, nevidím důvod, proč kvůli jediné aplikaci předělávat JVM, které pro všechny ostatní případy vyhovuje – spíš bych to pak viděl na špatnou volbu nástroje.
System.gc(), což je ale ošklivý hack. Ošklivý hack je i to, že je nutné pro takové chování explicitní volání GC opakovat, protože explicitní volání GC je zrovna případ, kdy by automatické uvolnění volné paměti dávalo smysl. Jenže spousta programů volá GC zbytečně, proto se GC paměti nerado vzdává i při explicitní GC. Pak z téhle soustavy hacků má něco rozumného vypadnout… Koneckonců i ta změna parametrů by přes JMX byla možná (a připadalo by mi to lepší, než nějaká funkce, která by je počítala), problém je, že s proměnlivými parametry mohou přestat platit některé invarianty, se kterými GC počítá. Ale Sunovské JVM je open-source, takže vám nic nebrání to tam dopsat
Pokud v těch keších nejsou objekty, ale „pole bajtů“, které se následně rovnou posílají na výstup, dalo by se také zvážit použití přímých bufferů (java.nio.ByteBuffer), kde by měla být jednak nižší režie při samotném posílání po síti, jednak je možná půjde explicitně z programu dealokovat (nevím, na kód jsem se nedíval) .
System.gc() chová normálně (tj. uvolní paměť) a nebere ohledy na špatně napsané aplikace, které volají System.gc() zbytečně“. Pokud by to nestačilo, pak přidat možnost přes JMX řídit další parametry JVM a vyvolávat další činnosti, jako je třeba právě okamžité uvolnění nevyužívané haldy. Mechanismy na řízení některých parametrů JVM a vyvolávání některých činností už JVM má, takže by se pouze přidaly další do existující množiny.
Připadá mi to normální, od toho je Sunovské JVM opensource, aby do něj mohli přispívat všichni. Narazil jste na nějaký problém, se kterým se setká málokdo, jde to upravit tak, aby vám to pomohlo a nikoho jiného to neovlivnilo, tak je přece logické tu úpravu udělat a poskytnout ji všem.
No a? Myslíte, že je to problém?Ano, alokace paměti od systému není zadarmo.
Zkusil jste si to představit? Jak by asi OS zjistil, že je stránka vynulovaná? Myslíte, že by OS vždy čas od času přečetl celou paměť, aby zjistil, jestli náhodou něco nebylo vynulováno?Jádro má speciální stránku plnou nul, také v jádru existuje mechanizmus na slučování stránek se stejným obsahem (KSM). Klidně si to považujte za bláznovství, ale je fakt, že v jádru se takovéhle věci řeší, a budou se řešit dál – protože třeba virtualizace představuje úplně stejný typ zátěže (tj. velké množství paměti alokované často „zbytečně“).
V příloze je program v C.Který ovšem využívá knihovní alokátor paměti, o kterém nevíte, jak se chová. Když už to chcete srovnávat s Céčkem, tak napište, jak se chová typický alokátor paměti v C )třeba ten z
glibc) – kdy vrací paměť systému.
Kromě toho nikdo nechce po JVM, aby do paměťové mapy dělala díry, naprosto by stačilo, aby po GC odstřelila celý konec haldy.Což je typická předčasná optimalizace. Zatím všichni tvrdí, že mají pocit, že je to špatné, ale nikdo neviděl ty špatné projevy v praxi a nikdo není schopen říci, proč by to doopravdy mělo být špatné. Vy tvrdíte, že je nesmyslné držet alokovanou paměť, kterou nepotřebuju, já tvrdím, že je nesmyslné dealokovat paměť, abych ji vzápětí znova alokoval. Oba ale skončíme u toho, že máme takový pocit. Mě by zajímalo, jak je to doopravdy, taky se mi nezdá jako nejlepší držet alokovanou paměť, když jí nepotřebuju. Ale připadá mi podezřelé, že to tak všem jenom připadá a nikdo zatím nepřišel s žádným důkazem…
Podle vás má webový server, bitmapový grafický editor, program pro statistické výpočty i tetris běžet ideálně se stejným nastavením JVM, pravděpodobně i se stejným nastavením OS a na stejném hardwaru; konfigurační volby (JVM nebo třeba linuxového jádra) mají být zbytečné, s různými typy zátěže si má poradit heuristika JVM nebo jádra.No já běžně všechny tyto programy provozuju na jednom železe a dokonce - světe drž se - i na jednom OS. A dokonce vedle těchto programů provozuju i pár dalších, zase jiných! (Ano vím, zdá se ti to nejspíš naprosto neuvěřitelné, ale nelžu, skutečně to funguje.
16.2.2010 15:42
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Z jiného úhlu pohledu je zase vracení paměti zbytečné. Pokud už jednou bylo potřeba tolik paměti, dá se předpokládat, že jí bude potřeba tolik i pozdějiTo není pravda, vezmeme-li v úvahu, že se na ten 1 GB program dostal třeba jen kvůli tomu, že nebyl volán GC. Že po zavolání GC spadne reálné využití paměti na třetinu je docela obvyklé.
Jinak mi připadá debata o nevracení paměti Javou jako čistě akademická, neví o případu, kdy by s tím byl nějaký problém – tedy kromě toho, že to velké číslo alokované paměti vypadá ve výpisu procesů blbě.Problém je v tom, že taková paměť je swapovaná na disk a pak zase vyswapovaná, jakmile neaktivitou GC využití paměti zase vyleze. Ve výsledku si JVM zabere co nejvíc prostředků chamtivě pro sebe.
To není pravda, vezmeme-li v úvahu, že se na ten 1 GB program dostal třeba jen kvůli tomu, že nebyl volán GC. Že po zavolání GC spadne reálné využití paměti na třetinu je docela obvyklé.Jenže ten program poběží dál, zase nebude volán GC a paměť postupně poroste až na ten 1 GB. A JVM bude zase postupně alokovat paměť, kterou před chvílí uvolnila.
Problém je v tom, že taková paměť je swapovaná na disk a pak zase vyswapovaná, jakmile neaktivitou GC využití paměti zase vyleze. Ve výsledku si JVM zabere co nejvíc prostředků chamtivě pro sebe.Což platí v případě, kdy má OS důvod stránku odswapovat a pak zase nahrát do paměti z disku. U prázdné stránky ale takový důvod nemá, ne?
18.2.2010 00:18
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Jenže ten program poběží dál, zase nebude volán GC a paměť postupně poroste až na ten 1 GB. A JVM bude zase postupně alokovat paměť, kterou před chvílí uvolnila.Pravda. Takže v JVM jsou rozbité hned dvě věci. Způsob používání a fungování GC a výchozí parametry uvolňování paměti. Čím to, že snad všude jinde GC funguje ohleduplněji než v Javě?
Což platí v případě, kdy má OS důvod stránku odswapovat a pak zase nahrát do paměti z disku. U prázdné stránky ale takový důvod nemá, ne?Jak prázdná? Je tam prostě nepoužívaný bordel JVM.
Pravda. Takže v JVM jsou rozbité hned dvě věci. Způsob používání a fungování GC a výchozí parametry uvolňování paměti. Čím to, že snad všude jinde GC funguje ohleduplněji než v Javě?Jaké dvě rozbité věci? Dozvím se konečně, co je špatně na předpokladu, že program obecně používá stále stejné množství paměti? Tj. že když už jednou potřeboval 1 GB, bude tolik paměti za chvíli potřebovat zase?
Jak prázdná? Je tam prostě nepoužívaný bordel JVM.Porovnejme si dvě situace. V první program najde volné místo někde uprostřed alokované paměti, tak do něj začne kopírovat data z konce alokované paměti. Tím konec uvolní, zjistí, že vyprázdnil celou stránku, tak ji vrátí OS. OS dostane vrácenou jednu stránku paměti, kterou může použít jinde, vynuluje ji a předá dalšímu programu, který si alokuje novou stránku. V druhém případě program najde volné místo někde uprostřed alokované paměti, vybere ten největší kus volného místa a data z okolní stránky překopíruje na zbylá volné místa. Uvolní se mu tak jedna stránka a řekne OS „tuhle stránku vynuluj“. OS si poznamená, že v té virtuální stránce jsou samé nuly a předá fyzickou stránku, která byla pod tou virtuální, jinému programu, který si požádal o alokaci (nebo ji přidá do seznamu volných stránek). Mně připadá, že druhý případ je efektivnější, protože se při něm méně kopíruje. Nebo se pletu?
14.2.2010 19:20
tomboytom-deviant | skóre: 7
| blog: lojdovo
| .com
14.2.2010 21:50
Algi | skóre: 1
| blog: Sinner
12.2.2010 17:34
Saljack | skóre: 28
| blog: Saljack
| Praha
JDownloader je hroznej moloch oproti FreeRapid Downloader, ten prostě dělá věci jednoduše a ne složitě. Takže zůstávám u FreeRapid Downloader a tím i podpořím český projekt
12.2.2010 11:38
kotyz | skóre: 25
| blog: kotyzblog
| Plzeň
Co se týče těch stahovacích pluginů pro různé úložné servery, tak ty jsou v JDownloaderu ve formě skriptů, které jsou neustále průběžně aktualizovány (JDownloader si je stahuje sám z netu) a některé podporují i lámání CAPTCHY. Když koukám na seznam, tak jich je přes 350! Tomu opravdu FatRat nemůže konkurovat...
12.2.2010 12:28
kotyz | skóre: 25
| blog: kotyzblog
| Plzeň
Leda nějak převést ten Java kód do C++ nebo ho zkompilovat do nativního kódu pomocí GCJ a pak k němu z FatRatu nějak nějak přistupovat (pokud je vubec něco takového možné, netuším, já jsem jen Pythonýr ).
Každopádně zdrojáky těch pluginů jsou tady: http://svn.jdownloader.org/repositories/browse/jd/trunk/src/jd/plugins/hoster
12.2.2010 13:45
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
12.2.2010 10:38
svido | skóre: 28
Ale na druhou stranku, formulace "vetsi objem dat" je dost diskutabilni...
12.2.2010 10:44
pushkin | skóre: 43
| blog: FluxBlog
12.2.2010 13:07
Jakub Lucký | skóre: 40
| Praha
12.2.2010 10:58
Dalibor Smolík | skóre: 54
| blog: Postrehy_ze_zivota
| 50°5'31.93"N,14°19'35.51"E
12.2.2010 11:46
Dent | skóre: 21
| blog: Standovo
12.2.2010 12:03
Sešívaný | skóre: 23
| Brno
12.2.2010 15:33
belisarivs | skóre: 22
| blog: Psychobláboly
12.2.2010 16:24
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
12.2.2010 16:55
Dalibor Smolík | skóre: 54
| blog: Postrehy_ze_zivota
| 50°5'31.93"N,14°19'35.51"E
12.2.2010 12:15
Jiří Svoboda | skóre: 37
| blog: cat /dev/mind
| Prostějov
12.2.2010 15:11
otasomil | skóre: 39
| blog: puppylinux
wget ci axel
Pokud se jakymkoli zpusobem prerusi spojeni tak je lze obnovit a pokracovat tam kde se skoncilo a to bez ztraty jedineho bajtu.
Neni webovy prohlizec jez by toto 100% zvladal - casto se potom rozchazi MD5SUM.
U filmu na ztrate nejkych par bajtu prakticky nezalezi. U instalacky jakehokoli OS ci programu vsak ano.
Vetsi objem dat je pro mne treba 4,5 GB iso DVD disku nejakyho distra.
CD (700 MB) jiz povazuji za maly objem.
12.2.2010 15:16
Fluttershy, yay! | skóre: 93
| blog:
12.2.2010 16:35
pepe_ | skóre: 48
12.2.2010 16:36
pepe_ | skóre: 48
.
, takže asi ne.
Přehlédl jsem checkboxy, moje chyba.
A ano, "nedocvaklo" mi, že bych se mohl ještě jednou podívat zda je to tak správně. Což zde je. To už tak bývá, když se něco o kousek liší od zažitých "taky-standardů".
Nicméně pro chyby ostatních mám pochopení a hned je neobviňuji z nedostatku inteligence, netvrdím, že jsou kdoví co. Možná je to tak zvykem u vás pro každou chybu člověka napadat a očerňovat, ale já na takové chování moc zvyklý nejsem.
Ano, obvykle se používá procentuelní vyjádření tak, že součet bývá 100%.Nikoli, to se nepoužívá obvykle. To se používá vždy v případech, kdy se jednotlivé možnosti navzájem vylučují a kdy je výčet možností úplný (protože pak je součet roven 100 % z definice procent). V případech, kdy se jednotlivé možnosti navzájem nevylučují, nemá součet podílů možností žádný smysl.
Nicméně pro chyby ostatních mám pochopení a hned je neobviňuji z nedostatku inteligence, netvrdím, že jsou kdoví co. Možná je to tak zvykem u vás pro každou chybu člověka napadat a očerňovat, ale já na takové chování moc zvyklý nejsem.Proč jste tedy zrovna komentářem zahajujícího toto vláknu udělal výjimku? Kdybyste normálně napsal, že podle vás by součet měl být sto procent a zeptal se, proč není, někdo by vás jednoduše odkázal na FAQ. Ale když vy jste právě obvinění nevynechal, neprojevil pochopení pro chyby ostatních, naopak jste apriori předpokládal chybu u druhých a ne u sebe.
Takže jediné, co z ankety můžeme zjistit, je kolik procent uživatelů používá který program.Ano, s tímto naprosto souhlasím, z dané ankety vidíme jen toto. A opravdu nevidíme vzájemný procentuelní poměr mezi jednotlivými možnostmi, který by také šel z takovéto ankety získat, ale nechci se hádat o relevantnosti takového výsledku.
"...celkový počet hlasů nikdy nikoho nezajímá..."nicméně je uveden. Právě teď pod anketou vidím text: "Celkem 904 hlasů". Což je navíc poněkud matoucí. Zároveň je to také poněkud v rozporu s výpočtem
"...podíl těch, kteří hlasovali pro určitou možnost, ku celkovému počtu hlasujících..."Problém totiž nastává, když není jasné, co je jeden hlas. Pokud jde o zastoupení jednotlivých programů na trhu, tak tam také můžeme uvažovat o situaci, že zákazníci nepoužívají jenom jeden z nich a také tvořit tabulky s procenty, které v součtu nebudou 100%, nicméně se takové statistiky moc nepoužívají, aspoň tedy ne v kruzích, kde se pohybuji. Pokud bylo uvedeno více lidí v omyl, tak věřte nebo ne, ale chyba v komunikaci bude zřejmě na obou stranách, nikoliv jen na jedné, jak zřejmě předpokládáte (viz. Vaše předchozí příspěvky). Já svůj omyl přiznávám. A přidávám se k tomu, co máte ve svém profilu. Nikdo z nás nemůže mít Pravdu. Pravda je opravdu o hodně větší než jsme my. My máme své úhly pohledu a z nich to může vypadat jinak, než to vidí druhý. Zároveň se omlouvám, nebudu zde více odpovídat, nemám prostě čas. Mí zákazníci chtějí vidět své web-apps hotové
.
Přeji pěkný den.
A opravdu nevidíme vzájemný procentuelní poměr mezi jednotlivými možnostmi, který by také šel z takovéto ankety získat, ale nechci se hádat o relevantnosti takového výsledku.Z této ankety získat nejde, protože nedokážete zjistit poměr používání u jednotlivých hlasujících.
Právě teď pod anketou vidím text: "Celkem 904 hlasů".To je špatně, mělo by tam být „hlasujících“.
Pokud jde o zastoupení jednotlivých programů na trhu, tak tam také můžeme uvažovat o situaci, že zákazníci nepoužívají jenom jeden z nich a také tvořit tabulky s procenty, které v součtu nebudou 100%, nicméně se takové statistiky moc nepoužívají, aspoň tedy ne v kruzích, kde se pohybuji.Ale on je rozdíl mezi „podíl uživatelů, kteří používají daný program“ a „podíl na trhu“. V prvním případě tvoří celek počet uživatelů, a protože každý může používat víc programů, součet podílů může být různý od nuly. U podílu na trhu je celkem celý trh a součet jednotlivých podílů na trhu bude jedna (protože každý podíl je na trhu zastoupen právě jednou).
Pokud bylo uvedeno více lidí v omyl, tak věřte nebo ne, ale chyba v komunikaci bude zřejmě na obou stranách, nikoliv jen na jedné, jak zřejmě předpokládáte (viz. Vaše předchozí příspěvky).Ta druhá strana, na které došlo k chybě při komunikaci, je bohužel asi výuka matematiky na základních školách, která nenaučí lidi za procenty vidět podíl a naučit je podíly porovnávat. Máte pravdu v tom, že anketa by se dala vylepšit – „celkem hlasů“ by mělo být nazváno „celkem hlasujících“, pod anketu s checkboxy by se rovnou mohl přidávat odkaz na FAQ. Nejde ani o to, že každému musí být hned na první pohled jasné, proč v té anketě vychází součet podílů větší než jedna. Důvod, proč jsem váš komentář komentoval tak nevybíravě je ten, že se takový komentář objeví skoro pod každou anketou s checkboxy – a skoro nikdy to není uctivé upozornění, že komentující buď něco na anketě nepochopil, a nebo je tam chyba při výpočtu. Naopak snad pokaždé je to něco na způsob „máte tam chybu“. To opravdu automaticky bez přemýšlení napadne mnoho lidí, ale když už o tom chci psát komentář, bylo by dobré se nad tím zamyslet, a chybu předpokládat spíš u sebe než u druhých. Když takhle bude každý postupovat, bude se snažit do komentáře popsat, proč tam ta chyba je – a v tom okamžiku to už musí dojít každému, i tomu, komu nepomohlo první zamyšlení. Takže ten můj komentář se netýkal toho, že byste ten princip ankety nepochopil, ale hlavně toho, že jste ten komentář s pravděpodobností hraničící s jistotou napsal dřív, než jste se pokusil vyloučit chybu na své straně. Ale máte pravdu v tom, že jsem pak zareagoval úplně stejně, resp. z mého komentáře nebylo patrné, zda jsem uvažoval i o tom, že se v hodnocení vašeho komentáře nemýlím já.
Ta druhá strana, na které došlo k chybě při komunikaci, je bohužel asi výuka matematiky na základních školách, která nenaučí lidi za procenty vidět podíl a naučit je podíly porovnávat.Nějak jsem to moc zkrátil. Tím jsem nemyslel, že vám chybí základní vzdělání, ale to, že lidé si zvykli na to, že když je vedle sebe několik údajů v procentech, má to dohromady dávat sto procent – a nepřemýšlí o tom, proč.
Nicméně pro chyby ostatních mám pochopení a hned je neobviňuji z nedostatku inteligence, netvrdím, že jsou kdoví co. Možná je to tak zvykem u vás pro každou chybu člověka napadat a očerňovat, ale já na takové chování moc zvyklý nejsem.Toho si radši ani nevšímej, vzhledem k tomu, že autorem je soudruh Jirsák
13.2.2010 14:07
Jendа | skóre: 78
| blog: Jenda
| JO70FB
14.2.2010 01:01
otula | skóre: 45
| blog: otakar
| Adamov
Mno, někdo občas o něčem nemusí vědět, tak honem, běžte si do něj kopnoutI přes toho mrkajícího smajlíka mám pocit, že ti chybí smysl pro humor. Ale hlavně mne udivuje, že se, coby náhodný kolemjdoucí, tolik čílíš kvůli procentům v anketě. Pokud ten problém nedokážeš překousnout, vyděl si hodnotu uvedených procent setinou součtu všech procent, dostaneš výsledky odpovídající své představě a nebudeš se kvůli tomu muset zbytečně hádat - zbytečně si takhle necháš rozhodit čakru
13.2.2010 13:32
Jendа | skóre: 78
| blog: Jenda
| JO70FB
. Což se stává.
16.2.2010 19:39
pavlix | skóre: 54
| blog: pavlix
16.2.2010 19:42
Algi | skóre: 1
| blog: Sinner
16.2.2010 19:56
Jakub Lucký | skóre: 40
| Praha
13.2.2010 17:29
Nicky726 | skóre: 56
| blog: Nicky726
13.2.2010 20:20
Jakub Lucký | skóre: 40
| Praha
13.2.2010 21:33
xkucf03 | skóre: 49
| blog: xkucf03
13.2.2010 21:38
Jakub Lucký | skóre: 40
| Praha
13.2.2010 22:12
Jakub Lucký | skóre: 40
| Praha
13.2.2010 21:12
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
13.2.2010 23:16
Fluttershy, yay! | skóre: 93
| blog:
Je zvláštní, že tady tolik lidí používá na stažení souboru wget - má to snad oproti prohlížeči nějakou výhodu?Člověk nemusí přepínat do prohlížeče
14.2.2010 01:31
otula | skóre: 45
| blog: otakar
| Adamov
Je zvláštní, že tady tolik lidí používá na stažení souboru wget - má to snad oproti prohlížeči nějakou výhodu?
je rychlejší dostat se do jiného než ~ adresářeOd toho jsou v souborovém dialogu záložky – třeba když si ukládám Dilberta nebo komix z Rootu tak prostě jednou kliknu na záložku a jsem ve správné složce – nemusím psát příkazy do konsole.
14.2.2010 12:07
otula | skóre: 45
| blog: otakar
| Adamov
Už tolikrát se mi stalo, že jsem si wgetem místo požadovaného souboru stáhl nějakou pitomou HTML stránku.Smrt javascriptu!
třeba když si ukládám DilbertaNa Dilberta zde někdo před časem napsal pěkný skriptík do cronu
IMGDIR=/home/ota/dilbert DNES=`date "+%Y-%m-%d"` mkdir -p $IMGDIR &>/dev/null cd $IMGDIR wget --quiet --output-document=dilbert-$DNES.gif \ `curl -s http://ekonomika.idnes.cz/dilbert.asp | egrep -i \ "i\.idnes\.cz.*\/maxi\/.*dilb.*" | grep -o "src=\"[^\"]*\"" | sed "s/src=\"//;s/\"//"` chown ota:users $IMGDIR/dilbert-$DNES.gif
)
Wgetem. Kde to nejde skriptem. Z rapidshare pomoci udelatka.
17.2.2010 18:49
Jendа | skóre: 78
| blog: Jenda
| JO70FB
18.2.2010 15:06
pushkin | skóre: 43
| blog: FluxBlog
18.2.2010 10:49
Jardík | skóre: 40
| blog: jarda_bloguje
