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.
Bylo vydáno Eclipse IDE 2026-06 aneb Eclipse 4.40. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Asterinas (GitHub) je v Rustu napsané jádro operačního systému poskytující s jádrem Linux kompatibilní ABI. Vydána byla verze 0.18.0. První distribucí postavenou nad jádrem Asterinas je Asterinas NixOS. Nejedná se o oficiální projekt NixOS a nemá nic společného s NixOS Foundation.
Podrobně byla rozebrána kritická zranitelnost v nf_tables (CVE-2026-23111). Další lokální eskalace práv na Linuxu. V upstreamu byla zranitelnost již v únoru opravena. Ve zdrojovém kódu stačilo odstranit 1 vykřičník.
Evropská komise (EK) nařídila americké společnosti Meta, že musí znovu umožnit bezplatný přístup konkurenčním obecně zaměřeným asistentům umělé inteligence (AI) k WhatsAppu a tento přístup musí zachovat až do ukončení antimonopolního šetření. Opatření je dočasné a má zabránit vážnému a nevratnému poškození konkurence na rychle rostoucím trhu s obecnými AI asistenty. Meta uvedla, že se proti rozhodnutí odvolá.
Společnost Anthropic představila AI modely Claude Fable 5 a Claude Mythos 5. Claude Fable 5 je první model třídy Mythos určený pro běžné použití.
Byla vydána nová stabilní verze 3.24.0, tj. první z nové řady 3.24, minimalistické linuxové distribuce zaměřené na bezpečnost Alpine Linux (Wikipedie) postavené na standardní knihovně jazyka C musl libc a BusyBoxu. Přehled novinek v poznámkách k vydání.
Na čem pracují vývojáři v Rustu napsaného mikrokernelového unixového operačního systému Redox OS (Wikipedie)? Byl publikován přehled vývoje za květen. Vypíchnout lze nový scheduler EEVDF nebo port desktopového prostředí Xfce na Redox OS.
Upozornění pro uživatele Asahi Linuxu: Neaktualizujte macOS na verzi 27 Golden Gate! Apple změnil detekci spouštěcích oddílů. Po aktualizaci oddíl s Asahi Linuxem nevidí. Snad je to jenom chyba.
Jinak k tematu, psat na javovsky porgramy shellscripty neni zrovna vhodny, konkretne pro javu pouzivam anti build.xml, kterej funguje vyborne a staci mu dat ant run (pripadne jinak nadefinovany prikaz pro spusteni) a jede, ale samozrejme se k tomu da pouzit i klasicky makefile.To jako ze kdyz si chci spustit vas program, musim si krome JRE a programu nainstalovat jeste ant nebo make? No mozna to nebylo zas tak "predpojaty"
) v me distribuci a vytvorit z vasich uzasnych otevrenych zdrojaku a make-filu a ant-fajlu onen spousteci skript, kteremu se tak vehementne branite... A troufnu si odhadnout, ze nebudu sam
< target name="run" depends="dist">to rika vse samo a dat to do shellscriptu je otazka deseti sekund.
< java classname="cz.ive.IveExecutor" fork="true">
< classpath>
< pathelement location="${dist}/demoworld.jar"/>
< pathelement location="../ive_core/dist/ive_core.jar"/>
< /classpath>
< arg line="-w resources/cz/ive/resources/DemoWorld.xml"/>
< /java>
< /target>
no to se mi zda trochu predpojatyNie je, to je štatistika ... (ano, Churchill)
Jinak k tematu, psat na javovsky porgramy shellscripty neni zrovna vhodny, konkretne pro javu pouzivam anti build.xml,
head -1 ant #! /bin/sh wc -l ant 326 anthmm, používa ant a pritom "neni zrovna vhodny"
Nie je, to je štatistika ... (ano, Churchill)Neverim ziadnej statistike, ktoru si sam nesfalsujem ... (ano, tiez Churchill ;)
Mel jsem jeden program s veleslozitym skriptem na spusteni. V tom skriptu byly veci patrici do konfiguracniho souboru, tolik promennych tam bylo, fuj. Musel jsem upravit CONFIG.SYS, aby se vsechny vesly (Win98, blahe pameti)
. Ale takovych programu je nastesti mensina.
Java jim paradoxne umoznila tvorit programy ktery pobezej i na unixech, a pritom muzou zustat ve windows, cimz je nenuti se neco o unixu naucit.
Ja si myslim, ze obecne Java svym "vstricnym" api nenuti programatora poznat OS, tak jako napr. u C++. Nemuzu napsat, ze je to nevyhoda. Zalezi na kriteriich, na vahach ktere k nim priradime. Ale je to tak. Slovo paradoxne jsi zvolil dobre.jar, který má ve svém manifestu uvedenu jak classpath tak spustitelnou třídu, a případné parametry programu načítejte ze souboru properties, jehož umístění dovolte změnit přes systémovou vlastnost. Takže pak na všech platformách, kde je JVM, půjde program spustit prostým
java -Dconfiguration=config.properties -jar aplikace.jarZvláštní je, že většina startovacích skriptů po různé magii nakonec skončí stejně tím, že spustí právě
java -jar apliakce.jar, případně předá ještě nějaké parametry. Takže člověk může na startovací skript klidně zapomenout a pouštět program klasicky. Co někoho vede k složitému tvoření takového složitého skriptu, to je mi záhadou.
./startup.sh), odmění se vám tvrzením, že ólredy ranink
#!/usr/bin/java\n
intepreter script. Nič iné to totiž nie je, len súbor inštrukcií pre interpreter.
java -Dx=y -Da=b-jar aplikace.jarAž to budu psát do příkazové řádky po desáté, naštvu se, a dvouřádkový skript si na to napíšu sám. Skript distribuovaný autorem tomuhle nepomůže – ten zná zase pouze defaultní parametry. Ty spouštěcí skripty navíc často dělají to, že zjišťují, kde je umístěna Java, různě se to pokouší uhodnout a testují výsledek atd. Přitom je obecně uznávanou dohodou nastavovat tohle do proměnné prostředí
JAVA_HOME – a není nic snazšího než tuto proměnnou v Java aplikaci otestovat a pokud neexistuje, oznámit chybu. Druhá možnost je nastavení různých vlastností přímo JVM (např. velikost použitelné paměti), jenže to je zase otázka jednořádkového skriptu, ještě lépe větičky v dokumentaci.
Takže ony spouštěcí skripty jsou v drtivé případě případů zbytečné, často špatně napsané a psát je je spíš takový folklór pocházející z doby, kdy spousta lidí zřejmě měla nainstalovánu Javu ale neměla jí v $PATH, takže prosté java -jar aplikace.jar nefungovalo. Snad jediná Java aplikace, se kterou jsem se setkal, kde má spouštěcí "skript" opodstatnění, je eclipse. A to má stejně vazby přímo na operační systém (SWT) s "startovací skript" je realizován přímo jako binárka pro daný systém. Navíc konfigurační parametry si zase čte ze souboru, není potřeba psát kilometrovou příkazovou řádku.
Je to tedy problém těch, co ty zbytečné skripty píšou.
java -jar aplikace.jar, keď môžete mať multiplatformný Bourne shell skript s názvom aplikace?
(nevraviac o tom, že .jar je vlastne len knižnica ...)# ls -ldtr * java \ -Dgnu.utils.ls.format=long \ -Dgnu.utils.ls.expandDirectory=false \ -Dgnu.utils.ls.orderBy=time \ -Dgnu.utils.ls.reverseOrder=true \ -jar /bin/ls.jar(a to som ešte optimista, že používam aj vymenované hodnoty). Ako vravíte, o tomto sa v príručkách javy bohužiaľ nepíše.
.
-Dněco=něco) se v C aplikacích nebo skriptech zpravidla řeší proměnnými prostředí a konfiguračními soubory. Takže třeba když Portage má konfiguraci v /etc/make.conf a pokud jí chcete při jednom spuštění upravit, můžete použít
USE="-kde" emerge -a cosiv Javě by se spíš použilo
java -Duse=-kde -jar emerge.jar -a cosiMůžete použít i proměnnou prostředí, jenže jsou operační systémy, kde nastavit proměnnou prostředí jen pro právě spouštěný příkaz nejde. Java zavedla systémové vlastnosti jako alternativu pro proměnné prostředí, která se bude chovat na všech platformách stejně. Použití systémových vlastností nebo proměnných prostředí místo parametrů programu je opravdu řídké (teď si nevzpomenu na žádný program, který by tohle dělal – příklad uvedený výše v diskuzi je možná první takové použití systémových vlastností, které jsem někde zaznamenal) a Java v tom není žádnou výjimkou. Takže popsaný nešvar vznikl v této diskuzi, s reálným světem nemá nic společného.
GNU_UTILS_LS_FORMAT="long" \ GNU_UTILS_LS_EXPAND_DIRECTORY="false" \ GNU_UTILS_LS_ORDER_BY="time"\ GNU_UTILS_LS_REVERSE_ORDER="true \ ls *
main. A přesně to i odpovídá způsobům použití – systémové vlastnosti nebo proměnné prostředí používám k celkovému nastavení chování programu při každém běhu – kde má logovací soubor (to potřebuje vědět každá část programu), jaké má používat parametry TCP/IP spojení (proxy server, timeouty) atd. Naproti tomu parametry příkazového řádku určují co má teď program dělat – a to nemusí vědět každá část programu, naopak při startu je potřeba podle těchto parametrů rozhodnout, co a jak dál.
Představte si to na analogii s GUI – Soubor – Otevřít nebo Soubor – Tisk odpovídá program --open nebo program --print. Změna konfiguračních voleb v Nástroje – Možnosti apod. odpovídá změnám v proměnných prostředí nebo systémových proměnných.
main. IMHO to, že sú prístupné odvšadiaľ znižuje znovupoužiteľnosť kódu (v jednej aplikácii i vo viacerých aplikáciach zároveň). Na druhej strane, ak sa o prístup stará interpreter, nemusí to vedieť naprogramovať programátor, a teda stačí zamestnať "lacných" drevorubačov.
Taky zapomínáte na to, že proměnné prostředí i systémové vlastnosti jde měnit i za běhu aplikace. Uvědomte si, co se systémovými vlastnostmi zpravidla nastavuje: defaultní locale, třída implementace SAX parseru, třída implementace XSLT transformeru atd. Nechtěl bych být nucen na začátku běhu programu si odchytit nastavené locale a pak jej propagovat do všech tříd aplikace…
Výraz lety ověřená praxe znamená dlhotrvajúca chyba ?
Podľa mňa by prístup k nastaveniu systému mali mať len privilegované entity. Inak to celé dopadne ako registry.
je to taký jazyk pre managerov. dobrý na výuku, slabý pre prax.
Tiskni
Sdílej: