Na YouTube lze zhlédnout Godot Engine – 2025 Showreel s ukázkami toho nejlepšího letos vytvořeného v multiplatformním open source herním enginu Godot.
Blíží se konec roku a tím i všemožná vyhlášení slov roku 2025. Dle Collins English Dictionary je slovem roku vibe coding, dle Dictionary.com je to 6-7, …
Cloudflare Radar: podíl Linuxu na desktopu dosáhl v listopadu 6,2 %.
Chcete vědět, co se odehrálo ve světě techniky za poslední měsíc? Nebo si popovídat o tom, co zrovna bastlíte? Pak doražte na listopadovou Virtuální Bastlírnu s mikrofonem a kamerou, nalijte si něco k pití a ponořte se s strahovskými bastlíři do diskuze u virtuálního piva o technice i všem možném okolo. Mezi nejvýznamnější novinky patří Průšovo oznámení Core One L, zavedení RFID na filamentech, tisk silikonu nebo nový slicer. Dozvíte se ale i
… více »Vývojáři OpenMW (Wikipedie) oznámili vydání verze 0.50.0 této svobodné implementace enginu pro hru The Elder Scrolls III: Morrowind. Přehled novinek i s náhledy obrazovek v oznámení o vydání.
Komunita kolem Linux Containers po roce vývoje představila (YouTube) neměnný operační systém IncusOS speciálně navržený pro běh Incusu, tj. komunitního forku nástroje pro správu kontejnerů LXD. IncusOS poskytuje atomické aktualizace prostřednictvím mechanismu A/B aktualizací s využitím samostatných oddílů a vynucuje zabezpečení bootování pomocí UEFI Secure Bootu a modulu TPM 2.0. Postaven je na Debianu 13.
Mozilla začne od ledna poskytovat komerční podporu Firefoxu pro firmy. Jedná se o podporu nad rámec stávající podpory, která je k dispozici pro všechny zdarma.
V Bolzanu probíhá konference SFSCON (South Tyrol Free Software Conference). Jean-Baptiste Kempf, zakladatel a prezident VideoLAN a klíčový vývojář VLC media playeru, byl na ní oceněn cenou European SFS Award 2025 udělovanou Free Software Foundation Europe (FSFE) a Linux User Group Bolzano‑Bozen (LUGBZ).
Open-source minimalistický trackball Ploopy Nano byl po modelech modelech Classic a Thumb Trackball také aktualizován. Nová verze Nano 2 používá optický senzor PAW3222 a k původně beztlačítkovému designu přidává jedno tlačítko, které ve výchozí konfiguraci firmwaru QMK přepíná režim posouvání koulí. Sestavený trackball nyní vyjde na 60 kanadských dolarů (bez dopravy a DPH).
Github publikoval Octoverse 2025 (YouTube), tj. každoroční přehled o stavu open source a veřejných softwarových projektů na GitHubu. Každou sekundu se připojil více než jeden nový vývojář. Nejpoužívanějším programovacím jazykem se stal TypeScript.
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:
