Vývoj linuxové distribuce Clear Linux (Wikipedie) vyvíjené společností Intel a optimalizováné pro jejich procesory byl oficiálně ukončen.
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).
btrfs.fsck
bych se neodvážil ho mít jinde než pro experimentální použití.
/boot
100 MB na SSD/tmp
a /var/tmp
mám připojeny do ramdisku/var
mám připojen na nevímjakvelký oddíl na HDD (myslím, že kolem 100 GB, ale občas ho musím promazávat, když moc překypuje /var/abs)/home
, ale mám to trošku šíleněji)/boot
. Osobně dělám rozdělení takto:
swap
, /usr
, /var
, /tmp
a /home
.
Pokud bych to měl dělat bez LVM, tak třeba:
/home
v každém případě zvlášť a pokud možno nekomplikovaně. To je jedný oddíl, na jehož obsahu záleží, zbytek může jít do kytek. Samozřejmě, že se zálohuje, ale stejně...
LVM po několika letech, kdy ho Fedora dávala implicitně a nikdy jsem jeho vlastností nevyužil, na NB a desktopy nedávám. Akorát další zbytečný layer.
/ 20GiB /boot 256MiB /home 40GiB (LUKS) /srv 2GiB /var 4GiB /tmp v paměti max. 3GiB /test 20GiBNa stolním podobně jen
/srv
a /var
mají vyšší hodnoty a /home
je bez LUKS
./
(16 GB) + swap
(3 GB) + /home
./
(20 GB) + /home
, plánuju přidat green HDD jako /mnt/share
(až si obchodníci namastí kapsy a ceny spadnou na zem), swap jsem vynechal.Systém běžně zabírá pod 4 GB.Systém určitě, ale programy (tedy /usr, který máš podle všeho na /), těžko. I když nebudu počítat věci jako wesnoth, který sám zabere půl GB, tak je tu pořád TeX (kolem 200 MB bez dokumentace, ta je tak dalších 250 MB), a pod. Do 4 GB se mi / nevejde ani na notebooku, na workstation ani do 8 GB.
[vaclav@lt-tm2450 ~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/hda1 16G 3,3G 12G 22% / /dev/hda3 36G 1,1G 33G 4% /home tmpfs 997M 0 997M 0% /dev/shm
K čemu jsou běžnýmu uživateli -devel balíky? Ano, před pár desetiletími si vizionáři představovali, že každý uživatel počítače bude zároveň i programátor. Vývoj jim však za pravdu nedal.-devel balíky jsou pro instalaci ze zdrojáků (když potřebuje člověk nainstalovat něco co v distribuci buď není, nebo je to tam ve staré verzi). Ovšem k tomu člověk být programátor nepotřebuje, neboť postup instalace většiny "rozumných" věcí ze zdrojáků je typu "rozbalte zdrojáky, doinstalujte si tyhle a tyhle -devel balíčky a pak napište '
./configure && make && make install
' - a potom se to už bez dalšího zásahu uživatele zkompiluje a nainstaluje"
/usr
u mne je: du -s * 424696 bin 4 games 9472 include 462244 lib 1801372 lib64 80 local 53532 sbin 2652876 share 522620 src 0 tmp 16 X11R6 16 x86_64-suse-linuxjak je trochu poznat distribuce openSUSE 12.1 64bit a hlavní prostředí KDE. žádné hry jen pár v základu, programy na fotky jako digikam darktable hugin, libre office a tex a stejně jsem přes 7 GB celkem
Pracovni NTB:
/ (128 GB SSD) - prijde mi zbytecne to delit /home (750 GB SATA) - LUKS + LVM
Domaci desktopy/servery:
/boot (512MB) / (10 GB) /home (zbytek)Swap oddily nepouzivam, misto nich mam win386.swp...
/boot
i 512 MB. Když se podívám na obsazenost mého /boot, vidím jen 21 MB. Co všechno tam dáváte, že potřebujete tolik?
/boot
(to jsem zjistil až zpětně) a po restartu to chcíplo… , od té doby dělám vždy minimálně 256MiB - to nic nestojí… (ne že by to ten problém řešilo a zbavovalo mě to zodpovědnosti, ale je tam víc prostoru, když je to třeba)
hlavně file systém bude psát informace do inode o času zápisu do swapTenhle problém (že čtení souboru způsobuje zápis dat) lze vyřešit použitím parameteru "noatime" při mountování. Je jasné, že filesystem má nějaký overhead, ale otázkou je jestli u "obvykle vcelku spojitého" souboru co nemění velikost (takže není nutné spouštět algoritmus pro alokaci dalších bloků na disku) bude ten overhead filesystému spočitatelný pouze na CPU (tedy asi spíš minimální), nebo ten overhead bude znamenat čtení/zápis dalších bloků metadat někde na disku. (což by byl další seek a už celkem zpomalení)
To řeší sice nutnost zápisu při čtení, ale ne nutnost dalšího zápisu při zápisu. Last modified se změní tak jako tak.hlavně file systém bude psát informace do inode o času zápisu do swapTenhle problém (že čtení souboru způsobuje zápis dat) lze vyřešit použitím parameteru "noatime" při mountování.
Tiskni
Sdílej: