Crown je multiplatformní open source herní engine. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT a GPLv3+. Byla vydána nová verze 0.60. Vyzkoušet lze online demo.
Daniel Stenberg na svém blogu informuje, že po strncpy() byla ze zdrojových kódů curlu odstraněna také všechna volání funkce strcpy(). Funkci strcpy() nahradili vlastní funkcí curlx_strcopy().
Byla vydána nová verze 25.12.30 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Shotcut je vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
Společnost Valve publikovala přehled To nej roku 2025 ve službě Steam aneb ohlédnutí za nejprodávanějšími, nejhranějšími a dalšími nej hrami roku 2025.
Byly publikovány výsledky průzkumu mezi uživateli Blenderu uskutečněného v říjnu a listopadu 2025. Zúčastnilo se více než 5000 uživatelů.
V dokumentově orientované databázi MongoDB byla nalezena a v upstreamu již opravena kritická bezpečností chyba CVE-2025-14847 aneb MongoBleed.
Při úklidu na Utažské univerzitě se ve skladovacích prostorách náhodou podařilo nalézt magnetickou pásku s kopií Unixu V4. Páska byla zaslána do počítačového muzea, kde se z pásky úspěšně podařilo extrahovat data a Unix spustit. Je to patrně jediný známý dochovaný exemplář tohoto 52 let starého Unixu, prvního vůbec programovaného v jazyce C.
FFmpeg nechal kvůli porušení autorských práv odstranit z GitHubu jeden z repozitářů patřících čínské technologické firmě Rockchip. Důvodem bylo porušení LGPL ze strany Rockchipu. Rockchip byl FFmpegem na porušování LGPL upozorněn již téměř před dvěma roky.
K dispozici je nový CLI nástroj witr sloužící k analýze běžících procesů. Název je zkratkou slov why-is-this-running, 'proč tohle běží'. Klade si za cíl v 'jediném, lidsky čitelném, výstupu vysvětlit odkud daný spuštěný proces pochází, jak byl spuštěn a jaký řetězec systémů je zodpovědný za to, že tento proces právě teď běží'. Witr je napsán v jazyce Go.
Yazi je správce souborů běžící v terminálu. Napsán je v programovacím jazyce Rust. Podporuje asynchronní I/O operace. Vydán byl v nové verzi 25.12.29. Instalovat jej lze také ze Snapcraftu.
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: