Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 156 (pdf).
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 25.8.1. Přehled novinek v Changelogu.
Včera večer měl na YouTube premiéru dokumentární film Python: The Documentary | An origin story.
Společnost comma.ai po třech letech od vydání verze 0.9 vydala novou verzi 0.10 open source pokročilého asistenčního systému pro řidiče openpilot (Wikipedie). Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 4. snapshot Ubuntu 25.10 (Questing Quokka).
Řada vestavěných počítačových desek a vývojových platforem NVIDIA Jetson se rozrostla o NVIDIA Jetson Thor. Ve srovnání se svým předchůdcem NVIDIA Jetson Orin nabízí 7,5krát vyšší výpočetní výkon umělé inteligence a 3,5krát vyšší energetickou účinnost. Softwarový stack NVIDIA JetPack 7 je založen na Ubuntu 24.04 LTS.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) spolu s NSA a dalšími americkými úřady upozorňuje (en) na čínského aktéra Salt Typhoon, který kompromituje sítě po celém světě.
Společnost Framework Computer představila (YouTube) nový výkonnější Framework Laptop 16. Rozhodnou se lze například pro procesor Ryzen AI 9 HX 370 a grafickou kartu NVIDIA GeForce RTX 5070.
Google oznamuje, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Tato politika bude implementována během roku 2026 ve vybraných zemích (jihovýchodní Asie, Brazílie) a od roku 2027 celosvětově.
Byla vydána nová verze 21.1.0, tj. první stabilní verze z nové řady 21.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools a Libc++.
S ext3 (a už dlouho ani ext2) není problém, pokud si výslovně nezakážete indexování adresářů. Naopak, když jsem to zkoušel měřit, vycházela práce s velkými adresáři na ext3 rychleji než třeba na XFS.
Na druhou stranu, při určitých operacích je stejně potřeba prohledat adresář celý a to je pomalé i s indexováním - takže ani tam nehraje volba filesystému roli.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
ls -1U' (což by navíc na rozdíl od 'ls -l' vedlo ke správnému výsledku).
24.3.2011 00:40
David Watzke | skóre: 74
| blog: Blog...
| Praha
bash$ touch "a" "b > c" bash$ ls -1U a b?c bash$ ls -1U | wc -l 3 vs bash$ find . -type f -ls | wc -l 2pokud počítáme soubory tak spíš o jedna blíže ke správnému výsledku, který je zde 2.
.
Michal
Přístup je tam přímý, není třeba indexace. Vždy podle id v db sáhne přímo na určité soubory, tedy jako ten příklad /data/123456.jpg
A právě na to je ta indexace adresářů potřeba. Bez ní by byla časová náročnost vyhledání položky podle jména úměrná počtu položek v adresáři - a to je při velkém počtu položek (typicky od 10000 výše) docela velký problém.
. Nicméně, když to udělám tedy stylem /data/5/6/123456.jpg, tak tím asi nic nezkazím, že?
Ale teď jsem zkoušel dát ls -1 data/123456.jpg a zobrazilo se to okamžitě, tak nevím.
Když však zkusím ls -1 data | wc -l, tak zobrazí výsledek 125985 až během 63 sekund.
Michal
ls -1U data | wc -l ?
Ale teď jsem zkoušel dát ls -1 data/123456.jpg a zobrazilo se to okamžitě, tak nevím.
Ve všech dnes běžně používaných filesystémech adresáře indexované jsou, takže vyhledání položky podle jména je velmi rychlá operace.
Když však zkusím ls -1 data | wc -l, tak zobrazí výsledek 125985 až během 63 sekund.
To je úplně jiná situace. V tomto případě je potřeba projít všechny položky (v tom vám indexace stromem nepomůže, spíš naopak), seřadit je a seřazený seznam poslat na výstup. A při troše smůly se jako bonus na každou položku zavolá stat(). Příkaz ls totiž neví - a ani nemůže vědět - že výstup posílá "wc -l", takže by stačilo položky spočítat, ale musí vygenerovat stejný výstup, jako kdyby ho vypisoval na terminál (až na obarvovací sekvence, pokud používáte --color=tty).
Časová náročnost může být dána jednak pomalostí čtení z disku, jednak řazením:
...# time ls -1U >/dev/null ; time ls -1U >/dev/null ; time ls -1 >/dev/null real 0m28.198s user 0m0.184s sys 0m0.462s real 0m0.484s user 0m0.182s sys 0m0.302s real 0m2.929s user 0m2.576s sys 0m0.330s
ROK/MESIC/Soubor nebo lépe ROK/TYDEN/Soubor - pokud si to spočítáte tak zjistíte co je pro Vás vhodnější. Samozřejmě toto jednoduché řešení má nevýhody v nerovnoměrnosti obsahu souborů v adresářích a nutnost v DB uchovávat cestu k souboru (což při běžném webu nevadí, protože nejsou těch souborů miliony).
24.3.2011 14:51
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
getImage stránku, kde si musíte udělat vlastní reportování chyb.
24.3.2011 20:06
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Předně děkuji za doplnění. Obecně máte (nebo máš, jestli si můžeme tykat) pravdu.
Ve stránce můžete mít i velký roj obrázků a to znamená velký roj samostatných dotazů do DB. Způsobené problémy s výkonem nebudou v jednotkách procent ale minimálně v desítkách a klidně několika stovkách procent.
Všechny obrázky (jejich obsah čili data) je třeba přenést přes všechny vrstvy od DB až po výstup.
Obé lze řešit cachováním. Požadavky na obrázky mohou jít buď skrz memcached, případně to může cachovat samotný DB stroj. Jistě namítnete, že totéž si může cachovat samotný FS. Ano může, ale to by znamenalo řešení se všemi nevýhodami, které jsem popsal.
Musíte řešit getImage stránku, kde si musíte udělat vlastní reportování chyb.
Nemusí být možné (dle db, providera a jejich velikosti) přečíst všechna data obrázku najednou, ale třeba postupným vytahováním z db (nebo je třeba alespoň tuto možnost zvažovat).
Souhlas a tohle považuji za největší nevýhodu mého řešení (což jsem i napsal).
Zálohování je daleko náročnější protože pokud se jedná o mnoho data bez dalších řešení nelze zálohovat přírustkově, což v tomto případě na filesystému se přímo vybízí
I DB lze zálohovat inkrementálně.
Např. vygenerujete html stránku aby se všechno neustále stránka dynamicky nevytvářela z db, ale při tom všechny obrázku jdou stejně z db.
Vracím se k bodu jedna, každý jednotlivý obrázek se nemusí brát vždy z DB (disku), mohou být cachovány a pokud se to udělá inteligentně, tak mohou být připraveny stejně jako ta html stránka.
Neprovedete diskové operace na soubory-obrázky (jako hromadné přidání vodoznaku, změna třeba komprese/formátu, resample, hledání v obsahu, prohlížení pomocí nějakého „náhledovače“ a pod.).
To záleží, jakým způsobem jsou tyto operace prováděny. Samozřejmě nelze na to přímo pustit program, který umí pracovat pouze ze souborem (dejme tomu ImageMagick convert). Pokud se to ale zpracovává nějakou knihovnou přímo v programu, tak se ta obrázková data většinou stejně předávají přes nějaké pole bajtů nebo stream a zdroj dat může být kdekoliv (už na něm nezáleží). Případně se ta data dají tomu externímu programu ládovat přes jeho standardní vstup (pokud to umožňuje).
Off topic:
Konzistence lze řešit pře aplikační transakci, když se to udělá správně
Já jsem v tomto spíše pesimista. Málokdy se to udělá správně, (komerčního) vývojáře tlačí rozpočet, termíny, séf apod. Rozhodně bych si nevsadil na vývojáře webové aplikace, že je schopen zvládnout transakční zpracování dat lépe, než vyspělá DB. Nic proti tomu webistovi, ale to už je zcela jiná liga.
že Vám tam nějaký soubor přebývá - no a co, lze jej dohledat a situaci napravit
Tak jednak by mě zajímalo jak se zjistí, že nějaký soubor přebývá. Ještě jsem neviděl webovou aplikaci (tohoto typu), která by měla něco jako "fsdbck". To se prostě nijak nezjisti. Ale ono nejde ani tak o to, že by nějaký soubor přebýval. To je ještě ok. Co ale například uděláte, když vám ten soubor na FS přejmenuji za jiný (prostě přehodím)? Aplikace si toho vůbec nevšimne, a bude nabízet jiný soubor. Ok tohle chcete řešit přes CRC32 (mno, lépe než kontrolní součet by bylo lepší použít hashovací funkce, ale rozumíme si). Tak jinak, ten soubor vám pojmenuji zcela jinak? Aplikace si toho možná všimne, možná ne (spíše ne, prostě v servírovaném html dokumentu bude stále odkaz na neexistující soubor). Tohle se prostě v DB nestane (pokud se nebudeme bavit o přímé editaci databázových datových souborů), tam to všechno ohlídá integrita, na "přejmenování" mohou být trigery, které upraví vazby na další tabulky apod.
MD5 zajišťuje plnohodnotnou kontroluBejvávalo... Tao Xie and Dengguo Feng (30 May 2009). How To Find Weak Input Differences For MD5 Collision Attacks.
Dejte mi dva rozdílné soubory ze stejnou MD5-kou a stejnou velikostí
Máte je v příloze. Nebo tady jich najdete hned osm.
25.3.2011 07:26
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Přírustková záloha např. MySQL - bez toho anž bych tuto zálohu připravil (přes sql), jak? (nevím, a asi bych chtěl)
V PostgreSQL se to umí přes WAL log (Continuous Archiving and Point-In-Time Recovery), v MySQL to lze dělat také pomocí binárních logů (Point-in-Time (Incremental) Recovery Using the Binary Log).
no není obojí je prostě externí zásah a obojí je špatně a projeví se to stejným způsobem −> zobrazí se špatný obrázek.
Nevím, zda jsme se přesně pochopili. Já jsem směřoval k tomu, že pokud to mám v DB ošetřené pomocí referenční integrity, triggerů a všeho co jde (Ok, jako pokud se budeme bavit o MYISAM, tak tu diskusi asi můžeme uzavřít, já mám stále na mysli plnou DB), tak mi databáze samotná nedovolí tam udělat nežádoucí změnu, případně se ta změna projeví všude a výsledek bude opět konzistentní stav. Ten software tu integritu přímo vynucuje. Zatímco na disku ten obrázkový soubor mám přímo přístupný a nic mě nezastaví. Ano, je to externí zásah, ano nikdo nepovolaný by se neměl dostat ani na DB, ani na FS. Ovšem ona ta DB integrita dost často ochrání data i před chybou v aplikaci. Je to prostě vrstva navíc.
Praktická zkušenost: Atestovaný elektronický nástroj pro správu veřejných zakázek (EZAK). PHP(bohužel) + PostgreSQL (bohudík 
). Veškeré dokumenty v DB, verzované, některé i šifrované (dle zákona). Každá změna DB je zaznamenávána pro audit. Pro mě, jako pro technika (nejsem programátor, vše co tu píšu je z pohledu technika a admina DB), je to super stav, kdy vím, že mi stačí zálohovat pouze DB a aplikace se případně (při obnově) nainstaluje nová. Nemusím řešit zálohu ještě něčeho jiného (což mě skutečně štve na všech redakčních systémech -- záloha dvou různých míst, kterou lze jen těžko udělat ve stejný čas), záloha (také několik GB) je konzistentní (udělá se v jedné transakci -- WAL backup zatím nepoužívám).
24.3.2011 15:12
AraxoN | skóre: 47
| blog: slon_v_porcelane
| Košice
24.3.2011 21:37
/data/123456.jpg by to bolo /data/00/01/E2/40.jpg.
.
Michal
#!/bin/bash
if [ $# -eq 1 ] ; then
CUT="NO";
else
if [ $# -eq 2 -a "$2" == "-extcut" ] ; then
CUT="YES";
else
echo " ";
echo "usage: $0 directory_name [-extcut]";
echo " ";
echo "where: directory_name is directory with pictures";
echo " -extcut option will cut files extension (if exists)";
exit 1;
fi
fi
DIR=$1;
if [ ! -d $DIR ] ; then
echo " ";
echo "'$DIR' is not a directory!";
exit 1;
fi
cd $DIR
for FILE in `ls $DIR`
do
if [ -f $DIR/$FILE ] ; then
NEWNAME=$FILE;
if [ "$CUT" == "YES" ] ; then
NEWNAME=`echo $FILE | sed 's/^\(.*\)\..*/\1/g'`;
fi
NEWPATH=./`echo $NEWNAME | sed 's/^\(.*\)\..*/\1/g' | sed 's/\(...\)/\1\//g' | sed 's/^\(.*\/\)[^\/]*$/\1/g'`;
echo "copy: '$DIR/$FILE' to '$NEWPATH$NEWNAME'"
mkdir -p "$NEWPATH"
cp -f "$DIR/$FILE" "$NEWPATH$NEWNAME"
rm "$DIR/$FILE"
fi
done
echo "Successfully imported."
exit 0;
cp; rm místo mv. Šetřme životní prostředí, a navíc, co když se kopírování nepovede? To klidně smažete originál?
for file in `ls $DIR` taky - máte dost dlouhou příkazovou řádku? Měřil jste ji? Raději for file in $DIR/*, spolupracujte s shellem, ne proti němu.
Hláška "Successfully imported" a exit 0 na konci by měla reflektovat činnost skriptu, ne se vysmát do očí uživateli s nepřipojeným cílovým diskem a smazanými fotkami :)
Tiskni
Sdílej:
