Byla vydána verze 1.90.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
GNUnet (Wikipedie) byl vydán v nové major verzi 0.25.0. Jedná se o framework pro decentralizované peer-to-peer síťování, na kterém je postavena řada aplikací.
Byla vydána nová major verze 7.0 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Nově je postavena je na Debianu 13 (Trixie) a GNOME 48 (Bengaluru). Další novinky v příslušném seznamu.
Společnost Meta na dvoudenní konferenci Meta Connect 2025 představuje své novinky. První den byly představeny nové AI brýle: Ray-Ban Meta (Gen 2), sportovní Oakley Meta Vanguard a především Meta Ray-Ban Display s integrovaným displejem a EMG náramkem pro ovládání.
Po půl roce vývoje od vydání verze 48 bylo vydáno GNOME 49 s kódovým názvem Brescia (Mastodon). S přehrávačem videí Showtime místo Totemu a prohlížečem dokumentů Papers místo Evince. Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře.
Open source softwarový stack ROCm (Wikipedie) pro vývoj AI a HPC na GPU od AMD byl vydán ve verzi 7.0.0. Přidána byla podpora AMD Instinct MI355X a MI350X.
Byla vydána nová verze 258 správce systému a služeb systemd (GitHub).
Byla vydána Java 25 / JDK 25. Nových vlastností (JEP - JDK Enhancement Proposal) je 18. Jedná se o LTS verzi.
Věra Pohlová před 26 lety: „Tyhle aféry každého jenom otravují. Já bych všechny ty internety a počítače zakázala“. Jde o odpověď na anketní otázku deníku Metro vydaného 17. září 1999 na téma zneužití údajů o sporožirových účtech klientů České spořitelny.
Byla publikována Výroční zpráva Blender Foundation za rok 2024 (pdf).
Uz ma Rust dynamicky linkovane knihovny? Uz je v ABI kompatibilni aspon zpetne sam se sebou?ABI stabilní není. Dynamické linkování funguje už velmi dlouho, akorát ti s tim nepomůže tooling a musíš si sestavování, kompatibilitu etc. řešit do značný míry sám. Osobně bych nečekal, že by vůbec někdy Rust v nějaký větší míře přecházel na dynamické linkování vzhledem k širokému používání generik. Dynamického linkování v Rustu bych spíš viděl jako doplněk pro případy jako třeba nějaké binární pluginy apod.
Syntakticky blízké je třeba D nebo Java. Zrovna Rust je dost jiný (a často mi přijde, že poněkud samoúčelně, podobně jako Go… trochu z toho čiší snaha dělat věci za každou cenu jinak a vymezovat se proti stávajícím jazykům).
První příspěvek a hned rust-katolíkSpíš je to troll, kterýmu je to reálně jedno, jen si našel způsob trollení.Víš jak poznáš že někdo dělá v rUsTU? řekne ti to.
aje teda jakoby víc lepšejší rust nebo c????? :O :O ;D ;D
No, tak čistě osobně jsem rustem nadšen od doby, co jsem s tim začal něco dělat (ca. 2014), takže samozřejmě rust :Đ, ale to je subjektivní, objektivní názor neexistuje a záleží, jaký máš požadavky, preference a tak...aje teda jakoby víc lepšejší rust nebo c????? :O :O ;D ;D
nm
), tak zjistíš, že to podporuje Unicode a konverzi kódování UTF-8, UTF-16, ISO-8859-1, ASCII... nebo že tam máš garbage collector a další věci. Jasně, můžeš říct, že pro hello world to je zbytečné a navíc, ale v drtivé většině aplikací zrovna tyhle věci potřebuješ a do té céčkovské aplikace by sis příslušné knihovny musel přidat a ta binárka by ti taky nakynula. Výsledek je pak srovnatelný, akorát v té Javě se píše o dost pohodlněji a máš tam lepší správu paměti, tu podporu Unicodu a další věci, které moderní vysokoúrovňový jazyk podporuje.
Jinak ano, taky je mi bližší, když si člověk explicitně přibalí jen to, co potřebuje, a ta základní povinná výbava je minimální. Ale těch 2,4 MB je na dnešní poměry docela málo a zbytečností tam moc není. Takže za mě je tohle fajn cesta. Určitě lepší než smolit nějaké céčko jak v 70. letech a každou chvíli se střílet do nohy.
Z hlediska uživatele (programátora uživatelské aplikace) je důležité třeba to, že read a write můžou vrátit jenom částečně naplněný buffer (jako návratovou hodnotu vrátí, kolik dat se skutečně přečetlo/zapsalo, a pokud chcete víc, tak je musíte spustit znova se zbytkem dat)to je skutecne u site nebou roury ten pripad, jak pises, ale u souboru na harrdisku si myslim je mozne rici, ze pokud se neprecte tolik, kolik se zadalo v tom odpovidajicim parametru, tak je problem ...
read()
je vážně nízkouúrovňová věc, která toho moc neumí. Proto máme fread()
, který takové ošklivosti řeší a drží si vlastní buffer, který se do integeru (file descriptoru) prostě nevejde (narozdíl od FILE*
).
Konkrétně viz read(3p)
:
If a read() is interrupted by a signal before it reads any data, it shall return −1 with errno set to [EINTR].
If a read() is interrupted by a signal after it has successfully read some data, it shall return the number of bytes read.
read(3p)
je posixová manuálová stránka, která popisuje, jak by se ten syscall měl chovat podle POSIXu. read(2)
je linuxová manuálová stránka, která (je-li dostatečně aktuální) popisuje, jak se aktuálně chová na Linuxu (včetně případných rozšíření).
EINTR
The call was interrupted by a signal before any data was read; see signal(7).
Dává to tak i víc smyslu. Pokud byste vrátil -1/EINTR
, nebude mít volající šanci poznat, jestli se něco přečetlo a pokud ano, kolik toho bylo.
u souboru na harrdisku si myslim je mozne rici, ze pokud se neprecte tolik, kolik se zadalo v tom odpovidajicim parametru, tak je problem
Ne tak úplně:
mike@lion:/srv/ram> ls -l file8 -rw-r--r-- 1 mike users 8589934592 zář 5 01:12 file8 mike@lion:/srv/ram> strace dd if=file8 of=/dev/null bs=8G ... read(0, "t\371\246\323\310\34\365\332\202\200'X\366\234GI\327N9\353\224\361\n\315\200)z(?\221\220&"..., 8589934592) = 2147479552 write(1, "t\371\246\323\310\34\365\332\202\200'X\366\234GI\327N9\353\224\361\n\315\200)z(?\221\220&"..., 2147479552) = 2147479552 read(0, "\234]Z\213\217\214B\247 SZ\320\20\361\273i\376\250?\26\324\320\333\213\n\256^=\26{0\325"..., 8589934592) = 2147479552 write(1, "\234]Z\213\217\214B\247 SZ\320\20\361\273i\376\250?\26\324\320\333\213\n\256^=\26{0\325"..., 2147479552) = 2147479552 read(0, "\"\177l\254\316\212\325\342]\378\244;*\\\365l\25A\352\6\t\310\311/\313\336.\23\250D<"..., 8589934592) = 2147479552 write(1, "\"\177l\254\316\212\325\342]\378\244;*\\\365l\25A\352\6\t\310\311/\313\336.\23\250D<"..., 2147479552) = 2147479552 read(0, "\204\232\271\5\225\10/J\346\333\236\326/~{\264\214\217\244\31\367\212SK\220\2421\220\302n<A"..., 8589934592) = 2147479552 write(1, "\204\232\271\5\225\10/J\346\333\236\326/~{\264\214\217\244\31\367\212SK\220\2421\220\302n<A"..., 2147479552) = 2147479552 read(0, "\372\271\247_\252K\32\253\253\372\366\300\34\37\362\33\332\363\r{\3\6-\24\20\344\302\376\333~\366\245"..., 8589934592) = 16384 write(1, "\372\271\247_\252K\32\253\253\372\366\300\34\37\362\33\332\363\r{\3\6-\24\20\344\302\376\333~\366\245"..., 16384) = 16384 read(0, "", 8589934592) = 0 close(0) = 0 close(1) = 0 ... 0+5 records out 8589934592 bytes (8,6 GB, 8,0 GiB) copied, 1,06331 s, 8,1 GB/s)
read()
a fread()
je v tom, že read()
je dost těžké použít zcela správně. Takže hlavní poučení je používat knihovny, například fread()
, kde už se s tím trápil někdo jiný.
read()
, dostanete nekonzistentní obsah (a dost možná i obsah, který vůbec nedává smysl).
read()
nemusí přijít vůbec a pak byste tam měl leak za každé takové nedokončené čtení.
Nebylo by pak lepší napoprvé vracet chybu, pokud se nepovede načíst vše najednou?
Třeba informace z alsy jsou někdy docela dlouhé:
$ cat /proc/asound/card0/codec#0 | wc 113 527 3958
Jindy je to třeba jen jedno číslo nebo jeden krátký řádek.
Nebylo by pak lepší napoprvé vracet chybu, pokud se nepovede načíst vše najednou?
Někde by to asi smysl mělo, ale určitě ne obecně. Co když userspace opravdu zajímá jen začátek? Navíc existují soubory jako /proc/kcore
, které celé najednou ani přečíst nejdou.
Mimochodem, 3958 není tak moc, to se pořád vejde do 4096, což je IIRC defautní délka bloku, po kterém čte glibc, pokud si neřeknete o víc (např. když zavoláte fgetc()
). Ale jsou i soubory, které mohou být podstatně delší, např. v /proc/net
.
To je pravda, někdo asi může chtít číst jen začátek a nemusí to být chyba. Správné řešení by nejspíš bylo to vázat na otevřený FD a dokud ho uživatel nezavře, tak držet tu původní verzi konzistentní (zatímco jiným už poskytovat novější data). Akorát by se musela paměť alokovat dynamicky a bylo by to náročnější na implementaci.
readfile
syscall, který načte soubor a tečka - takže věci co čtou periodicky hodně z /proc nemusí dělat open, (p)read, close. Ale zatím to nevypadá hotově.
Hodi se to spis pro aplikace typu grep, co prohledava vsechny soubory.AFAIK rychlý alternativy ke grepu (ag, ripgrep) se na tohle snažej používat memory mapping. ripgrep v komentářích tvrdí, že používá heuristiky, ale jestli to dobře čtu, tak jen vypne mmaping na 32 bitech a na macosu, ale jinak se snaží používat mmap. Nevim, jestli readfile má tohle změnit...
EINVAL
. (Což možná není úplně košér / serióznější projekt by to asi udělal jinak, ale zas mi nepřijde, že možností by bylo kdovíkolik, protože jak píšeš, člověk si tam nechce skladovat někde nějaký rozdělaný "transakce".)
select()
/ poll()
/ epoll()
je příklad toho, kdy je potřeba jít na nižší úroveň a knihovní nadstavby použít nejde. Vlastně už samotné neblokující čtení by se s fread()
kombinovalo dost obtížně.
fileno()
a vesele ho předat select()
. Například Qt toto umí také. Také jde naopak někde sebrat file descriptor a pomocí fdopen()
si nad ním nachystat tu nadstavbu.
Neblokující IO je však trochu jiná kapitola, tam už to je komplikovanější.
fileno()
nebo fdopen()
je ta jednoduchá část. Problém je v tom, že otázka, jestli read()
bude blokovat, není stejná jako jestli fread()
bude blokovat. A kterýkoli z těch tří syscallů mi odpoví jen na tu první, zatímco mne, pokud budu používat ke čtení fread()
bude zajímat ta druhá.
supr fígl to ulocked dělání se souboramama :O :O snad stim jako někde neudělám neštěstí :D
Tiskni
Sdílej: