Közel az Ubuntu a root nélküli X futtatáshoz

Ubuntu

Az Ubuntu kereskedelmi szponzora, a Canonical alkalmazásában álló Christopher James Halse Rogers tegnapelőtt egy levelet postázott az xorg-devel levelezési listára, amelyben arról írt, hogy úgy tűnik, gyakorlatilag majdnem az összes feltétel adott ahhoz, hogy root privilégium nélkül lehessen X szervert futtatni. Két függőben levő probléma van már csak a fejlesztők előtt. Az egyik a /proc/mtrr írásra való megnyitása, de ezt a KMS-t használó (pl. nyílt forrású ATI, Intel és Nouveau) driver-ek nem igénylik, illetve a /sys/class/backlight/*/brightness megfelelő jogosultságokkal való ellátása.

Ha a fenti problémák megoldódnak, akkor Halse Rogers ír egy patchet, amely az X elindításakor ellenőrzi, hogy

  • a Kernel-based Mode Setting használatban van-e
  • /dev/backlight létezik-e, és ha igen, akkor a megfelelő jogokkal
  • dev/input/* a megfelelő jogokkal rendelkezik-e

Ha ezek a feltételek teljesülnek, akkor az X eldobja a root privilégiumokat.

Christopher James Halse Rogers azt kérdezte a lista tagjaitól, hogy ez az elképzelés megfelelő-e. Greg Kroah-Hartman azt válaszolta neki, hogy nézze meg a legfrissebb MeeGo image-eket, mert azokban ezek a problémák már orvosolva vannak.

A részletek itt.

( Sanya v | 2010. 06. 27., v – 10:24 )

Éljen! gondolom ez a rootkitek ellen van, illetve az esetleges sebezhetőségek ellen.

Egyáltalán nem rossz dolog, sőt, a lehető legtöbb programra ki kellene terjeszteni ezt a lehetőséget. Nem mindegy, hogy a támadó egy root jogokkal futó alkalmazás, vagy egy mezei user jogaival rendelkező alkalmazás felett veszi át az irányítást.

SKL - leírásgyűjtemény és informatikai portál

Beszállítói szerződések, beérkezett pályázatok, pénzügyi kimutatások, fotók a titkárnőről meg rólad, örökélet elixírjének leírása, akármi, ami valakinek értékes lehet, felhasználható ellened.

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

Kicsit kevered szerintem a szezont a fazonnal. Az op. rendszer védelme szerintem ott véget ér, hogy a lehető legnehezebbé teszi a támadó számára, hogy zombit csináljon a gépedből és a tudtodon kívül mondjuk spam-et küldjön vagy ugródeszkaként szolgáljon egy komolyabb betöréshez. A személyes- és/vagy céges adatok védelme érzésem szerint túlmutat ezen és nem feladata, hogy megvédjen a saját hülyeségedtől.

Egy erosen sarkitott peldaval elve, igen. Attol nem kell megvedenie (es nem is tud), hogy te futtatsz egy programot ami elkuldi a dokumentumaidat valahova a tudtodon kivul. Amit mondjuk egy mezei email kliensnek is tudnia kell, ha csatolni akarsz valamit egy levelhez. Vagy esetleg van otlet arra, hogy a ket dolog kozott az op. rendszernek hogyan kene kulonbseget tennie?

Hamis. Az, ha meghekkelik a bongeszodet mondjuk egy JS bugon keresztul es lenyuljak/letorlik/titkositjak a file-jaidat, holott nem tul nagy munkaval megoldhato lenne a fontos file-ok vedelme (peldaul mas UID-on futtatva az internethez hozzafero alkalmazasokat, es valami apparmor-szeru hozzaferessel limitalni a hozzaferest a fontos anyagokhoz), az az OS hibaja.

Az, hogy mondjuk botnetet futtatnak a gepeden, a felhasznalok 99%-at nem erdekli, mert kulonosebb negativ hatasat nem latja.

Ne feledd: ez desktop. Teljesen masok a kovetelmenyek es a prioritasok, mint szerverfronton.

Masik iranybol kozelitve a dolgot a tamadok 99%-at nem erdekli a szemelyeses doksijaid, szamlaid, kimutatasaid es csaladi fotoid. Viszont az a 99% nagyon is tori magat, hogy zombit csinaljon a gepedbol es mindent megtesz azert, hogy egy esetleges balhe eseten eloszor nalad tartsanak hazkutatast a rendorok.

Ne feledd: ez egy otthoni felhasznaloknak szant, desktop operacios rendszer.

Ezt nem tudod. Tamadotol fugg. Hitelkartyaszamok, kulonfele szemelyi azonositok, jelszavak nagyon is erdekesek lehetnek az atlag tamadonak is. A celzott tamadaskor meg csak ezek.

A rendszert manapsag kvazi 0 ido alatt ujra lehet huzni, es ez egyben megoldja a zombi/OS-hack problemat.

Ha beleturnak az adataidba, lenyuljak, modositjak oket, a karod nem egy delutan, hanem hetek-honapok-evek munkaja. Ergo megiscsak a masik szemszog a fontosabb.

Még 2 dolog:

1. a rendszer újrahúzás nem megoldás semmiféle problémára, ennyi erővel azt is mondhatnád, hogy biztonságos a gépem, mert nincs bekapcsolva
2. "Ha beleturnak az adataidba, lenyuljak, modositjak oket, a karod nem egy delutan, hanem hetek-honapok-evek munkaja."
Mit? Milyen adatokba? Ki nyúl bele és hogyan? Letörli? Nincs backup? Titkos info? Nincs titkosítva? Céges adat? Mit keres az otthoni gépen? Kicsit úgy érzem, mintha olyasmitől félnél, amiről nem is igazán tudod, hogy pontosan micsoda.

Ha a rendszer esztétikuma fejlődik/változik, akkor az a baj. Ha az X-et root jog nélküli futtatásra állítják át, akkor az. Nem lehet mindenkinek egyszerre a kedvére tenni. Szívem szerint én is jobban örülnék, ha a teljesítményt optimalizálnák egy kicsit, mert nekem egyre lomhábbnak tűnik az egész.
Amúgy ennek tényleg csak a biztonság növelése az előnye? Esetleg hozhat-e valami más hasznot?

Csak biztonság. De nem hinném hogy erre annyira szükség lenne. Mármint.. asztali gépen az emberek szarnak sokszor bele. Szerverre aki Gnome-ot rak vagy X-et az pedig mehet más munkát keresni. Félre értés ne essék, jó ha újítanak. De megvallom, én inkább a Xorg helyettesítésén, átírásán munkálkodnék amiről szó esett mert fos. Mielőtt bárki beleszól, nem én még nem írtam X szervert. Azt se egyedül és nem ingyen csinálták.

(A kódbázis elavult, zavaros. Jó lenne valami modern, egy modern natív toolkittel amivel szép, jó, natív alkalmazásokat lehetne írni és nincs GTK+, Qt, ZY- , hanem van grafikus felület, és kész. Nincs bloat, nincs folyton törés. (Nem ellenségeskedésből. A Qt nagyon jó toolkit. De nem akarok egy kereskedelmi toolkitet akármilyen pöszmeteg alkalmazáshoz, a GTK egyre bénább) (Az utóbbi csak vicc kedvéért mert nemrég módosították ugye a Xorg kiadási tervét "sokkal dinamikusabbra", mely lényegében azt hozza hogy akár naponta 2-3 RC is megjelenik mint épp kis ideje történt.))

Wx widgets-ről nem tudom mit lehet vele kezdeni, lehet ez egy jó megoldás. (Esetleg Java-ban kéne írni az egészet? :))

Azért lássuk be, hogy van olyan konfiguráló eszköz, amit csak GTK-ban írtak meg, system-config-valami-nél már találkoztam ilyesmivel. Nem volt konzolos. Lehet persze mondani, hogy DISPLAY máshol van, de amikor van egy két agyament függőség, aminek a végén úgyis felrakod/felrakod a grafikus beállító eszközt, aminek meg kell az X. És itt jön be az, hogy nem mindig éri meg a szöveges fájlt csesztetni, mert valaki mégis felrakja a grafikus modulokat, elindul valami más és a beállításaidat felülírja... Yast-nál jártam így, kézzel beállítottam, elvileg a yast-nak nem kellett volna hozzányúlnia a fájlhoz - le volt tiltva - de mégis megtörtént. ok, annó 9-es SLES volt, de akkor is...
Elég munkás lecsupaszítani egy ilyen szervert, persze én is jobban szeretem, minek rá X. Csak akkor az kell, hogy senki ne nyúljon hozzá és mindenki pontosan tudja miként kell kivitelezni a konzolos beállításokat. Itt szokott borulni a rendszer.

Én arra gondolok hogy alapból szükség van rá. Nem vagyok az a "Jajj nem rakom fel me izé" típus, volt már itt is picsogás a VLC-nél hogy "jujj az izé Qt-val jön ez így má nem jó maradok a 0.0.1 beta-nál me az gtk-s" ... Nem, ez nem én leszek.

De ilyesmire feleslegesnek tartok egy toolkitet. Alapvető programok, például rendszerbeállítások, maga a grafikus felület (tehát Gnome mondjuk) íródhatna a natívval. Remélem érted mire gondolok.

Tény, nagyon JÓ toolkit, és fürge is ahhoz képest. Csak láthattad, valaki írt erről egy nagyon jó posztot hogy miért is hülye dolog ez. Nem kell mindenhez minnél erősebb toolkit, ágyúval verébre.. Érted..

Qt-nak megvan a maga szerepköre, például SMPlayer, KDE, sorolhatnám. Sok jó dolog íródott alatta. De alap rendszer komponenseket nem írnék benne.

Szerintem nem kéne egy kereskedelmi dologtól függeni. Mármint.. jó hogy van persze, illetve óriási lehetőségek rejlenek benne amiket ki lehet használni.. de akkor is szerintem maga a rendszer maga ne épüljön rá, inkább csak a körítés (Például külön alkalmazások). De ez csak magánvélemény természetesen. Ez most olyan mintha a Microsoft csak adna egy kernelt, bebootolna a rendszer, és például beüdvözölne az Oracle kommunista vörös logója hogy üdvözlet a JavaW7 felületen. Engem zavarna kicsit.

Második: Fürgeség. Jó a Qt, de mégse olyan hopsz és már be is van töltve. Nem olyasmi ami natívan ott van, ami már úgyis fut, amivel rajzolni lehetne simán. Ugye Xorgnak is van ősrégi elavult megoldása amivel csinálhatsz alkalmazásokat, de szerintem ehhez csak az nyúl akinek hat anyja van (vagy aki olyan perverz mint Poli, illetve ugye maga a Xorg fejlesztők.. karbantartják).

Harmadik: A Qt-ban jó dolgokat lehet írni. De például egy szövegszerkesztő megírására elég nagy ágyúnak tűnik nekem. Egy alap alkalmazás ne támaszkodjon ilyesmire, ha nem muszáj. Most egy példa. Mousepad például simán lehetne natív (GTK helyett), míg Kate már bőven megérdemli a toolkitet. (A KWrite -ot nem írom mert Gedit-hez képest már így is egy halom tulajdonságával kiemelkedik.)

Nem. Eredetileg a Qt készült Linuxon fő GUI toolkitnek, csak nem volt elég szabad a licence, ezért lett a GTK. Most, hogy a Qt is teljesen szabad, nem sok értelmét látom a GTK-nak. Az Ubuntusok gondolkodnak a GNOME Qt portolásán, ami nem is lenne egy teljesen rossz ötlet.

A Qt az egyik legjobban megtervezett GUI framework, első rangú dokumentációval. Szinte bármilyen általános problémára nemhogy leírás, de példaprogram is van (érthető magyarázattal, nem túl szájbarágós, mint az MSDN, de nem is túl szűkszavú, mint a legtöbb FLOSS fw doksija). Külön előny még, hogy van egy remek Python portja, így tényleg percek alatt össze lehet vele dobni egy apró GUI toolt.

Nekem eddig sohasem volt bajom a Qt sebességével. Nézd meg KDE alatt, ott arra épül minden. Ráadásul kezdik beemelni a teljes OpenGL gyorsítást, onnantól ugyanolyan gyors lesz, mint egy Aqua/Aero GUI.

Egyszerű programokat nem gonoszságból írnak meg egy nagy frameworkre támaszkodva, hanem azért, mert nagyon gyorsan készen van. Írj meg egy mousepad szintű szövegszerkesztőt Qt-ban és Xt-ben, aztán hasonlítsd össze a kód méretét és a befektetett munkaórákat.

csak egy kérdés: ha már úgyis bent csücsül a memóriában a Qt/GTK+/whatever, akkor miért ne használja minél több program? Lásd Windows: majdnem minden program ugyanazt a toolkitet használja, ami automatikusan betöltődik.

Tehát ez alapján inkább integráljuk a Qt-t az X-be, hogy legyen egy fejlesztőbarát keretrendszerünk, amit minden program használhat aztán, nem? ;)

int getRandomNumber() { // ←ez itt már az aláírásom
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

A QT az GPL/LGPL, és egy cég fejleszti. Gyorsnak gyors, kényelmesnek kényelmes.

Akármilyen GUI rendszert fejlesztünk, érdemes egy jól összerakott keretrendszert használni, mert ez
egyrészt megkönnyíti a munkát, másrészt talán valamennyire visszafogja az átlagos kódereket az "alkotástól" (talán nem lesz annyira szemét a kód).

Érdemes keretrendszert persze, de ehhez kéne egy jól megtervezett, gyors, natív keretrendszer. Ami nincs. A jól megtervezett pedig itt nem lesz szerintem egyhamar kulcsszó. Nem vagyok "MS buzi" (Ahogy kalóz pajtás fogalmazott), de azért el kell ismerni hogy ott sikeresen megterveztek már egy pár dolgot és legalább azt megtanulhatnák hogy néha össze kéne fogni.

En ritkan ertek egyet NagyZ-vel, de oszinten szolva most van nemi igazsaga. Hogy az MS-ek sikeresen megterveztek valamit... inkabb ugy kellene mondani, hogy sikeresen teljesitettek hataridore a terveket, de minosegben nem sokkal jobb a dolog a OpenSource cuccoknal. Egy csomo minden el van cseszve pl a WinAPI-ban is, pedig ez a rendszer alapja. A hiresebb baklovesekrol meg talan nem is kene emlitest tenni (WinME, WinVista). Szoval, inkabb neked nem volt teljes egeszeben igazad, es tenyleg utana kene nezned par dolognak.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ez egyértelműen a biztonság növekedését hozza, a dolog jellegéből adódóan, de a biztonság növekedésének lehet más vonzata is. Ne felejtsük el, hogy manapság nagyon fontos irányvonal a távoli alkalmazások futtatása. Habár az X-et át lehet irányítani ssh-n keresztül, de az nevetségesen LOW LEVEL. Minden egérmozdulatnál kommunikál, rosszabb mint a VNC. Az AJAX-al pl össze sem lehet hasonlítani. Ez a lépés egy fontos szerkezetváltozás, ami szerintem el kell, ha az X lépést akar tartani az igényekkel a jövőben. A távoli alkalmazás futtatáshoz kéne egy absztrakciós réteg a puszta megjelenítés, és a programok érdemi része közé, ez pedig elképzelhetetlen a mostani felállásban, mind teljesítmény, mind biztonság szempontjából.

ha az X lépést akar tartani az igényekkel a jövőben.

szerintem az X nem képes lépést tartani a jövőbeni igényekkel. Lehet toldozgatni, de nekem az a benyomásom, hogy a normál desktop felhasználásra szánt grafikus felület szerepét néhol túlteljesíti (kliens-szerver felépítésre általában szerintem nem lenne szükség), néhol nevetségesen alulmúlja (mondjuk alkalmazások számára nyújtott szolgáltatások)

Helyi szinten szerintem nem kéne ez a kliens-szerver modell, legalábbis nem pipe-on keresztül, hanem shared memory-val vagy valami hasonló. E-helyett kéne valami GTK eszemaszom szerver, ami gyors shared memory-ba van az X-el, de magas szolgáltatást nyújt az alkalmazásoknak, pl: ajax szintűt, pipe-on keresztül.
így tudnám elképzelni a jövőt. :)

Mint ahogy az sem vita tárgya, hogy ez a mondat marhaság.
Az X-nek semmit nem kell továbbítania a hálózaton, nem vnc meg nem virtuális bittérkép.
A grafikus primitívek mennek át a hálózaton és a lokális X szerver hajtja végre őket. Ergo semmiféle visszaközvetítésre meg egyéb marhaságra nincs szükség.

Nézd meg az oldalt amit belinkeltem a VirtualGL-ről.
A helyzet az hogy az OpenGL, legalábbis az amit én ismerek, nem az X-en keresztül működik. Az alkalmazás az X-től függetlenül alakít ki kapcsolatot a videókártyával, a gyártó által szolgáltatott OpenGL driveren keresztül. A driver meg magasról tesz a kliens-szerver modellre.

"legalábbis az amit én ismerek": és itt le is zárhatjuk a kérdést.
az oldalt megnéztem, szerinted honnan tudtam volna, hogy vékonykliensről szól, ha nem nézem meg?

A linuxos driverek, legalábbis, amiket én láttam eddig, az nvidia driverei, szépen működnek kliens-szerver modellben.

Megkerestem:

http://en.wikipedia.org/wiki/VirtualGL#TurboVNC

Az ábrát nézd, szépen le van rajzolva minden. Az is, hogy az xlib és az OpenGL 2 teljesen különböző csatorna az alkalmazás számára. Ha az egyiket átirányítod attól még a másik nem fog magától átjönni, ezért jön a képbe a VirtualGL az ábrán látható módon.

Arról nem én tehetek, hogy te teljesen más témáról kezdtél beszélni, mint én, itt erősködsz olyan weblapokkal, amiknek fel sem kellett volna merülni.

Egy szót sem szóltam vnc-ről, sem vékonykliensről, mint amit te itt belinkeltél. Én teljes X-ről beszéltem, sem nem vnc-ről, sem nem vékonykliensről. Tudod értelmezni ezt a különbséget?

ja és a vicc az, hogy Gabucino is helyesen idézte, amit mondtam, csak te kezdted el ferdíteni a dolgokat. Na de akinek a vnc jobb, mint az x, attól mit is várhatunk.

Ja, vnc tud pl. displaypostscriptet, mint a solarisos X szerverek? (vagyis az, ami a solarisban X helyett van?)

Elmondom még egyszer hogy nem szándékozom a VNC mellett kardoskodni, csak példaként hoztam fel. Igen undorító dolog hogy bittérképként kell közvetíteni a változásokat a képen. Megértem hogy nem csíped, de szerintem túlzásba viszed, hogy így nekem esel. Mind a 2 dolognak megvan a hátulütője. A vnc hátulütője hogy a szöveges részeket képként viszi át. Az X átirányításnak a hátulütője hogy a manapság használt libek abszolút nem törődnek azzal hogy minimálisra szorítsák az X-el való kommunikációt. Mindig van egy absztrakciós szint ahol optimális a kommunikáció, az X szerintem messze van ettől. No meg azt a luxust már hadd engedjem meg magamnak, hogy mozgassam az ablakokat, anélkül hogy a hálózaton keresztül frissítené őket, 800-szor közben. Máskülönben miért használnék ablakkezelőt?

Az volt az eredeti állítás, hogy X-en átmegy az opengl. Ennek cáfolatára te felhoztad, hogy vnc-n nem megy át, tehát ez nem igaz. Igen, szárítókötélen sem megy át, csak ez nem cáfolja az eredeti állítást. Hogy akarsz-e vnc mellett kardoskodni, az a te dolgod, az eredeti állításhoz képest a vnc offtopic.

Abból indultam ki hogy X-en nem megy át, és mint alternatívát hoztam fel ezt a VirtualGL-t, hogy hátha ezzel menne. Az igazság az hogy csak konkrét tapasztalatom van a dologgal kapcsolatban:
Nvidia CUDA kompatibilis kártyán futtattam CUDA példaprogramokat úgy hogy a gépre ssh-val voltam bejelentkezve. Csak az a CUDA mintaprogram működött ami nem használt openGL-t, utána mondták is nekem hogy az openGL nem fog menni ssh-n keresztül. Amúgy a sima X rendesen működött. Csak úgy mellékesen megemlítem hogy a CUDA ugyan abban a képernyő memóriában dolgozik mint az OpenGL, és ha elindítom a gépen a CUDA mintaprogramot, akkor azt a kártyát használja ehhez, ami abban a gépben van ahol a programot futtatom, nem azt ahol ülök. Annak nem lenne így értelme.

Oké, tehát eddig nem tudtad bizonyítani/cáfolni az X-szel kapcsolatos állításomat vnc-s környezetben, akkor most nekifogsz trollkodni az opengl-lel kapcsolatos állításomról cuda-s környezetben?

Indulj már ki egyszer abból, ami a valóság, hogy X-en átmegy. MERT ÁTMEGY. És mivel átmegy, arra az esetre, hogy mi van, ha nem menne át, példákat meg találgatásokat hozni felesleges. Gondolom nem szoktál vészforgatókönyveket kidolgozni arra az esetre, ha a fű kék, az ég meg zöld, mert láthatóan nem fordul ez elő. Ha mégis megtetted volna, ugye nem csodálkoztál, hogy "neked estek" emiatt?

"de az iksz tud hálózaton keresztül opengl-t!!!44"

Amikor ezt a sort olvastam, még a saját negatív tapasztalatomból indultam ki, és abban igazam is volt, hogy az illető iróniának szánta a dolgot. Akkor még nem is sejthettem hogy ki áll az idézet mögött. A tudtam volna hogy TE vagy az, kétszer is meggondoltam volna hogy kételkedni merjek az állításban. Amúgy meg ha tévedtem hát tévedtem, leszarom. A személyes tapasztalatok hangoztatása még belefér szerintem, az is hogy kifogásod van ellene. Viszont hogy "letrollozol" az már szerintem trollkodás. :)

Nehogy komolyan vedd. Lazíts. :)

A szo amit keresel, a "bocs". Es egyebkent tenyleg nem volt igazad, mert te kezdted el a VNC-vel peldalozni, holott mindenki tudja, hogy azon nem csak az OGL, de nagyon sok minden nem megy at. Az XDMCP meg tok maskepp mukodik, mint az RDP/VNC protokollok. A futo alkalmazasnak meg ott a lokalis videokartya OGL csatornaja.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Én úgy tudom, de hajlandó vagyok elfogadni ellentétes érvet, hogy az X protokollban van olyan, hogy bittérképeket resource-ként bele lehet tölteni az X szerverbe és akkor az ilyen sávszélesség problémák nagyon sokat javulnak.

Hogy ezt nem használják a programozók, az szerintem nem az X problémája. Bár az a tény, hogy nekem most 900 mega ramot zabál az xorgom, arra enged következtetni, hogy használják.

Taxy barátod írta:
"Ha elhúzol egy ablakot a másik előtt, akkor az ablak kap egy "redraw" téglalap eseményt, ami átmegy a hálózaton, és a program fogja ,és újrarajzolja azt a téglalapot,"
és te nem tiltakoztál.

ergo az applikációnak kell az ablakkezelésen gondolkodnia.

Az utolsó két szavaddal kapcsolatban arra figyelj, hogyha kitúrod a házijószágokat a macskaalomból, annak káros következményei lehetnek.

> és te nem tiltakoztál.

Igen, okos gyermek, csak ha hatalmas agyadba beleférne a kettővel feljebb lévő komment tartalma, akkor tudnád hogy mi volt az előzménye:

"Kényszermegoldásnak jó, ha nincs más, de a web, a JavaScript és társai világrengető zsenialitásnak számítanak ehhez képest."

[ #FreedomFlotilla ] [ hupexpertize© ] [ hupdiploma ]

> újabb bizonyíték arra, hogy a világnézeted feje tetejére van állítva.

Mit szívsz? A második húsz perccel az első után jött. Én értettem, sőt vélhetően a legtöbb ember fel tudja fedezni a logikai-időrendi kapcsolatot. Ha te nem, akkor ideje leállnod a droggal.

[ #FreedomFlotilla ] [ hupexpertize© ] [ hupdiploma ]

"a legtöbb ember fel tudja fedezni a logikai-időrendi kapcsolatot"

Valószínűleg ő is értette volna ha gondolkodik mielőtt lő, de nem, az első adandó alkalmat kihasználja hogy támadjon. Vannak itt a hup-on "only write" userek. Szerintem ő inkább "only attack" user. Legalábbis én egyetlen jóindulatú hozzászólást sem láttam még tőle,legalábbis ebben a thread-ben biztosan nem.

Ha egy képet nézel az ablakban, akkor újraküldi a képnak azt a részét amit letakartál, ha folyamatosan mozgatsz előtte valamit akkor minden egyes kis mozdulatnál befrissít egy kis szelet képet.
Kényszermegoldásnak jó, ha nincs más, de a web, a JavaScript és társai világrengető zsenialitásnak számítanak ehhez képest. Csak hát ugye a web az web, az x meg x.

Ha elhúzol egy ablakot a másik előtt, akkor az ablak kap egy "redraw" téglalap eseményt, ami átmegy a hálózaton, és a program fogja ,és újrarajzolja azt a téglalapot, ami azzal jár hogy a hálózaton újraküldi a képnek azt a téglalapját. Az eseménykezelők egyébként is indokolatlanul sok forgalmat csinálhatnak, és kis reakcióidő esetén percekig tarthat néhány művelet.

nem, a szánalmas az, hogy olyan dolgokkal akarja bizonyítani az állításom hamisságát, amiknek semmi köze az egészhez. Emellett feltételezi, hogy ilyen triviális dolgokat sem tudok az X-ről.

Nincs miről érvelni. Két eset van, vagy a vnc-ről meg a cuda-ról akar beszélni, oké, akkor ne fossuk itt folyton a szót arról, amit eredetileg állítottam, vagy az eredeti állításomat akarja megcáfolni, akkor ne beszéljen a Háború és békéről. Mert távolról úgy tűnik, mintha neki lenne érve, holott nincs. Csak valami nem ismert okból nem akarja beismerni.

Az eredeti állítás tehát, amit Gabucino felvetett (és tőlem idézte, pontosan): X esetén hálózattranszparensen átmegy az opengl. Tehát a gyengeelméjűek kedvéért X-ről volt szó és nem vnc-ről, emellett opengl-ről volt szó és nem cuda-ról.

Nem akarom eldönteni a vitát, de megvizsgáltam a dolgot, és érdekes tapasztalatokat szereztem. Először is, egy ssh log: http://pastebin.ca/1891453

A logban látszik, hogy a szerver gépen is fut egy X szerver a :0.0 porton, illetve a kliens gépen is, a localhost:10.0 porton. A glxinfo kimenete alapján a szerveren, amiben egy Nvidia GeForce 4 MX 440 van, van direct rendering, azonban a kliensen, amiben egy ATI Mobility Radeon HD 3450 van, nincs direct rendering.

Ami nem látszik, hogy a kliensen, ami egy Windows 7, Xming szolgál X szerverként.

Ebben a felállásban a szerveren, és a kliensen is megkaptam a glxgears képét.

Szerintem csak azért kaphattam meg a kliensen a glxgears képét, mert a kliensen nem volt direct rendering, ezért szoftveresen lett lerenderelve a kép a szerveren, ami az X szervernek továbbítódott a hálózaton keresztül. Direct rendering esetén az opengl adatot is át kellene küldeni a hálózaton, amit végül a kliens videókártyája kapna meg, amiből lerenderelné a képet. Viszont az opengl adatot az X nem kapja meg, tehát az nem kerül átküldésre a hálózaton. Úgyhogy ezért nem volt támogatva a kliensen a direct rendering.

Ezt a feltételezésemet úgy tudnám bizonyítani, ha a kliensen tudnám futtatni a glxinfo-t, illetve a glxgearst, szerverként az Xminget használva, és lenne direct rendering.

--
Don't be an Ubuntard!

"Direct rendering esetén az opengl adatot is át kellene küldeni a hálózaton, amit végül a kliens videókártyája kapna meg, amiből lerenderelné a képet.": pontosan ez történik, azzal az apró különbséggel, hogy X esetén a kliens és a szerver kifejezések felcserélődnek. Az a gép, ami előtt ülsz és amiben a videokártya van, az a szerver.

Ha van két linuxod, az egyikben nincs videokártya, felraksz rá egy opengl-es programot, a másik előtt ülsz, van benne rendesen konfigurált videokártya, akkor látni fogod a kimenetét hardveres opengl gyorsítással.

Nem hiszek benne, hogy egy w7-en futó xming támogat opengl-t, de ezügyben meggyőzhető vagyok.
ami ellentmond ennek a feltételezésemnek az az, hogyha mesa szoftver renderelés történt volna, akkor nem 1000 fps-sel megy a glxgears, hanem két nagyságrenddel kevesebbel.

Egyébként meg amit belinkeltem a VirtualGL-ről abban explicit benne van hogy neked van igazad:
"Indirect rendering uses the GLX extension to the X Window System ("X11" or "X") to encapsulate the OpenGL commands inside of the X11 protocol stream and ship them from an application to an X display."

Na ez bizonyíték. Nem üres fecsegés. Most már elégedett vagy?

Az ok nélküli belekötés, hogy olyan helyesírási hibákat vét, amitől ellenkezőjére változhat a mondatának értelme? És neked is az a fontos, hogy belekötöttem a helyesírásába, nem az, hogy amit mondott, szakmailag helytelen volt?

Különben is: helyesírási hibába belekötni soha nem ok nélküli:P Herótom van a funkcionális analfabétáktól.

bambínó ilyen... Vakon kardoskodik ideák mellett, a gyakorlati alkalmazásukról kevés fogalma van, kényes kérdéseknél pedig inkább a helyesírásra terel. Hupper-effektus.

Én használtam régen hálózaton keresztül X-et, és még pontosan emlékszek mennyire stresszes volt folyamatosan arra ügyelni, hogy a képernyőn elférjen _egyszerre_ az összes remote X ablak, mert ha átfedték egymást akkor a már jelzett hatás jött elő, nevezetesen hogy a lefedett ablak képe aktiválás esetén megint átjött a hálózaton, és amíg ez nem ment végbe addig remek fehér képet láthatott az user. Elvileg itt jöhetett volna képbe a lokálisan futó X szerver előnye, ha ezt userfriendly-bb módon kezelte volna, de nem. Mert az X egy szar rendszer, amiben nemhogy doublebuffering nincs (ablakkezelésről van szó), de "singlebuffering" se.

[ #FreedomFlotilla ] [ hupexpertize© ] [ hupdiploma ]

Helyi gépen nem is kell minden ablakhoz külön "singlebuffering", az memóriapazarlás lenne. Itt jön ki az hogy nem lehet ugyan azt a protokollt használni helyi szinten, és távoli alakalmazásoknál. Helyi szinten indokolatlanul lassít, mert a memória mozgatások mind stream-en keresztül mennek. Helyi szinten szerintem minimum shared memory kéne az X-el. Távoli alkalmazásoknál, meg a program egy része a kliensen kell hogy fusson (JavaScript), másik része meg a szerveren (php). A kettő pedig egészen feladat specifikus kommunikációt használ, a lényeges dolgokat küldik át, nem azt hogy az egeret merre mozdítottam.

Megmondom én. Mert a burokban élő elkényelmesedett fejlesztők azt hiszik hogy mindenki olyan nagyvárosban él ahol csettintésre ott a nagyonszélessávú internet.
Bezárnám szívesen mindet egy max gprs internet lefedettségű helyre fél évre, és sok embernek eszébe jutna hogy egy progi ne úgy épüljön fel hogy telepítés után olyan dolgokat szed le a netről amit külön nem lehet letölteni és pendrive-on hazavinni... Ok. Jó ötlet az online oprendszer, de ha nincs net akkor ott vagy egy használhatatlan géppel. Vagy a fenti példa alapján két hétig tudod használni a géped mert lefogy a mobilnet, vezetékes meg a környéken sincs. A fizikális hordozhatóságról meg inkább nem beszélek.

- - - - - - - - - - - - - - - - - - - - - - - - -
Fejlődőképes hiperláma, és okleveles érdekfeszítő

A gond ott van, hogy mindket verzio elvben ugyanabbol a kodbazisbol taplalkozik, a fejlesztok nem fognak lefejleszteni egy, a maganszektor szamara keszitett verziot. Igy pedig a maganszektor meg van szopatva, nem kicsit, hanem nagyon.

Es igen, lehet gondolni az uzleti celokra, am ez nem zarja ki a maganszektor igenyeinek figyelembevetelet.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

( hory v | 2010. 06. 27., v – 15:14 )

Szerintem biztonsag szempontjabol a root-kent futo X egy nagysagrenddel kisebb problema, mint az, hogy az osszes GUI a desktop fo userenek uid-je alatt fut. Volt egy aranyos kezdemenyezes, amivel pl. a browser-t, vagy egyeb hackelheto process-t mas UID alatt, elkulonitve indit. Ennek az az elonye, mar a karokozas megelozesen tul, hogy az erzekeny file-okat nem erheti el egy esetleges hack. Mert ugye desktop user siman elerheti a neki fontos file-okat...

Szoval igen, egyetertek azokkal, akik szerint ez szep, csak epp kb. olyan, mint vadiuj gumikat rakni egy trotty ladara. Nem ez a legnagyobb problema.

Szerintem biztonsag szempontjabol a root-kent futo X egy nagysagrenddel kisebb problema,

Valoban szar lehet egy user accounttal egy bugos Xlib/Xserver komboval rootolni a gepet, mint ahogy erre mar volt pelda. :) Es mint a mellekelt abra mutatja sajnos vannak esetek amikor meg szerver oldalon is kotelezo az X...

---
pontscho / fresh!mindworkz

Kotelezo szerveren X? Ezt hogy erted? Te vagy a root. Ha valami lama usernek kell, akkor csinalsz neki egy X-es terminalt. Ha valami szoftver igenyli, akkor meg szepen atirod a csomagban, hogy ne fuggjon tole, es kesz. Esetleg krealsz egy hamis X szerver csomagot, felrakod, es kesz, fuggosegek kielegitve is, meg nem is.

Ezt tenyleg nem problema megoldani.

( uid_4263 v | 2010. 06. 27., v – 17:03 )

Mikor ütik le az OpenBSD -sek a magas labdát?

...

( Hijaszu | 2010. 06. 28., h – 09:33 )

Csak nekem tűnt fel a mondatban, hogy "akkor az X eldobja a root privilégiumokat."? Akkor még mindig rootként kell futtatni, különben nem lennének ilyen privilégiumai...

amit linkeltem abban benne van, hogy miert van szuksege az x-nek az indulas pillanataban root-ra, es mit kellett hozzafejleszteni ahhoz, hogy az indulas utan eldobhassa a jogokat.
ez olyan hogy miert kell, hogy az apache rootkent induljon(persze fork utan eldobja a jogokat) ha 80as portra akar bindolni...

Tyrael