Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapy a AI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.
Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).
Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.
2.6.18-0.2-default
), že celý proces zatuhne a nezbyde než natvrdo comp (Thinkpad T60) vypnout a znova nastartovat - přičemž někdy klapne hned druhý pokus, jindy třeba 5x za sebou smůla...
Stává se to náhodně, ať je comp připojení do sítě anebo sólo (nevysledoval jsem žádnou pravidelnost), ale ve stále stejném místě: poslední funkční výpis bootovacího procesu bývá
udev on /dev type tmpfs (rw)
a v případě, že bootování pokračuje dobře, následuje
loop: loaded (max 8 devices)
V logu bootování nenajdu samozřejmě nic (protože se tam dostanu pouze když vše proběhne v pořádku).
Našel jsem náhodně rozházené podobné zprávy o tuhnutí openSUSE v různých konfiguracích a za různých podmínek, ale ani jedna se neshodovala (a řešení jsem nenašel snad nikde).
Jde o poměrně čerstvou instalaci z openSUSE DVD a plně aktualizovanou z oficiálních repozitářů - mám dojem, že se tento problém začal objevovat až po aktualizaci, ale vzhledem ke krátkosti vlastní instalace to nemusí nic znamenat, protože jsem relativně velmi málo rebootoval.
Ještě přidám, že na /home
je šifrovaný souborový systém a že jsem se nehrabal ani v jádře, ani v konfiguračních souborech.
Uvítám jakýkoliv nápad či návrh řešení, případné další potřebné informace rád dodám. Díky.
PS. A to jsem si openSUSE vybral v bláhové naději, že se podobných překvapení v podobě zásadní nefunkčnosti systému nedočkám... nechutně padající Kontact v důležitých okamžicích se mi sice asi podařilo vyřešit jedním zápisem do kontactrc
a na podobné "maličkosti" jsem připraven, ale je to opravdu trapné, když potřebujete zapnout comp a tolik opěvovaný Linux ne a ne naběhnout. V takovém případě musím prchat k Vistám, které jsem původně chtěl dočista odmazat. Tak nějak si ale najednou netroufám... a ani někomu předvádět výhody Linuxu Možná hloupost ale jsi si jistý že je RAM-ka a disk OK? Sám provozuju openSUSE 10.2 x64 na notebooku HP nx6125 (Turion/ATI) a problémy nemám
Možná hloupost ale jsi si jistý že je RAM-ka a disk OK? Sám provozuju openSUSE 10.2 x64 na notebooku HP nx6125 (Turion/ATI) a problémy nemámNe, to si jistý nejsem. Snad o víkendu najdu čas to otestovat (hlavně vybrat nějaké nástroje). Je mi jasné, že openSUSE na spoustě notebooků (i T60) běží bez problémů a že to pravděpodobně může být i chybou nebo nějakou specifickou konfigurací HW - teď ještě jak to přesně zjistit... Smůla asi je, že reklamovat notebook s tím, že na něm neběží Linux, v tomhle případě asi nepomůžek, protože doporučovaný systém je víte jaký
Prakticky jsem to na notebooku ještě nezkoušel ale asi nejlepší řešení by bylo spustit nějaké live distro které má minimálně memtest86 a s tím tu RAM-ku otestovat. S tím diskem nevím. Hlavně aby případný test nepoškodil data.
Pokud by byla RAM-ka OK, tak je tu možnost, že se něco opravdu pokazilo v software. Pak jen zkusit reinstalaci systému
Má verze kernelu je 2.6.18.8-03-default x86_64
Jejda, opravuji na Mám . Chtěl jsem to uvést pouze pro upřesnění mé konfigurace.
Neviem, ci to pomoze, ale ja mam kernel 2.6.18-0.3-default, takze odporucam skontrolovat updateUpdatoval jsem na .0.3 a evidentně to nepomohlo. Paradoxně nejhorší je, že to vytuhnutí se nestává vždycky... a když to naběhne, tak zase nemám chuť comp vypínat a testovat, jestli to naběhne i podruhé
Ja mam T60, ale x86 - nemam problemNo právě, možností kombinací je docela dost... a kdoví jestli svou roli nehrají i skvrny na slunci
Mounting local file systems... done proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) debugfs on /sys/kernel/debug type debugfs (rw) udev on /dev type tmpfs (rw)a konec, vždycky na tomto místě, ale ne vždycky
loop: loaded (max 8 devices)
které by mělo následovat, ale nenásleduje?
Později se objevili problémy s destrukcí paměti i ve windows. Dělá ti to od začátku nebo to začalo později?Prakticky od začátku, tj. asi 1 týden, protože ale jak píšu, občas se to neděje ... problém je, jakým způsobem to věrohodně otestovat, tj. někomu předvést. Čekat tedy na problémy i ve Windows?
Pokud se jedná o nějaké hardwarové problémy mohlo by to zlobit i ve windows. Akorát nevím jak otestovat doma základní desku. Třeba bude nakonec chyba jen v linuxu nezkoušel si jiné distro s novějším kernelem Ubuntu, Fedoru?Bohužel se s tím notebookem dostanu zatím jen k poněkud pomalému připojení na net, tzn. že instalovat a udržovat např. Arch nebo Gentoo je poměrně nepohodlné. Dále si také Visty pro sebe zarezervovaly přes půlku HD (asi 45G) a nechtějí se už dál zmenšovat, i když mají ještě 73% neobsazeno ... prý to budou potřebovat, což je dost hustý už samo o sobě. Uvidím, co se bude dít dál, tj. jestli se problém bude zhoršovat, postupně zkusím i novější jádra do SUSE a když ani to nepomůže, tak snad nějakou jinou distribuci... i když předtím bych se raději dopátral toho, kde může být chyba... tj. co je to ten "loop", který už nenaběhne, jestli např. s tím nemá přece jen něco společného ta zašifrovaná /home partišna, anebo jestli je chyba v "udev" - což je místo, kde pravidelně proces vytuhne (viz popis výše). OpenSUSE jsem zvolil na tenhle notebook (T60) po zralé uvaze, a tak nevím, jestli mám doufat raději v chybu HW anebo přece jen v nějaký skrytý bug SW
kernel-default-2.6.22_rc4_git3-2@i586
z Factory.
Pokud používáš smart tak přidej channel
[factory] type = yast2 name = factory disabled = yes priority = 5 baseurl = http://download.opensuse.org/distribution/SL-OSS-factory/inst-source/odblokuj jej (
smart channel --enable factory
), proveď update (smart update factory
) a upgraduj (smart upgrade kernel-default
).
smart channel --disable factory
.
Zkus tam narvat jádro kernel-default-2.6.22_rc4_git3-2@i586
z Factory.
Nerad bych to zakřik, ale se zmíněným jádrem už se zatím povedly 4 pokusy ze 4, čili to opravdu vypadá na jádro, díky Zkus pro jistotu s puvodnim jadrem vyvolat vytuh s parametrem jadra vga=normal (pridat do /boot/grub/menu.lst nebo rucne v grubu prikazdem bootu) ... treba se dozvime vic, uvidime. Nekdy to pomuze.Díky, zkusil jsem, ale nevypsalo se nic jiného než při bootování s výpisem do framebufferu.
2.6.22-rc4-git6-2-default
nezaznamenal už několik dní při bootování žádný problém, považuji tímto problém za vyřešený. Díky za všechny tipy a rady.
Omlouvám se "komunitě", že si nebudu zpátky instalovat starší jádro a pokoušet se zjistit, kde ta chyba byla.
Ještě přidám, že na /home
je šifrovaný souborový systém
Přidám jen, že na šifrování to nezáleží, když jsem ho odstranil, problém s distribučním jádrem (2.6.18) trvá. Nové jádro (2.6.22) vyřeší problém s bootováním, ale bohužel zase znemožní funkci wifi.
Zatím jsem nenašel žádný triviální a spolehlivý postup, jak tohle dilema vyřešit (viz link výše). Jediné řešení je snad čekat na 10.3...
Tiskni
Sdílej: