Byla vydána nová verze 24.04.28 s kódovým názvem Time After Time svobodného multiplatformního video editoru Shotcut (Wikipedie) a nová verze 7.24.0 souvisejícího frameworku MLT Multimedia Framework. Nejnovější Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Byla vydána verze 5.30 dnes již open source operačního systému RISC OS (Wikipedie).
V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Byla vydána verze 1.74.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání na GitHubu. Vyzkoušet Rust lze například na stránce Rust by Example.
Tiskni Sdílej:
:$cat hello.rs fn main() { println!("Hello World!"); } :$ rustc hello.rs :$ ls -al hello -rwxr-x--- 1 xxx xxx 11603080 Nov 16 20:39 hello :$rustc --version rustc 1.63.0
Veľa štastia programovať pre navykonnejšie počítače na procesore RISC.
Mac je pre ľudi, ktorím robí aj rozhodnutie problém.
printf("Hello world")
má při statickém linkování 745KB, stripnuté 667K. Teprve při dynamickém linkování to je 16KB, resp. 15K stripnuté.
erin@erin-desktop ~> ls -lh /boot/ostree/fedora-b57af0c7fbbfccce5ef8bf2aa99df8aad7d52128507c82c3f67d6b4352d6b80a/vmlinuz-6.5.11-300.fc39.x86_64 /usr/lib64/libc.so.6
-rwxr-xr-x. 1 root root 14M 13. lis 19.53 /boot/ostree/fedora-b57af0c7fbbfccce5ef8bf2aa99df8aad7d52128507c82c3f67d6b4352d6b80a/vmlinuz-6.5.11-300.fc39.x86_64*
-rwxr-xr-x. 4 root root 2,2M 1. led 1970 /usr/lib64/libc.so.6*
...a to není všechno.
$master≫ cat hello.asm global start section .text start: mov rax, 0x02000004 mov rdi, 1 mov rsi, message mov rdx, 13 syscall mov rax, 0x02000001 xor rdi, rdi syscall section .data message: db "Hello, World", 10 $master≫ nasm -f macho64 hello.asm $master≫ ld -macosx_version_min 10.7.0 -o hello hello.o $master≫ ls -l -rwxr-xr-x 1 kapica staff 32904 Nov 17 21:18 hello -rw-r--r-- 1 kapica staff 290 Nov 17 21:16 hello.asm -rw-r--r-- 1 kapica staff 399 Nov 17 21:18 hello.o $master≫ ./hello Hello, World $master≫
Mara Bos co jsem koukala naposledy pracuje na lepším dynamickém linkování.
Tak to je dobrá zpráva.
těch situací kdy to je skutečně výhodné imho zas tak moc není
Výhodné z jakého důvodu? Ono nejde jen o velikost binárky, ale i o možnost napojení na jinou verzi/implementaci knihovny, ať už kvůli aktualizacím nebo hackování, zkoumání, co program dělá, nebo upravování jednotlivých funkcí přes LD_PRELOAD
.
Sice můžeš říct, že si můžu upravit zdrojáky a přeložit si celou aplikaci, ale někdy ty zdrojáky nejsou (nebo třeba nejsou v té konkrétní verzi) nebo to nechci dělat, protože to trvá dlouho, zabírá to místo a musím je stahovat a často to přináší další závislosti (které pro běh nejsou potřeba)… Takže možnost podstrčit jinou verzi knihoven je pro mě jednoznačně plus. Dynamické linkování beru jako výchozí normální stav – a až pokud je k tomu dobrý důvod, mám z toho konkrétní užitek, tak použiji statické linkování.
Pro mě by důvod byla hlavně možnost psát aplikaci umožňující dynamické pluginy.Ono to spolu souvisí. Knihovna je v principu totéž jako modul/plugin v modulárním systému. Např. v OSGi v Javě máš knihovny třetích stran i moduly vlastní aplikace na stejné úrovni, všechno to jsou tzv. bundly a se vším se pracuje stejným způsobem – máš tam deklarované závislosti na ostatních modulech/službách, deklarované služby, které poskytuješ ty, má to stejný diagram stavů, můžeš to dynamicky instalovat/odinstalovávat, zapínat/vypínat. A rozhodně to není výsada Javy nebo dynamičtějších jazyků. Hezký příklad, že psát modulárně jde i ve starém dobrém Céčku, je SQLite. Tohle je obecná teorie nezávislá na jazyku. Viz Niklaus Wirth a další práce na tohle téma. Mimochodem, dochází tu k podobnému omylu jako v případě desktopů / pracovních stanic. Někdy před 10+ lety vyšly statistiky o tom, že se prodává víc mobilů / tabletů než desktopů / notebooků / pracovních stanic. To si někteří vyložili tak, že se má vše optimalizovat pro mobily a dotykové ovládání… a následky této scestné úvahy sklízíme dodnes – spousta věcí na desktopu je rozvrtaná a polofunkční, nedotažená, i když třeba dřív fungovala. Navíc se to sešlo s dalším omylem a to, že „čím víc lidí se do vývoje softwaru zapojí, tím líp“. V praxi vídám, že je to přesně naopak – čím víc lidí se do projektu zapojí, tím hůř to dopadá. Týká se to jak uzavřených komerčních produktů, tak otevřených. Jsou tu samozřejmě světlé výjimky (např. když spousta lidí vyvíjí ovladače, každý pro něco jiného, a pak to dají na jednu hromadu – tohle škáluje celkem dobře). Dneska tu zase máme trend mikroslužeb a různých kontejnerů (dockerů, kubernetů atd.). A opět si to někteří vykládají tak, že je možné všechno zahodit a věnovat se čistě jen tomu trendu. Že je něco zrovna v kurzu, neznamená, že se může kašlat na vše ostatní – ty další případy užití nezmizely a stále je potřeba jim věnovat náležitou pozornost. Desktopy, pracovní stanice nebo trvale instalované systémy (ne jen jednorázově nakopírované binárky spuštěné v nějakém kontejneru) tu jsou pořád a je potřeba, aby fungovaly.
Osgi je zrovna priklad technologie kde inzinierske hladisko uplne odignorovalo bezne use cases a interoperabilitu s non osgi svetom.Ta interoperabilita je dnes už celkem dobrá, většina knihoven ty OSGi hlavičky už má nebo není problém si knihovnu do bundlu přebalit.
To co pises o loading/unloading za behu je nieco co v realite nechces.Kvůli tomu to právě děláš. Pokud ti stačí statické moduly, tak můžeš použít JPMS (relativně novinka) nebo odjakživa: nasypat správná JARka do class path (a použít třeba
ServiceLoader
nebo ani to ne).
Je užitečné mít možnost nasadit nový modul k těm stávajícím a ještě víc se hodí možnost upgradovat nějaký modul nebo ho restartovat s novou konfigrací. Dají se takhle hezky dělat upgrady bez výpadku – tohle používám s Camelem – ten pozdrží příchozí požadavky/zprávy (např. HTTP) a mezi tím se otočí modul obsahující implementaci služby. Klient žádný výpadek nepozoruje, neodmítne mu to spojení, nepřeruší ho to, všimne si maximálně delší odezvy (třeba vteřina nebo spíš méně).
masivny refresh bundlovModul by tohle měl v pohodě přežít. Rozhodně to není tak, že by Karaf (OSGi běhové prostředí) natvrdo sestřelil moduly v půlce práce. Např. ten Camel dokončí rozpracované úlohy a až pak se ten tvůj modul, kde ho používáš, otočí.
A potom pride faza 2 modlenie sa aby sa to dalo hore co neni az taka samozrejmost.Pokud ti dojde paměť, místo na disku nebo se při restartu načte nová konfigurace a do té doby to běželo se starou (to záleží na tobě, jestli ji načítáš automaticky nebo jen při re/startu), tak se to samozřejmě rozbít může, ale jinak by to fungovat mělo. Nicméně: taky jsem si s tím užil různá trápení za ty roky, co to používám – netvrdím, že je to bezchybná technologie… ale to není žádná. Ta myšlenka je ale jednoznačně správná – takhle mají systémy vypadat – a implementace je dostatečně dobrá na to, aby to šlo používat v praxi.
Dají se takhle hezky dělat upgrady bez výpadku – tohle používám s Camelem – ten pozdrží příchozí požadavky/zprávy (např. HTTP) a mezi tím se otočí modul obsahující implementaci služby. Klient žádný výpadek nepozoruje, neodmítne mu to spojení, nepřeruší ho to, všimne si maximálně delší odezvy (třeba vteřina nebo spíš méně).Ten kritizovaný kubernetes tohle udělá aniž by bylo potřeba tu službu psát v jazyce X s frameworkem Y (ano, vim že osgi implementací je několik, ale tím se to moc nemění) nebo vymýšlet nějaké rovnáky na ohejbáky zavádějící dynamické linkování všeho...
Tohle je obecná teorie nezávislá na jazyku.Ježišmarja, to je furt dokola... Ukaž technické řešení, jak se má dynamicky a bez degradace aktuální kvality (výkon, bezpečnost) linkovat Iterator nebo Stream nebo AsyncWrite. Inb4 "nevím, neznám technické detaily Rustu, to po mě nechtějte" - aha, a jak teda víš, že na jazyku nezáleží? Tvůj kód linkuje string nebo iostream nebo unordered_mapu dynamicky?
RUSTFLAGS='-C strip=symbols -C prefer-dynamic' cargo build --release
Což je blíž tomu jak kompiluje C.
nam tu z lispovskych jazyku zbylo, ma dnes vpodstate kazdy moderni jazyk (az na makra)Nemaji homoikonicitu, ktera prave umoznuje mit takovy efektivni makro system. Makra vam umoznuji transformovat jazyk jako takovy v mire co zadny jiny jazyk nezvlada, doslova vytvorit novy DSL.
common lisp urcite neni jednoduchy,Neni, common/ANSI lisp je stejny clusterfuck jako C++, pokusili se vyhovet vsem a do standardu integrovali pomalu i kuchynsky drez. Cetl jsem ANSI Common Lisp od Paul Graham, znam i C++ standard a vetsinu Stroustrupovych knih, C++ mi prijde jako vice nekonzistentni bazmek. Jadro lispovskych jazyku je jednoduche, implementace interpreteru byva(l) bezny semestralni ukol. Ostatne i vetsinu implementace standardu CL lze resit jako set maker nad relativne jednoduchym jadrem.
src/c
. Museli ho mit opravdu trivialni, nebot dispozici meli skutecne jen par kilobajtu. Je videt, ze kompilator vicemene pracoval na urovni rutin/funkci a ze to psali lide, kteri do nedavna psali v dominantne assembleru, treba:
jumpc(tree, lbl, cond) int tree[]; { extern jump, cctab[], rcexpr, isn, label, branch, cbranch; int l1, l2; if (tree==0) return; switch(*tree) { /* & */ case 47: if (cond) { cbranch(tree[3], l1=isn++, 0, 0); cbranch(tree[4], l1, 0, 0); jump(lbl); label(l1); } else { cbranch(tree[3], l1=isn++, 0, 0); cbranch(tree[4], l2=isn++, 1, 0); label(l1); jump(lbl); label(l2); } return; /* | */ case 48: if (cond) { cbranch(tree[3], l1=isn++, 1, 0); cbranch(tree[4], l2=isn++, 0, 0); label(l1); jump(lbl); label(l2); } else { cbranch(tree[3], l1=isn++, 1, 0); cbranch(tree[4], l1, 1, 0); jump(lbl); label(l1); } return; /* ! */ case 34: jumpc(tree[3], lbl, !cond); return; } rcexpr(tree, cctab, 0); branch(l1=isn++, *tree, cond); jump(lbl); label(l1); return; }