Google Chrome 156 byl prohlášen za stabilní. Přehled novinek v poznámkách k vydání. Opraveno bylo 353 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Indická společnost eMudhra po bezpečnostním incidentu, tj. kompromitaci soukromých klíčů osmi mezilehlých certifikátů své certifikační autority, opouští globální byznys s SSL/TLS certifikáty.
Dle Phoronixu zveřejnila společnost Trend Micro prostřednictvím programu Zero Day Initiative (ZDI) několik hlášení bezpečnostních zranitelností přímo na veřejném mailing listu LKML, přestože některé chyby dosud nemají opravu začleněnou do hlavní větve jádra. Mezi hlášenými problémy jsou dvě zranitelnosti s hodnocením CVSS 9.0, týkající se SMB Direct a KSMBD, které mohou umožnit vzdálené spuštění kódu. Další hlášení se týkají … více »
Správce hesel KeePassXC byl vydán ve verzi 2.8.0. Přechází na Qt 6, podporuje vkládání hesel s Waylandem, rychlé odemykání pomocí Polkitu nebo možnost nastavení klávesových zkratek (seznam změn).
Databáze DuckDB (Wikipedie) byla vydána ve verzi 2.0.0 LTS. S kódovým názvem Cinnamon Teal (čírka skořicová). S vyladěným protokolem Quack.
V implementaci Broadcom 802.11 byla zjištěna chyba ve zpracování WPS/EAP, týká se to SDK od roku 2010. Broadcom podle výzkumníka Quentina Kaisera odmítl CVE přidělit. Modemy Huawei a Technicolor jsou používány i v ČR, v LTE routerech, běžných domácích routerech a firemních přístupových bodech, jejich současný počet a zranitelnost konkrétních verzí však zatím neznáme. Více detailů a demo. GitHub / Broadcom 802.11 SDK Detection Toolkit.
Byla vydána nová verze 10.8 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Přehled novinek v poznámkách k vydání. Přibyl balíček DietPi WireGuard.
Oslavte vydání openSUSE Leap 16.1 s námi v Praze! Ve středu 4. listopadu 2026 (den po vydání Leapu 16.1) vás zveme na malou oslavu vydání openSUSE Leap 16.1 do pražské kanceláře SUSE. Připravili jsme pro vás dvě krátké přednášky: … více »
Dle plánu bylo PHP vydáno v nových verzích 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Opraveny jsou kritické zranitelnosti CVE-2026-109618 a CVE-2026-109619 aneb PHP2Shell.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-2.1 a 24.04-1.5. S opravou kritických zranitelností.
V Distribučních novinkách se už párkrát objevila zmínka o prostředí LXDE. DesktopLinux.com jej v krátkosti představuje jako odlehčenou alternativu ke GNOME, která je ve vývoji od roku 2006. Údajné vysoké nároky jiných prostředí byly důvodem k založení projektu. Součástmi jsou souborový správce PCManFM, hlavní panel LXPanel (s možností konfigurace), správce relace LXSession, LXAppearance pro nastavení vzhledu GTK+, emulátor terminálu LXTerminal a několik externích programů. Prostředí ve velmi modulární - jeho součásti jsou vydávány odděleně.
Tiskni
Sdílej:
Kolik? Kolik ještě?
"If Windows 98 and xp work quite well on old machines, why my Linux desktop needs a 1.0 GHz CPU + 1GB RAM?"Na to se dá reagovat snad jen tímto způsobem: "Když svoje GNOME v pohodě používám na 256 MB RAM, proč vzniká další 'odlehčené' prostředí?"
Můj otec rozběhl XPčka na notesu s 133Mhz Pentiem-classic, 64MB RAM(snad jich bylo i o kapánek míň) a nějakou hodně starou VGA grafikou, kterou mi pro jistotu i Xka načetla s ovladačem VESA.
After X11 and LXDE are started, the total memory usage is about 45 MB on i386 machines. (This value may be higher or lower according to different system configurations.) Though LXDE itself doesn't require better hardware, other applications under X do need it. For example, Firefox and OpenOffice.org 2 are quite memory-hungry. So it's recommended that you have RAM more than 128 MB.tedy selsky řečeno toto: LXDE spolu s X11 sežere kolem 45 MB RAM, záleží na konfiguraci systému. Ačkoli to samotnému LXDE stačí, nebude to stačit mnohým dalším aplikacím. Například FF2 nebo OOo jsou pěkní otesánci. Proto doporučujeme použít více, než 128 MB RAM.
Dobře, dejme tomu, že doporučení nad 128 MB RAM se týká provozu FF a OOo, ačkoliv to z té věty úplně jednoznačně nevyplývá, a že srovnání s win98 se týká LXDE bez dalších X11 aplikací.
Ve FAQ:
Why yet another desktop environment? Aren't there already KDE, GNOME, XFCE, and a lot of well-made DEs? Why reinventing the wheel?
Though they are well-made and powerful, they are bloated, and eat up our RAMs. (...)
If Windows 98 and xp work quite well on old machines, why my Linux desktop needs a 1.0 GHz CPU + 1GB RAM? We don't believe building such a usable desktop environment requires that much resource usage, so we try it ourselves.
Naznačují, že GNOME, KDE i XFCE plýtvají RAM a potřebují jí 1 GB. (Tak by mě zajímalo, jestli LXDE na doporučovaných 192 MB bude běhat stejně rychle, jako XFCE na tom naznačeném 1 GB. Vím, že to netvrdí, ale působí to takovým dojmem.)
Dobře, dejme tomu, že doporučení nad 128 MB RAM se týká provozu FF a OOo, ačkoliv to z té věty úplně jednoznačně nevyplývá... ...Naznačují, že GNOME, KDE i XFCE plýtvají RAM a potřebují jí 1 GBZ té věty velmi jasně vyplývá, že doporučení se týká provozu dalších aplikací, v čele s FF2 a OOo. Naproti tomu nenaznačují, že Gnome, KDE či XFCE spotřebují celý GB paměti, ale naznačují, že je tolik paměti potřeba pro jejich provoz (včetně aplikací) - což uznávám, že je (za předpokladu 32bitového systému) docela přepísknuté a silně to zavádní reklamou (ovšem s 64bitovým systémem jsem pocítil 512MB RAM jako velmi omezující během několika minut práce).
tedy selsky řečeno toto: LXDE spolu s X11 sežere kolem 45 MB RAM, záleží na konfiguraci systému. Ačkoli to samotnému LXDE stačí, nebude to stačit mnohým dalším aplikacím. Například FF2 nebo OOo jsou pěkní otesánci. Proto doporučujeme použít více, než 128 MB RAM.45 MB RAM mi sežere celý systém s KDE 3.5. Čili závěrem asi tolik: LXDE nenabízí ve výchozím stavu bez aplikací žádnou paměťovou úsporu oproti KDE, zato s aplikacemi bude paměťově velmi výrazně výhodnější KDE (díky sdíleným knihovnám KDE a velké míře integrace, oproti spouštění samostatných, těžkotonážních aplikací v LXDE). Navíc bude LXDE mnohem pomalejší vzhledem k tomu, že je to GTK+ prostředí a už samotný nápad (se kterým nevím proč pořád další a další bloudové přicházejí) stavět cokoli „odhlehčeného“ na GTK+ je asi stejný protimluv jako „chytrý blbec“ či „svižné GNOME“. Zkrátka, potvrdilo se to, co jsem předpokládal už hned když jsem se o tom projektu dozvěděl poprvé: zgruntu pomýlený projekt, naprosto zbytečný, totálně na *****.
45 MB RAM mi sežere celý systém s KDE 3.5Tak to tedy čumím. Na screenshotu je po čerstvém startu systému a přihlášení spuštěn navíc jen KSysGuard a KSnapshot, které si samozřejmě můžeš odečíst.
)
), ale jakmile se v tom budou spouštět aplikace, pak už je to celkem k ničemu, protože v KDE spotřeba paměti se spouštěnými KDE aplikacemi tolik nevzrůstá (díky bohaté funkčnosti sdílených knihoven KDE), zato v čistém prostředí, které nic neumí, se pak musí pouštět programy, které si musí tu funkcionalitu dotáhnout s sebou (a dost pravděpodobně každá sama za sebe, nesdíleně), takže co z toho...
A jak už bylo řečeno, nejde jen o paměť. Vsadím se, že KDE 3.x bude na pomalém počítači rychlejší už právě kvůli tomu, že nepoužívá GTK+. Qt 3.x je daleko rychlejší. Takže účel toho prostředí mi opravdu uniká. Obzvlášť když je tu Xfce, které už plní takovou tu roli velmi mírně, zanedbatelně lehčího prostředí pro příznivce pomalosti GTK+, kteří nechtějí GNOME.
Pokud chce někdo duševně zdravý udělat opravdu odlehčený a rychlý desktop, ať to proboha založí na nečem pro ten účel rozumném jako je lehké a rychlé FLTK nebo snad i FOX toolkit. Ale přijde mi, že programátoři prostě pořád volí GTK+ úplně bezmyšlenkovitě, ze zvyku a setrvačnosti, protože to používají všichni, a to i na projekty kam se naprosto nehodí (multimediální a graficky náročnější programy, které pomalost GTK+ naprosto degraduje a znehodnocuje), vůbec si neuvědomují, co tím činí a jaké to má následky.
WDE je můj malý projektík, na který teď nemám moc času, ale určitě bych chtěl aby měl budoucnost. Dřív jsem chtěl udělat WM a tento toolkit jsem psal pro něj, ale doba se změnila a teď bych z toho chtěl udělat spíš takovou lehkou alternativu k masivním toolkitům typu Qt.
Nový koncept je takový, že se bude skládat ze 3 vrstev
- Core - to bude něco jako glib, tady bych chtěl implementovat ten systém signálů a slotů, v Qt se to povedlo tak proč vymýšlet něco jiného
- Fog - Grafická vrstva, toto mě baví nejvíc a momentálně na mailing listu agg probíhá diskuze o agg a vypadá to na fork, to znamená, že pokud se mi povede spolupráce, mohla alespoň tato knihovna mít velký smysl. Představa je taková, že by se pro pipeline použila knihovna agg a pro vyplňování spanů by se použili moje funkce, které jsem napsal už dřív v MMX a SSE2. Úplně nový koncept mě napadl nedávno a to použít vlákna na vícejádrových procesorech. Chtěl bych toto téma i na diplomku tak mi držte palce aby mi to vedoucí povolil
- UI - Netřeba vysvětlovat co to znamená:)
Pokud se najde víc lidí, kterým by se líbila myšlenka WDE jsem schopen na tom znovu začít pracovat, pokud ne, otevřu to až budu mít čas. Jsou ale věci, kterých se v průběhu vývoje držím a nemusí být každému sympatické (je to nepoužívat stl, výjimky a rtti v knihovně samotné)
Při psaní WDE jsem právě udělal jednu chybu, přeoptimalizace. Všechno bylo psané pro vysokou rychlosti a teď se v tom asi nikdo kromě mě nevyzná. Avšak i přes toto všechno vznikly některé zajímavé věci, třeba:
Core::String fn()
{
// alokuje s na zásobníku
Core::StringT<1024> str;
// kotel operací ...
// chytré, vrátí str jako dynamicky alokovaný řetězec
return str;
}
Možná je i chyba, že jsem WDE nikde neprezentoval a neptal se lidí co by v nějakém jednoduchém toolkitu potřebovali. Já jsem si teď uletěl v javascriptovém toolkitu qooxdoo a až budu psat UI vrstvu tak to bude výborná inspirace, je to super.
V případě zájmů i otázek mě kontaktuje na mail, mám radost když se o WDE někdo zajímá:)
ať to proboha založí na nečem pro ten účel rozumném jako je lehké a rychlé FLTK nebo snad i FOX toolkit. Ale přijde mi, že programátoři prostě pořád volí GTK+ úplně bezmyšlenkovitěBezmyšlenkovitě to určitě není. Na tvou otázku odpovídají:
Using gtk+ 2 is a hard choice. The i18n support of other toolkits are not very good. Apart from lightweight & fast, useability is important at the same time. For English users, there is no problem, but can FLTK and FOX handle bi-directional text rendering? I know they already supported utf-8, but utf-8 is only the minimal requirement to be internationalized.V tomto mají pravdu, že pokud má být prostředí použitelné celosvětově, není volba snadná: Použití gtk+ 2 je nesnadná volba, ale podpora i18n není u ostatních toolkitů dobrá. Kromě lehkosti a rychlosti je důležitá i použitelnost. Pro anglicky mluvící není problém, ale co obousměrné vykreslování textu? Jasně, již podporují UTF-8, ale to je jen malá část internacionalizace.
Pomalu už si připadám jako nějaký obhájce tohoto prostředí, které ale vůbec neznám. Jen zastávám to, že by člověk neměl na základě svých pocitů hned něco odsuzovat.