ls -1TörténelemHUP adás-vételNépszerű témákNépszerű fórum témákHardverAjánlott böngésző Linux Weekly NewsFreeBSD Project NewsOpenBSD Journal |
btrfs-gui - grafikus kezelőfelület készül btrfs-hezA 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.
»
|
KeresésNavigációBelépésHupWikiÁllásajánlatokHWSWFriss blogbejegyzések
HUP napi hírlevélLegfrissebb HUP videókLegfrissebb HUP képekLegfrissebb HUP dokumentumokSzavazásMit tudsz a B-tree struktúráról? Részletekbe menően ismerem a felépítését, funkcióját, határait és felhasználását. 10% Kevésbé ismerem, mint az első pontban, de hozzá tudok szólni a témához. 18% Használom, de nem ismerem minden részletét. 4% Hallottam már róla, minimális mértékben ismerem. 27% Egyáltalán nem ismerem. 34% Csak az eredmény érdekel. 8% Összes szavazat: 560
Új felhasználók
InformációKövess minket!Partnerünk |
slashdotted
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
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.)
+1, felesleges
szerintem teljesen jo, kicsit a windows disk managerjere emlekeztet :)
joh, nyilvan diskparttol sem ilyedek meg ha azt kelle hasznalni, de a grafikus feluleten azert megiscsak intuitivabb
--
NetBSD - Simplicity is prerequisite for reliability
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.Nem ertem most miert az a baj hogy erre mi szukseg van, mikor eddig mindig az volt a mondas hogy az opensource evolucios modellben fejlodik es kulonben is hobbibol csinaljak - maguknak...
es az tud remote fs-t kezelni?
--
NetBSD - Simplicity is prerequisite for reliability
Elvileg igen, lehet másik gépre csatlakozni.
+1, guis particionalas nem rossz dolog. Gondolom itt direkt brfs fícsörök (snapshot, raid) támogatás miatt van saját felület. Mondjuk azt tényleg utálatos lehet parancssorból használni sokszor.
Sok-sok éve Tru64-en (vagy akkor hogy hívták, OSF1?) láttam grafikus volume manager konfiguráló programot, ha annak volt értelme, ennek is lehet. (nem, annak se volt)
Nem mintha Solaris-on nem lenne...
--
trey @ gépház
Meg minden platformon ahol pl. a Veritas volume manager elérhető.
Egy ideig igen jó volt a gui-ja, nem tudom mennyire cseszték el az utóbbi 2-3 évben.
SPARC Solaris 8-on használtam éles rendszeren utoljára. Sun StorEdge D1000-et piszkáltam vele. Akkor még Solstice Disk Suite néven futott ha jól emlékszem.
--
trey @ gépház
Az teljesen más.
A Solstice azóta Solaris Volume manager névre hallgat, és az speciel szerintem egy elég jó kis volume manager volt, és most sem rossz. A régi gui-ja szerintem
hulladékelég körülményes volt, a mostanit nem tudom, mert nem használom.Már hogy érted, hogy teljesen más?
--
trey @ gépház
Más termék. A Solstice a Suné volt, átnevezték Solaris Volume Managernek. A Veritasnak saját cuccai vannak.
--
Web 2.0: you make the content, they make the money.
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ó.)
Az ok, hogy más gyártó. Én a funkciójáról beszéltem :)
--
trey @ gépház
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.
"ha korrektül meg van csinálva"
Te kis vicces fiú :)
Aki azt a néhány LVM parancsot nem képes megtanulni, ne álljon rendszergazdának.
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.
A GUI abban az egy esetben segít, ha fogalmad sincs, mit akarsz csinálni, pláne hogyan. Akkor meríthetsz belőle ötletet.
Bizony, bizony. Ld. még `man iptables`, illetve Gufw.
Van ott sima ufw is, ami majdnem olyan kényelmes, mint a grafikus frontend, vagy mi. Sőt...
Ahh, a shorewallnal nem kell jobb. A default peldakonfigok teljesen jok alap kornyezetre, ahol meg bonyolult a helyzet, ott meg az ember ugyis nullarol rakja ossze maganak a profilt.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo PortalAttól hogy CLI még lehet hozzá (nem helyette) GUI. Nem kizáró ok. Használni meg majd mindenkinek azt illik amelyik a számára az adott feladathoz hatékonyabb…
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -> Kérjük a humoros aláírást itt elhelyezni. <- - -
Az a jó HUP-ban, hogy ha már valaki nem tud értelmeset írni, kiragad valami részt és abba köt bele.:)
Azért fogtad ezt a mondatod:
"Egy fs-t nem mindig csak rendszergazdák birizgálnak, egy fs-t nem csak szerveren használnak."
Ez a lényeg, és ez igaz az LVM-re is.
Aki nem ért hozzá, ne piszkálja. Filesystemet se, de volume managementtel pláne ne foglalkozzék. Ha valaki nem ért a volume managementhez, azon egy GUI nem segít. Ha pedig veszi a fáradtságot, hogy megértse, ne álljon meg a CLI megtanulása elött.
Ave, Saabi.
"Aki nem ért hozzá, ne piszkálja."
Akkor már csak egy hozzáértő kell, aki megmondja, hogy ki a hozzáértő. :)
"...ne álljon meg a CLI megtanulása elött."
Akkor előbb a GUI és utána a CLI?
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.
"tkinter.ttk (often packaged as python-tk)"
Ez most komoly?
Ehhez ért, na...! Nehogy már valami gtk vagy qt alapú legyen! :)
-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --
Űrtechnológia, az UFÓ-k is ezt használják.
tkinter-rel tényleg kár elkezdeni ezt a projektet, akkor inkább keresne prímszámokat az ember.
Fuszenecker Róbert
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 ott bukik, hogy ezt saját maga szórakoztatására csinálta.
--
trey @ gépház
Egy hobbiprojekt is lehet igényes. Nem tilos szép programokat írni. Főleg, ha az ember publikálni is akarja.
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.
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.
fsck mikor lesz?
Van.
Ennyi a forráskódja:
#include <stdio.h>
int main()
{
/* printf("Hello World!\n"); */
printf("Btrfsck v0.19\n");
return 0;
}
Fuszenecker Róbert
Jah. Tegnap majdnem megkérdeztem én is.
Talán kicsit hasznosabb lenne, mint ez. (Tudom, más fejleszti.)
Kicsit olyan érzésem van, mint a W95-el. Kinézett valahogy (GUI), de esett, kelt (mármint a btrfs (is)).
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.
"... egyszerűen azért, mert az emberben az evolúció a látást fejlesztette ki fő érzékszervnek. ..."
Igen, csak a hupon nagy divat a szemellenző. :))
Utolsó mondatra +1.
--
dropbox
Teljesen igazad van.
A sok rettentő okosnak meg egy szót üzennék: dashboard. Biztosan az is az ördögtől való.
+1
Jó összefoglalás, teljesen igazat adok.
-1
CLI kimenetkből is át lehet tekinteni a környezetet, csak fantázia kell hozzá!