Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 38 reacties

Fedora moet op termijn een nieuwe partitiemanager krijgen die beter overweg kan met nieuwe bestandssystemen en de diverse opslagtechnieken. Developer Vratislav Podzimek werkt daarom aan de Blivet-gui-tool, die uiterlijk sterk lijkt op het bekende Gparted.

De Blivet-gui-software maakt gebruik van de Blivet-pythonscripts die deel uitmaken van Fedora's Anaconda-installer. Anaconda kan volgens Podzimek in tegenstelling tot andere partitietools wel gebruikmaken van vrijwel alle moderne opslagtechnieken. De tool is echter nog volop in aanbouw en ondersteuning voor bijvoorbeeld het aanmaken van raid-configuraties en een btrfs-bestandssysteem moet nog geïmplementeerd worden, evenals meer mogelijkheden voor lvm-volumes.

De grafische interface van Blivet lijkt sterk op die van Gparted. De ontwikkelaar zegt daarvoor te hebben gekozen om geen grote drempels op te werpen voor gebruikers van de partitietool. Op termijn moet de Blivet-gui ook een standaardonderdeel gaan vormen van de Fedora Linux-distributie, waarbij met behulp van een configuratiebestand de Anaconda-installer geconfigureerd kan worden. Gebruikers kunnen alvast een testversie installeren.

Blivet-gui

Moderatie-faq Wijzig weergave

Reacties (38)

De ontwikkelaar zegt daarvoor te hebben gekozen om geen grote drempels op te werpen voor gebruikers van de partitietool.
.... wat betekend dat functioneel en inhoudelijk?

heb nu zo iets van; gparted light ofzo :+
Ja precies, heb ook geen idee waarom ik dit zou gebruiken in plaats van GPArted.
Inderdaad dit is een beetje het wiel opnieuw uitvinden. En RAID en BTRFS ondersteuning moet nog toegevoegd worden lol, dus momenteel is de tool redelijk waardeloos. Bovendien mis ik ook ondersteuning voor ZFS.
Neuh, dat mis je niet hoor.

Ben van het weekend van ZFSforLinux afgestapt. BTRFS is ontiegelijk veel sneller in mijn opzet. En ja, je kunt een hele tering zooi optimaliseren zodat het sneller is, maar dan nog eet het memory als een 4-jarige met een vrijbrief in de snoepwinkel.
Het enige geheugen dat ik ZFS vooral zie eten is voor z'n cache (ARC), welke gewoon vrijgegeven wordt als een applicatie het nodig heeft. Ik gebruik het alleen niet in Linux, maar in FreeBSD, wellicht is de implementatie daar anders?
Ja de implementatie is aanzienlijk anders. Ze hebben het geheugen management van BSD geimplementeerd (noemen ze SPL - Solaris Portability Layer) waardoor het ingebouwde cache management e.d. in de kernel overgeslagen wordt. Hierdoor staat een groot deel van het memory management van linux zelf buiten spel.
Gparted heeft veel beperkingen, denk maar aan LVM's.
Volgens mij zegt de naam dan ook grotendeels dat het een partition manager is - geen volume manager.
Daarbij heb je LVM niet meer nodig - het is irrelevant geworden dankzij btrfs...
Behalve als je geen BTRFS gebruikt. Bij ZFS heb je ook geen LVM nodig. Maar soms wil je wel LVM gebruiken en dan heb je het wel nodig. :p
Laatst eens zitten kijken of ik nog LVM moest gebruiken of alles met btrfs kon, maar de conclusie was toch gewoon met LVMs werken. Btrfs is mooi, maar nog niet geschikt voor alle soorten data. Het wordt nog steeds sterk afgeraden bijvoorbeeld om KVMs op een btrfs partitie te zetten.
Je kunt vm images op btrfs gebruiken maar dan moet je voor die bestanden copy-on-write uitschakelen.
Gelukkig hebben we daar de RHEL LVM Gui voor. Handig dat ze dit nu allemaal in 1 pakket inbouwen.
die beter overweg kan met nieuwe bestandssystemen en de diverse opslagtechnieken
daarom dus.

En het is nooit verkeerd om meerdere opties te hebben qua tooling.
[...]
daarom dus.

En het is nooit verkeerd om meerdere opties te hebben qua tooling.
Ja so what..., maar waarom dan weer een eigen partitiemanager maken. Waarom niet mee helpen gparted te verbeteren?

Ik wordt soms echt een beetje moe van alle versnipperingen binnen de Linux community |:( . Leuk dat het kan uiteraard en beperkt in ieder geval geen innovatieve ideeŽn. Alleen op deze manier zal Linux/GNU nooit een sterk imago worden! De linux kernel daar in tegen heeft juist een super sterk imago
deel je ergernis; er zijn zoo veel initatieven, 70-90% klaar.... werk gewoon samen en maak een super-krachtige tool, ipv 1001x hetzelfde maar toch net niet.
Soms is het makkelijker om van nul iets opnieuw op te bouwen dan je te moeten verdiepen in duizenden regels legacy code.

Zie ook de Google moonshots: 10X Is Easier Than 10 Percent
Het punt dat gemaakt wordt in het stukje uit het artikel waar jij op doelt gaat erover dat je om grote verbeteringen te realiseren de hele opbouw/aanpak van nul af aan moet evalueren. Het punt is niet dat het "makkelijker" is om maar bij elk ding van nul af aan te beginnen.

Daarnaast heb ik niet het idee dat in dit geval alle aspecten van hoe een partitietool eruit zou moeten zien opnieuw zijn geŽvalueerd om zo tot een 10X beter product te komen. In tegendeel: "De grafische interface van Blivet lijkt sterk op die van Gparted. De ontwikkelaar zegt daarvoor te hebben gekozen om geen grote drempels op te werpen voor gebruikers van de partitietool."

Het lijkt er dus wel degelijk op een meer-van-hetzelfde-aanpak.
Ja so what..., maar waarom dan weer een eigen partitiemanager maken. Waarom niet mee helpen gparted te verbeteren?
Geen idee, maakt het uit? Meneer hier bouwt op zichzelf een mooie tool die gaat concurreren met gparted. Dat betekent dat: gparted moet zich aanpassen om ook deze goeie dingen te gaan ondersteunen, of: deze tool hier word superieur aan gparted omdat gparted niet mee wil.

Beide situaties zijn win-situaties voor de gebruiker.

En "weer" een eigen partitiemanager maken valt wel mee, enige die echt gebruikt worden zijn volgens mij gparted en de partitiemanager van KDE. Das niet echt veel keus.
Ik heb meer iets van: frankenstein op basis van palimpsest (nu Disk Utility of gnome-disk-utility ofzo) en gparted.

Welk probleem ze hier nu mee op denken te lossen zie ik ook niet. Mensen die gaan partitioneren of schijven gaan beheren zijn over het algemeen mensen die weten wat partitioneren of beheren betekent, en daarmee ook mensen die prima met de CLI of GParted overweg kunnen :p
GParted heeft geen ondersteuning voor features (o.a. snapshots) in nieuwe filesystems zoals btrfs (video).

[Reactie gewijzigd door ClementL op 8 september 2014 13:01]

Is het dan niet eenvoiudiger om het dan in GParted in te bouwen? Lijkt me dat je dan sneller klaar bent :)
Dat zul je aan de developers moet vragen. Echter is Red Hat dol op zijn in-house software .
Het moet ook btrfs support krijgen, maar ik vraag me dan af: Was het niet beter dit gewoon in gparted te bouwen?
quote: phoronix
Red Hat decided to develop a new GUI-driven utility for storage management on Fedora/RHEL as GParted, one of the popular programs for disk management on Linux, doesn't support all of the technologies found in modern Linux distributions.
Dat betekend alleen de gui lijkt veel op Gparted, de functionaliteit zal veel groter worden als Gparted. Zie het dus niet als Gparted lite, eerder als een Gparted++

[Reactie gewijzigd door br men op 8 september 2014 12:58]

Persoonlijk had ik liever gezien dat Fedora eens wat aan de stabiliteit doet. Zelfs packages die als "stable" worden omschreven voelen vaak aan alsof ze nog in een alpha / beta-fase verkeren.

Ubuntu is momenteel de beste keus als je met Linux wilt gaan werken. Indien Gnome 3 / Unity niet bevalt installeer je gewoon de "flashback" software waarmee je de klassieke Gnome 2 interface terug krijgt (wel gemoderniseerd). Heb een poosje met Linux Mint gewerkt, maar daar vielen de prestaties heel erg van tegen.

Fedora is leuk om mee te experimenteren maar werkt niet betrouwbaar genoeg om als vast OS te gebruiken. Tenminste, dat is mijn ervaring.
Mijn ervaring is juist het tegenovergestelde. Ubuntu die in eens niet meer kan opstarten na een update terwijl ik daar met Fedora nooit problemen heb gehad. Ook voor servers is mijn voorkeur liever CentOS dan Ubuntu Server. Ik heb ooit de overstap gemaakt vanwege driver problemen die ik geregeld had bij Ubuntu. Zoals het leeg trekken van de accu.
Centos met ubuntu-server vergelijken is appels met peren vergelijken.
Centos kun je beter met Debian vergelijken.
En dan komt in mijn mening Debian als winnaar uit de bus, maar dat is ieders eigen keus.
Fedora is dan ook een bewuste zandbak. Ubuntu in een RHEL omgeving dumpen :X
Fedora loopt (net als meeste distro's) toch aardig wat achter op Arch Linux. Ik vind dan ook dat ze zich beter op hun kerntaak focussen want vroeger was ik er wel fan van.
Euhm zowel Fedora als Arch zijn bleeding edge, echter is Arch een rolling release en is dus minder gefocused op zijn werk als test branch. Maw Fedora loopt voor op Arch
Komend vanuit de route Ubuntu>Mint>Distro-hopping galore>Fedora, biedt deze distro mij nu al 2 jaar stabiliteit (vanaf Fedora 17 XFCE).
Huis-, tuin- en keuken gebruik, weinig spannends maar altijd stabiel.
Ook geen gedonder met (un)stable updates.
Eenmaal geen netwerk verbinding kunnen maken na een update, update teruggedraait en weer opnieuw gedaan; niet reproduceerbaar, daarna nog een snapshot teruggezet en weer geprobeerd te reproduceren maar de update leverde geen probleem meer op.
Net zo goed anekdotische ervaring als de jouwe maar wel compleet tegengesteld.

-
Verder een mooi initiatief. Zoals al boven opgemerkt een' Gparted++' ipv de 'zoveelste partition manager'
Anaconda is een archaische installer die nieuwe gebruikers kan tergen met "Next/Confirm/OK" knoppen ergens linksboven ipv rechtsbeneden zoals gewoonlijk, verbetering daar is meegenomen, helemaal met een fijne partition manager die binnenkort GParted waarschijnlijk voorbijstreeft.
Ik zie niet de meerwaarde om een geheel nieuwe tool te ontwikkelen als er al code is wat aangepast moet worden of zie ik dit verkeerd?

Dit is eigenlijk een beetje een algemeen probleem dat er best snel wordt gezegd dat er maar een geheel nieuwe tool ontwikkeld moet worden/geforkt wordt ipv dat de oude code verbeterd wordt.
Tjah volgens mij hadden ze hier ook beter de koppen bij elkaar kunnen steken en verder te gaan met gparted of bijvoorbeeld een fork van partitioner.
Aan de andere kant, de mensen die met dit soort zaken bezig zijn weten er een stuk meer van dan ik zelf dus ze zullen ervast goed over nagedacht hebben.
De man heeft de scripts die de Anaconda-installer gebruikt gemaakt. Dit zijn krachtige python scripts die reeds ruime tijd in de achtergrond gebruikt worden, maar voor de 'gewone' gebruiker nooit toegankelijk waren. Nu maakt hij er ook een GUI voor. Deze scripts zijn altijd gelijkwaardig, soms uitgebreider dan Gparted zijn functionaliteiten. Is het dan zo onlogisch dat deze man zijn eigen scripts wilt voorzien van een GUI ipv een ander project te verbeteren? Ik denk dat dit gewoon het gevolg is van een gezonde dosis aan trots; iets wat elke goede programmeur heeft. (of zou moeten hebben). Zeker als hij ook werkt aan de uitbreiding van de scripts met veel features waar Gparted nog zelfs geen plannen voor heeft. (tot zover ik weet, maar hier heb ik niet naar gezocht... - voor zij die zich geroepen voelen... :) -)
Zucht, het zoveelste vehikel in de molen van Fedora.

Heb onlangs CentOS geinstalleerd.
Wat was die partitiemanager/installer een schok.
10 jaar terug in de tijd. Ik kon mijn ogen niet geloven, vol bugs en vele crashes.

Heb daarna maar Oracle unbreakable uitgeprobeerd daar dit een Rhel kloon is om maar eens te kijken waar die installer vandaan kwam.
Zelfde puinhoop. De partitie van openSUSE Tumbleweed werd +/- 50 x weergegeven.

Er wordt geen mogelijkheid opgehouden dat er mensen zijn met meerdere besturingssystemen dus geen grub install op de partitie maar enkel mogelijk op de bootsector van de harde schijf. Volledige Microsoft mentaliteit voor een Linux distributie.

Dan maar eens gaan kijken wat Fedora inhield om toch maar eens na te gaan of het misschien onwaarschijnlijke mogelijk was en dat de installer idd 100% Fedora was.

Dat was dus ook zo, maar uiteindelijk crashte de installer van Fedora op de partitie van CentOS.

Echt niet iets om over naar huis te schrijven.

Jammer dat Rhel en alles daar omheen zoals Oracle/CentOS op Fedora gebaseerd is.
Echt geen reclame voor Linux die installer/partitioner.

[Reactie gewijzigd door El_Bartholomew op 8 september 2014 19:32]

Anaconda kan volgens Podzimek in tegenstelling tot andere partitietools wel gebruikmaken van vrijwel alle moderne opslagtechnieken.
Hmmm, volgens mij kan de Volume/Partitiemanager van openSUSE (ook geintegreerd in de installer) eigenlijk alles wel. Zie ik iets over het hoofd?

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True