btrfs-gui - grafikus kezelőfelület készül btrfs-hez

Fájlrendszer, NAS, storage

A linux-btrfs levelezési listán Hugo Mills ma bejelentette, hogy az elmúlt hetekben azon dolgozott, hogy egy grafikus felhasználói felületet üssön össze a btrfs fájlrendszerhez. A fejlesztéssel odáig jutott, hogy kiadta a szoftver első publikus alpha verzióját.

A programmal mind a localhost-on levő, mind hálózattal rendelkező távoli gépen levő fájlrendszert lehet kezelni. A fejlesztés korai fázisban jár, így a szoftver jelenleg csak korlátozottan használható.

Részletek a projekt weboldalán és a bejelentésben.

( nevergone v | 2011. 06. 02., cs – 22:26 )

slashdotted

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

( Zahy v | 2011. 06. 02., cs – 22:33 )

Most komolyan. Erre szükség van? (OK, tudom ma már a rendszergazdák se tudnak/szoktak parancssorban bohóckodni. Meg különben is, ő ideje, úgy veri el, ahogy akarja. Asszem inkább nem is kérdeztem semmit.)

Erre nincs szükség, arra lenne hogy egy népszerű asztali környezet által már most is szállított és más fájlrendszerek esetén hasonló fícsöröket már tudó lemezkezelő segédprogram rendelkezzen btrfs-támogatással (ne feledjük, ezt lakossági fájlrendszerként is tervezik felhasználni), de azzal nem lehetne egy teljes képernyőképet kitölteni, legfeljebb egy-két legördülő menüben lenne egy-egy új menüpont, az meg olyan snassz, már-már észrevehetetlen, egyáltalán nem hangsúlyozná ki ENNYIRE a fejlesztőúr e-penzsenijét.

igen köszönöm.
A zfs előtt (tudtommal)2 féle volume manager volt solarisra . Az egyik az Solstice(SVM), a másik a Veritas. Az előbbi a Sun saját(?) terméke, része jó ideje a default oprendszernek. Az utóbbi 3rd.party, jelenleg a Symantech tulajdona és elég sok platformra elérhető, többek között Solarisra, Linuxra, AIX-re. (És sokba kerül cserébe viszont elég jó.)

Most komolyan.
Tényleg ennyire sötétek vagytok itt előttem páran?
Egy fs-t nem mindig csak rendszergazdák birizgálnak, egy fs-t nem csak szerveren használnak.
Teljesen jó és korrekt dolog, ha az adott fs közeli ember csinál egy ilyen tools-t, és/ha minden funkcióval felvértezi (és nem
egy harmadik fél által összetaknyolt, mindenes szarba próbálja beletuszkolni).
De tovább megyek, gáz, ha rendszergazdának tartjátok magatokat és nem láttok tovább az orrotoknál: igenis lehetnek (sőt vannak is) olyan rendszerek, ahol egy ilyen, ha korrektül meg van csinálva simán áldás lehet.
Az IBM-nek volt anno egy korrekt LVM szerű megoldása.. a neve nem ugrik be.. csináltak hozzá GUI-t, ami már csak arra is jó volt, hogy azon tudtál kísérletezni, szemben a fos LVM-el, ahol X év telt el mire csináltak hozzá valami felületet.
Melyik a jobb, korrektebb eljárás?
Én annak örülnék, ha ez lenne az alap, ha valaki csinál egy fs-t akkor írjon is hozzá egy korrekt gui-t.

Aki látott már szervert több száz diszkkel, és 100-as nagyságrendű fájlrendszerrel mindenféle raid-be szervezve, az tudja, hogy néha tök felesleges órákat cli-vel rejszolni, amikor tizedannyi idő alatt is meg lehet oldani gui-n egy bonyolultabb diszk átszervezést.
Arról nem is beszélve, hogy a gui-n ránézésre ki lehet olyan dolgokat szúrni, amit cli-ből gyakran esélytelen.
Ez nem jelenti azt, hogy nem kötelező ismerni a cli-t is.

GUI-t elég nehéz scriptelni, ráadásul több erőforrást igényel a használata mint a CLI-é. Egy barátom konkrétan kérte, hogy az XP24000-hez CLI-t biztosítsunk, mert a hócipője tele a GUI-val, egy élet amíg bármit megold benne.
A GUI abban az egy esetben segít, ha fogalmad sincs, mit akarsz csinálni, pláne hogyan. Akkor meríthetsz belőle ötletet. HPVM alatt gyorsabban rakok össze egy guestet mint CLI-vel, mivel HPVM-et elég ritkán használok, a parancs amit össze kell állítani pedig nagyon összetett is lehet akár.
Persze olyat is láttam, hogy valaki 500+ volume group kialakításánál elrontotta az egyiknél a minor numbert, ezért érdekes dolgokat művelt vele az LVM. De ezt egy "ls -l /dev/*/group" paranccsal ki lehetett szúrni, mivel sorakoztak egymás alatt a 0xnn0000-k, de az egyik 0x0nn000 volt.
Volt olyan esetem úgy tíz éve, hogy útban Tiszafüredre az autópályán - a barátnőm vezetett - mobiltelefonon bejelentkezve - semmi 3G, kapcsolt vonal 9600-on! - LVM tükrözést javítottam éles üzemű servereken. Ezesetben egy GUI konkrétan lehetetlenné tette volna a dolgot, CLI-n viszont semmiféle problémát nem jelentett.

Ave, Saabi.

csak annyit akartam kihozni asz egészből, hogy a gui vizuális, így sok esetben gyorsabban áttekinthető.
Volt úgy hogy gui-val dolgoztam ugyanazon a rendszeren, és volt úgy hogy scripteket írtam, hogy legeneráljam velük a migrációs scripteket.
Van úgy, hogy az egyik jobb, van úgy hogy a másik, a jó dolog az, ha tudsz választani.

Egyébként akkor is hasznos, ha másik platformon kell valamit csinálni, és pontosan tudod mit akarsz, csak a parancsokat nem ismered, és nincs időd man-okat meg dokukat nyálazni.
Pl. nekem egyszer határozottan segített a smitty, mert AIX-en nagyon nem vagyok otthon, viszont szükségem volt egy volume kiterjesztésére elég sürgősen.

Akkor már csak egy hozzáértő kell, aki megmondja, hogy ki a hozzáértő. :)

Nem hiszem, hogy megmondóemberre volna szükség. Aki tudja, mi célt szolgál a volume management, mik a merev lemezek, partíciók, LUN-ok és logical volume-ok, vagy kötetek, mi fán terem az extent, mi a tükrözés, RAID, etc... Az nem kezdi úgy a mondandóját hogy: "Nem tudom"
Akinek viszont a fentiekről nincsen fogalma, azon egy GUI sem segít. Szerintem. De ha már vette a fáradtságot, hogy a fentieket megtanulja, szerintem ne álljon meg itt és tanulja meg a kezelőparancsok használatát is. Már persze ha van benne némi szakmai önérzet. Szerintem.

Ave, Saabi.

Pedig a hupperek nagy százaléka megmondóember. :)

Egyébként ott van a hp-nek a hpacucli nevű tool-ja. Tényleg király, mindent meg lehet vele csinálni. És néha mégis biztonságosabbnak érezném, ha lenne előtte egy GUI, hogy vizuálisabb visszajelzésem is legyen az aktuális állapotról.

( mn3monic v | 2011. 06. 03., p – 07:11 )

"tkinter.ttk (often packaged as python-tk)"
Ez most komoly?

Konkrétan mi a baj a python-tk-val? Speciel én wxPython-ban csináltam volna, és a GUI közreadott képei valóban kicsit kőkorinak néznek ki, de a lényeg, hogy működik, nem? Vagy vannak egyéb komoly gondok a python-tk-val?
(Ne feledjük, hogy néha kőkorinak kinéző AWT-s Java alkalmazások is fölbukkannak. Asszem, az abevjava is AWT-s.)

Ha valaki grafikus felületet készít (azért, hogy a kevésbé hozzáértők vagy az öregedő adminisztrátok munkáját megkönnyítse), akkor válasszon egy olyan technológiát, amiben

#1 lehet tisztességes kódot írni, dokumentációval, mindennel,
#2 ne legyen kifejezetten ocsmány a felület, mert egy ronda GUI-t nem túl kellemes nézni sem.

Fuszenecker Róbert

Ez így van, de nekem mondjuk nem fáj, ha elsőre mondjuk nem olyannak sikerül. A közösségi fejlesztés pont arról szól, hogy van valami, amit a közösség jobbá tehet azzal, hogy hozzájárul. Néha az sem biztos, hogy az első próbálkozás a legjobb. Néha az is elég lehet, hogy valaki ötletet ad, más a közösségből pedig megcsinálja jobban.

--
trey @ gépház

#1 lehet tisztességes kódot írni, dokumentációval, mindennel,
Python-tk-ban nem lehet? Nem tudom, csak kérdezem. Igazából azt sem tudom, hogy wxPython-ban lehet-e, mert dialógusablaknál bonyolultabbat még nem csináltam.

#2 ne legyen kifejezetten ocsmány a felület, mert egy ronda GUI-t nem túl kellemes nézni sem.
Ízlések és pofonok ugye. Speciel nekem a kedvencem az SWT, az meg nincs Python-ra. Hát ez a tkinter nem tűnik valami korszerűnek, de vannak ennél rosszabb GUI-k is. Annak örüljünk, hogy legalább Python-ban készült a dolog.

Ellent kell hogy mondjak. a Tk toolkit és a Python Tkinter binding pontosan az ilyen jellegű feladatok megoldására ideális: olyan eszköz fejlesztésére, ami nem igényel bonyolult grafikus felületet, jellemzően szakemberek használják, és várhatóan a kezelőfelülete a jövőben sem fog elburjánzani, mert egyetlen, jól körülhatárolható feladatot lát el. Ezért van még mindig ott a Tkinter a Python core modulok között, és folyamatosan fejlesztik is. A Tk mögött pedig, ha jól tudom, ott az ActiveState. A Tk nem a nagy GUI frameworkok riválisa, hanem kiegészítője.
Az is nagy előnye, hogy - szemben azzal, amit valaki írt róla - nem teszi átláthatatlanná a kódot, mert a használata egyszerű, mint a faék, és villámgyorsan össze lehet dobni benne egy egyszerű GUI-t. Ami Tkinter-es esetben tényleg átvihető változtatás nélkül bárhova, ahol van Python, csak a Tk-t kell feltenni pluszban, ami szintén minden nagyobb platformra van csomagolva. Egyébként a fentiek a Perl-ben írt Tk-s programokra is igazak.
Hogy ronda és keveset tud? Így van, ezért mondtam, hogy behatárolt az alkalmazási területe. A kinézetét egyébként az új TTk (Themed Tk) widgetek jelentősen javítják. Itt lehet látni képeket, és van tutorial a használatukról, amikből látszik, hogy szkriptnyelveken írt toolok grafikus felületeként milyen jó is tud lenni.

( airwave | 2011. 06. 03., p – 07:13 )

Ja ez olyan mint a nyuszin a sapka... Ha nem lenne az a baj, ha van az is baj. Ha meg valaki csinal is valamit azt meg kritizaljak, hogy miert nem igy miert nem amugy.

( horvatha | 2011. 06. 03., p – 14:21 )

Nem értem ezt a sok hozzászólást arról, hogy a grafikus kezelőfelület ilyen kérdésben eleve káros, függetlenül a kivitelezés minőségétől.

CLI-párti vagyok, aki bejön a szobámba és látja, hogy egy szép nagy monitoron kisebb fekete ablakocskákba szoktam írogatni még fájl másoláskor is, az gyakran néz őskövületnek, de a grafikus felületeknek sokszor látom értelmét. Rengeteg komoly vizsgálat vonatkozott arra, milyen stílusban tárolt információt tud az agy gyorsan és hibamentesen felfogni. Ezekben egyértelműen a grafikus megjelenítések győznek. Ez még profi felhasználókra is igaz.

A desktopra gyúró cégek (MS, Apple) mániákusan grafikussá akarnak mindent tenni: ez nyilván egy szélsőséges álláspont. Még mezei felhasználók esetén is, mert bizony, még egy fájlmásolás is sokszor gyorsabb és hibamentesebb CLI-ből, mint klikkentgetéssel. ("cp ab-*.dat ~/Data2")

De az itt felszólalók egy része lehurrogja a grafikus felületű fájlrendszer kezelőt, ami ugyanolyan szélsőséges dolog. Nem csak arról van szó, hogy valaki lusta megtanulni pár parancsot. Egyszerűen áttekinthetőbb, ha egy jó színkódolással térképszerűen van előttem a lemez, ha ráállok egy területre, arról jön fel infó, stb., egyszerűen azért, mert az emberben az evolúció a látást fejlesztette ki fő érzékszervnek. CLI-párti vagyok, sok évig fdisk-eltem, mke2fs-eltem, stb, de mostanában szívesen használok grafikus partícionálót, mert egyből áttekintem, mi is az ábra.

A grafikus felület tehát nemcsak azoknak szól, akik hülyék/lusták pár parancsot megtanulni, hanem azoknak is, akik szeretik áttekinteni a dolgokat. Kár tehát fikázni.