Google Chrome 144 byl prohlášen za stabilní. Nejnovější stabilní verze 144.0.7559.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 10 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře (YouTube).
Microsoft zveřejnil zdrojový kód XAML Studia a uvolnil ho pod MIT licencí. XAML Studio je nástroj ze světa Windows, určený pro tvorbu uživatelského rozhraní aplikací pomocí XAML (Extensible Application Markup Language). Stalo se tak zhruba po osmi letech od prvního prohlášení Microsoftu, že se tento kód chystá zveřejnit.
TimeCapsule, 'časová kapsle', je jazykový model trénovaný výhradně na datech z určitých míst a časových období, aby se tak napodobila autentická slovní zásoba, způsob vyjadřování a názory dané doby. Na Hugging face jsou k dispozici modely natrénované na historických textech dostupných v oblasti Londýna mezi lety 1800 až 1875.
Radicle byl vydán ve verzi 1.6.0 s kódovým jménem Amaryllis. Jedná se o distribuovanou alternativu k softwarům pro spolupráci jako např. GitLab.
Zemřel Scott Adams, tvůrce komiksových stripů Dilbert parodujících pracovní prostředí velké firmy.
Sdružení CZ.NIC vydalo novou verzi Knot Resolveru (6.1.0). Jedná se o první vydanou stabilní verzi 6, která je nyní oficiálně preferovanou a doporučovanou verzí, namísto předešlé verze 5. Více o Knot Resolveru 6 je možné se dočíst přímo v dokumentaci.
Byl vydán Linux Mint 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.
Wine bylo po roce vývoje od vydání verze 10.0 vydáno v nové stabilní verzi 11.0. Přehled novinek na GitLabu. Vypíchnuta je podpora NTSYNC a dokončení architektury WoW64.
Byl vydán Mozilla Firefox 147.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Firefox nově podporuje Freedesktop.org XDG Base Directory Specification. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 147 bude brzy k dispozici také na Flathubu a Snapcraftu.
Asociace repair.org udělila anticeny těm nejhorším produktům představeným na veletrhu CES 2026. Oceněnými jsou například šmírující kamery Amazon Ring AI, chytrý běžecký pás od společnosti Merach, která otevřeně přiznává, že nedokáže zabezpečit osobní data uživatelů, případně jednorázové lízátko, které rozvibrovává čelisti uživatele a tak přehrává hudbu. Absolutním vítězem je lednička od Samsungu, která zobrazuje reklamy a kterou lze otevřít pouze hlasovým příkazem přes cloudovou službu.
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: