Společnost DuckDuckGo rozšířila svůj AI chat Duck.ai o GPT-5 mini (𝕏). Duck.ai umožňuje anonymní přístup bez vytváření účtů k několika modelům umělé inteligence. Aktuálně k GPT-4o mini, GPT-5 mini, Llama 4 Scout, Claude Haiku 3.5 a Mistral Small 3.
Marek Tóth v příspěvku DOM-based Extension Clickjacking: Data ve správcích hesel v ohrožení na svém blogu popsal novou clickjacking techniku s několika variantami útoků a otestoval ji proti 11 správcům hesel. Výsledkem bylo nalezení několika 0-day zranitelností, které mohly ovlivnit uložená data desítek milionů uživatelů. Jedno kliknutí kdekoliv na webové stránce kontrolované útočníkem umožňovalo ukrást uživatelská data ze
… více »Na dnešní akci Made by Google 2025 (YouTube) byly představeny telefony Pixel 10 s novým čipem Google Tensor G5 a novými AI funkcemi, hodinky Pixel Watch 4 a sluchátka Pixel Buds 2a.
The Document Foundation oznámila vydání nové major verze 25.8 svobodného kancelářského balíku LibreOffice. Podrobný přehled nových vlastností i s náhledy v poznámkách k vydání (cs) a také na Youtube a PeerTube.
Zeek (Wikipedie), původně Bro, byl vydán v nové major verzi 8.0.0. Jedná se o open source platformu pro analýzu síťového provozu. Vyzkoušet lze online.
Byl vydán Mozilla Firefox 142.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 142 je již k dispozici také na Flathubu a Snapcraftu.
Python Developers Survey 2024, výsledky průzkumu mezi vývojáři v Pythonu organizovaném Python Software Foundation ve spolupráci se společností JetBrains v říjnu a listopadu loňského roku. Zúčastnilo se 30 tisíc vývojářů z 200 zemí. Linux používá 59 % z nich.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 25.08.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
Byla vydána nová verze 2.51.0 distribuovaného systému správy verzí Git. Přispělo 91 vývojářů, z toho 21 nových. Přehled novinek v příspěvku na blogu GitHubu a v poznámkách k vydání.
Řešení dotazu:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
19.5.2015 15:44
which rm? mas normalni /bin/rm?
pripadne zkus udelat link rm na /bin/busybox, ten by se mel chovat normalne, asi
trebas
ln -s /bin/busybox /usr/local/bin/rm
/usr/local/bin/rm ...
cp --sparse=always ?
jinak mi napada, ze se dlouho maze kvuli tomu, ze je sparse a tim padem fragmentovana, co e4defrag?
S jakyma optionama je ten filesystem primountovany?Implicitně takto: /dev/sda3 on /share/HDA_DATA type ext4 (rw,usrjquota=aquota.user,jqfmt=vfsv0,user_xattr,data=ordered,nodelalloc,noacl) Zkoušel jsem to remountnout s delalloc, ale žádný rozdíl. Zajímavé je, že pár GB velké soubory (typu například .mkv
) to smaže v řádu maximálně jednotek sekund, ale mazání tady těch vmware záloh je pomalé, i když jsou relativně stejně velké (+- 4GB).
Začínám podezírat ext4 vs děravost souborů.
unlink() nebo unlinkat().
lstat64("stodulkovi.cz-flat.vmdk", {st_mode=S_IFREG|0600, st_size=64424509440, ...}) = 0
access("stodulkovi.cz-flat.vmdk", W_OK) = 0
unlink("stodulkovi.cz-flat.vmdk"
...a v tom unlinku visí ten dlouhý čas. Pak to uklidí a končí. Takže nic zvláštního.
pokud tam mas 'find' tak to zkus smazat s nim find co --delete
- The NAS will reboot automatically after large files (larger than 850G) are removed in File Station. - It takes a very long time to move a large number of folders and files to another shared folder on the same NAS via File Station. - The Turbo NAS will occasionally reboot when transmitting large files via CIFS/SMB. - The Turbo NAS will occasionally reboot when you backup files to an external hard drive.Takže mě jejich implementace připadá dost děravá. A zkusil bych jejich forum.
V "top" se mi vypisuje, že rm běží na procesoru (proč? más pustit unlink() a čekat)
To, že běží syscall v jádře, se pořád prezentuje jako stav "R", teprve pokud by spal, bude to buď "S" (interruptible) nebo "D" (uninterruptible). Nanejvýš hrozí, že zakročí soft lockup detector, pokud by v tom jádře běžel beze spánku moc dlouho.
Jinak mazání dlouhých souborů je na ext2/3/4 opravdu pomalé, což je dáno implementací pomocí indirect, double indirect a triple indirect bloků. Ale 10 minut na desítky GB je opravdu hodně, leda snad při kombinaci pomalého procesoru, pomalého disku a málo paměti.
[...] leda snad při kombinaci pomalého procesoru, pomalého disku a málo paměti.To tam všechno je: Marvel ARM 800MHz (jednojádro tuším), 256MB RAM a disk je taky jakýsi "green". Nicméně pořád nemám uspokojivou odpověď, proč je takový rozdíl mazat zálohu malého image z vmware o velikosti 4GB (trvá cca 40s, tzn. oněch ~100MB/s) a podobně velký jiný soubor např. Rebelka.mkv (smaže za méně než 1s). Jediný rozdíl mezi těmi soubory je v tom, že vmware vznikl přes NFS a je děravý.
rm skončí" ano.
Hm, díky. Už to chápu, ale časem tomu dám asi šanci. Pořád mi totiž připadá, že tam probíhá něco jako safe erase (nějakou chybou?), které ext3 vůbec neumí, takže bych měl aspoň jistotu, že neprobíhá.
Ale stejně je mi divné, že tento problém jsem nikde na netu popsaný nenašel, přestože na qnap zálohuje přes ghettoVCB z vmware kde kdo a já nemám nikde v tom setupu nic nestandardního - ani na vmware, ani na qnapu. Nebo na ty zálohy použiju RPI s raspbianem - tam je aspoň standardní systém.
Jinak mazání dlouhých souborů je na ext2/3/4 opravdu pomalé, což je dáno implementací pomocí indirect, double indirect a triple indirect bloků. Ale 10 minut na desítky GB je opravdu hodně, leda snad při kombinaci pomalého procesoru, pomalého disku a málo paměti.Nakonec beru toto vysvětlení jako řešení, v zásadě je to opravdu plečka - ARMv5/800MHz. Pro řešení svého problému jsem přidal do crontabu na tom NASu řádek, který dělá "echo > soubor" do těch image, které jsou starší, než 6 dnů, což bude trvat asi hodinu denně, ale pak to zálohovací script z vmware při rotaci záloh bez problému během pikosekundy smaže (přes NFS) a netimeoutuje - to byl původní problém. Aspoň se ten NAS nebude furt flákat.
Tiskni
Sdílej:
