Uživatelé mobilních telefonů s Linuxem si nyní mohou nainstalovat aplikaci Mobilní Datovka. Díky tomu je přístup k datovým schránkám dostupný i na zařízeních s mobilními linuxovými distribucemi, jako jsou například Mobian, NixOS Mobile, pmOS atd. Aplikace je dostupná na Flathubu.
Software Freedom Conservancy v novém dokumentu shrnuje doporučení, jak přistupovat ke generativní AI založené na LLM při přispívání do svobodného a open-source softwaru. Mimo jiné vyzývá k obezřetnosti, transparentnosti a revizi generovaného kódu člověkem.
Byla vydána nová verze 5.6.0 programu na úpravu digitálních fotografií darktable (Wikipedie).
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma. V Týdnu v GNOME je zmíněn flatpak balíček pro GIMP 0.54.1 z roku 1996. Jedná se o poslední verzi GIMPu postavenou nad toolkitem Motif.
Home Assistant Operating System, tj. linuxová distribuce optimalizována pro hostování Home Assistanta a jeho aplikací, byl vydán v nové major verzi 18.0.
Po šestiletém úsilí byla z jádra Linux odstraněna funkce strncpy(). Všechna předchozí volání této funkce byla převedena na bezpečnější alternativy.
Byla vydána nová verze 261 správce systému a služeb systemd (Wikipedie, GitHub). Z novinek lze vypíchnout nový subsystém IMDS (Cloud "Instance Metadata Service"), nový příkaz storagectl nebo novou komponentu systemd-sysinstall.
Vývojové prostředí Qt Creator bylo vydáno ve verzi 20 (seznam změn). Novinky zahrnují hlavně rozšíření pro integraci LLM agentů nebo minimalistický editační režim uživatelského rozhraní („zen mode“).
Už jste se prolétli na webu Google Earth? Přibyl tam Simulátor letu (Nástroje / Simulátor letu). Funguje i bez účtu Google [𝕏].
Byla vydána nová verze 4.7 (𝕏, Bluesky, Mastodon) multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu.
Firefox není zase až takový paměťový žrout, jak se o něm proslýchá. Nebo alespoň u mne to není pravda. Od jisté doby se Firefoxu podařilo obsadit až 1GB paměti, jen tak, cca po hodině používání. Samozřejmostí byly nějaký ty stránky naplněné až po okraj Flashem, těžko se dnes Flashi ubránit.
Jak šel čas, tak jsem se prostě naučil občas Firefox, tak nějak lidově řečeno, sestřelit. Až do jedné chvíle to fungovalo. Když jednou, zkolaboval celý systém, a už nenaběhl, resp. nenaběhl celý notebook. Nějakou dobu jsem řešil kde je problém, až jsme ho odhalil v přídavném paměťovém modulu, který jsem zakoupil cca před čtvrt rokem. Modul jsem vyndal z notebooku a na původních 512MB zase Firefox pěkně běhal někde okolo 200MB. Teď když mám nový 1GB modul, zřejmě už bezchybný, tak je vše v pořádku, Firefox si i teď běhá pří vytíženích, které jsem požadoval i dříve, někde okolo 200 – 300MB. Prostě ať si kdo chce, co chce, říká, Firefox není tak špatný, zejména co se paměťové náročnosti týče. Je pravda Konqueror a Lynx jsou lepší 
Tiskni
Sdílej:
Ze Firefox zere pamet, tak to nejsou chyby, s kterymi by se "bohuzel" nedalo zit. Neprijemne, ale chodi to.
Horsi veci, co jsem nasel behem par let, ale mozna uz opraveno:
1) u elementu <textarea /> v takovemto tvaru s Vam zobrazi zbytek html kodu do konce html stranky v texaree. takze nejake xslt transformace nasledne generuji neco, co firefox korektne nezobrazi. Staci, kdyz do textarey nedate v transformaci hodnotu. A pak generujte xhtml...
2) OSCP validace certifikatu - je -li certifikacni autorita self signed, tak dojde k zacykleni a stranka se nezobrazi. Delalo to a mozna dela na forpsi.com pres https.
3) SSL certifikat sice podle hlasky naimportujete uspesne, ale neni nikde videt v prehledu certifikatu.
Ale v TOP-TEN chyb u me vede OpenOffice, kdy 9 a 12 -ti hranna hvezdicka v openxml se zobrazi stejne..... A takovych srand je tam vice.
gf
u elementu <textarea /gt; v takovemto tvaru s Vam zobrazi zbytek html kodu do konce html stranky v texaree. takze nejake xslt transformace nasledne generuji neco, co firefox korektne nezobrazi. Staci, kdyz do textarey nedate v transformaci hodnotu. A pak generujte xhtml...
Tak HTML nebo XHTML?
2.4.2009 13:35
microcz | skóre: 18
| blog: Michalův zápisník
| Praha
lol, dobry, treba se ty zbyvajici hrany pohybuji kdesi v imaginarni rovine :D
2.4.2009 14:30
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
u elementu <textarea /> v takovemto tvaru s Vam zobrazi zbytek html kodu do konce html stranky v texaree. takze nejake xslt transformace nasledne generuji neco, co firefox korektne nezobrazi. Staci, kdyz do textarey nedate v transformaci hodnotu. A pak generujte xhtml...To samé je třeba i u <title />, což je něco, co třeba leze z OpenOffice.org. IE a Firefox to zvorají.
2.4.2009 16:36
Nicky726 | skóre: 56
| blog: Nicky726
1) u elementu <textarea /> v takovemto tvaru s Vam zobrazi zbytek html kodu do konce html stranky v texaree. takze nejake xslt transformace nasledne generuji neco, co firefox korektne nezobrazi. Staci, kdyz do textarey nedate v transformaci hodnotu. A pak generujte xhtml...Ještě někdy na přelomu roku jsem na to narazil, když jsem ladil webík na školní projekt. Od té doby ale FF používám minimálně, tak nevím, zda to je opravené. Jinak poté, co jsem zjistil, že FF se zhruba třemi oušky kolem bere 175 MB RAM a Konqueror či Arora s těmi samými do 70 MB, jsem začal dávat přednost jim. Alespoň v KDE, tam má Konqueror navíc přínos v lepší integraci s ostatními aplikacemi.
Ja si myslým, že to s tou pamäťou nie je až také zlé. 4 doplnky, 9 zásuvnývch modulov a 34 otvorených tabov <300MB.
Možno že po čerstvom štarte žerie oproti Konqeroru nepomerne viac, ale s pribúdajúcimi tabmi rastie využitie pamäte dosť pomaly.
Myslím, že je důležitější, jak se s prohlížečem pracuje a co a jak v něm jde dělat, než to porovnat podle jednoho parametru při startu.
tahle stránka u mne MF zcela přetíží, Opera bez větších problémů:
http://www.mbank.cz/blog/article.html?id=114
2.4.2009 22:13
David Watzke | skóre: 74
| blog: Blog...
| Praha
2.4.2009 22:32
David Watzke | skóre: 74
| blog: Blog...
| Praha
Můžete zjistit, jak dlouho trvá načtení diskuze u vás v Opeře? Mně to na 15 sekund zamrzne, a pak se to ještě nějakou dobu cuká. Celkem 25 sekund.
Podle toho bych mohl odhadnout, jak dlouho mi to bude trvat ve Firefoxu.
Nicméně diskuze v javascriptu – to je hrůza.
2.4.2009 23:56
kozzi | skóre: 55
| blog: vse_o_vsem
| Pacman (Bratrušov)
3.4.2009 13:58
David Watzke | skóre: 74
| blog: Blog...
| Praha
Nicméně diskuze v javascriptu – to je hrůza.To jo, zhovadilost.
FF 3.0.8 na Ubuntu 9.04 v pohodě, +10MB, jinak FF jede 3 hodiny, otevřeny různé stránky do max 10 tabů, zatím to sežralo 94MB (220MB virtualní)
3.4.2009 16:42
vlastikroot | skóre: 24
| blog: vlastikovo
| Milevsko
Firefox 3.0.8, Gentoo 64 bit, načtení a zásek na cca 2 sekundy. Hotovo, žádný další problém nepozorován.
3.4.2009 10:02
unknown_ | skóre: 30
| blog: blog
3.4.2009 10:58
Toman | skóre: 29
| blog: Tomanův blog
| Kostelec nad Orlicí
No podla mna vacsina z toho je cache a to proste nieco zere (hlavne obrazky). Bez nej by to bolo dost pomale, ja mam teraz uz tyzden (pc suspendujem) okolo 100M, ale to je pod win. Posledne som resetoval ked zral okolo 600M. Tiez sa to zacne boptnat ked tam clovek otvara flashe, javy a pdfka.
Na Ubuntu 9.04... Třeba na tv.nova.cz/... nějaký ten seriál ve Flashi... Všiml jsem si, že Firefox žere třeba cca 25% CPU a Xorg 70% (někdy oba míň a k tomu gnome-system-monitor 50%)... A pak se doberte k reálným výsledkům... Asi není všechno vina Firefoxu, něco shnilého je i v Xorg (nejen v Ubuntu, i na Open SUSE, i v KDE distrech - NO FLAME).
Ale... Na stejné sestavě se Seamonkey seká o poznání méně, na OpenSUSE se Firefox seká neznatelně, v KDE(4.2) se seká úplně všechno..
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
