Immich byl vydán v nové verzi 3.0.0. Jedná se o alternativu k výchozím aplikacím od Googlu a Applu pro správu fotografií a videí umožňující vlastní hosting serveru Immich. K vyzkoušení je demo. Immich je součástí balíčků open source aplikací FUTO. Zdrojové kódy jsou k dispozici na GitHubu pod licencí AGPL-3.0.
Společnost Juno Computers prodávající počítače s předinstalovaným Linuxem má nově v nabídce linuxový tablet Juno Tab 4 - WiFi. Na výběr je Debian, Ubuntu a Kubuntu. Předobjednat jej lze za 949 liber (26 500 korun).
Podman (Pod Manager), nástroj umožňující vytvářet a provozovat kontejnery, aniž by uživatel potřeboval práva roota, byl vydán v nové major verzi 6.0.0. Přehled novinek v poznámkách k vydání. Řešena je i vážná bezpečnostní chyba CVE-2026-57231.
Společnost Sony oznámila, že od ledna 2028 přestane vydávat nové hry pro PlayStation na fyzických discích. Všechny budoucí tituly budou dostupné výhradně v digitální podobě na PlayStation Store.
Google Chrome 150 byl prohlášen za stabilní. Nejnovější stabilní verze 150.0.7871.46 přináší řadu novinek. Podrobný přehled v poznámkách k vydání. Opraveno bylo 433 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Soudní dvůr Evropské unie potvrdil rekordní pokutu 4,125 miliardy eur (100 miliard Kč) americké technologické firmě Google ze skupiny Alphabet. Pokutu firmě v roce 2018 vyměřila Evropská komise (EK) za to, že Google podle ní zneužívá operačního systému Android k potlačení konkurence na trhu vyhledávacích služeb.
Administrativa amerického prezidenta Donalda Trumpa povolila firmě Anthropic obnovit plný přístup klientů k modelům umělé inteligence (AI) Fable 5 a Mythos 5. Ty byly nedostupné bezmála tři týdny kvůli bezpečnostním obavám vlády, třebaže americké ministerstvo obchodu minulý pátek povolilo omezený přístup k modelu Mythos 5 pro některé „důvěryhodné“ domácí organizace.
Francúzska organizácia na ochranu spotrebiteľa, po viac než ôsmych rokoch skúmania, žaluje Epson za plánované zastarávanie tlačiarní. Súd sa začína dnes, 2. 7. 2026, vo francúzskom Nanterre.
Erin Catto, autor open source 2D fyzikálního enginu Box2D (Wikipedie), představil nový 3D fyzikální engine Box3D. Engine je již používán ve hře The Legend of California.
Byla vydána nová verze 4.0.0 multiplatformního svobodného frameworku pro zpracování obrazu G'MIC (GREYC's Magic for Image Computing, Wikipedie). Přehled novinek i s náhledy nových filtrů na PIXLS.US.
Může mi někdo vysvětlit, proč jsou operace provedené na souborech otevřených pomocí open() mnohem pomalejší než operace prováděné se soubory otevřenými pomocí fopen()? (Oboje dvoje na obyčejných souborech)
Případně pokuď existuje, tak bych uvítal nějaký "trik" jak dosáhnout stejné rychlosti.
Hmm, takže s tím očividně neumím zacházet... Proč může být druhý kód mnohonásobně pomalejší než první?
kód 1 - fopen
/* Hlavicka */ if(!fwrite(&header, sizeof(header), 1, fp)) return 0; /* Data */ if((fr = fopen(file_name, "r")) == NULL) return 0; while(c = getc(fr), !feof(fr)) putc(c, fp); if(fclose(fr) == EOF) return 0;
kód 2 - open
/* Hlavicka */ if(write(fp, &header, sizeof(header)) != sizeof(header)) return 0; /* Data */ if((fr = open(file_name, O_RDONLY)) == -1) return 0; while(read(fr, &c, 1) > 0) write(fp, &c, 1) if(close(fr) == -1) return 0;
fp je deskriptor normálního otevřeného souboru, v prvnim případě FILE *, ve druhém int.
Program ve kterém to potřebuju použít by měl bejt obdobou tar -cvvzf. Potřeboval bych proto vytvořený archiv po znaku rovnou posílat pomocí roury komprimátoru, ale pomocí write() a read() je to strašně pomalý - tak, že mnohem rychlejší je nejdříve vytvořit archiv a pak ho znova načítat a komprimovat...
Co zkusit ve druhem pripade misto jednoho znaku treba 1000?:
char pole[1000];
while(read(fr,pole,1000))
write(fp,pole,1000);
Duvod je ten, ze kdyz jedes znak po znaku, tak pro kazdou operaci pouzijes jedno preruseni a to bez ohledu na to, kolik mas dat, takze procesor se musi porad starat o preruseni misto toho aby dal prikaz pameti/disku, ze ma neco udelat.
To mě taky napadlo, ale pro LZW kompresy potřebuju ty znaky pak dostávat stejně po znaku (šlo by si ale udělat nějakej buffer). Nicméně proč je to pomocí fputs() "normálně" rychlý a pomocí write() tak pomalý?
Tiskni
Sdílej: