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).
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
