Multimediální server a user space API PipeWire (Wikipedie) poskytující PulseAudio, JACK, ALSA a GStreamer rozhraní byl vydán ve verzi 1.6.0 (Bluesky). Přehled novinek na GitLabu.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-1.2 a 20.04 OTA-12.
Byla vydána (Mastodon, 𝕏) nová stabilní verze 2.0 otevřeného operačního systému pro chytré hodinky AsteroidOS (Wikipedie). Přehled novinek v oznámení o vydání a na YouTube.
WoWee je open-source klient pro MMORPG hru World of Warcraft, kompatibilní se základní verzí a rozšířeními The Burning Crusade a Wrath of the Lich King. Klient je napsaný v C++ a využívá vlastní OpenGL renderer, pro provoz vyžaduje modely, grafiku, hudbu, zvuky a další assety z originální kopie hry od Blizzardu. Zdrojový kód je na GitHubu, dostupný pod licencí MIT.
Byl představen ICT Supply Chain Security Toolbox, společný nezávazný rámec EU pro posuzování a snižování kybernetických bezpečnostních rizik v ICT dodavatelských řetězcích. Toolbox identifikuje možné rizikové scénáře ovlivňující ICT dodavatelské řetězce a na jejich podkladě nabízí koordinovaná doporučení k hodnocení a mitigaci rizik. Doporučení se dotýkají mj. podpory multi-vendor strategií a snižování závislostí na vysoce
… více »Nizozemský ministr obrany Gijs Tuinman prohlásil, že je možné stíhací letouny F-35 'jailbreaknout stejně jako iPhony', tedy upravit jejich software bez souhlasu USA nebo spolupráce s výrobcem Lockheed Martin. Tento výrok zazněl v rozhovoru na BNR Nieuwsradio, kde Tuinman naznačil, že evropské země by mohly potřebovat větší nezávislost na americké technologii. Jak by bylo jailbreak možné technicky provést pan ministr nijak nespecifikoval, nicméně je známé, že izraelské letectvo ve svých modifikovaných stíhačkách F-35 používá vlastní software.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 162 (pdf).
Sdružení CZ.NIC, správce české národní domény, zveřejnilo Domain Report za rok 2025 s klíčovými daty o vývoji domény .CZ. Na konci roku 2025 bylo v registru české národní domény celkem 1 515 860 s koncovkou .CZ. Průměrně bylo měsíčně zaregistrováno 16 222 domén, přičemž nejvíce registrací proběhlo v lednu (18 722) a nejméně pak v červnu (14 559). Podíl domén zabezpečených pomocí technologie DNSSEC se po několika letech stagnace výrazně
… více »Google představil telefon Pixel 10a. S funkci Satelitní SOS, která vás spojí se záchrannými složkami i v místech bez signálu Wi-Fi nebo mobilní sítě. Cena telefonu je od 13 290 Kč.
Byl publikován přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Fedora 43 Asahi Remix s KDE Plasma už funguje na M3. Zatím ale bez GPU akcelerace. Vývojáře lze podpořit na Open Collective a GitHub Sponsors.
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:
