Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
No dobře, ale to by nešlo spustit na nové konzolyČeho?
Tento ovladač umožňuje spuštění X serveru v okně z jiného X serveru.A moje reakce :
Mě se prostě nezdá, že spustí někde další XServer jen proto, aby se vytvořilo okno do něhož se namapuje nová plocha a další strom oken. To se mi nezdá prostě jako moc košer řešení....Pravda, část viny je na mé straně, protože jsem měl napsat, že podle mého názoru je lepší spustit další relaci na nové konzoli, a když už chci se přihlašovat k nové relaci v okně té stávající, použít takové řešení, aby nebylo nutno (kdekoliv) spouštět další Xka. Něco jako WM spuštěný ve WM (i vzdáleně). Prostě na vzdálené přihlášení se mi zdá spuštění nového xserveru zbytečné (a tím i tahle feature).... Pokud jsem tě dobře pochopil, tak ty jsi vyloženě proti nebyl, jen nechápeš proč je to řešeno jako ovladač pro Xka.
Prostě na vzdálené přihlášení se mi zdá spuštění nového xserveru zbytečné (a tím i tahle feature)....Právě proto aby se nemusel spouštět další X server se spouští buď Xnest (což je X server s výstupem do pixmapy místo do grafické karty) a nebo právě tento nový udělátor.
je lepší spustit další relaci na nové konzoliTo je další z možností. Dle mého názoru je úplně nejlepší řešení nedělat takové psí kusy ale poslat si gnome-panel ze vzdáleného serveru a nacpat ho nahoru, takže spodní panel je lokální (a spouští se v něm aplikace lokálně) a horní panel je vzdálený a aplikace se v něm spouští vzdáleně (a nebo aspoň tak mi to fungovalo ve Widlích).
Pokud jsem tě dobře pochopil, tak ty jsi vyloženě proti nebyl, jen nechápeš proč je to řešeno jako ovladač pro Xka.No teď už asi jo. Xnest je samostatná aplikace a čistě softwarově řešený Xserver (bez akcelerace čehokoliv). Toto to akorát prožene skrze místní X server, takže by to mohlo využívat jeho funkcí. Nebo je to aspoň jediné rozumné vysvětlení co mě napadá.
Právě proto aby se nemusel spouštět další X server se spouští buď Xnest (což je X server s výstupem do pixmapy místo do grafické karty) a nebo právě tento nový udělátor.Asi fakt každý mluvíme jinou řečí
To je další z možností. Dle mého názoru je úplně nejlepší řešení nedělat takové psí kusy ale poslat si gnome-panel ze vzdáleného serveru a nacpat ho nahoru, takže spodní panel je lokální (a spouští se v něm aplikace lokálně) a horní panel je vzdálený a aplikace se v něm spouští vzdáleně (a nebo aspoň tak mi to fungovalo ve Widlích).Může být. Jen mám tu představu, že pokud spustím jakoukoliv Xaplikaci na vzdáleném systému, pak tento systém přesměruje veškerou komunikaci dané aplikace přes Xprotokol přímo na lokální XServer. A ten ji obslouží jakoby to byl normální požadavek normální lokální aplikace - jemu může být putna, kde aplikace fyzicky běží. Bylo by to jen otázkou nastavení přístupu. Pokud bych se přihlašoval k existující relaci - tedy na vzdáleném systému už instance (samostatný proces) Xserveru běží, bude se vzdálený Xserver k tomu locálnímu chovat jako klasická Xaplikace. Co a jakým způsobem bude vykreslovat do okna přiděleného locálním Xserverem je už jen čistě jeho problém (třeba ty bitmapy). Pořád nevidím důvod pro tento účel spouštět další Xka.
Vzdálené připojení. Konzolí mám na mysli virtuální konzoli. A nebo proč by pro podobné účely nemohl umět vytvořit druhé nějaké subRootWindow (rovnou, bez nutnosti kdekoliv spouštět delší instanci Xek)? Mě se prostě nezdá, že spustí někde další XServer jen proto, aby se vytvořilo okno do něhož se namapuje nová plocha a další strom oken. To se mi nezdá prostě jako moc košer řešení....Je to obvykle reseni - shell Vam na systemu bezi urcite take vicekrat nez 1 a nijak se nedivite. Je to i spravne reseni, protoze tak dojde k oddeleni jak z hlediska prostredi (prava k pristupu, konfigurace) tak i z hledika zdroju (nepretizi se Vam hlavni X server). V pripade pripojeni neduveryhodneho X klienta je takove reseni nutnosti, protoze jinak by Vam mohl lezt bez omezeni v systemu.
Je to obvykle reseniAno, ale to neznamená, že všem musí připadat jako to jediné možné, nebo dokonce správné...
shell Vam na systemu bezi urcite take vicekrat nez 1 a nijak se nediviteJedna instance shellu sežere neporovnatelně méně systémových prostředků, než jedna instance XServeru. Nemluvě o dalších věcech - je to konec konců server, že ano...
Je to i spravne reseni, protoze tak dojde k oddeleni jak z hlediska prostredi (prava k pristupu, konfigurace) tak i z hledika zdroju (nepretizi se Vam hlavni X server). V pripade pripojeni neduveryhodneho X klienta je takove reseni nutnosti, protoze jinak by Vam mohl lezt bez omezeni v systemu.Nemyslím, že by to muselo být až zas tak horké.Přístupy lze nastavit nastavit přes aplikaci xhost (popř. /etc/X*.host), a pomocí mechanizmů Xsecurity. Myslím, že přetížení XServeru by se dalo řešit pomocí nějakých limitů. Navíc, přijde mi jednodušší nastavit a zabazpečit jeden server, než dva a více. Co se týče možnosti získání přístupu nedůvěryhodného klienta do systému, tam je problém ten, že XServer běží pořád s rootovskými právy
Jedna instance shellu sežere neporovnatelně méně systémových prostředků, než jedna instance XServeru.Narazel jsem na to, ze Xkrat vice instanci jednoho programu nespotrebovava Xkrat vice zdroju - kod a data jsou v pameti jen jednou.
Co se týče možnosti získání přístupu nedůvěryhodného klienta do systému, tam je problém ten, že XServer běží pořád s rootovskými právyTady mi prijde, ze jste vubec nepochopil, co jsem myslel, tak uvedu priklad - pracujete na pocitaci A a pustite si na nem X server s Vasim prostredim. Pote se potrebujete pripojit napriklad do prace, tak se zalogujete SSHckem a pustite program z pocitace B. Pocitac B byl ale kompromitovany a spusteny program si pres Xka pusti Xterm na pocitaci A a vykrade Vam data z ~. V pripade pouziti 2 instanci X by toto neslo.Obávám se však, že díky tomuto hrozí podobné nebezpečí i v případě že se v jeho implementaci objeví nějaká závažná bezpečnostní chyba, nebo bude špatně nakonfigurovaný. Obavám se, že spouštění více instancí XServeru toto ryziko nijak nesníží, spíše naopak.
Narazel jsem na to, ze Xkrat vice instanci jednoho programu nespotrebovava Xkrat vice zdroju - kod a data jsou v pameti jen jednou.Je chybou si představit pod pojmem "systémové prostředky" jen systémovou paměť. Může to být například i procesor (čas procesoru). Navíc zátěž na paměť není konstantní, ale mění se podle množství (velikosti) a způsobu zpracování vstupních dat. Tedy navýšení nemusí být takto lineární, ale rozhodně tam bude. A u Xserveru bude poznatelně větší, než u shellu.
Tady mi prijde, ze jste vubec nepochopil, co jsem myslel, tak uvedu priklad - pracujete na pocitaci A a pustite si na nem X server s Vasim prostredim. Pote se potrebujete pripojit napriklad do prace, tak se zalogujete SSHckem a pustite program z pocitace B. Pocitac B byl ale kompromitovany a spusteny program si pres Xka pusti Xterm na pocitaci A a vykrade Vam data z ~. V pripade pouziti 2 instanci X by toto neslo.Myslím, že jsem Vás pochopil. Jen prostě nějak nedovedu přijmout to, že přes Xserver lze spouštět příkazy/programy. To přece není jeho úloha! Jeho úkolem (pokud to dobře chápu) obsloužit požadavky aplikace ohledně grafického subsystému. Pokud umí (nebo poskytuje) něco navíc (nedej bože byť i nepřímo přístup k lokálním datům) pak by to mělo být někde možné zakázat, znemožnit. Pokud to není možné pak je asi něco špatně. Neberte to tak, že se Vám to snažím za každou cenu vyvrátit. Jen se prostě snažím ukázat na to co se mi na celé té věci moc nelíbí. A jak tak diskutujeme, docházím čím dál víc k dojmu, že je něco v návrhu systému X špatně. Teď by mě jen zajímalo co...
Tady mi prijde, ze jste vubec nepochopil, co jsem myslel, tak uvedu priklad - pracujete na pocitaci A a pustite si na nem X server s Vasim prostredim. Pote se potrebujete pripojit napriklad do prace, tak se zalogujete SSHckem a pustite program z pocitace B. Pocitac B byl ale kompromitovany a spusteny program si pres Xka pusti Xterm na pocitaci A a vykrade Vam data z ~. V pripade pouziti 2 instanci X by toto neslo.To je blbost. Pokud si pustím něco přes X forwarding přes SSH, tak mi spuštěný program může maximálně tak zaplevelit dektop mnoha okny, případně zasvinit clipboard, ale nemá šanci něco číst nebo zapisovat na můj počítač nebo pouštět další programy (pouštět teda může, ale spustí je na tom vzdáleném systému).
To je blbost. Pokud si pustím něco přes X forwarding přes SSH, tak mi spuštěný program může maximálně tak zaplevelit dektop mnoha okny, případně zasvinit clipboard, ale nemá šanci něco číst nebo zapisovat na můj počítač nebo pouštět další programy (pouštět teda může, ale spustí je na tom vzdáleném systému).Staci trochu premyslet -- muzete posilat udalosti ostatnim klientum. Takze co treba poslat udalost panelu, at pusti xterm a tomu pak posilat stisky klaves?
ForwardAgent yes
v ssh configu, což je tuším default, tak se otevírá cesta k prostému připojení se přes SSH zpět na původní stroj, případně na jiné stroje které má uživatel k dispozici (dle situace). Což může být ještě horší než hrátky s X serverem.
void ManageEnvelope() { /* Yo dawg, I herd you like rectangle wawes, so I put a rectangle wawe in your rectangle envelope so you can generate rectangle wave while you generate rectangle wave */
Tiskni
Sdílej: