Byla vydána beta verze Ubuntu 25.04 s kódovým názvem Plucky Puffin. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 25.04 mělo vyjít 17. dubna 2025.
Textový editor Neovim byl vydán ve verzi 0.11 (𝕏). Přehled novinek v příspěvku na blogu a poznámkách k vydání.
Živé ISO obrazy Debianu Bookworm jsou 100 % reprodukovatelné.
Boudhayan "bbhtt" Bhattcharya v článku Uzavření kapitoly o OpenH264 vysvětluje, proč bylo OpenH264 odstraněno z Freedesktop SDK.
Představeny byly nové verze AI modelů: DeepSeek V3-0324, Google Gemini 2.5 a OpenAI 4o Image Generation.
XZ Utils (Wikipedie) byly vydány ve verzi 5.8.0. Jedná se o první větší vydání od backdooru v XZ v loňském roce.
Byla vydána nová verze 0.40.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 2.20 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
LibrePCB, tj. svobodný multiplatformní softwarový nástroj pro návrh desek plošných spojů (PCB), byl vydán ve verzi 1.3.0. Přehled novinek v příspěvku na blogu a v aktualizované dokumentaci. Vypíchnut je interaktivní HTML BOM (Bill of Materials) a počáteční podpora Rustu. Zdrojové kódy LibrePCB jsou k dispozici na GitHubu pod licencí GPLv3.
Minulý měsíc Hector "marcan" Martin skončil jako upstream vývojář linuxového jádra i jako vedoucí projektu Asahi Linux. Vývoj Asahi Linuxu, tj. Linuxu pro Apple Silicon, ale pokračuje dál. Byl publikován březnový přehled dění a novinek z vývoje. Vývojáře lze podpořit na Open Collective.
V minulém blogu jsem psala o vrácení do života postaršího pc, který zahálel v koutě. Pokud tedy vlastníte stejně jako já více počítačů, určitě jste někdy přemýšleli nad tím, jak tyto stroje efektivně spravovat a pracovat na nich. V případě dvou počítačů si můžete buď pořídit dva monitory, dvě klávesnice, dvě myši a pracovat na dvou oddělených stanicích, anebo zkusit vzdálenou správu nebo přímo plochu.
ssh uživatelské_jméno@jméno_počítače nebo IP adresa
např.
ssh richmond@192.168.1.20
Pokud chcete spouštět grafické aplikace za pomocí X11 forwarding, použijte přepínač -X:
ssh -X richmond@192.168.1.20
A pokud chcete spustit grafickou aplikaci, která by se objevila na vzdáleném stroji, použijte pro její spouštění DISPLAY=:0.0 (nebo DISPLAY=:0.1 apod. Záleží na nastavení)
DISPLAY=:0.0 gedit
Tiskni
Sdílej:
X :1 -query 192.168.1.20
XDMCP není vůbec špatná věc... (a tuším že přes to chodí opengl akcelerovaně)...Hmm, to by me velice zajimalo jak, kdyz graficky vykon je zavisly na komunikaci CPU-GPU. Ne nadarmo ted vymejslej takovy veci jako PCIe x16. Dejte si misto PCIe 100Mbit (nebo i 1Gbit) ethernet s latencema oproti PCIe jako krava a dejte vedet jak na tom pobezi OpenGL. Zdenek
XDMCP není vůbec špatná věc...Ze všech výše jmenovaných bych dokonce řekl, že i nejlepší(až na to že se okna přenášejí jako XPM a né jako JPEG) a u Linuxu téměř nejjednodušší . Jen je nepěkné, že se i WindowManager spouští vzdáleně. Osobně to dělám, tak že si jako WM spustím lokálně Beryl nebo Compiz(není nutné pořád táhat po síti pixmapy při každém zakrytí okna) a přepošlu si pouze do již používaného X-Serveru kicker nebo gnome-panel, který umístím nahoru nebo na bok.
a tuším že přes to chodí opengl akcelerovaněAno, to sice chodí, ale i u blbého glxgears se FastEthernetová síť docela zapotí a plynulost…
Téže není nutné. [xkg]dm má na to tlačítko Vzdálené přihlášení přes XDMCP a ve Windows lze použít Xming.X :1 -query 192.168.1.20
až na to že se okna přenášejí jako XPM a né jako JPEG
To je hodně nepřesné. XDMCP je jen protokol pro komunikaci mezi dvěma displaymanagery, který vám umožní vzdálené přihlášení. Vlastní komunikace aplikace s X serverem probíhá naprosto stejně, jako když ji spustíte normálně a nastavíte proměnnou DISPLAY
na váš X server. Takže se přenášejí jednotlivá grafická primitiva. Mimochodem, pokud si zrovna neprohlížíte fotky, používat JPEG kompresi pro bitmapy oken by byl hodně nešťastný nápad.
Jen je nepěkné, že se i WindowManager spouští vzdáleně.
XDMCP existuje právě proto, abyste si celou session včetně windowmanageru spustil na vzdáleném počítači a u vás běžel jen X server a windowmanager. Odeberte tuto vlastnost a XDMCP vlastně vůbec nepotřebujete.
Vypadá to, že ohledně fungování X11 a XDMCP panují trochu zkreslené představy, proto doporučuji k přečtení příslušnou kapitolu v učebnici.
Jen nazývám věci nesprávnými jmény. Významy XDMCP a X Protocol k sobě patří stejně jako Lolek a Bolek, takže prosím omluvte mou sníženou rozlišovací schopnost.To je hodně nepřesné. XDMCP je jen protokol pro komunikaci mezi dvěma displaymanagery, který vám umožní vzdálené přihlášení. Vlastní komunikace aplikace s X serverem probíhá naprosto stejně, jako když ji spustíte normálně a nastavíte proměnnou
DISPLAY
na váš X server. Takže se přenášejí jednotlivá grafická primitiva.XDMCP existuje právě proto, abyste si celou session včetně windowmanageru spustil na vzdáleném počítači a u vás běžel jen X server a windowmanager. Odeberte tuto vlastnost a XDMCP vlastně vůbec nepotřebujete.
Vypadá to, že ohledně fungování X11 a XDMCP panují trochu zkreslené představy, proto doporučuji k přečtení příslušnou kapitolu v učebnici.
Mimochodem, pokud si zrovna neprohlížíte fotky, používat JPEG kompresi pro bitmapy oken by byl hodně nešťastný nápad.Ale přenášet pixmapy na pomalé lince také není zrovna to nejšťastnější řešení.
Významy XDMCP a X Protocol k sobě patří stejně jako Lolek a BolekNo, jak se to vezme. To je jako rict, ze UDP a TCP k sobe patri. Pritom ale UDP a TCP muzu provozovat uplne zvlast jeden bez druheho, stejne tak XDMCP (UDP) a X11proto (TCP) muzu provozovat nezavisle. XDMCP slouzi pouze k nalezeni login manageru. DEtaily http://en.tldp.org/HOWTO/XDMCP-HOWTO/gdm.html a http://en.wikipedia.org/wiki/X_display_manager. Potom spusti na lokalnim X serveru pres X11proto prihlasovaci manazer. Cili, pokud se nechci prihlasovat managerem, muzu si spustit celou X session vcetne WindowManagera pres Xforward v SSH. Je to proste neco jineho.
Významy XDMCP a X Protocol k sobě patří stejně jako Lolek a Bolek
To bych rozhodně netvrdil. Použití XDMCP k vytvoření vzdálené session bez následného použití X11 pro komunikaci vzdálených aplikací s lokálním X serverem si sice dokážu představit jen těžko, ale naopak X11 se dnes daleko častěji používá bez XDMCP než s ním (a to i když budu počítat jen případy, kdy X server a aplikace neběží na stejném stroji).
Ale přenášet pixmapy na pomalé lince také není zrovna to nejšťastnější řešení.
Jenže to X11 protokol nedělá. X11 protokol přenáší od aplikace k X serveru požadavky na jednotlivé primitivní operace - nakresli čáru, vyplň oblast, zkopíruj oblast jinam, napiš text atd. Pixmapy z toho dělá až X server a ten je na druhé straně. Teprve v okamžiku, kdy se aplikace rozhodne vykreslit nějakou pixmapu - třeba při tom prohlížení fotek - musí ji poslat X serveru (stejně jako když poběží lokálně). Ale i pak bych upřednostnil třeba kompresi, kterou disponuje ssh, pro obsah většiny oken je JPEG naprosto nevhodný (používání JPEGu pro screenshoty je sice poměrně časté, ale je to hrozný nešvar).
Šifrování na nízké úrovni využívá klíč o 56 bitech (256 možných čísel). Pokud chcete vysoké zabezpečení, vězte, že SSH umí pracovat až s 1024 bitovým klíčem.V tejto casti splietate 2 rozne veci: symetricke a asymetricke sifrovanie. Dlzka 56 bitov zodpoveda DESu, co jem uz naozaj malo. Takze sa pouziva napr. AES128 alebo AES256. Este som nepocul, ze by niekto pouzival blokovu sifrun s dlzkou kluca vacsou ako 256bitov. Aj ked sa mozrejme ze, taka sifra sa da navrhnut. Na druhu stranu pri asymetrickom sifrovani 1024 je uz teraz v podstate dolna hranica. Asymetricke sifrovanie sa nepouziva na prenos vsetkych udajov, prenesie sa len session key, kt. sa potom pouziva v symetrickej sifre.
Pokud chcete spouštět grafické aplikace za pomocí X11 forwarding, použijte přepínač -X: ssh -X richmond@192.168.1.20 A pokud chcete spustit grafickou aplikaci, která by se objevila na vzdáleném stroji, použijte pro její spouštění DISPLAY=:0.0 (nebo DISPLAY=:0.1 apod. Záleží na nastavení) DISPLAY=:0.0 geditssh -X vytvari samo promennou DISPLAY, obsahujici obvykle neco jako localhost:10 (nebo cislo vetsi). Nastaveni display offset se dela v sshd_configu (viz man) a sam ssh -X provede taky zapis tzv. cookies pro autentizaci na lokalnim X serveru. Povoleni X forwardingu je samozrejme nutny povolit v sshd_configu a pripadne se da nastavit pro vybrany host v ssh_config. Pokud chces spustit aplikaci na vzdalenych serveru, aby se ti objevila na tvym lokalnim X serveru (X session), tak musis do DISPLAY nacpat celej nazev tvyho X serveru a za to teprve cislo displaye, tedy napr. pracuju na stanici mojews.doma, DISPLAY mam :0.0 a na serveru mujserver.doma chci pustit xterm, tak musis po nalogovani pres SSH bez -X nastavit DISPLAY="mujews.doma:0.0". Krome toho samozrejme firewall musi povolovat spojeni na port 6000, X server musi mit povolene prijimani TCP spojeni a navic musis bud (a) na vzdalenym serveru nastavit spravne cookies (na svym PC xauth list $DISPLAY a pak na serveru xauth mojews.doma:0.0 . COOKIE), a/nebo (ted si nejsem jistej) (b) povolit pristup ze serveru do tvyho X serveru pomoci xhost +mujserver.doma. Celkove je tahle varianta hodne slozite a jednodussi je tunelovat to SSHckem, to chodi vetsinou - akorat pozor, nezapomenout, ze na serveru, kam se pomoci ssh -X prihlasuju, musi byt nainstalovany xauth program (debian balicek xbase-clients), aby ulozit X cookies, jinak to fungovat nebude. Jinak jen pro upresneni:
Tightvnc (a uz ani realvnc v pripade x-server 1.4) se nedokaze pripojit k bezicimu sezeni.Tohle trosku nechapu: * bud mas na mysli bezici klasicky vncserver(Xvnc), v tom pripade se samozrejme tightvnc i realvnc dokaze pripojit, jinak by to ani nemelo smysl * nebo mas na mysli pripojovani pres vnc k bezici X session (klasicky na lokalnim monitoru) a v tom pripade viz Osobne na sdileni aktualni X session pouzivam bud synergy nebo x11vnc Tady je to mozna trosku neprehledne. Zatimco synergy umoznuje pouze ovladat vzdalenou plochu pomoci stejny kbd+mys, ale clovek musi mit druhy monitor u druheho pocitace se zobrazenou plochou. Kdezto x11vnc aktualni X session zabali do VNC serveru-pak je mozne bud podobne jako synergy pomoci x2vnc nebo win2vnc "preject" kurzorem na druhy monitor a ovladat druhou plochu (samozrejme clovek musi mit druhy monitor a vyhled na ten monitor), nebo je mozne pouzit vncviewer a zobrazit si vzdalenou X session na svem pocitaci (tohle jde pouzit i pro PC, ktera jsou nekde daleko na internetu a neni vyhled na monitor, nebo dokonce ani monitor nemaji). Dobry je, ze se tim da taky delat "vzdalena pomoc", kdyz uzival v linuxu v Xkach neco nevi, tak se muze clovek pripojit na jeho Xka a pomoct mu.