Počítačová hra Factorio (Wikipedie) nově běží nativně na ARM64 Linuxu a headsetu Steam Frame.
Fugleramme, v překladu 'ptačí rámeček', je open-source projekt postavený na Raspberry Pi, který pomocí lokální umělé inteligence BirdNET-Go rozpoznává ptačí druhy podle jejich zpěvu a na displeji následně zobrazuje koláž tvořenou odpovídajícími ilustracemi. Databáze obsahuje přes 800 ručně vybraných historických přírodovědných ilustrací více než 400 druhů ptáků.
… více »Unicode Consortium, nezisková organizace koordinující rozvoj standardu Unicode, oznámila vydání Unicode 18.0. Přidáno bylo 13 007 nových znaků. Celkově jich je 172 808. Přibylo 9 nových Emoji.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 169 (pdf).
Byla vydána nová verze 6.4 programovacího jazyka Swift (Wikipedie). Zdrojové kódy jsou k dispozici na GitHubu.
Německý kancléř Friedrich Merz (CDU) se během debaty s finalisty studentské vědecké soutěže Jugend forscht vyjádřil pro konec anonymity na internetu a vyslovil názor, že pro uživatele Internetu by měla platit podobná právní odpovědnost jako pro novináře tradičních médií. Na dotaz studenta, jak by se tedy povinnost uvádět pravé jméno slučovala s prací investigativních novinářů nebo ochranou jejich zdrojů, Merz neodpověděl, ve své
… více »Společnost Fujitsu představila FUJITSU-MONAKA CPU a Fujitsu MONAKA Server. Navrženo, vyvinuto a vyrobeno v Japonsku. Pro suverénní AI infrastrukturu.
Předprodej v květnu představených notebooků Googlebook, nástupců notebooků Chromebook, bude spuštěn v pondělí 21. září.
Byla vydána betaverze Fedora Linuxu 45 (ChangeSet), tj. poslední zastávka před vydáním finální verze, která je naplánována na úterý 20. října. S konzolí kmscon místo fbcon. Současně byla vydána betaverze Fedora Linux Asahi Remixu 45. S podporou čipů M3.
Po půl roce vývoje od vydání verze 50 bylo vydáno GNOME 51 s kódovým názvem "A Coruña" (Mastodon). Podrobný přehled novinek i s náhledy v poznámkách k vydání a v novinkách pro vývojáře. Videopředstavení na PeerTube a YouTube.
Osobne misto RealVNC pouzivam TightVNC, obsahuje totiz kodovani tight, nastaveni jpg kvality obrazu a kompresniho stupne.Souhlasím, že je RealVNC (alespoň v základní variantě) nejpomalejší, ale v době psaní článku jsem jiné servery nezkoušel. Ale používám jej pořád, protože se mi nechce vrtat do něčeho, co už jsem rozjel
K tomu tunelovani bych se take spis primlouval k stunnelu, zvlaste kdyz by uzivatel nemel mit pristup na shell, navic pres stunnel jde autentizovat pomoci certifikatu, takze i autentizace muze byt bezpecna ...Používám ssh klíče, takže by to mělo být také bezpečné. Je pravda, že jsem se mohl aspoň odkázat na článek o tunelování na root.cz, kde se probírají i jiné možnosti (se kterými nemám osobně zkušenosti). Díky za komentář, mám pocit, že vydal za celý článek
Souhlasím, že je RealVNC (alespoň v základní variantě) nejpomalejší, ale v době psaní článku jsem jiné servery nezkoušel. Ale používám jej pořád, protože se mi nechce vrtat do něčeho, co už jsem rozjelRekl bych, ze i v realvnc jsou prikazy vncserver a Xvnc a parametry budou stejne jako v tightvnc, takze neni ceho se bat.
Používám ssh klíče, takže by to mělo být také bezpečné. Je pravda, že jsem se mohl aspoň odkázat na článek o tunelování na root.cz, kde se probírají i jiné možnosti (se kterými nemám osobně zkušenosti).Jojo, urcite pres SSH je to stejne bezpecne jako pres stunnel, akorat vyhoda stunnelu je, ze se nemusi vytvaret shell ucty a navic, co me posledni dobou trapilo pri ssh tunelovani, ze jsem na ssh serveru musel spustit nejaky program, aby se spojeni neuzavrelo a tunel zustal. Tak jsem vymyslel ruzne sleepy a podobne, ale bylo to blby, protoze obcas se stalo, ze spojeni sice spadlo, ale protoze na tunel byly pripojene nejake aplikace, tak se ssh spojeni uplne neuzavrelo, takze ssh poslouchalo na portu, ale uz nedokazalo s cilovym serverem komunikovat. Dokud to ssh neskoncilo, tak se samozrejme nenahodilo nove. A i kdyby se nove nahodilo, tak nemohlo poslouchat na tom portu, protoze se tam drzelo to stare ssh. Navic pak jeste kdyz to ssh treba i kompletne spadlo a zacalo se nahazovat nove, tak se obcas stalo, ze na ssh serveru zustal bezet ten udrzovaci proces, takze jsem musel resit jeste zabijeni tech starych procesu. Samozrjeme klic byl bez hesla, coz byla taky dira, ale na ssh serveru jsem mel v authorized_key omezeni pro ten klic na jeden prikaz (ten udrzovac spojeni). Proste nebylo to ono. Takze jsem presel na stunnel - je to jednoduche na konfiguraci a pritom dostatecne bezpecne (vyzadovani certifikatu podepsanych od vybrace CA). Takze ted je to dobry.
Pokud by chtel nekdo v Linuxu, aby se pomoci VNCview pripojil k te session, kterou ma na lokalnim monitoru, lze pouzit x11vnc, ktery vytvori virtualni VNCserver s obsahem, ktery se zobrazuje na lokalnim monitoru. Tzn. chovani bude pak naprosto stejne jako v pripade Windows.Případně přímo v Gnome je vino: Systém -> Nastavení -> Vzdálená pracovní plocha, nebo
vino-preferences (alespoň na FC6 to tak je).
Ma predstava je takovato: * PC1 bezi na windows * PC2 bezi na linuxu * PC3 bezi na windows nebo linuxu Encodovani: * PC2 se pripoji pre vncviewer na PC1 * na PC1 se encoduje deni ve vncvieweru * encodovane video se posila do site * PC2 je dost vykonny na on-line encodovani Prohlizeni: * na PC3 pustim VLC a koukam na videoTakze se mi jedna o cteni dat z vncviewer (asi vncrec?) a nasledne prekonvertovani do MPEG streamu (asi transcode s podporou vnc?) a naslednou distrubuci videa do site.
Jediná nevýhoda použití ssh je, že protokol pracuje na aplikační úrovni; to znamená, že to není zcela transparentní, ale je nutné změnit číslo portu.
ssh -L 5901:localhost:5900 user@server.domena
SSH tunel není transparentní? A co brání při tunelování použití zcela transparentního
ssh -L 5901:localhost:5901 user@server.domena
?
Já to tak alespoň používám (linux), měnit port mě ještě nenapadlo. To je nějaká vlastnost Windows? Obecně je komunikace je vedená na lokální 5901 posílána na vzdálený ssh port a tam z localhostu na 5901 vzdáleného stroje, takže nevidím problém, asi není dobré to prezentovat jako vlastnost ssh, když je patrně jen řešen nějaký nesoulad v konkrétním nastavení služeb (patrně na woknech běžící vnc:5900 na nějž se chceme z nejasných příčin připojovat podobně jako na linux vnc:5901, ale to jen hádám).
Při používání Putty mě pouze vypeklo to, že je v definici tunelu nutné místo localhost zadat IP adresu 127.0.0.1
V jakém případě je nutno někam do putty.exe zadávat 127.0.0.1? Pokud se připojuji z Woken používám
Connection -> SSH -> Tunnels ->"
Source port: 5901
Destination: server.domena:5901
V jakém případě je nějak potřeba psát 127.0.0.1?
A.
localhost nevytvořil.
-L -R, Putty na to má volby Local, Remote při v sekci Tunnels - viz obrázek
Ale latenci neodstraním. NX je oproti tomu někde úplně jinde.
Tiskni
Sdílej: