Na blogu Raspberry Pi byla představena rozšiřující deska Raspberry Pi AI HAT+ 2 s akcelerátorem Hailo-10 a 8 GB RAM. Na rozdíl od předchozí Raspberry Pi AI HAT+ podporuje generativní AI. Cena desky je 130 dolarů.
Wikipedie slaví 25. výročí svého založení. Vznikla 15. ledna 2001 jako doplňkový projekt k dnes již neexistující encyklopedii Nupedia. Doména wikipedia.org byla zaregistrována 12. ledna 2001. Zítra proběhne v Praze Večer svobodné kultury, který pořádá spolek Wikimedia ČR.
Po více než dvou letech od vydání předchozí verze 2.12 byla vydána nová stabilní verze 2.14 systémového zavaděče GNU GRUB (GRand Unified Bootloader, Wikipedie). Přehled novinek v souboru NEWS a v aktualizované dokumentaci.
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.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
ssh -N -R 22222:localhost:22 server
("server" má v .ssh/config adresu, port a uživatele). S připojením není problém, to by mělo být všude stabilní. Tunel vždy chvíli funguje, ale po zhruba deseti minutách přestane odpovídat. Po jeho zrušení a opětovném zadání příkazu výše:
Error: remote port forwarding failed for listen port 22222
Podle návodů na internetu funguje na opravení, když na serveru zabiju proces, který tento port používal (nestat -> kill). Ale to je velmi nepraktické a v praxi nepoužitelné. Záhadou mně je, že toto spojení nefunguje, ale stejný tunel (samozřejmě s rozdílným portem) přes stejný server z jiného stroje (na jiné lokaci) bez komplikací funguje. Nedokázali byste poradit, jak se této blokace portu zbavit?
-f (background fork) -T (nealokuje pseudo tty) [-C (komprese..) optional]Zadruhe, spojeni pravdepodovne vyhori na timeout, necinnost Duvod muze byt rozdilna konfigurace klienta, ale port na serveru zustane "bimdnuty". To muzes overit debugovanim.
-v (-vv -vvv)Zatreti, resenim by mohlo byt upravit konfiguraci. Naprikl ad. Pridat do .ssh/config(klient):
ServerAliveInterval 300 (5minut) (ServerAliveCountMax 3) (3 pokusy)Nebo parametry konfiguracnich souboru(server):
TCPKeepAlive yes ClientAliveInterval 300 ClientAliveCountMax 3No a konecne autossh varianta(nepouzivam..):
autossh -M 20000 -f -N server -R 22222:localhost:22 -C
Možná je lepší položit otázku abstraktněji, tedy jak dosáhnout určitého cíle. Cílem je zjevně dostat se zvenčí na nějaký stroj ve vnitřní síti, na který se z nějakého důvodu nedá zvenku routovat. Měl bych jisté tušení, jaký důvod to asi bude. Takže: Není náhodou řešením IPv6?
Před deseti lety, když ještě IPv6 nebyl všude běžně dostupný, jsem taky provozoval pár (desítek) takových SSH tunelů, aby stroje za NATem (tedy za morem a neštovicemi v jednom) mohly být dostupné skrz tohle SSH over SSH. Vždycky to stálo za hovno. Někdy tunely vydržely den, někdy hodinu. Někdy se samy obnovovaly, někdy ne. Někde někdo změnil nastavení firewallu a najednou TCP spojení automaticky vypršela po 10 minutách, pokud nebyla opravdu hodně aktivní, tedy TCP keepalive k udržení spojení nestačil. (!) Důvodem prý bylo, aby na nějakém NAT routeru nedocházely porty, když spousta spojení od strojů z vnitřní sítě zůstane viset. Tak se prostě méně aktivní nebo neaktivní spojení zabila, zkrátka ve prospěch těch, která (zdánlivě) něco dělají. Tohle byl vždycky zoufalý a předem prohraný boj. Internet, ve kterém se nedá routovat z kteréhokoliv stroje na kterýkoliv jiný, prostě není Internet, je to něco polovičatého a na houby. Do prvních videokonferenčních aplikací se v roce 2002 prostě zadala IP adresa protistrany a všechno fungovalo. NAT ale postupně způsobil, že tak běžná a samozřejmá věc jako komunikace mezi libovolnými dvěma počítači prostě fungovat přestala. Místo relativně bezpečných přímých spojení, u kterých se dá dohodnout bezpečné šifrování, zvítězily prasárny typu Skype, kde end to end šifrování není a kde je to s bezpečností opravdu zlé. Zkrátka a dobře, snaha o spolehlivě fungující permanetní SSH tunely je podle mě předem prohraná bitva, zatímco IPv6 je v každém ohledu výhra.
No ale mně IPSec road warrioři (StrongSwan) taky občas selhávají na některých divně nakonfigurovaných sítích, kde NAT záměrně nectí TCP spojení ani UDP „mapování“. Sice ne napořád, obnovují se mnohem spolehlivěji než u toho SSH, ale u některých spojení i výpadek v řádu několika desítek sekund docela dost vadí. NAT router, který si nakonfiguruju sám, takové divné věci nedělá, ale různé polorozbité sítě vidím všude možně. Internet s NATem zkrátka není Internet.
VPN (například IPSec) má přesto jednu zásadní výhodu: Road warrior může mít stálou veřejnou IP adresu (IPv6, samozřejmě). Funguje tam IPv6 přes IPv4 (i všechny 3 ostatní kombinace) a na toho road warriora se pak dá připojovat zvenčí na standardní port 22 (pokud příslušný VPN/IPSec server správně routuje), bez speciálních portů a jiných nepravidelností.
Mně se JuiceSSH z Androidu připojuje všude přes IPv6, kdykoliv vidí AAAA záznam… Zrovna s Androidem rozhodně problém nebude. Pokud poskytovatel neumí IPv6, je to samozřejmě horší problém. Není ale důvod používat SixXS, když je ke každé veřejné IPv4 adrese automaticky k dispozici 6to4 s 2^80 IPv6 adres. Zejména od doby, co nic.cz před cca 5 lety začal provozovat vlastní server s magickou adresou 192.88.99.1 (což je adresa, která má podle konvence vést k nejbližší 6to4 bráně), je i rychlost a stabilita bez nejmenších problémů. Jenom musí mít člověk na routeru alespoň tu jednu veřejnou IPv4 adresu, jinak už nepomůže nic. 
Tiskni
Sdílej:
