Vyjádřeni Software Freedom Conservancy (SFC) k porušování licence AGPLv3 společností Bambu Lab v jejich softwaru Bambu Studio pro 3D tisk. Bambu Studio vychází z PrusaSliceru. Ten zase z Slic3ru. Spuštěn byl projekt baltobu, který kombinuje několik strategií pro řešení problému. SFC zastřeší vývoj svobodné náhrady proprietární knihovny libbambu_networking pomocí reverzního inženýrství a reimplementace, forku OrcaSliceru pro Bambu Lab tiskárny od Paweła Jarczaka a forku celého Bambu Studia pod názvem Viscose.
Správce souborů GNOME Commander (Wikipedie) byl přepsán do Rustu a vydán v nové verzi 2.0.0.
Sway (Wikipedie), dlaždicový (tiling) správce oken pro Wayland kompatibilní s i3, byl vydán ve verzi 1.12. Do vývoje se zapojilo 50 vývojářů. Přehled novinek na GitHubu. Sway 1.12 závisí na wlroots 0.20.0.
Papež Lev XIV. ve své první encyklice Magnifica Humanitas (Skvělé lidství), která se věnuje umělé inteligenci (AI), varoval před dezinformacemi, které AI manipulací s obsahem vytváří. Moc mají podle něj sociální sítě ovládané hrstkou soukromníků. Upozornil také roli digitálních platforem v obchodování s lidmi, které podle něj musí být uznáno jako současná forma otroctví. Papež se také poprvé omluvil za roli, kterou Vatikán sehrál při legitimizaci otroctví, a za to, že jej po staletí neodsoudil.
Český telekomunikační úřad zveřejnil Výroční zprávu za rok 2025 (pdf), která shrnuje jeho hlavní aktivity v oblasti regulace elektronických komunikací, poštovních služeb, digitálních služeb a přípravy na dohled nad umělou inteligencí. Součástí zprávy jsou také data o vývoji trhu, včetně pokračujícího růstu spotřeby mobilních dat a rozšiřování sítí nové generace. Celkový objem přenesených mobilních dat dosáhl v roce 2025 přibližně
… více »Tým sdružení CZ.NIC vyvíjející routovacího daemona BIRD oznámil vydání nových verzí 3.3.0 a 2.19.0. Ty přinášejí podporu pro EVPN/VXLAN a automatizaci BGP na základě router advertisementů. Více informací je k dispozici v archivu uživatelského mailing-listu.
Open source software pro úpravu digitálních fotografií LightZone (Wikipedie) byl vydán v nové verzi 5.0.0. LightZone je dnes k dispozici pod licencí BSD. Původně se jednalo o proprietární software vyvíjený společností Light Crafts. Ta v prosinci 2012 souhlasila s uvolněním zdrojových kódů jako open source [Wayback Machine].
Byla vydána verze 0.84 telnet a ssh klienta PuTTY (Wikipedie). Podrobnosti v přehledu nových vlastností a oprav chyb a Change Logu.
Microsoft představil Azure Linux 4.0 a Azure Container Linux. Na konferenci Open Source Summit North America 2026 organizované konsorciem Linux Foundation a sponzorované také Microsoftem. Azure Linux 4.0 vychází z Fedora Linuxu. Azure Container Linux je založen na projektu Flatcar. Azure Linux (GitHub, Wikipedie) byl původně znám jako CBL-Mariner.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 165 (pdf).
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: