Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 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ářejí všichni účastníci, se skládá z desetiminutových
… více »Richard Stallman přednáší ve středu 7. května od 16:30 na Technické univerzitě v Liberci o vlivu technologií na svobodu. Přednáška je určená jak odborné tak laické veřejnosti.
Jean-Baptiste Mardelle se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.04.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
TmuxAI (GitHub) je AI asistent pro práci v terminálu. Vyžaduje účet na OpenRouter.
Byla vydána nová verze R14.1.4 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5, Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání. Podrobný přehled v Changelogu.
Bylo vydáno OpenBSD 7.7. Opět bez písničky.
V Tiraně proběhl letošní Linux App Summit (LAS) (Mastodon). Zatím nesestříhané videozáznamy přednášek jsou k dispozici na YouTube.
Se na to můžu vysrat, já mám na všechno takový štěstí. Došla mi baterka v NB a ten linux je tak neinteligentní, že mi to ani neoznámil, ani se nevypnul a prostě nechal tu baterku dojít úplně a černo. Po rebootu už systém nenaběhnul, grub nebyl schopen přečíst FS a načíst kernel. Z live CD jsem spustil kontrolu oddílu, hodilo to errora (superblock invalid, trying backup blocks... bad magic number in super-block while trying to open /dev/sda1), FS neopraven a navěky mrtev. Úkol (i když naprosto primitivní) na programování v řiti, pracně konfigurovaný openbox a conky v řiti ... ještě že tam nebyly důležitá data. Připadá mi to nechutné, to se Linux není schopen za těch několik let vypořádat s výpadkem? Jelikož máme doma dementní jističe a každou chvíli to vylítne, tak si tohodle Okýnka na desktopu užily až až a vždycky to přežily bez újmy na zdraví. Njn, NTFS je, narozdíl od ext4, kvalitní a moderní FS. Teď na ten NB radši dám původní Windows a rovnou ho i reklamuju kvůli tomu posranýmu ALPS touchpadu, jak už jsem tu někdy zmiňoval.
Tiskni
Sdílej:
Tobe se jeste nikdy neslozily Windows, ze? :-)
Jinak nevim, v cem je problem. Nahodim cistou instalaci systemu (1/2 hod), pripojim se na svuj backup disk a natahnu data (vcetne /etc a konfigurace sveho uzivatele, cca 1 hod podle mnozstvi dat), nainstaluju baliky podle seznamu nainstalovanych instalaci v backupu (max 1/2 hod) a jedu dal... A ze nedelas zalohy? No za to operacni system fakt nemuze. Panecku, nechtel bych se srat s nahazovanim windows a win aplikaci od nuly.
Kdyz je milujes, neni co resit. Je to jeden bash skriptik, rsync a cron. O tom, ze zalohuju se dozvim jen diky rozsviceni HDD LED presne v 21:00.
Abys nerekl, ze jsem skrt, posilam muj zalohovaci skript. Ale bacha, pod Win ti nepojede ;). Skript vyzaduje v ~/backup/ symlinky na vsechny adresare, ktere chces zalohovat a ssh klic bez hesla k jinemu pocitaci v siti (v mem pripade zalohovaci Xen cell na domacim serveru).
#!/bin/bash
SERVER=doma
SSHUSER=rbackup@$SERVER
SSHDIR=/mnt/data/backup/omicron
SSHIDENTITY=/home/marekp/.ssh/rbackup
BACKWHAT=/home/marekp/backup/
BACKTO=$SSHUSER:$SSHDIR/actual
ping -c 1 $SERVER > /dev/null
if [ "x$?" != "x0" ]; then
echo "E Nelze pingnout zalohovaci pocitac '$SERVER'"
exit
fi
#echo "Zalohuji LVM ze serveru..."
#scp -i $SSHIDENTITY -r $SERVER:/etc/lvm /home/marekp/zaloha/
date > $BACKWHAT/timestamp
dpkg -l > $BACKWHAT/dpkg-l
echo "Zalohuji data na vzdaleny pocitac"
rsync --verbose --recursive --copy-links --times --stats --exclude-from=$BACKWHAT/backup.exclude -e "ssh -i $SSHIDENTITY -o Compression=yes" $BACKWHAT $BACKTO
echo "I Spoustim komprimaci souboru na vzdalenem pocitaci."
ssh -i $SSHIDENTITY $SSHUSER "cd $SSHDIR && tar cf `date +"%u"`.tar actual" &
echo "I HOTOVO!"
Nerikam zkopirovat to 1:1, chce to mozna trochu invence. Nikdo nerika, ze ta zaloha navic musi byt kazdy den. Ale co, svoje jsem si uz rekl...
Diky za tip s PRE.
A ted trochu k tematu - moje Ubuntu mi dochazejici baterku hlasi (applet v systray), jestli pocitac vypina nebo ne nevim, protoze to nikdy nenechavam nadoraz.
Můj Arch taky, a při kriticky nízkém stavu baterie se uspí na disk.
+1,
Můj Debian taky, holt si Jardík neumí nastavit ACPI.
no v ubuntu to funguje i bez explicitniho nastavovani
Mně to na Macbooku s MAC OS X taky hlásí.
No, můj CentOS ve virtuálu vidí notebookovou baterii a obtěžuje mě ta vyskakovací bublina, když se od napájení odpojím.
Naproti tomu moje Ubuntu mi na notebooku docházející baterku nehlásí -- zčásti to bude tím, že nemám puštěný žádný panel, a pak asi taky tím, že tam dávno žádná baterka není.
Tak jako tak, souborový systém (ext3) přežil už mnoho tvrdých vypnutí a nikdy nebyly potíže. Takže autor blogu buďto neměl štěstí, ale velkou smůlu, anebo je ext4 prostě málo robustní.
A zálohovat je nutnost. Škoda, že se to člověk naučí obvykle až po ztrátě důležiých dat...
Oprava, vzpomínám si, že nejmíň jednou jsem ext3 na starém počítači dlouho opravoval ručně a potíže s tím tedy byly. Také se mi jednou podobně zblbnul XFS. Ale jinak se to snad vždy opravilo samo.
Úkol (i když naprosto primitivní) na programování v řiti, pracně konfigurovaný openbox a conky v řiti ... -> zodpovedne a spravne nastavene zalohovanie v riti
To bude rukama a ne Linuxem
to jsou holt ti magori co nahodi LFS/arch/gentoo, nakonfigurovat to neumi, a pak se divi
a nebo si to rucne prenastavil v gnome a zapomel za to - nebude zas celej blogpost zachvilu preskrtnutej - jak minule ?
No minulý týden se mi počítač na tvrdo vypnul asi tak ~30 (viz můj zápisek Padající počítač) a po každém pádu systém dokázal naběhnout bez jakékoliv kontroly disku (EXT3 + Reiserfs) s obouma jsme pracoval.
Za to, když jsem tam měl xfs... jo to se ztrácely data i při normálním vypnutí a zapnutí
A mění to vůbec něco?
Vazne by me zajimalo, proc jeste ten hrozny Linux pouzivas, kdyz poslednich par let si na nej jen stezujes? Nevyhovuje ti, dobra, tak pouzivej Windows a bud s nimi spokojeny. Sbohem.
Možná proto, že Windoze vypadají dobře na plakátech, ale na práci to není?
Jako jeden z mála tě musím podpořit, protože se mi to na ext3 opakovaně stalo též (nicméně jsem toho zase tolik neztratil). Dokonce jsem si kvůli tomu nechal žurnálovat úplně veškerá data na systémovém oddílu. Prostě Windows když natvrdo vypneš – pohoda, a to že jsem to udělal nesčetněkrát. Linux – a jéje. Zatím jsem to příliš neprozkoumával ani se nepokoušel přijít na příčinu. Disk jsem měl v IDE módu, takže NCQ zřejmě mohu vyškrtnout.
Lidé, kteří cosi mumlají o zálohování, se mohou dělat chytrými, jak chtějí, ale jsou úplně mimo.
> Lidé, kteří cosi mumlají o zálohování, se mohou dělat chytrými, jak chtějí, ale jsou úplně mimo.
Je to, samozrejme, az posledni zachrana. Kazdopadne nesmirne ucinna.
Osobne provadim se svym notebookem OPRAVDU psi kusy, vyndavani baterky za behu, vypinani natvrdo (kdyz se mi zrovna nechce cekat na vypnuti systemu), pad ze stolu na zem s roztocenym diskem apod. a nikdy jsem o zadna data neprisel. Kazdopadne i presto zalohuju, protoze POTOM bude pozde. Kdyz se pak jednomu z milionu stane, ze si pri vypnuti natvrdo zrusi cely oddil a jeste drzkuje, ze zalohovani je zbytecny, tak nemam zadnych dalsich rad.
Se zalohovanim to taky neprehanim, neco zalohovany mam, ale neni to vsechno a neni to nejcerstvejsi. Ale nebudu zalohovat sbirku filmu a serialu, to by se mi nikam neveslo a kdybych o to prisel tak to neni zadna skoda, stejne na to kouknu vetsinou jen jednou. Fotky nebo veci do skoly mam poruznu na flashkach a dvd.
ja mam asi taky ten jinej (stejnej jak ty) ext3, pred par hodinama mi vypadnul laptop z ruky, fsck jsem teda radeji nechal dojet, system i filesystem bez problemu
He, to netusim, co tim na tom notebooku bezi za veci, kdyz porad zapisujou na disk. Me na notebooku s ext3 uz taky parkrat dosla baterka - proste jsem nepripojil zdroj, zapomnel jsme na to a nechal notebook zapnutej. Vzdycky to system rozdejchal, zadny problemy jsem nemel, ale je pravda, ze ten notebook mam jako workstation, ne jako server se spoustou daemonu neustale zapisujich na disk. Ale i nase server, kdyz obcas vytuhnou (vmware), tak rozdejchaji vypnuti natvrdo bez problemu. Tos tam musel honit nejakou drsnou vec.
Dale, jestli pouzivas experimental fs ext4, tak co nadavas - urcite je u ty volby varovani, ze je to experimental.
A vypnout system podle baterie samozrejme linux umi, akorat sis asi neco zapomnel nainstalovat.
Ale jinak opravdu, pokud ti linux nefunguje, tak pouzivej windows a chod na ne nadavat na nejaky windows forum:)
Njn, NTFS je, narozdíl od ext4, kvalitní a moderní FS.
Nerikals, ze mas uzivatelsky data na SPADFS? :-)
Ano, naprosto Vás chápu, ale neobávejte se, nejste sám kdo má tyto problémy se špatným systémem, u nás v práci si nemálo uživatelů stěžuje na systém... jakýkoliv systém, na admina ... jakéhokoliv admina a na software ... jakýkoliv software. Je zajímavé, že tyto problémy vyvstávají vždy u stejného okruhu pracovníků, kdežto jiní, se s nimi nikdy nesetkají. Máte holt smůlu, všichni kolem Vás jsou neschopní neumětelové, alespoň, že máte jistotu, že chyba není nikdy na Vaší straně. Zkuste být k nám druhým trošku shovívavější, na rozdíl od Vás jsme jen lidé.
crash_count < code_generated^code_usability + data_on_net
. Jelikoz jarda pouziva nestabilni FS, crash_count bude urcite vysoky. Kdyz prihlizim k code_usability nad 1 se nejspis nedostane. Data on net je diky velke lasce k GPL a kompletne celemu free software taky nedosazitelna hodnota (mozna az zaporna