Unity a Wayland-en

Címkék

Mark Shuttleworth október végén robbantotta a bombát: az Ubuntu a GNOME shell helyett az Unity felé indul el. Most egy újabb meglepő adalékkal szolgált, nevezetesen azzal, hogy az Ubuntu lehet az első desktop terjesztés, amely befogadja a Wayland névre hallgató, OpenGL-alapú "display management system"-et.

A Wayland egy C-ben írt, pehelysúlyú, MIT licences diplay szerver. Fejlesztője a Red Hat alkalmazásában álló Kristian Høgsberg. A 2008-ban indult projekt jelenleg is erősen fejlesztés alatt áll. A Wayland a Linux kernel meglevő infrastruktúráit - DRM, KMS, GEM - használja.

A Wayland-et jelenleg semmilyen projekt sem használja. Első felhasználására a MeeGo-ban kerülhet sor.

Shuttleworth szerint az Ubuntu 11.04-re már tudnak szállítani *valamit*, de sokkal közelebb állnak az igazsághoz, ha azt mondják, hogy a szélesebb közönség számára is használhatót körülbelül egy év múlva letenni az asztalra.

Részletek a blogbejegyzésben.

Hozzászólások

Nem értem én ezt. Asszondá, hogy az X überzsírkirály, de mivel nehéz konfigurálni nem jó. Akkor miért nem csinálják meg olyanra, hogy könnyebb legyen konfigurálni? Miért vállalja be a sokkal nagyobb kockázatot? MS egy üzletember és gyaníthatóan csinált egy kockázati elemzést és láthatta, hogy az X -ben kevesebb a kockázat. Akkor már csak az a kérdés, hogy mi a szöszért dobja ki az X-t?

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

az x egy régi, bloated valami. az x-et nem dobják még ki sehova, max ha a wayland használhatónak bizonyul. egy from-scratch implementációt sokkal könnyebb karbantartani, tisztább a kódja, kisebb támadási felülete van (már csak azért is, mert nem támogatja a hálózati működést), modern technológiák felhasználására lett tervezve, és mivel ilyen pici, remélhetőleg keveseb a potenciális bugok száma és valószínűleg gyorsabb is.

a kockázatos részt nem értem. x újra/átírási projektről nem hallottam, a wayland viszont már adott. mi a kockázat?

"az x egy régi"

Nem érv semmi mellett vagy ellen.

"bloated valami"

Inkább csak egészen másfelé indult még az "őskorban", és az infrastruktúrája (szerver-kliens megoldás) kicsit overkill a mai desktopnak szánt rendszerekre. Az X-et eredetileg arra tervezték, hogy a kiszolgáló és kliens rész külön gépeken fusson.

A többivel már egyetértek! Sok "haladó" emberke osztja az észt az X-szel kapcsolatban, nem ártana, ha felváltaná valami modernebb kialakítású megoldás.

--
"ktorrent utan az utorrent volt [...] beallithatatlan"
...

regen hallottam mar ilyen jo hirt a Linux hazatajarol :)

Nem csak a kompozit parasztvakításról van szó, hanem egy modern, valós igényeket kielégítő desktop grafikus alrendszerről. Az X11/X.org csak mellékesen nyújtja azt (nem túl hatékonyan) amire szükségünk van mostanság.

--
"ktorrent utan az utorrent volt [...] beallithatatlan"
...

Fogadjunk, hogy gyorsabb lesz.

Igazából nekem a legnagyobb bajom az X-el, hogy egy Nvidia driver+Composition páros képtelen megoldani a tear-mentes videólejátszást. Config turkálássál lehet rajta javítani, de nem lesz tökéletes. A Wayland egyik célkitűzése pont ennek az elkerülése.

UPDATE:
Úgy tűnik ez inkább a gnome/compiz bénasága, mert KDE alatt a saját KWin-es compositorral semmi probléma nincs. Ugyan olyan tökéletes a kép, mint mondjuk win7 alatt. Legalábbis a phonon-t használó lejátszókkal.

------------------
My Open-Source Android "Projects"

Nagyon úgy néz ki, ráfér a renováció az X11-re, az egész C/S architektura nem passzol sok renszernél. Üdvözítő lenne, ha Mark tá
mogatásával be tudnának futtatni egy lighweight alternatívát az X.Org mellé.
A Wayland gondolom, úgyis csak egy bizonyos réteget fog érniteni (Linux kernel függő, ha jól értem) de sokban közelebb hozná az embedded, vagy mobil eszközöket a PC-khez.

Manapsag a szoftverek >95%-a valamilyen publikus framework-ot hasznal, elsopro tobbsegben qt-t vagy gtk-t. Ha ezekbe implementalja valaki a wayland tamogatast, akkor kvazi olyan szintre kerul az X, mint a macos-ben: heba-hoba kell, de igazabol tavoli szerveren gui-t futtatni hasznalja csak az ember.

Vagyis igy, MeeGo es Ubuntu tamogatassal kb. 1 ev mulva lesz a normalis grafikus felulete a linux-nak, es eljo a linux desktop eve (kerdes, hogy lesz-e addigra desktop ;).

"nagy az overhead-je a C/S architektura miatt"

X.Org wiki szerint lehet, egy kicsit.

"Eroforrasnal gondolok itt a memorara, amit megeszik"

Egy alap X memóriafoglalása néhányszor 10 MB legfeljebb. 256 MB-ba már jó pár grafikus alkalmazás is belefér. Úgyhogy nekem nem úgy tűnik, hogy ez manapság jelentős. Érdekes lenne egy statisztika, hogy ugyanaz a (Qt vagy GTK) program Linux/X-en vagy Windowson eszik több memóriát, bár a shared libek miatt nehéz lenne megcsinálni.

Tehat van overhead, bar valoban nem grandiozus. Lehet, portolt architekturakon (mobil eszkozok, alacsony fogyasztasu, lasabb processorok) mar jobban erezheto, de ez mindenkepp egy folosleges kor, mikor a kliens es a server ugyanazon az eszkozon fut, es minden eroforras pazarlas karos.

Nehanyszor 10MB nekem rengetegnek tunik, plane, ha masok ezt toredekbol megcsianljak. Nekem nem kell halozaton keresztul XTerm, vagy XClock. Nekem az kellene, hogy hasonlo rendszer birjon futni egy gyenge gepen (pda, telefon, regi gep) es egy uj eszkozon (eros gep, akar jatekgep, mediabox) ... erre az X11 most nem kepes igazan hatekonyan, de a Wayland jo lenne.

Elolvastam a rövid ábrás architekturális leírást.

De pár dolog nem egészen világos, pl:

- Amikor más gépen futtatok Wayland klienst mint amin a szerver van, akkor ezt a megosztott videobuffer dolgot hogy oldja meg?

- Ha ezt megoldotta, és a helyi és távoli alkalmazások egyaránt hozzáférnek a megosztott bufferhez, hogy oldja fel a konfliktust: pl azonos területre rajzolnának?

- Egy távoli alkalmazás belenézhet a videobufferembe, és lelophatja/felülírhatja a képernyőmön lévő helyi alkalmazások által kijelzett adatokat?

"Amikor más gépen futtatok Wayland klienst mint amin a szerver van, akkor ezt a megosztott videobuffer dolgot hogy oldja meg?"

a wayland pont, hogy nem ilyet akar. erre ott a bloated x. a wayland egy pehelysúlyú szerver *localhost-ra*. és ez a felhasználók többségének tökéletesen elég is lesz. innestől a másik két kérdés már nem érdekes.

Fasza. Ha jól értelmezem, akkor beágyaznak mégegy réteget az X és a kernel közé. Azt erősen kétlem, hogy hirtelen a teljes disztribet átportolnák Wayland kliensekre...
A megoldás abból a szempontból jó, hogy a composition manager nem párhuzamosan fog futni az X-el, és emiatt javulni fog a rendszer teljesítménye (elmaradnak a damage eventek és azokra adott válaszok). Ami problémás, az a driverek kérdése. Kétséges, hogy a nagy gyártók csak az Ubuntu kedvéért nekiállnának Wayland drivereket reszelni.
KMS szép és jó, de nem más, mint egy igencsak régóta érő probléma (kernel szintű videódriver és API) igencsak lassú megoldása.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Javíts ki ha tévednék, de jelen pillanatban az Ubuntuban, a framebuffert használó alkalmazások kivételével, MINDEN GUI-s alkalmazás az X-et használja, beleértve a Compizt is. Feltételezem, hacsak nem vették meg fél india kóderkapacitását, a Canonical erőforrásai arra lesznek elegek, hogy a következő release-ben kikukázzák a Compizt és befűzzék a Waylandot az X szerver alá.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Szerintem nem gond, a "fontos" es "elterjedt" dolgok ugyis kb a nepszeru widget-eket hasznaljak mint a gtk meg a qt amit lehetne (sot screenshot-ok tanulsaga szerint valamennyire mar most is lehet) kozvetlenul wayland folott futtatni. Az X ott jonne a kepbe, ha kell valami "elvetemult" program ami kozvetlen xlib-re epul, vagy valami mas exotikus eset all fenn. Viszont par site-ot nezegetve meg a commentjeit, van aki mar felvetette, hogy kene olyan libx11/xcb ahol az API valtozatlan csak eppen wayland-ra "forditja at" a kereseket, igy elvileg ez is megoldhato, bar az X es a wayland architekturaja nem biztos, hogy ezt egyszeruve tenne ...

Imho olyan meg nincs, hogy "wayland driver" vagy en ertettem felre valamit; amennyire en latom, meglevo dolgokat (mint pl a KMS) hasznal, szoval csak azokat kene implementalgatni a driver iroknak amit most is megtehetnenek wayland nelkul is vegre, gondoljunk csak tenyleg a KMS-re megint, meg a nem root-kent futo X server abrandjara is, meg ha most nem is a wayland-ot nezzuk egy pillanatra ...

Azt nem mondanam, hogy a wayland az, hogy atkerulnek ... Elvegre a KMS is egy dolog, amit kernelben oldananak meg, es nem az X-nek kene csinalnia, megsincs koze a wayland-hez (illetve van, de ugy ertendo: joval elobb kitalaltak mint a wayland-et, az mas kerdes h a wayland is hasznalja). Nyilvan azert vannak olyan dolgok, ahol valtozas van/lesz, azert nem vagyok eppen se X server, sem pedig wayland szakerto, de altalanossagban jo iranynak tartom a dolgot. Persze mint mindent, ezt is lehet jol/rosszul csinalni. Meglatjuk ...

Na ez az ember sokat tesz azért, hogy eljöjjön a Linux desktop éve. :)
Remélem az egyik következő lépése a klasszikus fájlrendszer hierarchia kiiktatása lesz.

Így van, meg a mappák elnevezése is olyan hogy aki először látja annak egyáltalán nem triviális hogy mit is jelent pontosan. Értem én, hogy a 3 betűs könyvtárneveket egyszerű begépelni a parancssorba, csakhogy éppen oda kellene eljutni hogy az egyszerű desktop felhasználónak ne is kelljen tudnia, mi az a parancssor. Bár nem használtam soha OS X-et, az az elrendezés nekem is tetszik.

így van, ha elindítod a nautilust vagy dolphint (az átlag felhaználó ezekkel találkozik), akkor ott van a home, meg a mappáid, videók, zene stb.
Aki ebben eltéved az ... OSx alatt is ott vannak a 3 betűs könyvtárak, lévén UNIX meg POSIX szabványos (fixme). Ebben egyáltalán nincs külömbség mondjuk osx meg Linux + gnome,kde között.

java'nother blog

Ez így van, ráadásul a Gnome Shell és a Unity is abba az irányba indult el, hogy a felhasználónak abszolút ne is kelljen "szembesülnie" a fájlrendszerrel. Viszont ha egy adott alkalmazás fájljait akarom megnézni (ami ezért simán előfordulhat), akkor nyilván jobb, ha ezek egy helyen vannak, mint hogy ha ezek szét vannak dobálva. A GoboLinux-féle hierarchia nekem pl. kimondottan tetszik, és ha jól tudom az OS X is hasonlót használ (fixme).

De egyébként számtalan akadálya van jelenleg a Linux kényelmes felhasználásának desktopon, és jobban meggondolva tényleg nem ez a legégetőbb. Például az egyenesen egy rossz vicc 2010-ben hogy update közben nem lehet csomagokat telepíteni.

"Ez Windows alatt nincs így, az alkalmazás telepítője nézheti meg, hogy fut-e a process-ek között más telepítő."

de így van (hint). ha valami 3rd party telepítőt használsz, akkor azok persze nem fognak tudni egymásról (meg úgy alapvetően nem is akarnak, lesz ami lesz alapon), de ez kb. olyan, mint debian-on pkgsrc-zni. na, úgy apt-get update alatt is tudsz telepíteni, ja. de pl. próbálj meg adobe readert telepíteni jre telepítés közben. az eddig írtak alapján meg fogsz lepődni.

"Át kellene venni, hogy elsődlegesen shutdown közben telepítsen."

grat. szerintem is fasza ötlet, hogy egy program telepítéséhez kötelező jelleggel újra kelljen indítani a gépet.

Csakhogy sokkal inkább elterjedtek a 3rd telepítők, mint az msi (pedig tud pár nyalánkságot, mint pl. az AD-n keresztüli installáció).
Ezek többsége is tudd processz-eket figyelni, más kérdés, hogy a szállítók nem teszik be.

"grat. szerintem is fasza ötlet, hogy egy program telepítéséhez kötelező jelleggel újra kelljen indítani a gépet."

Nem ezt írtam.
Windows alatt out-of-the-box lehetőséged van, hogy az update-eket a leállítás közben telepítsd.
Így biztosan nem fog semmi bezavarni és nyugodtan hagyhatod a gépet teleépítgetni, amikor már nincs szükséged rá.

Windows alatt out-of-the-box lehetőséged van, hogy az update-eket a leállítás közben telepítsd.

Nem lehetőséged van erre, hanem bizonyos esetekben by design csak így lehet frissíteni, mivel a fájlrendszer kezeli a lock műveletet, egy megnyitott fájlt nem tudsz lecserélni amíg fut a program -- vagy fut az oprendszer.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

"Csakhogy sokkal inkább elterjedtek a 3rd telepítők"

1. citation needed
2. több != jobb

egy olyan programra, ami annyit csinál, hogy betolja a fájlokat program files\foobar alá, meg bejegyzi regitry-be, hogy "élek, itt vagyok", pont elég is egy 3rd party valami, az nyilván nem fog semmivel ütközni, ha egyszerre fut. ha valami komoly rendszerváltoztatásokat végez, akkor azért msi használhatóbb, már csak emiatt a konfliktuskezelés miatt is.

1) Bármelyik linuxos csomagkezelő egy rövid paranccsal megmutatja az adott csomag összes fájlját. A Synaptic és a YaST szép, grafikus felülettel nyújtja ugyanezt. A Windows-ban ugyanez nem lehet, vagy igen korlátozott, megbízhatatlan módszerekkel (pl. Revo Uninstaller vagy egyébb segédprogramokkal). A Linux csomagkezelése egyszerűen jobb, mint a Windows-é. Az rpm (de még a deb is) fantasztikus. És még a registry-nek nevezett borzalomról nem beszéltünk.
2) Hogyha a "U:\Buntu\Program Files\Sebastian Trueg and Friends\K3b" módszert követnénk, akkor hogyan válna lehetségessé pl. a /var vagy más típusú mappák külön, célspecifikus partíciókra való heylezése?
3) A Windows esetében sem települ minden program egy és csakis egy mappa alá. Sok alkalmazás telepítője ott is sokfelé tesz ezt-azt.

Tudom én használni a Gconf-ot, szoktam is, és tényleg hasznos (is lehet) hogy egy sorral terminálból ki lehet adni a config módosítást, és nem kell fájlt túrni. De ettől függetlenül tényleg kísértetiesen hasonlít a registryre.

Jó persze kevesebb szemét van benne, meg rendben van tartva, de ez nem a Gconfon múlik, hanem a fejlesztőkön.

meg tegyuk hozza, hogy csak a gnome, es a kapcsolodo programok tartjak ott a beallitasaikat, es nem az alaprenfdszer, ahol a leginkabb ciki, ha egy esetleges karbantartasi/helyreallitasi muvelet soran adatbazisban kell turkalni, es nem szovegfajlokban.
es a windows registry is "rendben" lenne, ha minden fejleszto betartana az ajanlasokat
(vagy szigorubban szabajoztak volna a hozzaferest mar az elejetol fogva)

Ezek szerint nem volt érthető, amit mondani akartam. Linux alatt a /bin, /tmp, /var stb. tartalmuk jellege alapján különül el. A /var mappába olyan változó adatok kerülnek, amelyek nem puszta ideiglenes (temporális) fájlok, de állandóan változhatnak. Jellemzően ilyenek például egy mail-szerver adatai. Namármost SOK programnak lehetnek ilyen adatai! Ergo rendkívül célszerű, hogy a különféle programok nem-változó fájlai egy bizonyos partíción legyenek, a változó (sokszor külső, hálózati forrás alapján változó) adatok pedig egy másik partíción - quota-val és egyébb biztonsági paraméterrel. Tehát ilyen szempontból még mindig a unix-os megoldás az elegánsabb, logikusabb, biztonságosabb (ami funkciójuk és viselkedésük alapján különíti el a programok telepített fájljait és képződő adatait). Amiről feljebb beszéltek, az egészen más. És nyugodtak lehetünk affelől, hogy hiába adsz meg egy biz. telepítési célmappát, hogyha a "setup" úgy van kitalálva, akkor bizony írogathat fájlokat máshova is. (Ilynek például az Adobe programjai.) A windows-os "setup"-nál megbízhatatlanabb, áttekinthetetlenebb telepítési megoldás nincs. Nagyon rossz.

Windowson is van, soft/hardlink valamint ott is lehet köteteket mappába csatolni.

Szóval, ha a program nem adna lehetőséget a saját adatfájljainak helyének kiválasztására (általában szokott, de ugye erre nem lehet alapozni), akkor még minidg lehet csinálni azt, hogy az adott könyvtárhoz becsatolunk egy másik disket.

----------------
Lvl86 Troll

Viszont ha 10 program mindegyikének a beállításait, vagy a változó adatait külön partícióra szeretnéd rakni, akkor nem tudod azt a partíciót 10 helyre becsatolni. Persze kézzel symlinkelgetni lehet, ha lehet tudni, hogy mit hol tárol a program. Ezzel csak akkor van baj, ha a valamikor a program abból a könyvtárból ..-tal hivatkozik a szülőkönyvtárra -ezt én Linuxon szívtam meg egyszer.

A UNIX világban ugye azért vannak külön dobálva a programok cuccai, mert más-más használati esetről van szó, és az akkori nagygépes környezetben számított, hogy egy-egy fájlrendszert milyen hardver szolgál ki.

Ez most kezd visszajönni az SSD-HDD hibridekkel, amikor tudatos döntés lehet az, hogy melyik fájlrendszert teszem SSD-re, és melyiket teszem HDD-re, mivel az SSD vs HDD ár/kapacitás aránya még igen eltérő, s a használati módjuk is igen eltérő, egy klasszikus UNIX fájlrendszer pedig szinte módosítások nélkül rátehető erre a filozófiára.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Mit jelent az, hogy update közben nem lehet csomagokat telepíteni?

Ami nekem erről beugrik, hogy az aptitude-ban kiválasztom, hogy ezt a 60 csomagot akkor upgrade-eljük, ezt a másik 10-et meg telepítsük, ha már úgyis erre járok, az megy.

Vagy a csomaglista frissítése (update) közben nem megy az install? Ez engem nem zavar :-)

Vagy hogy nem megy két install párhuzamosan, egyikben egy upgrade, másikban egy install? Persze, hogy nem megy, mert lockloja az adatbázist. Szerencsére egyszerre viszont megy, tehát ezt nem érzem nagy gondnak.

Vagy teljesen félreértem, hogy mit akarsz

Gyerekek, nem azzal van gond, hogy ismeretlen és ijesztő nevű mappákban kell turkálni, hanem azzal, hogy nem alkalmas a mappa/könyvtár elgondolás arra, hogy normálisan, áttekinthetően eltároljuk a dolgainkat.

Egy filmet ne a letöltések mappában, vagy ne a videók mappában, vagy ne az archívum mappában kelljen keresni, ne kelljen emlékeznem arra hogy hova tettem, hány példányban van szétszórva, stb. Sokkal emberközelibb megoldás lehetne, ha függően attól hogy mit szeretnék a gépen lévő adatokat szempontok alapján listázhatnám. Ne attól legyen valami videó, hogy én a videók mappába raktam, hanem attól, hogy az. és ne legyen érdekes hogy hol van, milyen mappában. Ne is legyen ilyen dolog, hogy mappa. Cimkék legyenek, és legyen annak a filmnek "2. évad" és "Stargate" cimkéje. A típusa pedig ne avi, vagy mpg legyen, hanem az, hogy videó. Ezt kellene látnom a felszínen, de igazság szerint az sem jó, ha a mostani mappaszerkezetekre van építve tíz-húsz réteg, ami indexeli a fájljaimat, lassítja a rendszeremet, megákat eszik a memóriából ahelyett, hogy eleve a fájlrendszer, a kernel, a gui úgy lenne kialakítva, hogy ezt támogassa.

Nem tudom hogy lehetne kilépni ebből a mappa elgondolásból, szerintem nagyon nehezen. Mindenki rétegetet épít, hogy a visszafelé kompatibilitás meglegyen, pedig ebből csak az van, hogy lassan egy betű kiírásához több munka kell, mint amennyit egy 286-os egész életében dolgozott...

akkor meg a cimkekbe fogsz belehulyulni elobb-utobb.
felcimkezni mindent (most a 2.-exemmel karacsonyi stargate nezes kozben keszult pucer fotoinkra milyen cimket tegyek?) es a vegen mar annyi cimked lesz, mint file, es egyszerubb lenne mar mindent a /-alatt omlesztve tartani...
tartsd a fejedben az adatbazist (az adataidrol), legyen egy szisztemad, es akkor nem kell szegeny konyvtarakat basztatni, meg 10-20 reteget meg folejuk huzni.
problema megoldva ;)

Nem kell felcimkézni mindent, legalábbis nem jobban, mint most teszi az ember. A különbség annyi lenne, hogy a mappastruktúra elemei közvetlenül elérhetők lennének, és felcserélhetők

pl fényképek csoportosításánál:

fotók/2010/kirándulás/tokaj mappába sorolhatnád a képeket

No de mi van, ha neked az összes évből kellenek a kirándulások? Persze össze lehet zsonglőrködni terminálban, meg guin is szerintem, de a lényeg, hogy gyorsan és egyszerűen elérd ezeket a fájlokat.

Cimkékkel ha csak annyit teszel, hogy a mappaneveket használod cimkének, akkor tudsz olyat csinálni, hogy

fotók/kirándulás
vagy fotók/tokaj, és itt nem muszáj kirándulásnak lenni.

Szóval nem hiszem hogy nagy plusz munka lenne az embernek. A rendszertervezőknek már inkább, mert a világnak így kellene működnie: A fájloknak hordozniuk kellene a cimkéket magukkal ha pendrive-ról hozod, vagy ha netről töltöd akkor is.

>de a lényeg, hogy gyorsan és egyszerűen elérd ezeket a fájlokat.
gyorsan, es egyszeruen erem el a fajlaimat
a peldanak hozott fotokatalogizalasra pl. shotwell-t hasznalok
>mert a világnak így kellene működnie
=DDDDDDDDDDDDDDDDDD
szerinted

az egesz vilagmegvalto otleteddel az a baj, hogy mar tobben is regota probalkoznak
vele, de ugy altalaban az embereket nem erdekli. a file/folder struktura is azert lett sikeres, mert egy irl is alkalmazott koncepcio logikus folytatasa a virtualis terben. az emberek (a gepek meg plane) legegyszerubben ugy talalnak meg valamit, ha tudjak, hol hol van. zokni also fiok, anyos darabjai kozepso, gatya felso. mas modszerhez akkor folyamodnak, ha ez nem vezet eredmenyre. de akkor is, altalaban visszaemlekezel a tulajdonsagaira, es abbol probalsz kovetkeztetni, hogy *hova* tehetted.

inkabb fog maga a file fogalma kihalni (legalabbis a fogyasztoi retegben) es terjednek majd az ipad fele interfacek, ahol vannak a "zenek", meg a "kepek", a "filmek", az "emailek", meg a ""word"-dokumentumok" amiket a hozzajuk tartozo applikaciobol lehet abuzalni, de olyannal, hogy fajl, a user nem fog talalkozni.

A zoknik ritkan szoktak cimkek alapjan elougralni a fiokbol, szoval feleslegesen ne hozz olyan hasonlatokat egy tok trivialis problema leirasara, ami ugysem illeszkedik.

Egyebkent sem latom, miert ne mukodhet a ket modszer egyszerre (nagyon alap szinten ma is mukodik) es egyebkent egyet tudok erteni a cimkezos kollegaval, van akinek szuksege van ra. En pl sokkal szivesebben keresnek a fajlok metadatai alapjan nem csupan a gepemen, de az interneten is...

>A zoknik ritkan szoktak cimkek alapjan elougralni a fiokbol
ezert jo pelda :) mert nem minden fajltipusra lehet jol metaadatok alapjan keresni
>a ket modszer egyszerre
igy egesz mas
>En pl sokkal szivesebben keresnek a fajlok metadatai alapjan
lsd. feljebb, ez nalam is igaz a zenekre, meg a kepekre, de ez mar nem a fajlrendszer/fajlkezelo feladata, es ez *szerintem* jol van igy.
aki meg sok dokumentummal dolgozik, annak jelenleg is vannak tartalomindexelos
megoldasok, amiknek a teljesitemnyevel sincs semmi baj, ha csak arra a szajbalokott *dokumentumok* mappara kapcsolja be a teljesszoveg-indexelest.
a lenyeg annyi, hogy ne ontsuk ki a furdovizzel egyutt a gyereket is
a file/folder hiearchianak pont a trivialitasa miatt mindig lesz letjogosultsaga
hogy bizonyos feladatokhoz milyen rendszerezesi metodust alkalmazunk meg
mellette, az mar mas tema.

meg azok szerint is, akik az indexelőket létrehozták, meg azok szerint, akik a wordpresst csinálták, és nem fájlkezelőt, hanem médiatárat adnak az usernek, meg a flickr fejlesztői szerint akik nem mappáztatják a képeket, hanem cimkézgetik, meg a többi ide kommentelő szerint (sokkal több nem jut az eszembe, de biztos nem csak én gondolom így)

Nem használom fő rendszerként szóval lehet hogy lemaradtam valamiről, de azért ott is csak mappák vannak. nem igazán tudom hogy tudnám megjeleníteni egy ablakba a képeimet azon kívül, hogy rákeresek arra hogy képek.

Egyébként a problémám ezzel, meg az összes informatikai fejlesztéssel ami manapság jön az az, hogy csak egy plusz réteget raknak a mostani megoldás fölé. Ez két okból problémás: Egyrészt: egyszer kelljen a rétegen kívül dolgoznod a géppel valamiért. Pl: Linux alatt is vannak indexelők, meg ilyesmik, de nem igazán integrálódnak a rendszerbe. Ha én nyitok egy terminált ott a "régeten kívül" vagyok, szóal ugyanúgy fájlokkal találkozom, és máris nem érem el azokat a funkciókat amik az asztalon megvannak.

A másik gondom az, hogy szarra akarunk várat építeni - már elnézést. Ez a rohadt sok réteg felesleges lenne, ha a kernel vagy a fájlrendszer alapból támogatná ezt. Persze millió kompatibilitási probléma jönne vele, ezért nem igazán tartom megvalósíthatónak, de legalább valamivel gyorsabb lenne, mert nem egy indexelőnek kellene a háttérben dolgoznia, memóriát ennie, stb.

Sajnos ma minden olyan sok erőforrást eszik, hogy nem győzök csodálkozni. Nem tudom találkoztatok-e a minecraft-tal. A Doom2-nek volt ilyen grafikája, és szaggat a nem túl új, de azért WoW-ra alkalmas gépemen. Holott lehete gyorsabb is. Ugyanez a helyzet az indexelőkkel, ne legyenek erőforrászabálók ha nem muszáj.

Miért néztem be?. Gagyi szar grafikája van, és tudom, hogy a proci is dolgozik rendesen mögötte, de azért ne 5-10 fps-t toljon amikor egyhelyben állok. A példa arra jött, hogy tuti lehetne optimalizálni jobban, hogy esetleg gyengébb gépeken (mint az enyém) elfusson.

Azért írtam mert nem jó összehasonlítani a 2 motort. Egyik bsp alapú az adott architektúra futtatási környezetére optimalizálva, a másik voxel alapú ráadásul egy virtuális futtatási környezetben. Talán a hasonlóság a kettő között hogy mindkettő software rendered, de ezenkívül semmi más.

Értem én, oké. Nagyjából tudom, hogy azért több dolog megy a háttérben, megértem miért lassú, de futtattam ugyanezen a gépen WoW-ot is, ott sokkal részletgazdagabb textúrák, és bonyolultabb objektumok vannak. De írtam is, tudom hogy a cpu dolgozik sokat. Viszont abban is biztos vagyok, hogy meg lehetne oldani gyengébb gépekre is ugyanezt. A problémám az volt, hogy nem teszik. Itt is van fölösleges réteg a java képviseletében. Lehet vitatkozni hogy a java virtuális gép mennyire lassít, vagy nem lassít, de valami overhead biztos van. És ez a bajom azzal, hogy sokminden felesleges rétegekre van építve

Tény, hogy lassít valamennyit a Java, de nem ez a lényeg.

Tapasztalataim szerint a VGA kártyáknak limitált az, hogy hány poligont képesek lerenderelni. A VGA kártyákat is a játékok igényei alapján fejlesztik, az meg jelenleg az, hogy viszonylag low poly modelleket használnak, aztán shaderekkel trükköznek.

Ezzel szemben a Minecraft alapvetően buta grafikus objektumokkal dolgozik, de abból viszont akár rengeteggel. Persze, ezen is lehet optimalizálni.

De majd valaki témában okos ember elmondja, hogy akkor mi is az igazság.

----------------
Lvl86 Troll

Ki címkézné fel neked ezeket a dolgokat? Szerintem több idő felcímkézni egy fájlt, mint beletenni egy mappába. Ha automatikusan menne biztos lehetsz-e abban, hogy tényleg jól van-e megcsinálva, egyáltalán támogatja-e minden formátum, hogy valamilyen kategorizáló információt is szolgáltat magában? Pl. MP3 id tagek esetén működne, JPG EXIF adatokkal ki lennél segítve? Mekkora tűrése lenne a címkéknek? Pl. én meg tudnék őrülni, amikor a médiatár alapú zenelejátszó megkülönbözteti a kisbetű-nagybetűvel írt zenekarneveket, ha egyetlen mappára uszítanám rá az egyszerű lejátszót, semmi ilyen gondom nem lenne. Esetleg ha elírom a címkét, megkérdezze, hogy nem másra gondoltam-e és ajánljon fel mást? Elég komplexnek tűnik ez ahhoz, hogy minél mélyebb rétegben legyen megvalósítva, és akár szabvány lehessen (értsd: rendszerről rendszerre másolva ugyanúgy működjenek a címkék).

igen, komplex, írtam is feljebb másokhoz reagálva :)

A cimkézést egyébként ugyanúgy csinálnád mint a mappázást. De nézd így: Ha csak annyi változna, hogy nem ragaszkodunk a mappa struktúrálásához már jobb lenne a világ. Szóval ha felcserélhető lenne a sorrend a mappanevek egymás után fűzésében, és egy mappa tartalmazná az almappák elemeit.

pl a képek mappába lépéskor az összes kép látszana, és ha külön pipálsz hozzá olyat, hogy 2010, vagy hogy kirándulás, akkor szűkülne a lista. de nem a 2010 alatt lenne a kirándulás, és nem a kirándulás alatt a 2010, hanem egymástól függetlenül elérhető mindkettő, de egybe is foglalható

(nehéz a fogalmazás így reggel 4kor)

A forráskód sima szöveg. nem igényel külön erőfeszítést szerintem, hacsak nem akarsz vele foglalkozni, mert akkor lehet kitalálni hozzá cimkéket. Na az audiot tényleg kihagytam, meg biztos van még valami, de azért néhány nagyon hasonló adattípus köré épül a világunk, még ha millió fájltípus létezik is.

Aki nem képes fiókokban tájékozódni, aki nem emlékszik a fiókjaira, az sajnos értelmi fogyatékos, és nem alkalmas számítógép kezelésére. A konyhában, a ruhaszekrényben, a való életben mindenhol így tájékozódunk. A "fiók + (indexelt) keresés" módszerénél nincs jobb megoldás.

Nem a képességről van szó, hanem a kényelemről. Ráadásul nem mindegy, hogy mennyi adatot kell feldolgoznod. Gondolkodj egy fotós szemével, aki 10 évnyi termést tárolna, és vannak helyszínek, események, időpontok, szereplők ami szerint csoportosíthatod a képeket, és ott már nagyon nem mindegy hogy dátum/helyszín vagy helyszín/dátum szerint csoportosítod (ha hirtelen kellenek a 2010-es képek akkor az utóbbi, ha hirtelen kellenek a budapesti képek akkor az elöbbi a jobb, de egy választás behatárolja a lehetőségeidet). Nem tudod könnyen listázni például azokat a képeket amin "zoli szerepel, és 2009-ben készültek. Cimkékkel ez marha könnyen menne.

Egyébként a való életben is nehezebb a mappákat kezelni, csak ott nem igazán tudunk cimkékben gondolkodni, mivel nem igazán van olyan rendszer ami a cimkézett dokumentumokat az arcunkba tolja ha kérjük, a mappákat viszont könnyen kézbevesszük.

De elég nagy fejtörést tud okozni, amikor szolgáltatótípus szerint rendezted a számláidat mappába, és hirtelen az idei számlákat kell előszedned valamiért. Túrhatsz végig 5-6 mappát.

Ezzel megint csak az a baj hogy plusz réteg, ami erőforrás, meg nem általánosan elérhető. Hiába tagelem be egy programban a fotóimat, ha azokat másolva egy másik gépen másik programban ugyanúgy be kell tagelnem. És nem csak fotót lehet tagelni, hanem mindent amit most mappába raksz. Hiszen a mappába rakás is tagelés, csak sokkal megkötöttebb.

"Ezzel megint csak az a baj hogy plusz réteg, ami erőforrás"

Helyette tegyük bele a filerendszerbe, hogy az is lassuljon miatta, ami csak egy sima, "hagyományos" fileművelet lenne?

"meg nem általánosan elérhető. Hiába tagelem be egy programban a fotóimat, ha azokat másolva egy másik gépen másik programban ugyanúgy be kell tagelnem."

A tagelés se. Hiába tageled be egy jövőbeli, tagelést kezelő filerendszeren a fotóidat, ha azokat másolva egy másik gépen, másik, tagelést kezelő filerendszeren ugyanúgy be kell tagelned.

"És nem csak fotót lehet tagelni, hanem mindent amit most mappába raksz."

Nem tudok elképzelni olyan élethelyzetet, hogy pl. bármiféle forráskódot ne szimplán egy vcs repo-jában tároljak, hanem azon túl még tagelni is akarjam.

"hogy az is lassuljon miatta, ami csak egy sima, "hagyományos" fileművelet lenne?"

Egyetértek, ez korrekt meglátás.

"azokat másolva egy másik gépen, másik, tagelést kezelő filerendszeren ugyanúgy be kell tagelned."

Ez van most. De ha kicsit rendszerközelibben lenne megoldva, akkor már nem kellene. Mint ahogy a fájlneveket sem kell minden gépen újra megadnom, vagy a módosítás dátumát, vagy a többi adatot amit a fájlrendszer tárol.

Forráskód: Persze hogy nem akarod tagelni, nem is arról van szó, hogy miden fájlt vadul neki kell állni cimkézgetni. A forráskódokkal nem kell foglalkozni. Elhelyezhetők azok szépen cimkés rendszerben ugyanúgy mint mappában. Csak pasziánsz mappa helyett pasziánsz cimke lesz. esetleg egy plusz forráskód cimke (ahogy most is van src mappa)

"Ez van most. De ha kicsit rendszerközelibben lenne megoldva, akkor már nem kellene. Mint ahogy a fájlneveket sem kell minden gépen újra megadnom, vagy a módosítás dátumát, vagy a többi adatot amit a fájlrendszer tárol."

És ugyanez lenne tageléssel is. Valahogy nem bízok benne, hogy majd kompatibilis módon implementálják a tagelést különböző OS-ek különböző filerendszereiben.

Valóban. Aztán megszületik az igény, hogy az legyen, és az lesz. Van ntfs linux alatt, mert volt rá igény, úgyhogy lesz egységes cimkéző fájlrendszer mindegyik rendszer alatt, ha lesz rá igény. Addig meg szívunk az inkompatibilitás miatt, mert ez már csak így szokott lenni.

>Ezzel megint csak az a baj hogy plusz réteg, ami erőforrás, meg nem általánosan elérhető
nem is kell annak lennie. egyszeruen egy "altalanos", a fajlkezelobe epitett metaadat alapu rendszerezes nem lehet minden tipusu informaciora hatekony. probaltal mar svajcibicskaval fat vagni? a fureszessel? ugyan lehet, de azert joval egyszerubb es gyorsabb egy motoros lancfuresszel.
ugyan ez igaz pl. a kepkatalogizalasra. amug is szuksegem van egy kepkezelo szoftverre, akkor meg mar miert ne tudja a kepek katalogizalasat is egy fust alatt? es akkor rogton ezt a szoftvert inditom, es nem a fajlkezelot, szoval nem +1 reteg, hanem egyik helyett a masik. a kepek mappan belul a tenyleges mappa/fajl strukturaval nem is kell foglalkoznom, az intezi nekem a shotwell

egyelőre mégis fájlrendszert használunk. kitalálod, hogy az egész úgy szar, ahogy van, közben meg csak arról szól a történet, hogy képtelen vagy rendet tartani és/vagy szar a memóriád. az indexereket és ilyen-olyan library-t használó programokat meg egyenesen ignorálod (pl. dokumentumokra, zenére, képekre 100%, hogy létezik ilyen, de videóra valószínűleg szintén).

mindössze annyit kéne csinálni, hogy a karácsonyi képeket nem egy random mappába tolod be, hanem mondjuk a "karacsony 2009"-be (nagyon megerőltető). ezután pl. a windows search pár mp-n belül megtalálná. de nem, inkább címkézzünk fel minden rohadt fájlt kézzel, mert hát az mennyivel jobbabb. képtelenek vagytok meglátni az analógiát, hogy sok fájlt ugyanazzal a címkével ellátni pont ugyanaz a hatás, mint ugyanabba a mappába tenni. a több címke meg a hierarchiával váltható ki. ha ti ezen nem tudtok úrrá lenni, jobb lenne, ha nem használnátok gépet. bár egyáltalán nem tudom, miért olyan hatalmas probléma ez, én sosem éreztem szorongást egy mappa megfelelő helyen, megfelelő névvel létrehozásakor.

1) nem szarozom le, csak osztom sokak véleményét, miszerint elavult, és egy cimkés rendszer előnyösebb lenne

2) tényleg szar a memóriám, és tényleg nem tudok rendet rakni. Gondolkozz el a következőn: Suliba járok, az összes beadandót, tananyagot mappába teszem évekre lebontva, azon belül tantárgyakra. Aztán hirtelen kell nekem az összes matek anyag. Nem egyszerűbb rábökni a "matek" cimkére, mint végigmászni az összes év mappáján? Naugye hogy igen. És ez bizonyítja, hogy *ebben* nagyon jó ez az elgondolás. Azt még senki nem mondta meg, hogy miben lenne rossz :)

3) amiről te beszélsz az cimkézés. Csak épp a mappanév tartalmazza a cimkéket (karácsony, és 2009), és ezekre keresel, illetve a keresővel szűrsz. Egyébként így tárolom a cuccaimat, nem is halok bele, de mondom, van egyszerűbb. Nagyon hülye példa: az ács keresőkifejezésre bejönne a karácsony, a cimkéknél talán ez meg lenne oldva.

4) A windows search (vagy akármelyik) nem igazán találja meg pár mp alatt, nekem egy find és grep kotor az 1T vinyómon 5 percig amikor keresek valamit. És igen, nem használok indexelőt, mert nem igazán van sok memóriám :)

5) Sehol nem mondtam, hogy mindent fel kell cimkézni kézzel. Ugyanannyi erőfeszítést jelentene, mint most jelent mappába pakolni a cuccokat. A különbség annyi lenne, hogy a karácsony 2009 mappa helyett a karácsony és a 2009 cimkékre rángatod rá a képet a fényképezőgépről.

Ha már itt tartunk nevezhetjük a cimkét mappának, és látványra annyi lenne a különbség, hogy ugyanaz a fájl több mappában is ott van, de mégsem létezik több példányban.

6) A hierarchiával már említettem mi a probléma, az alsóbb szinten lévő elemekbe nem tudsz belépni a felsö kihagyása nélkül (pl a karácsony/2009-ből csak a 2009-be ha a 2009-es dolgaid kellenek.

Bírom egyébként, hogy ha valaki a bevált és megszokott módszerek ellen szólni, azt nagyon leszólják :)

>És ez bizonyítja, hogy *ebben* nagyon jó ez az elgondolás. Azt még senki nem mondta meg, hogy miben lenne rossz :)
azt nem irta meg meg senki, hogy a gyakorlatban ez a cimkezgetos modszer hogy mukodne. mert igy korulirva nagyon szep, csak hat a megvalositasa, es azutan persze a mindennapi hasznalata mar mas kerdes.
lentebb irtal egy peldat, hogy egyik, meg masik cimkere ("mappara") huzod ra a fenykepeket. oke. a cimkek hogy lesznek kategorizalva? a mentes parbeszedablakban ott lesz omlesztve az osszes user adat cimke? vagy azok is mappakban lesznek? :D esetleg lesz egy keresobox, amivel lehet szukiteni a listat? es aztan rahuzom a fajlokat, majd egy masikat is keresek, arra is, esigytovabb, vegul mehet az import?
szinte latom, ahogy az osszes r=1 user elso dolga egy "asztal" cimke letrehozasa lenne, es oda omlesztene mindent ..
ez a baj ezekkel a szep otletekkel, hogy csak nagyon egy szempontbol nezik a dolgokat. lehet, hogy a fajlok visszakeresese bizonyos esetekben gyorsabb, de cserebe a mentes/kategorizalas lesz idoigenyesebb, es raadasul a rendszer komplexitasa is nagysagrendekkel megno. vagyis roviden: amit nyerunk a reven, azt elveszitjuk a vamon. minden szempontot merlegelve, a mappa/fajl felosztas a "legkisebb rossz"

Nem te leszel aki ezt implementalja majd, ezert sem ertem miert faj ha mas mast akar, kulonosen annak fenyeben hogy a ket modszer siman megfer egymas mellett es valoszinuleg csak egymast egeszitene ki. A tippelgetest arrol hogyan mukodne, mi mennyibe kerulne, de kulonosen az elegansan levont kovetkeztetest a hozzaszolasod vegen mar csak megmosolyogni tudom.

létezhetne.

most így találod meg ezt a fájlt: view-services-mp3tunes-amarok.png

/share/kde4/apps/amarok/icons/hicolor/16x16/actions/

cimkékkel meg így:

share, kde4, apps, amarok, icons, hicolor, 16x16, actions

De lehet, hogy kevesebbel :)

Ha észreveszed: TÖK ugyanaz mint ha mappa lenne. A hierarchia hiányozna egyedül, de a legtöbb esetben az nem probléma.

Nagyon jó, hogy vannak címkék a KDE4-ben, de én nem örülnék neki, ha csak a címkékre korlátozódnánk. Aki nem a desktopon matat, nem a dokumentumai közt, annak valószínűleg nincs szüksége a címkékre, desktopon viszont kifejezetten kényelmes és hasznos, csodálom, hogy ez a KDE-n kívül nem igazán terjedt el. Az viszont desktopon sem tetszene, ha nem lenne hierarchia, mert önmagában a címkézéssel elég könnyű káoszt kreálni.

mostanában pl. egy könyvtárban levő xml fájlokat kell kezelni. Van pár ezer. Vagy pár tízezer? Nem tudom.

Egy szimpla ls is eszméletlenül soká tart.

Ha nincs hierarchia, hanem minden fájl be van hányva egy helyre, félek, ugyanez lenne.

Nekem a rendszerfájlok hierarchiájával nincs bajom, a sajátjaimat meg rendezem cimkével is, hierarchiával is. Bár cimkével sokkal kevesebbet, főleg csak a fotóimat.

G

Egyetértek veled, nem egyszerű ha az implementálást végig kell gondolni. Talán jó megoldás lenne ha adattípusokban gondolkodnánk. Pl a desktopon ott van a képek, zenék, videók mappa mint most akármelyik rendszeren. és amikor a képekre nyomsz akkor bizony bejön ömlesztve minden, és oldalsávban cimkékből szűkítesz, pl hozzápipálod hogy 2009, badacsony, vagy videóknál hogy stargate, 2. évad. A google docs-ban is lehet cimkézni, bár ott hibrid mappás megoldás van. Azt jónak tartom.

"És igen, nem használok indexelőt, mert nem igazán van sok memóriám :)"

Pedig csak a fájlrendszerről kellene legalább plain text-be egy find kimenetet lementeni :)

Aztán ezen lehet okosítani mindenféle fast text search megoldással.

----------------
Lvl86 Troll

A te agyad hogy dolgozza fel, hogy csak azért, mert neked nem tetszik sokak még előnyösnek tarthatják? :)

Csak azért, mert én említem meg, nem jelenti azt, hogy csak az én véleményem, és én tartom jónak. Mások is írták, valaki feljebb egy blogjbejegyzést is pakolt be, ami egész jól kifejti miért jobb a cimke alapú adattárolás. Vagy guglizz rá, ha nem hiszed, hogy nem csak az én véleményem, engem nem érdekel. :)

Adj hozzá még egyet. Szerintem is jó dolog. Viszont a hagyományos fájlrendszer-hierarchia „lecserélése” címkékre hülyeség. Mindkettőnek megvannak a maga pozitívumai. Desktopon a kettőt együtt használva nagyon jól rendezett dokumentumokat kapunk. Szóval egyáltalán nem faszság, ha a hagyományos struktúra _mellett_ használjuk. Egyébként milyen DE-t használsz? :)

No most megpróbáltam anyám szemével nézni a bubuntut. Elment egy fájlt. Alapértelmezetten feldobja neki a home tartalmát a "Save" ablak, abban lát Dokumentumok, Zenék, stb. mappát. Nem fog feljebb lépni, elmenti oda, ahová való. Na most ezek után elfilóztam, hogy a lányok a cégnél mit csinálnak Win7-el. Ugyanezt, Azt sem tudják, hogy a C-meghajtón van más mappa is. Szóval én nem igazán érzem értelmét a változtatásnak r1-user szempontból. Az persze más tészta, hogy admin részére, vagy rendszertechnikailag van-e létjogosultsága egy változtatásnak (én elvagyok vele, hót' logikus -> na jó, vannak néha varázslatok, bevallom, de nem vészes). Erre viszont ott a csomagkezelő. Gobo féle változtatásnak akkor van értelme, ha nincs csomagkezelőd. Ubuntunak viszont van, s köszöni, jól működik. Tehát megint eljutottunk oda, hogy r1 és admin szempontjából minden működik, telepíteni mindkettő tud, Dokumentumok a helyén...
No persze lehet, hogy én gondolom rosszul, ennek jogát fenntartom :)

Ennél egy dolog tud szebb lenni, amikor az r1 user mindent az asztalon tárol. És akkor jön a következő sztori. Elpusztult windows, újratelepíteni egyszerűbb és gyorsabb, mint a régibe életet lehelni, tehát:
"-Kell-e valamit elmenteni a merevlemzről? (ez a kérdés már lehet bonyolult, inkább "Van valami fontos a gépen?")
- Nem, nincs.
- Biztos?
- Biztos!
- Akkor sika.
tik-tak-tik-tak
- És ami az asztalon volt, az hová tűnt?
- Kérdeztem, van e fontos a gépen, azt mondtad: nincs.
- Mert az nem a gépen volt, hanem az asztalon.
- ÁÁÁÁÁÁÁÁÁ!"
Egyszer futottam bele ilyenbe. Azóta nem kérdezek, csak automatikusan mentem a "dokumentumok" mappát, az asztalt, meg az appdatából a mozilla/thunderbird mappát ha van. (Ha nincs rákérdezek böngésző/levelező cuccainak mentésére és aszerint)

Szerk.:
Ill. bocs, van ennél jobb. Amikor a fontos dolgokat egy kedves ismerősöm a kukában tartotta. Én meg azzal kezdtem a "rendrakást", hogy ürítettem a kukát. Jujujujjuj...

Hasonló helyzet, mint az "asztalosnál", -kicsit én is "hibás" voltam benne. Ugyanis állandóan szívtam a vérét, hogy micsoda kupleráj van folyton az asztalán. Tudod, mikor így fényképek, dokumentumok, skype telepítő, skype telepítő(2), flash telepítő, stb, és megtölti a 1600*1200-as monitort. Úgyhogy mikor szólt, hogy "valami gond van, meg kellene nézni" előtte fogta és egy lasszóval az ikonokat belehúzta a kukába, hogy ne csesztessem miatta. Mondván, hogy majd utána visszateszi.
Azóta erről leszokott, én viszont hajlamos vagyok idegen gépnél mindig megkérdezni, hogy lehet-e üríteni a kukát. Az ördög nem alszik. :)

Remelem meg az elejen gondolnak a remote desktop , ill. desktop rogzites temara is.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Márpedig - a fellelhető leírások szerint - a Wayland nem támogatja a remote desktopot.

De lesz megoldás: kompatibilis üzemmód vagy erre a célra fejlesztett szoftver. Egy ssh és hasonlók kedvéért nem sok értelme van ezt a bonyolult architektúrát fenntartani. Sok meló lehet a karbantartása és egyre kevesebb a haszna. A klasszikus távoli futtatás csak kevés helyen szükséges, jellemzően ott, ahol az X kliens komoly CPU teljesítményt igényel. A mai hardverek mellett erre egyre kevésbé van szükség.

Az X már réges-rég megérett a cserére. A régi fejlesztők azt mondják, hogy ha újrakezdhetnék, akkor eszük ágában sem lenne platformfüggetlen módon megírni, hanem kihasználnák a futtató kernel szolgáltatásait.

NB: A Windows nem támogatja, mégis lehet távolról adminisztrálni, sokféle megoldás van rá. Távoli meghajtók kezelése, audio/video stream hálózaton, stb. szintén megoldott.

Mondjuk azért mert az Ubuntu a desktop felhasználókat célozza meg? És az Apple valamit nyilván jobban csinál mint a Linux disztribútorok, tekintve hogy van kimutatható részesedése a desktop piacból...

És attól hogy valaki egyszerűen és kényelmesen használható desktop OS-t akar egyáltalán nem hülye, sőt éppen hogy ez a normális.

Az a különbség, hogy az Apple mindig is a desktop (és nagyrészt hülye) felhasználókat célozta meg, míg az Ubuntunak (még ha az is a célja, hogy a hülyék használják) jelenleg a felhasználói jó része haladóbb az átlagnál. Megtehetik, hogy a hülye felhasználók megszerzése céljából elidegenítik a haladókat, de ez jelenleg jelentős veszteséget okozna, nem csak a felhasználók számában, hanem a fejlesztésben is, hiszen a tesztelők, potenciális közösségi fejlesztők a haladó felhasználók közül kerülnek ki.

Ha nem csak egy marginális réteg (< 1%) operációs rendszere akarnak lenni, akkor ezt az utat kell követniük. Amúgy meg továbbra sem értem miért lenne hülye az aki minél egyszerűbben használható oprendszert akar desktopra.

Szerintem a Canonical nagyon jó irányba indult el, Shuttlework igazi 'benevolent dictator', ilyen emberre van szükség. Jó, hogy nem hagyja magát a közösség által befolyásolni, és nem adja fel az utat amin elindult, mert az mára már gondolom mindenkinek tiszta hogy a közösségi fejlesztés elvével tökéletes ellentétben van az innováció.

"Ha nem csak egy marginális réteg (< 1%) operációs rendszere akarnak lenni, akkor ezt az utat kell követniük."

Nem, akkor meg kell felelniük a haladó felhasználók és az átlag elvárásainak is. Ha erre nincs erőforrás, akkor végképp nincs erőforrás arra, hogy a haladó felhasználókból álló közösség nélkül fejlesszék. Nem csak az számít, hogy a felhasználóknak mekkora része haladó, hanem az is, hogy a jelenlegi potenciális felhasználóknak mekkora része. A Linux potenciális felhasználói között a haladók aránya fokozatosan csökkenhet esetleg az átlagos szintig, de nem lehet átugrani azt az időszakot, amíg a haladó és az egyszerű felhasználók is sokan vannak.

"az mára már gondolom mindenkinek tiszta hogy a közösségi fejlesztés elvével tökéletes ellentétben van az innováció."

Nem. Az innovatív fejlesztés elterjedésének esetleg.

"Megtehetik, hogy a hülye felhasználók megszerzése céljából elidegenítik a haladókat"

Én azt nem értem, hogy ez miért törvényszerűség. Miért jelenti a felhasználóbarátabb, egyszerűbb azt, hogy funkciószegényebb, kevesebbet tud?

Lehet, hogy átláthatóbb a nagyon kezdőnek, de egy idő után a használhatóság rovására megy. Szerintem lehet programot tervezni úgy, hogy átlátható legyen, de a haladó eszközök is kényelmesen elérhetők legyenek.

Nem hozzám szólt a kérdés, de válaszolok egy példával:
Suse Yast. integrált rendszerbeállítóeszköz meg miegymás. Azon keresztül jól be lehet állítani a gépet, de ha már a szöveges konfigot szerkeszted, akkor lehetnek problémák...

Ez csak fél válasz volt, mert nem törvényszerűség, de megeshet könnyen szvsz.

"Tipikus user"

Pont arról volt szó, hogy a haladó felhasználóknak is megfelelőnek kell/kéne maradnia.

"nem akar beállítani semmit"

Amíg minden alapból úgy működik, ahogy akarja. Ez viszont csak akkor lehetne így mindig, ha gondolatolvasást implementálnának a rendszerbe.

Amúgy (Boobek-nek) a YaST szerintem pont jó arra, hogy aki sok mindent állítgatni akar, az is kényelmesen tehesse; a config fájlokkal nem szokott problémám lenni, legföljebb néha másik config fájlt kell módosítani.

"Amíg minden alapból úgy működik, ahogy akarja. Ez viszont csak akkor lehetne így mindig, ha gondolatolvasást implementálnának a rendszerbe."

Lehet, hogy nekem alacsonyak az igényeim, de a Win7 beállításait a telepítés óta (kb. 6 hónap) nem kellett piszkálnom, és szerintem a felhasználók elsöprő többségénél ugyanez a helyzet.

El kell dönteni, hogy a Linux akar-e egyáltalán valamit a desktop piacon. Ha nem, akkor minden jó ahogy van, ha igen, akkor ezt az utat kel követni.

Erről csak az jut az eszembe, hogy amikor az iphone-t kidobták akkor nem lehetett hátteret állítani, aztán idővel megjelent a jailbreakelt iphone-okhoz program ami megoldotta, később megjelent natívan a funkció. Pedig háttérkép nélkül is jól működött a telefon. Lehet sokan maradnak a fekete háttérnél, vagy az alapnál, de attól, hogy be lehet állítani még nem lett bloated, viszont azoknak akik szeretik egyedi képpel felruházni a rendszert egy jó dolog.

Másik példa: Nemtom most hogy van, de annó gnome alatt nem lehetett állítani a képernyővédő tulajdonságát. Kivették a gombot, mert sokan nem használták. Nem hiányolom, nem is használok képernyővédőt, de biztos van aki egy egyéni üzenetet állítana be a 3d szöveg képernyővédőhöz.

Winhét telepítést én se nagyon piszkálom, de vannak dolgok amiket jó ha be lehet állítani. Én pl nem szeretem a gombok csoportosítását, és örülök neki hogy van módom kikapcsolni. És ez se nem haladó igény. És ha az is lenne, mi is csak emberek vagyunk, a haladó ne jelentse már azt, hogy nekünk registry, gconf editor meg conf fájlok szerkesztése jut.

Miért kellene meghalnia? Igény van rá. Én úgy vettem észre, hogy te nagy energiát fordítasz arra, hogy olyan dolgokkal foglalkozol, amit te nem használnál, vagy ami szerinted rossz. Miért nem abba ölsz ekkora energiát, ami szerinted jó és hagyod meg másoknak azt, ami szerintük nekik jó? Miért ne élhetne együtt egymás mellett a GNOME, a KDE és a többi desktop környezet. Én például baromira nem szeretem a KDE-t, de tőlem élhet ahogy akar, illetve használhatja az, akinek arra van igénye.

ha jól sejtem a hozzászólásláncból ez nem nekem szólt, de azé válaszolok:

a gnome nekem tökéletes lenne, ha nem lenne korlátozott. Van benne pl gvfs, amit nagyon hiányolok KDE-ből, hiába tud a KDE hasonlót, nem ugyanaz. Sokszor dolgozom távoli gépekkel, és jó hogy kényelmesen local tudom csatolni. Viszont amikor a számomra tökéletes rendszer egyébként hiányos az persze hogy kiakaszt, és zavar, főleg ha értelmetlen hiányosságok vannak benne

mivel tud többet a gvfs, mint a KDE kio-s megoldása?

Én mondjuk eddig még csak webdavot, sshfs-t és sambát használtam KDE alól, de azok jól működtek.

Szóval arra vagyok kíváncsi, hogy gnome alatt mi van, ami KDE alatt nincs, illetve ha ugyanaz, akkor mi miatt kényelmesebb?

Gnome-ot ritkán használok, és ez nem jött elő, azért kérdezem.

G

Miben tud többet: pont abban, amire te mondjuk az sshfs-t használod. a gvfs becsatol mindent a fájlrendszerbe, ezáltal minden program, még a leg alacsonyabb szintű terminálos alkalmazások is úgy látják, hogy helyben van a cucc, és működnek vele

A kio meg egy olyan réteg amit a kde-s programok tudnak használni, a többi meg le van szarva. Illetve ha jól láttam másolgat a háttérben temp mappába, szóval előfordulhat hogy egyegy fájllal tud dolgozni nem kde-s program is, de azért az nem ugyanaz, mint amikor a teljes mappa/fájlredszer látszólag a gépeden van.

GVFS-vel meg tudtam csinálni hogy az egyik gépemen indítottam el a másik gépemen lévő WoW telepítést wine-vel, és nem kellett 8-10 gigákat másolni amikor a másik gépen kellett futtatni. Azt is meg tudtam csinálni, hogy ftp szerverről becsatoltam egy ISO-t, és nem ment el idő a letöltéssel, hanem közvetlenül onnan telepítettem. Filmnézés előtt se állok neki másolgatni, ha véletlenül a másik (kisebb monitorral rendelkező) laptopomon van a film.

Tudom, elég speciális igényeim vannak, de szeretem kihasználni az ilyen jóságokat, és hiányzik ez KDE alól. És hogy akkor miért KDE-t használok? Mert sokminden másban meg ez jobb számomra.

"Miért jelenti a felhasználóbarátabb, egyszerűbb azt, hogy funkciószegényebb, kevesebbet tud?"

(Nagyjából) ezt Darkness és therion mondta. Én pont azt mondtam, hogy úgy kéne megfelelni az egyszerű felhasználóknak, hogy közben nem csökkentik a funkcionalitást a haladók számára.

Miért visszafelé haladás az ha az X-et lecserélik egy olyan display server-re ami a felhasználók többségének jobban meg fog felelni mint az X? Ami sokkal újabb, sokkal kisebb, sokkal modernebb? Igazából az a szívás hogy idáig vártak vele.

SZERK:

"A Linux elterjedtsége elsősorban a hardver- és szoftvergyártókon műlik, meg a megszokásokon, nem a Linuxok fejlesztőin."

Persze, ez mindig jól működő kifogás a közösségben, már csak a csúnya gonosz MS Linux-ellenes ármánykodásait kellene beleszőnöd, hogy teljes legyen a mese.

A Linux elterjedésének gátjai főleg a Linux-on belül keresendők, nem a kernelen belül, az rendben van, viszont ami felette van...

"sokkal újabb, sokkal kisebb, sokkal modernebb"

Attól, hogy kevesebbet tud? Erőforrások táján meg a GNOME/KDE+alkalmazások terén kéne szétnézni, az X ehhez képest eltörpül.

"A Linux elterjedésének gátjai főleg a Linux-on belül keresendők, nem a kernelen belül, az rendben van, viszont ami felette van..."

Valami konkrétum? Olyan, ami egy felhasználónak döntő. Merthogy amit én írtam, az egyértelműen az gyakran.

"Attól, hogy kevesebbet tud?"

Attól, hogy egy feladat elvégzésére lett kitalálva, amit nagyon jó eséllyel sokkal magasabb szinten tud elvégezni az X-nél, nem beszélve arról hogy a fejlesztés üteme is sokkal komolyabb lehet, mint az X esetében.

"Valami konkrétum? Olyan, ami egy felhasználónak döntő. Merthogy amit én írtam, az egyértelműen az gyakran."

Nyilván vannak a közösségen kívüli és belső okai annak, hogy ezidáig nem terjedt el. Csak már idegesít kicsit, hogy egyesek mindig csak a külső okokat veszik észre, amik persze nagyon fontosak, de talán először nem azokkal kellene elsősorban foglalkozni. Tehát most nem a kernelről beszélek elsősorban, hanem a disztribúciókról általánosságban. (Bár kernelszinten a visszafelé kompatibilitás nem áll túl jól, ami bizony a desktop felhasználónak is fontos. Hiszen az operációs rendszer nagyjából egyenértékű a rá elérhető programok összességével, és talán ösztönözné a cégeket a Linux-ra való fejlesztésben, ha biztosak lehetnének benne hogy az egyszer megírt program hosszú évekig működni fog.)

A problémákat a közösség nem képes megoldani, mert valamilyen szinten magából a közösségből erednek. Pl. Mikor fogják már belátni hogy desktopon régen rossz ha a felhasználónak el kell indítania a parancssort? Másik komoly probléma meglátásom szerint az integráltság, ugyanis amíg a Windows esetében minden komponens házon belül készül, azok makulátlanul integrálódnak az egész rendszerbe, egy Linux disztro lényegében összedobált programok halmaza.

És amúgy meglátásom szerint égető szükség lenne egy olyan magas szintű standard API-ra mint Windows-on a .NET.

Leszögezném, hogy NEM trollkodni akarok, én is használok Ubuntu-t, nagyon jó rendszernek tartom. Csak már kezd az agyamra menni hogy a Linux fanok mindig a csúnya kegyetlen világban látják a hibát, ha az merül fel, hogy miért olyan gyér az elterjedtsége, és fel sem merül bennük hogy ez valamennyire a Linux hibája is.

.net -> mono? annyira nem ismerem, de nem szokják szeretni úgy látom innen-onnan.

"egy Linux disztro lényegében összedobált programok halmaza."

Egyetértek. Kellene valami egységesítés, csak hát akárhányszor elkezdi valaki egy új disztró születik ami megint csak egy újabb probléma forrása.

Lehetne nekiállni egy rendszernek, ami "A linux", és a legjobb megoldásokat összeszedni, összehangolni egy normális desktop rendszerbe. Minőségellenőrzéssel, meg minden. Ez is csak egy disztró lenne, de ha ezt neveznék hivatalosan "A linux"-nak, akkor az talán kiemelné a disztrók közül annyira, hogy a fejlesztők ennek akarjanak megfelelni, és kész megoldásokba beledolgozni, egységesíteni, összehangolni.

A baj az, hogy amíg azt döntöd el, hogy a pulseaudio legyen "A hangrendszer", addig csak néhány emberrel kell összevitatkoznod, viszont ha meg akarod mondani hogy már pedig a linux az kde desktop lesz, akkor a fél világ fog melegebb éghajlatra kívánni.

".net -> mono? annyira nem ismerem, de nem szokják szeretni úgy látom innen-onnan."

Windows-on lassan már a .NET _A_ standard API. Linux-ra van Mono, de az nem ugyan az. Amúgy egy Java alapú API is jó lenne, csak legyen magas szintű és egységes. Helyette van egy csomó ilyen-olyan lib, ami megint csak nem ösztönzi a fejlesztőket arra, hogy Linux-ra fejlesszenek. Még egyszer leírom: az operációs rendszer használhatósága egyenesen arányos azzal hogy mennyi és milyen minőségű szoftver érhető el rá.

"Egyetértek. Kellene valami egységesítés, csak hát akárhányszor elkezdi valaki egy új disztró születik ami megint csak egy újabb probléma forrása."

Így van. Ez a közösségi fejlesztés buktatója. Én sem vagyok az ilyen fejlesztés ellen, mert vannak vitathatatlan előnyei is, meg a mögötte húzódó ideológia is szimpatikus. Csak ez a fajta átfogó koncepció nélküliség olyan negatívuma, amiből jelenleg nem igazán látom a a kiutat, és ez bizony súlyosan aláássa a Linux desktop esélyeit.

SZERK: Még a csomagkezelést sem tudják egységesre megcsinálni, ami azért ultra nagy gáz, mert esetleg olyat akarsz feltenni ami nincs meg az adott disztro repójában akkor jön a gyötrelem...

"Mikor fogják már belátni hogy desktopon régen rossz ha a felhasználónak el kell indítania a parancssort?"

Valószínűleg régóta tudják. Az utóbbi években nem volt olyan, amit ne tudtam volna parancssor nélkül megcsinálni, és egy tipikus desktop felhasználónak egyáltalán fogalma van róla. (Használom persze, a parancssort, mert kényelmes.) openSUSE-t használok persze, Ubuntu nem tudom, milyen.

Dehogy ne haladjunk. Sőt, én örülök neki, ha jön ilyen vérfrissítés, csak ne okozzon nekem hiányérzetet a korábbihoz képest. Tudjam az egyik gépem szoftverét a másikon futtatni (hogy a másik gépem erőforrását egye meg, hogy ne legyen két helyen a program, tudok jó indokokat ami nem annyira haladó)

Sőt, azt mondom, hogy oldják meg úgy, hogy az egyszerű ember is tudja használni ezeket a funkciókat. Lehet hogy igény is lenne rá. Nem tudjuk, mert most bonyolult, nincs az orrunk előtt, nem is tud róla a sima user.

Talán sokan (akik két gépet használnak) örülnének annak, ha két gép közt át lehetne húzni az alkalmazások ablakait egyik gépről a másikra épp úgy mint ha két monitorod lenne.

És ha ez úgy lenne megoldva, hogy a felhasználónak max annyit kell beállítania, hogy fizikailag hol vannak a gépek, és hogy tart-e igényt erre, akkor ez lehetne egy olyan featúra, ami eddig haladó igény volt, később viszont alap, és el se tudnánk képzelni az életünket nélküle.

Synergy megvan? Belövöd a két gépeden, és át tudod húzni az egeredet, és lényegében az egyik gép billenyűzetével, egerével irányítod mindkettőt, mint ha egy gépen két monitor lenne. Használom egészséggel, és nevetek azokon akik három négy gépükön 3-4 billentyűzettel dolgoznak. Azt is meg lehetne oldani user friendly módon, és lehet hogy mindenki használná :)

Van olyan felhasználói csoport, amelyik esetében ez törvényszerű. Nem igényelnek sok funkciót, jól kell eltalálni az alapértelmezett beállításokat ill. a legtöbb dolgot el kell helyette végezni és akkor nincs gond.

Egy jó OS körül nagy s/w ökoszisztéma épül ki: sok kisebb-nagyobb gyártó/fejlesztő készít dolgokat, így mindenki megtalálja azt, amit szeretne.

Nekem is többféle igényem van: egy webböngésző esetében elég amit a Chrome ad, grafika esetén - amatőr fotósként - PS Lightroom szintű megoldás kell.

És egy desktop felhasználó nem akarhat picit többet? Én is az vagyok, ha azt nézed, hogy mire használom a gépemet (filmet nézni, netezni, dolgozni) viszont ahogy teszem az már más: én becsatolok a fájlrendszerbe ssh-n (sambán, akármin) egy másik gépet ahelyett hogy pendrive-on másolgatnám a cuccokat. Nem nagy dolog, csak meg kell nyitni nautilusban, aztán ott van a .gvfs mappádban.

Az átlagfelhasználó lehet hogy nem jön rá hogy ilyet lehet, és hogy ez neki azt jelenti, hogy lanon keresztül nézhet filmet a másik gépéről anélkül hogy másolgatna, de ha az ilyen opciókat kihagyják a fejlesztésekből csak azért, mert (bocsánat, kiakadás) a sok hülye ember nem akarja megtanulni kezelni a gépét, oprendszerét, akkor az szív, aki mert egy picit hozzá érteni akarni.

És a picit hozzá érteni akaró ilyen fórumokon anyázik, mert kénytelen lesz a későbbiekben a talán már nem is annyira támogatott, nem is annyira kompatibilis X-szel szenvedni, ha olyan dolgokat akar, amik picit az advanced kategóriába tartoznak, de azért néhány gombnyomással, vagy paranccsal elérhetők most még.

Az egyszerűen és könnyen használható desktop os nem azt jelenti hogy ne tudjon a rendszer semmi pluszt a háttérben a "bölcsek" számára. Az apple egyébként tényleg jól csinál valamit, de az sokkal inkább marketing mint a rendszer :) Egy ilyen flame-be inkább ne menjünk bele, de azért azon kiakadtam, hogy a laptopfedél lehajtásánál a gép sleep-be megy, és nem is tudom beállítani hogy ne tegye. Semmivel nem nehezítené a rendszer haszálatát ha lenne ilyen opció, de könnyítené a profibbak számára a kezelést, ha nem külön appokat kellene telepítgetni hozzá

Ha már apple: Az iphone-on egy gomb van. Az androidos telefonokon négy (többé kevésbé) Valahol olvastam, hogy minek négy, nem igazán egyértelmű az hogy melyik mikor mire hogyan. Szeritem meg de. Egyszer kell megtanulni hogy a back gombbal visszafele mégy, a home-vel a kezdőképernyőre, a menüvel helyi menüt hozol elő, a kereséssel meg keresel. Ezek az opciók nagyon szépen kihasználhatók, szemben egy iphone-val, ahol az app képernyő területéből veszi el a helyet a menü, a keresés, a vissza gomb, csak mert egy home gomb kényelmesnek tűnt. Való igaz, annak aki először lát iphone-t egyszerűbb kezelni, de hosszútávon jobb ha gyorsabban tudod kezelni a rendszert.

Nem véletlenül van egy csomó gui programban shortcut minden funkcióhoz. Nem jelenti azt, hogy nehéz lenne egy szöveszerkesztő csak azért, mert azon kívül, hogy gépelsz bele, és nyomod a B U I gombokat, még tud olyat, hogy a Ctrl-F-re csinál valami extrát.

engem igen.

Szeretem x forwarddal elindítani a másik gépen lévő programjaimat. és nem, a vnc nem alternatíva, mert az egész desktop, az x forward meg egy (vagy több) ablak.

Szeretem azt is, hogy a szerveremen tudok headless x szervert indítani, ami vnc-n belül fut (tightvncserver, a működését annyira nem igazán értem, de a lényeg hogy a vnc szerver alatt fut az x, ez tökéletesen jó szerveren, ahol nem igazán férek a valódi desktophoz még annyira sem, hogy egyszer egy vnc szervert elindítsak rajta (mert vps, és mert nincs is rajta x kliens, se monitor)

Tudom, nem vagyok átlagfelhasználó, de attól még reális igény, hogy az újítások ne járjanak azzal, hogy még kevesebb dologra leszek képes.

na igen, de írtam feljebb (bár azt a fájlrendszer-indexelgetős témában) hogy engem rohadtul zavar, hogy mindenre egy plusz réteg készül. Lassú, körülményes. Ha már kitalálják hogy a "grafikát a wayland tolja" akkor had ne kelljen még afölöltt X-et telepítgetnem. Ha tényleg bloated, és tényleg elavult, akkor örülök, hogy kikerül az életetemből, és használhatok valami újat, jobbat, szebbet, gyorsabbat. Csak tudjam használni.

Ráadásul, ha ez tényleg újabb, szebb, jobb, gyorsabb lesz, akkor az x fejlesztése egy idő után elsorvad, nem?

"engem rohadtul zavar, hogy mindenre egy plusz réteg készül. Lassú, körülményes."

Akkor örülj a Wayland-nek, mert legalább a helyben futtatot alkalmazásoknak nem kell egy plusz hálózattranszparens rétegen keresztülverekedniük magukat. Ami amúgyis a hálózaton keresztül jön, az már most is lassú és körülményes, szóval azoknak úgyis mindegy.

"Ráadásul, ha ez tényleg újabb, szebb, jobb, gyorsabb lesz, akkor az x fejlesztése egy idő után elsorvad, nem?"

Miért sorvadna el, amíg van rá igény?

Amíg van rá. Azt írták, hogy ezek az igények (távoli futtatás, ilyesmi) 10% usert érint. Ha csak ők használnak ezek után X-et (miért használna más, ha a wayland a többit jobban támogatja?), akkor csak ez a 10% fog bugreportolni, ők fognak csak új fejlesztési igényeket megfogalmazni, stb.

Hát szépen meg lennék lőve X remote nélkül! Sajna nem egy sem kettő szerver (Oracle, WL, stb..) telepítő/konfiguráló fut X alatt. Mivel a mi környezetünkben nincs grafikus terminál és a VNC-t nem tartom biztonságosnak, így ssh-ba tunnelelt X forwardinggal tudunk operálni. Hozzá tesztem, hogy a nagy szállítók remote-jai (HP ILO) lószart sem érnek.

Úgyhogy hajrá X! vagy CS utódja.

A baj az, hogy nem ugyanaz a kettő. Biztonság ide-oda. a vnc-vel egy asztalt, az x forwarddal meg egy ablakot forwardolsz. Ha meghal a neted akkor az x forwardold programok megszívták, a vnchez meg újracsatlakozol később. Viszont a vnc-vel átveszed az irányítást a gép felett, x forwarddal meg csak egy új alkalmazást nyitsz, más dolgozhat a gépen*. Más célra jók, amik közt persze van átfedés. A lényeg, hogy egyik eszköz se legyen elvéve, csak mert valaki egyiket jobbnak tartja a másiknál.

* tudom, headless x szerver vnc-n keresztül. De azért a vnc többnyire távirányításra jó.

remote desktopra gondolsz? hiányolom is linux alatt. Illetve nem, mert meg van oldva, csak nem olyan egyszerű mint win alatt. Vnc szerver, indít magának X-et, fut benne a teljes desktop új példánya ha úgy van beállítva, vagy az amit akarsz, a folyamat él amíg a gép él, disconnect után is. Kb mint a screen.

http://s01.de/~tox/index.cgi/unixy_software
X11
http://harmful.cat-v.org/software/c++/I_did_it_for_you_all
kis c++ trollkodas, de ez a resze nagyon tetszik:

Actually, I got some of the ideas from X10, you know, X windows. That was such a bitch of a graphics system, that it only just ran on those Sun 3/60 things.. They had all the ingredients for what I wanted. A really ridiculously complex syntax, obscure functions, and pseudo-OO structure. Even now, nobody writes raw X-windows code. Motif is the only way to go if you want to retain your sanity..

Nem szeretem ezt bombát robbantott kifejezést. Csak simán az Ubuntu áttér egy GNOME alapú Unity default shellre, semmi több.

A Waylandet meg kell támogatni Nvidiás driverekkel és már mehet is desktop meg gaming szoftverfejlesztés.

Hajrá Ubuntu!

--
GPLv3-as hozzászólás.

es mikor lesz a wayland letolva a kernelbe a KMS melle, mert az ott a gyors? :)

es mindjart el is kerkeztunk a windowshoz, oda, ami ellen mindenki fujjolt, hogy hat mert az szar, es nem biztonsagos, hogy a kernelben van a grafikus alrendszer, de nyugi, ez lesz a jovo, es a linux kernelben is ott lesz a teljes grafikus alrendszer ;)
___
info

"es mindjart el is kerkeztunk a windowshoz, oda, ami ellen mindenki fujjolt, hogy hat mert az szar, es nem biztonsagos, hogy a kernelben van a grafikus alrendszer, de nyugi, ez lesz a jovo, es a linux kernelben is ott lesz a teljes grafikus alrendszer ;)"

te láttál valamit a windows-ból az xp óta? nekem úgy tűnik, nem.

Én nem értek hozzá de win7 alatt volt olyan alkalmazás amitől megfagyott a videokártya.
MI történt ?
Kb. pár másodpercig nagy sötétség aztán kép visszajött,lent tray ikonoknál megjelent egy popup a következő szöveggel: a videokártyád működés közben leállt, vidókártya újraindítva.
Azt ennyi, semmi reboot semmi fagyás stb.
Na majd ha ilyen lesz linux-on akkor majd örülni fogtok.

Sajnos amit eddig linux alatt éltem át ott bizony keményen a reset gombhoz kellet nyúlni, mert a híres überstabil X úgy megfagyott hogy csak nézel ki a fejedből. Ehhez képest amit említettem fényévekre van :p
Ha azt nézem linux alatt rendes eszközkezelő sincs, upsz, elnézést azért van pár bugware cucc, aminek kismillio header meg lib kell, kézzel kell bekonfigurálni ha azt akarod hogy egy rendes fagyás után ne fossanjon be végleg a rendszer.
Ja hogy nem szokott fagyni a gép mert a linux csudajó, hát aki max. webet böngészget, meg zenét hallgat annál el is tudom ezt hinni (bár ebbe is nyugodt szívvel bele lehet kötni:p).

Sajnos ez nem ugyanaz, és nálam ubuntunál azért a 0-hoz képest gyakran előfordult, hogy csontá fagyott... legalább 10-15-ször az elmúlt 1-2 évben!

A ctrl alt bckpsace pedig nem ugyanaz a megoldás, mint amit előbb barátunk említett... azzal a megoldással a futó grafikus alkalmazások megmaradnak, ezzel nem.