Vývojáři mobilní Datovky prosí o pomoc s testováním beta verze mobilní Datovky s novým grafickým rozhraním, podporou pro tmavý režim a podporou pro VoDZ. Aplikace je zatím dostupná pouze pro zařízení Android a je umístěna v samostatném instalačním kanále Datovka Beta. Tento kanál slouží pro testovaní nové funkcionality a grafického uživatelského rozhraní. Datovka Beta se instaluje jako samostatná aplikace s vlastními daty, která
… více »Harlequin byl vydán ve verzi 1.0.0. Jedná se o TUI (Text User Interface) IDE (Integrated Development Environment) k systému pro správu SQL OLAP databází DuckDB.
Po roce a půl od představení DALL·E 2 představila společnost OpenAI novou verzi DALL·E 3 svého AI systému pro generování "realisticky vypadajících obrázků nebo uměleckých děl" na základě popisu v přirozeném jazyce, viz příklad "kosmonaut na koni fotorealisticky". Jednou z novinek je integrace s ChatGPT.
Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 133 (pdf) a HackSpace 70 (pdf).
Po půl roce vývoje od vydání verze 44 bylo vydáno GNOME 45 s kódovým názvem Rīga. Přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře. Krátké představení na YouTube. Jednou z nejviditelnějších změn je odstranění tlačítka Činnosti (Activities) v levém horním rohu. Nově je tam indikátor ploch. Výchozím prohlížečem obrázků je nově Loupe, nahradil Eye of GNOME (eog). Novou aplikací pro práci s webovou kamerou je Snapshot, nahradil Cheese. Rozšíření GNOME Shellu fungující v předchozích verzích nejsou s verzí 45 kompatibilní.
Linux Foundation představila a zaštítila svobodný a otevřený fork Terraformu s názvem OpenTofu. Ten vznikl pod původním názvem OpenTF jako reakce na přelicencování Terraformu na BSL (Business Source License) společností HashiCorp.
Google oznámil (en), že konverzační AI Bard (Wikipedie) může nyní komunikovat s aplikacemi a službami Google: "Díky nejnovějšímu rozšíření služby může Bard najít a zobrazit relevantní informace z nástrojů společnosti Google, které používáte každý den, jako je například Gmail, Dokumenty, Disk, Mapy, YouTube a Letenky Google, a to i když jsou potřebné informace v různých aplikacích a službách."
Apache Pinot (GitHub, Wikipedie) dospěl do verze 1.0. Jedná se o realtimeový distribuovaný OLAP datastore navržený tak, aby na OLAP dotazy odpovídal s nízkou latencí.
Byla vydána Java 21 / JDK 21. Nových vlastností (JEP - JDK Enhancement Proposal) je 15. Jedná se o LTS verzi. Nová Java / JDK vychází každých 6 měsíců.
Byla vydána betaverze Fedora Linuxu 39, tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 17. října. Nový Fedora Linux přinese GNOME 45, LibreOffice 7.6, GCC 13.2, …
Řešení dotazu:
/
, /boot
a případně swap?
bez komentára
selinux všetko vyrieši.
Sice možná všechno vyřeší, ale nějak nesouvisí s původním dotazem, že ano.
Měl-li to být náznak, že oddělené filesystémy nějak zlepšují izolaci, odpověď je, že nezlepšují. Oddělené filesystémy nenabízí bezpečnostní výhody ve srovnání s jedním jediným. Kdyby měl kernel tak zásadní bug, že by se dalo například utéct z LXC nebo z chrootu nebo jinak eskalovat oprávnění, dostat se k datům z ostatních filesystémů by byla všeho všudy otázka času. Leda že by ty filesystémy byly zašifrované a nebyly by namountované. Jenže … k čemu by vlastně potom byly? Jednou by je někdo namountovat musel. A pak je ten problém stále stejný.
/home
mi dává možnost bez závažných operací přeinstalovat systém, bez toho abych musel zvláště pracovat z uživatelskými daty. Tedy zazálohovat /home
a pak jej restaurovat do nového systému. Pokud se rozhodnu, v konfiguraci s odděleným /home
, vyměnit distribuci nebo k nové verzi (verzové distribuce) přistoupit tak, že systém reinstaluji, a ne aktualizuji verzi, systém jednoduše přeinstaluji s tím že formátuji oddíly pro /
a /boot
a /home
nechám nedotčený a je to akce na pár minut. Reinstalace systému se společnám prostorem se zachováním uživatelských dat je mnohem náročnější akce. Mit samostatný prostor pro systém a pro uživatele se mi mnohokrát osvědčilo. Jak v případě Win, když už v čase XP jsem použiva C: jen na systém a data měl na D: a dalších oddílech. A stejně tak v linuxovém prostředí.
Reinstalace systému se společnám prostorem se zachováním uživatelských dat je mnohem náročnější akce.Moje distribuce třeba tento problém nemá, prostě rozbalím rootfs na souborový systém, kde už třeba /home, /root, /opt a /usr/local jsou a nikomu to nevadí.
* Protoze chci mit nektere oddily "nosuid", "noexec", ... apod ?nosuid i noexec mi fungují per subvolume.
* Protoze chci mit nektere oddily s jinym poctem inode na kb ... ?S dnešními FS, které packují malé soubory k sobě?
* Protoze chci mit moznost nektere oddily v pripade potreby jednoduse odmigrovat jinam (na ssh apod) ... ?Tak tady vůbec nechápu, jak to souvisí s tím, jestli je to samostatný FS.
Dělení disku na oddíly je zlozvyk z minulého desetiletí. Doporučuji disk nedělit a pak bude prostor vždy k dispozici tam, kde je potřeba. Opravdu je to takhle jednoduché.
Nemá-li člověk swap, stačí jeden jediný oddíl v případě BIOSu, dva oddíly v případě UEFI. (Oddíly to v obou případech musí být a nemůže to být filesystém přímo na disku, protože jinak by z toho firmware nenabootoval. Ale není-li to bootovací disk, pak tam ani oddíly být nemusí.)
Má-li člověk swap, například kvůli uspání do RAM, pak je samozřejmě potřeba mít „oddíl“ na swap. Ale to je lepší zařídit pomocí LVM (proto ty uvozovky) a MBR oddíl nebo GPT oddíl jiný než /boot/efi nechat jen jeden (případně s LUKS uvnitř, aby i swap byl šifrovaný, atp.).
Kdysi ještě platilo, že chce-li uživatel šifrovaný root (/), pak musí mít oddělený /boot, který je nešifrovaný. To už ale dnes dávno neplatí, protože GRUB podporuje LUKS. Jen to může být (naneštěstí stále ještě) trochu nepohodlné, takže si umím představit, že by třeba někdo i dnes upřednostnil nešifrovaný /boot.
Jako filesystém je nejlepší nasadit Btrfs a v něm mít subvolume pro /, /etc, /var, /home (nebo případně pro každý domovský adresář zvlášť, opravdu podle gusta). Pak se dá bez problému
Kromě toho má Btrfs ještě spoustu dalších výhod a killer features. Dělení disku předem na oddíly je fakt zlo, které uživatele jen omezuje a dřív nebo později ho dostihne — například způsobem popsaným v dotazu.
Nedelenie nová moda ako ultra super featura. Bez delenia ten systém nebude nikdy bezpečný a selinux si môžu dať za klobuk.
Kromě toho, posledně jmenovaná metoda se dá snadno emulovat pomocí loopbacku (což může být sparse soubor a nemusí předem zabírat místo), případně pomocí encfs (i když encfs není ideální řešení, protože prozrazuje spoustu metadat, například uspořádání adresářů, počty a přibližné velikosti souborů).
Překvapuje mě jeden častý jev: Někdo si úplně zbytečně rozdrobí svůj diskový prostor na kousky a pak se snaží sám pro sebe hledat zdůvodnění, proč to vlastně udělat. Inu, pro nic za nic.
Oddělené filesystémy neposkytují žádnou bezpečnostní výhodu ve srovnání s jediným. Ve chvíli, kdy je v kernelu zásadní bug kolem eskalace práv nebo izolace virtuálních prostředí, jsou všechny možné konfigurace napadnutelné asi tak stejnou měrou.
Pro „ten systém nebude nikdy bezpečný“ bych prosil citaci. Co je to bezpečný systém? Jak se to pozná? Jak se pozná, když není bezpečný, a jaká přesně rizika pak hrozí? (Ta otázka nežádá výčet, nýbrž přesnou a konkrétní definici relevantní pro tento kontext, tedy pro dělené a nedělené filesystémy.) Kde je důkaz implikace, že systém s jedním filesystémem není nikdy bezpečný?
SELinux je v tomto případě téměř ortogonální záležitost. Nevidím důvod plést dohromady dělení či nedělení filesystémů a SELinux. UNIXové systémy mají, jak známo, jeden jediný adresářový strom, ve kterém jsou vidět všechny namountované filesystémy. SELinux tedy (ne)chrání (ne)rozdrobené filesystémy přesně stejnou měrou, tedy podle konkrétní konfigurace a konkrétního nasazení.
Andreji, mohl bys popsat tvůj způsob použití harddisku?Já mám velkou partition s btrfs, kde mám subvolumes pro / a /home. Je to hlavně pro to, abych mohl říct, kdy chci snapshotovat systém, a kdy data. Pak mám ještě jeden oddíl, s ext4, na kterém mám image virtuálů, protože ty se fragmentují kvůli btrfs CoW (které dřív nešlo vypnout selektivně pro subvolume, možná už to jde).
Já mám / samostatně, protože se mi lépe zálohuje a obnovuje celý malý diskový oddíl.Nikdy jsem systém nezálohoval jako bitovou kopii, vždycky rsyncuju, taruju atd. soubory.
Já mám /
nesamostatné, protože nechci mít žádné omezení na 15 GB ani na jakoukoliv jinou konstantu. A když root nezabírá celých 15 GB, pak samozřejmě chci, aby všechen nevyužitý prostor byl kdykoliv k dispozici jinde, třeba v /home
nebo /var
, podle aktuální potřeby.
Zálohování je triviální, protože /
je zkrátka obyčejný Btrfs subvolume. Takže prostě udělám snapshot, zazálohuju a hotovo. S obnovením by to bylo podobné, kdybych ho snad (hrůza pomyslet) někdy potřeboval provést. Nic mě přece nenutí zálohovat úplně celý Btrfs zároveň.
Btrfs nedoporučuji, pokud se uživatel nechce stát expertem na Btrfs a chce počítač jen používat. Já jsem si ho dal jen na domácí počítač, naštěstí ne na pracovní a za tu dobu mě potkalo:
Použil jsem grafickou utilitku Snapper pro vrácení půlky systému a během vracení to vyměnilo nejspíše dost knihoven na to, že mi spadl systém během vraceníMě naštěstí jen spuštění utility vytížilo systém na 100%, plán byl jen pomocí toho zkonfigurovat časy záloh aby nedocházelo k častému vytěžování, to bylo ale na 13.2.
Nabootoval jsem do readonly snapshotu a udělat z něj normální zapisovací. A byl jsem nadšený, jak to krásně funguje. Než jsem zjistil, že originální snapshot nejde vymazat (snapper na tom vždy spadl, low level btrfs utilita se sudo odmítla kvůli nějakým oprávněním). Takže pak jsem skončil s tím, že uvolnit místo mohu formátem diskuNápodobně, prroto, jsem při instalaci Leapu poprvé zvolil EXT4. Teď stále váhám, jestli ho nepoužít znovu, i když to bude spíš jen o nedostatku článků jak se s tím pracuje aby z toho použití bylo více výhod než naopak.
Tohle je výčet problémů z roku 2009. Dnes máme rok 2016.
Ale vždyť jsem psal: "Btrfs tedy doporučuji používat jen pokud mu opravdu dobře člověk rozumí a zná všechny ty případy, které ho mohou rozbít." Všechno, co jsi vyjmenoval je z toho, že máš s ním zkušenosti a víš, že nemůžeš přejmenovávat soubor v Krusaderu, koukat se na volné místo v Dolphinu, mazat soubory pro uvolnění místa, atd.
S tím volným místem, jestli tam je nějaká rezerva, tak je to buď relativně nové, nebo jsem něco (ne)zaškrtnul při instalaci. Ale opravdu mi partition šla až nadoraz, takže bootoval jen nějaký záchraný režim a klasický boot neproběhl. A v záchraném režimu jsem si ručně mazal pomocí snapperu staré snapshoty.
To že Dolhin ukazuje blbosti a ne skutečně obsazené místo je problém Dolphinu, nikoliv Btrfs - to má na to vlastní tool. A je to z toho důvodu, že objem reálně uložených dat může být diametrálně odlišný od toho co se vypočítá příkazem 'du'.To je právě naopak. to že dolphin nebo df ukazuje blbosti je hloupá a nepříjemná arogance tvůrců btrfs. pododobně jako odstřelení /var/messages je arogance lidí od systemd. Není podstatné aby seděl udaj obsazenosti s du. To nesedí ani jinde. Ale důležité a podstatné je, aby FS odpověděl smyslupným číslem na dotaz, kolik má volné místo. protože to znamená odhad, kolik ještě tam případně mohu zapsat. Všechny FS tento udaj symslupně odpoví standardním dotazem ale tvurci btrfs prohlásili, my na to kašlem a máme svoje nástroje. Tím vlastně říkají, že kašlou na všechny, kdo ten udaj používají ať již v grafických nebo textových nástrojích. A vůbec nic to nemění na tom, že ten údaj může být třeba minimální smysluplný odhad, že v mnoha případech se tam pak zapíše více, nebo průměr, kdy když budu zapisovat data bude klesat mnohem rychleji než co jsem zapsal, ale to, že FS hlási 15% místa, ale systém spadne proto nezapíše ani sektor je blbě. Přesto btrfs používám, protože některé jeho vlastnosti jsou pro mne důležitější než problém s reportem místa. Nicméně pořád to považuji za hloupou aroganci tvůrců.
pododobně jako odstřelení /var/messages je arogance lidí od systemd.Linux používam vyše desaťročie, ale o
/var/messages
som ešte nepočul. Ak sa jednalo o textové logy vo /var/
, tak tie má na starosti syslog a ten bez problémov koexistuje s systemd. Ak si si ho nenainštaloval, tak ho nepotrebuješ. A zvalovať to na chybu niečoho iného je mierne infantilné.
/var/log/messages je zalezitost CentOS/RHEL/Fedora,To je rôzne. Niektoré distribúcie to majú napríklad ako /var/log/syslog. Ale ako /var/messages som to ešte nevidel.
syslog ma sice na starosti soubory pod /var/log, ale treba v posledni Fedore uz neni ani nainstalovany, musel jsem pridat rsyslog a upravit journald.conf, aby to fungovalo jak v RHEL 7.V ktoromsi Ubuntu vyhodili syslog ešte pred zavedením SystemD, takže som si ho doinštaloval. A úpravu journald.conf som nikdy nemusel robiť aby sa mi chytil syslog. Takže naozaj za to nemôže SystemD, ale balíčkovači metabalíkov ktorí vyhodia voliteľné balíky a vytvárajú východziu konfiguráciu. Práve mám pod rukami napríklad Ubuntu 16.04, a v ňom má SystemD všetky položky zakomentované, a funguje mi bez problémov preposielanie na syslog (rsyslog).
/var/messages
som za tých pár desaťročí v IT nikdy nerátal.
Tím chcete říct, že pokud odkaz je součástí i snapshotu, místo se bez smazání celého toho snapshotu neuvolní?Mně se to na btrfs uvolňuje, teď jsem to vyzkoušel.
Ačkoliv vím, že snapshot obsahuje jen adresáře ve kterých se obvykle neukládají velké souboryJá teda používám snapshoty pro zálohování, to znamená, že mám stroj, na který každý den rsyncnu / z několika jiných serverů a pak udělám snapshot (a staré snapshoty po půl roce mažu). Takže snapshot obsahuje velmi velké soubory…
Ačkoliv vím, že snapshot obsahuje jen adresáře ve kterých se obvykle neukládají velké soubory a navíc obsahují jen rozdílové verze.Tak nevím, je to jinak, snapshot1 zabírá 5.5GiB ale snapshot66 už 5.6GiB, znamená to, že jsou to kompletní obrazy, bohužel se duplikují i celé adresáře /usr/bin a /lib které vytváří ty GiBs, naštěstí to neukládá /home nebo /var/log.
Všechno. Poslední výskyt nejdéle přežívající z uvedených chyb jsem viděl kolem roku 2012 a to nebyl zrovna moc aktuální kernel.
UUID=b9004a1e-a8f9-451e-bc26-ebe474735e25 swap swap defaults 0 0 UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 / btrfs defaults 0 0 UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /boot/grub2/i386-pc btrfs subvol=@/boot/grub2/i386-pc 0 0 UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /boot/grub2/x86_64-efi btrfs subvol=@/boot/grub2/x86_64-efi 0 0 UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /opt btrfs subvol=@/opt 0 0 UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /srv btrfs subvol=@/srv 0 0 UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /tmp btrfs subvol=@/tmp 0 0 UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /usr/local btrfs subvol=@/usr/local 0 0 UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/crash btrfs subvol=@/var/crash 0 0 UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/lib/libvirt/images btrfs subvol=@/var/lib/libvirt/images 0 0 UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/lib/mailman btrfs subvol=@/var/lib/mailman 0 0 UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/lib/mariadb btrfs subvol=@/var/lib/mariadb 0 0 UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/lib/mysql btrfs subvol=@/var/lib/mysql 0 0 UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/lib/named btrfs subvol=@/var/lib/named 0 0 UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/lib/pgsql btrfs subvol=@/var/lib/pgsql 0 0 UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/log btrfs subvol=@/var/log 0 0 UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/opt btrfs subvol=@/var/opt 0 0 UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/spool btrfs subvol=@/var/spool 0 0 UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /var/tmp btrfs subvol=@/var/tmp 0 0 UUID=39f2733c-cbf0-45af-aed0-c3a73460a724 /.snapshots btrfs subvol=@/.snapshots 0 0 UUID=4b4eadb7-7ffd-4a20-a497-4b5d32f6d393 /home xfs defaults 1 2
/boot
mountuji jen při aktualizaci jádra, takže se tím snižuje riziko, že ho nějak poškodím a systém už nenabootuje. A také mám /boot udělaný tak, aby z něj vždy šlo nějaké jádro nabootovat a dávám tam nějaký minimální shell nebo busybox. Pořád lepší, když se do vzdáleného počítače přes KVM dostanu alespoň do shellu, než když nenabootuje vůbec a musím řešit boot ze sítě.
Filesystem Size Used Avail Use% Mounted on /dev/sda1 20G 7.4G 11G 41% / /dev/sda2 343G 264G 62G 81% /homeTakto to mám už roky. Používam fakt dosť aplikácií, tie najväčšie sú asi Libre Office, GIMP, Blender, Inkscape, FireFox, Tor Browser, FileZilla viacero vývojových prostredí ako QT SDK, Lazarus, Geany, Gambas ... a množstvo všelijakého užitočného softvéru, a ako vidíš systém je zaplnený len na 41%.
Tiskni
Sdílej: