Po 9 týdnech vývoje od vydání Linuxu 7.0 oznámil Linus Torvalds vydání Linuxu 7.1. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna a časem také na Linux Kernel Newbies.
Cheat Engine (Wikipedie) je s verzí 7.7 k dispozici už také pro Linux. Jedná se o proprietární skener/debugger paměti používaný především k cheatování v počítačových hrách.
Vláda USA nařídila společnosti Anthropic pozastavit přístup k modelům Fable 5 a Mythos 5 pro všechny cizince, včetně zaměstnanců Anthropicu.
Společnost Murena představila (YouTube) novou verzi 4.0 mobilního operačního systému /e/OS (Wikipedie) založeného na Androidu a LineageOS bez aplikací a služeb od Googlu.
V Arch User Repository (AUR) bylo kompromitováno přes 400 opomíjených balíčků (jejich seznam). Útočník do nich začlenil škodlivý npm balíček atomic-lockfile, který krade citlivá data uživatelů. Publikována byla předběžná analýza spouštěného malwaru deps.
Homebrew, správce balíčků nejen pro macOS, byl vydán ve verzi 6.0.0 (seznam změn). Hlavními novinkami jsou bezpečnostní mechanismus tap trust kvůli důvěryhodnosti závislostí, vylepšení sandboxingu na Linuxu, interní JSON API nebo zlepšení výkonu.
Byla nalezena a 9. června opravena kritická zranitelnost ve FreeBSD v Kernel TLS (KTLS). Pojmenována byla Bumsrakete (FreeBSD-SA-26:26.ktls, CVE-2026-45257). Lokální neprivilegovaný uživatel může přepisovat soubory, ke kterým má právo pouze pro čtení. Přepsáním setuid binárky a jejím spuštěním může získat roota. Na všech verzích od verze 13.0 vydané v dubnu 2021.
Vývojáři open source operačního systému ReactOS (Wikipedie), jehož cílem je kompletní binární kompatibilita s aplikacemi a ovladači pro Windows, se na síti 𝕏 pochlubili, že ReactOS zvládne počítačovou hru Half-Life.
Byla vydána nová verze 4.8 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Využíván je Free Pascal Compiler (FPC) 3.2.2.
Apple container dospěl do verze 1.0.0. Jedná se o open source nástroj pro spouštění linuxových kontejnerů na macOS postavený nad containerization. Napsaný je v programovacím jazyce Swift a optimalizovaný pro Apple silicon.
$ touch test.txt $ zip -e -P test test.zip test.txtA teraz otvor ten test.zip v MC a skus sa pozriet cez F3 do suboru test.txt.
S tím opravdu moc udělat nejde. FISH protokol je založený na tom, že se přes SSH spustí na druhé straně běžný shell a do něho se posílají příkazy, které se spouští na cílové mašině a do nich se přes standardní vstup sypou data. Přitom jména souborů se musí pro shell příkazy escapovat tak, aby znich po odescapováním shellem vyšlo to co má. Je to hromada berliček, ale má to výhodu, že na druhé straně opravdu stačí jen SSH a shell.
Jakmile je na protistraně SSH-2 kompatibilní SSH daemon s podporou SFTP (většinou ve formě binárky /usr/lib/sftp-server -> /usr/lib/openssh/sftp-server) a daný uživatel má přidělené oprávnění k jeho využití (většinou default k právu loginu), tak je použití FISH nesmyls. Bohužel MC je staré a z dob SSH-1 uvázlo na FISH. Současná vývojová verze již v jedné větvi zahrnuje i plnou podporu SFTP, takže se blíská na lepší časy.
Jinak podpora ZIP vychází v MC velmi špatně. Při kopírování více souborů je často archiv pro každý otevíraný zvlášť. ZIP má sice výhodu (i nevýhodu), že je každý soubor komprimovaný zvlášť, takže není všechny soubory okolo nutné dekomprimovat, ale seek na pozici souboru je vražedý. Přitom MC,alespoň co vím, využívá volání externí bunárky a k naskenované adresářové struktuře offsety k souborům nezná, předat neumí. Co se týče problémů se jmény, tak při UTF-8 localech jména v osmibitových kódováních nadělají strašnou paseku. UNIX přitom pro nativní souborové systémy žádné konverze jmnen neřeší - uloží je binárně 1:1 jak je open/create zavolaný. Stejně tak je dodá při čtení adresáře. Při snaze o interpretaci předaného "unicode" pak dojde vychlášení nepovolených sekvencí UTF-8 kódování a prostředí se s tím poperou různě.
Na příkazové řádce je pak řešením použít "rm" nebo "mv", kde se místo nezobrazitelných/nezadatelných znaků použije žolík - ? nebo *.
ZIP z příkazové řádky většinou žádné problémy s rozbalením nemá, ale žádné překódování jmen také neřeší - binární řetezec z archivu předá open/create. TotalCommander správně očekává, že ve Windows mohou být s podivnými znaky potíše ještě větší a proto je nějak ošetří. Zároveň soubory vytváří přes Wine, které Windows kódování (CP852 nebo 437 +/-) (které je natvrdo ve jménech) převede na UTF-8.
Takže na ZIPy vytvořené na Windows není nakonec TC ve Wine špatná volba. Alternativa je buď naučit přímo unzip převádět jmnéna přes iconv knihovnu nebo soubor rozbalit a buď v C nebo oprasy v shellu jmnéna překódovat do utf-8. Zatím na to používám jen skript, který jsem někde potkal, upravil možná i částečně vymyslel.
for x in *; do y=`echo $x | iconv -c -f ISO-8859-2 -t ASCII | tr -d '[!:+*]'` if [ "$x" != "$y" ]; then mv -v "$x" "$y" fi done
S tím opravdu moc udělat nejde.Zvětšit hodnotu
bs. Stále to sice bude ošklivé, zbytečně složité a se spoustou berliček, ale o něco rychlejší. Za minimum práce (změna jednoho čísla) alespoň nějaké zlepšení.
BTW: už řadu let používám SSHFS a je to už hodně dávno, co jsem potřeboval shell link v mc, takže mě to ani tak netrápí.
Se zbytkem souhlasím.
proc vsichni (90% lidi kolem mne) ma neskutenou potrebu balit veci do raruLOL! Chytráku!
Když svejm kokotoidním windoze lama známejm něco zabalim do taru, nejsou schopný si ani
něco zabalim do taruA to buď rád, že to nejsou policajti – jednou se mi dostalo odpovědi – ať to prý pošlu nezašifrované
Ani já nemam tušení co na nich aktuálně je a voni na to nejspíš ani neměli mechaniku (ale pučit si jí ode mě nechtěli). A trvalo jim 3/4 roku než zjistili že na těch pár desítkách cd s linuxem je fakt linux a že tam žádný mp3 fakt nejsou. A když sem podával vysvětlení tak jim nejdřív nešel net a pak tiskárna. Až by je jeden politoval, v jakejch podmínkách a za jaký peníze musej dělat ...
Tak to je hustý.
když u mě při domovní prohlídceTo na tebe byl někdo hodný a naprášil tě?
A přišli si pro mě akorát v době kdy sem už to DC přestal používat, protože to byla síť nahovno. To nasere ...
Od tý doby jenom uložto a spol. a výjimečně torrent, ale těm se taky snažim vyhnout.
To byl nějakej celorepublikovej zátahjo to si tehdy pamatuji
protože to byla síť nahovno. To nasere ...to máš pravdu, že to nasere. Já jsem nějak DC nepoužíval.
výjimečně torrenttaky ne, uložto a mediafire mi stačí.
No ale stačilo pár měsíců ignorovat všechno co mi napsal a ono ho to přestalo bavit ...
insertto se mi sem tam taky stane, že se mi hotovej text nahrazuje tim co píšu, ale insert sem teď skoušel a tim to neni
unrar, což je nástroj přímo od výrobce.
Zip - v podstate zadny vetsi problem.
Rar - nekolik tipu:
"keep broken" flag -kb zachova i nekompletni fajly a fajly s blbym CRC
unrar x -kb blabla.rar
"recover" command: hodi se pri poskozeni nebo kdyz nejaka cast multipart archivu chybi (zachrani co se da)
rar r blabla.rar
rar rc blabla.rar
Diakritika: AFAIK moc problemu nebylo (kdyz je to blbe, tak se soubor prejmenuje pozdeji).
pacman -Qi kdelibs)...
200 nebo 300 MB? Co to dneska je?Tak to bych chtěl vidět, jak jsi to zjišťoval, kotyz.
Krusader mi absolutne nevyhovuje rozhranim.
(kde muzes pouzivat 100x lepsi krusader)To by mě zajímalo, podle jakýho měření je Krusader 100x lepší než TC. Přijde mi to naopak. Beru v úvahu přehlednost zobrazení, ovládání klávesnicí a FTPS.
unrar na Linuxu (s UTF8 locale) naprosto korektně.
Otázkou je, zda systém souborů je ta správná vrstva, která by měla řešit (re)kódování znaků do různých kódování.Právě. Použitím univerzálního kódování, které by bylo zároveň fyzickým uložením ve filesystému a zároveň v API, by úplně odpadla potřeba překódování. Tady vše hraje pro UTF-8, které je navíc používáno v aplikacích.
A když už unicode, tak spíše UTF32, ne? Ať je pevně daná maximální délka řetězce.Mně je to v celku jedno... v oblasti filesystémů jsem obyčejným uživatelem. Ale taky bych se rozhodoval mezi UTF-8 a UTF-32. Všechna ostatní kódování znaků mi dneska přijdou zbytečná.
Filesystem predsa neriesi ziadne kodovanie. Nazov suboru je jednoducho postupnost nenulovych bajtov. Ci si tam das UTF-8 alebo nieco ine, tak to uz je tvoj problem.Zřejmě jsi nikdy neslyšel o NTFS, že?
Filesystem predsa neriesi ziadne kodovanie. Nazov suboru je jednoducho postupnost nenulovych bajtov.Což je ale špatně, protože názvy souborů jsou informace především pro uživatele. A uživatele nezajímají nějaké bajty, ale znaky.
.cbr. Což jsou v podstatě zabalené stránky naskenované knížky.
.cbr archív a ten pak prohnat přes calibre do fb2. Výsledek je lepší, než když to je rovnou v PDF a taky mi to umožňuje podle potřeby ty obrázky předtím upravit (natočit stránky, optimálně snížit počet barev, spojit stránky atp.) tak aby pak byla optimálně využita celá plocha čtečky.
Skor na warez vseobecne, nielen na porno.My používáme jenom OSS warez :).
15070 státem spočtenejch rytířů Jedi používá na rozbalování sílu!!!
Tiskni
Sdílej: