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.
Ahoj, rad bych si udelal aplikaci s RPi, kteremu bych daval povely pres svuj web/server (mam i Linux server s verejnou IP). Premyslim ale nad tim, jak to udelat, aby to fungovalo pokud mozno vsude.
1) Nabizi se moznost, udelat z RPi webovy server a pripojovat se primo na nej, ale to bych pak nemel dostupne vsude. Vyhodou je, ze to pojede i bez pristupu na net, v lokalni siti, ale to je tak vsechno. Proto bych radeji, aby RPi pristupovalo na muj server a prebiralo povely z nej. Ja bych se pripojoval taky k serveru a zadaval povely - treba pres PC / NB / mobil.
Prvni reseni je, prinutit RPi, aby periodicky delalo GET na http://server.cz/?dotaz=comamdelat . No a na serveru by behal PHP script, ktery by odpovidal a odpoved by RPi zpracovalo a provedlo prikaz. Je to dobre reseni? Jde o to, ze RPi bude muset neustale provadet dotazy.
Druha moznost - Da se nejak navazat trvale spojeni na urcitem portu mezi RPi a serverem, tak, abych mohl ze serveru rict Pi - hele, udelej tohle, nebo tamto? Hadam, ze bych zase musel posilat nejake keepalive pakety? Za jak dlouho se vlastne navazane spojeni samo prerusi? A da se takhle komunikovat treba pres 80tku port? Byl bych rad, aby to slo protlacit i pres firewall a fungovalo na neverejne IP adrese (Rpi).
RESUME : Vyhodou prvniho reseni pro mne je, ze trochu umim PHP, takze serverovou cast bych si zvladl udelat. Ve druhem pripade by asi na serveru musel bezet nejaky daemon, ktery by komunikoval s netem - asi v Ccku, nebo pythonu, je to tak?
Doporucte mi, jak nejlepe to vyresit, aby to zralo co nejmene dat, bylo co nejrychlejsi a zaroven nebyly problemy s NATem, firewallem, atd.
ps axu | grep -q [u]ser@server || ssh -p 22 user@server -N -R 0.0.0.0:1234:localhost:22v sshd musí být
GatewayPorts clientspecified
.
Aha a kdybych to chtel postavit nad prostym TCP/IP? Ten websocket prostuduju, ten ssh tunel je trochu orisek, protoze pokud bych to pak chtel zjednodusit a portovat treba na arduino / jiny jednocip, kvuli cene, hodilo by se ,aby ten protokol byl co nejjednodussi.
Pro arduino je treba GET / POST komunikace uz hotova. navic, nebude ten SSH tunel nachylny na rozpojeni pri vypadcich site?
Premyslim nad tim a defakto by mi stacilo neco, jako je PUSH technologie u emailu, apod. Aby bylo navazene spojeni a ten server dokazal do toho Arduina, nebo RPi "stouchnout" hele, mam pro tebe data, stahni si je.
Abych nemusel proste periodicky delat GETy a volit mezi rychlosti odezvy / mnozstvim zbytecne prenesenych dat. I kdyz v souctu tech dat moc nebude, pokud bych jen posilal - neco noveho? a server odpovidal - NE. Ale jde o to, ze to bude neustale "PINGat" a zatezovat tu sit.
Jsem spis pres HW, tzn. ze otevrene tcp spojeni se chova defakto jako takovy UART? Jak potom na serveru? Muzu na jednom portu obslouzit vice takovych zarizeni? Nebo musi mit kazde svuj port?
Asi bych si mel nastudovat princip TCP, najdu tam vsechno potrebne, ze ? a na serveru se to potom resi a obsluhuje jak / cim? S phpckem si asi v tomhle pripade nevrznu, cili nejblizsi mi je asi python.
diky tedy aspon za nasmerovani, jde mi o to, vedet, co mam nastudovat, jake reseni bude pro tuhle vec nejlepsi. Zatim jsem vzdy komunikoval ve stylu GET/POST dotaz a odpoved. Ale ted bych potreboval, aby to bylo vice "realtime" a pritom se mi z toho nezblaznil router
Tiskni Sdílej: