Apple představil (YouTube) telefony iPhone 17 Pro a iPhone 17 Pro Max, iPhone 17 a iPhone Air, sluchátka AirPods Pro 3 a hodinky Watch Series 11, Watch SE 3 a Watch Ultra 3.
Realtimová strategie Warzone 2100 (Wikipedie) byla vydána ve verzi 4.6.0. Podrobný přehled novinek, změn a oprav v ChangeLogu na GitHubu. Nejnovější verzi Warzone 2100 lze již instalovat také ze Snapcraftu a Flathubu.
Polské vývojářské studio CD Projekt Red publikovalo na Printables.com 3D modely z počítačové hry Cyberpunk 2077.
Organizátoři konference LinuxDays 2025 vydali program a zároveň otevřeli registrace. Akce se uskuteční 4. a 5. října na FIT ČVUT v pražských Dejvicích, kde vás čekají přednášky, workshopy, stánky a spousta šikovných lidí. Vstup na akci je zdarma.
Uživatelé komunikátoru Signal si mohou svá data přímo v Signalu bezpečně zálohovat a v případě rozbití nebo ztráty telefonu následně na novém telefonu obnovit. Zálohování posledních 45 dnů je zdarma. Nad 45 dnů je zpoplatněno částkou 1,99 dolaru měsíčně.
Server Groklaw, zaměřený na kauzy jako právní spory SCO týkající se Linuxu, skončil před 12 lety, resp. doména stále existuje, ale web obsahuje spam propagující hazardní hry. LWN.net proto v úvodníku připomíná důležitost zachovávání komunitních zdrojů a upozorňuje, že Internet Archive je také jen jeden.
Jakub Vrána vydal Adminer ve verzi 5.4.0: "Delší dobu se v Admineru neobjevila žádná závažná chyba, tak jsem nemusel vydávat novou verzi, až počet změn hodně nabobtnal."
V Německu slavnostně uvedli do provozu (en) nejrychlejší počítač v Evropě. Superpočítač Jupiter se nachází ve výzkumném ústavu v Jülichu na západě země, podle německého kancléře Friedricha Merze otevírá nové možnosti pro trénování modelů umělé inteligence (AI) i pro vědecké simulace. Superpočítač Jupiter je nejrychlejší v Evropě a čtvrtý nejrychlejší na světě (TOP500). „Chceme, aby se z Německa stal národ umělé inteligence,“ uvedl na
… více »V Berlíně probíhá konference vývojářů a uživatelů desktopového prostředí KDE Plasma Akademy 2025. Při té příležitosti byla oznámena alfa verze nové linuxové distribuce KDE Linux.
Byl vydán Debian 13.1, tj. první opravná verze Debianu 13 s kódovým názvem Trixie a Debian 12.12, tj. dvanáctá opravná verze Debianu 12 s kódovým názvem Bookworm. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 a Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
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: