Všem čtenářkám a čtenářům AbcLinuxu krásné Vánoce.
Byla vydána nová verze 7.0 linuxové distribuce Parrot OS (Wikipedie). S kódovým názvem Echo. Jedná se o linuxovou distribuci založenou na Debianu a zaměřenou na penetrační testování, digitální forenzní analýzu, reverzní inženýrství, hacking, anonymitu nebo kryptografii. Přehled novinek v příspěvku na blogu.
Vývojáři postmarketOS vydali verzi 25.12 tohoto před osmi lety představeného operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME Shell on Mobile, KDE Plasma Mobile, Phosh a Sxmo.
Byla vydána nová verze 0.41.0 multimediálního přehrávače mpv (Wikipedie) vycházejícího z přehrávačů MPlayer a mplayer2. Přehled novinek, změn a oprav na GitHubu. Požadován je FFmpeg 6.1 nebo novější a také libplacebo 6.338.2 nebo novější.
Byla vydána nová verze 5.5 (novinky) skriptovacího jazyka Lua (Wikipedie). Po pěti a půl letech od vydání verze 5.4.
Byla vydána nová verze 5.4.0 programu na úpravu digitálních fotografií darktable (Wikipedie). Z novinek lze vypíchnout vylepšenou podporu Waylandu. Nejnovější darktable by měl na Waylandu fungovat stejně dobře jako na X11.
Byla vydána beta verze Linux Mintu 22.3 s kódovým jménem Zena. Podrobnosti v přehledu novinek a poznámkách k vydání. Vypíchnout lze, že nástroj Systémová hlášení (System Reports) získal mnoho nových funkcí a byl přejmenován na Informace o systému (System Information). Linux Mint 22.3 bude podporován do roku 2029.
GNU Project Debugger aneb GDB byl vydán ve verzi 17.1. Podrobný přehled novinek v souboru NEWS.
Josef Průša oznámil zveřejnění kompletních CAD souborů rámů tiskáren Prusa CORE One a CORE One L. Nejsou vydány pod obecnou veřejnou licenci GNU ani Creative Commons ale pod novou licencí OCL neboli Open Community License. Ta nepovoluje prodávat kompletní tiskárny či remixy založené na těchto zdrojích.
Nový CEO Mozilla Corporation Anthony Enzor-DeMeo tento týden prohlásil, že by se Firefox měl vyvinout v moderní AI prohlížeč. Po bouřlivých diskusích na redditu ujistil, že v nastavení Firefoxu bude existovat volba pro zakázání všech AI funkcí.
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: