Co přinese Fedora 19? (diskuse)

[yac]

První dva projekty lze zkombinovat do komba OpenShift nad OpenStackem... FOSS modulární cloud v základní výbavě je sice pro BFU poněkud obskurní, ale přesto zajímavá vlastnost.

Distribuovaný a svobodný mrak je přecejen lepší než... všchno u Amaznou/Googlu/Facebooku/$YOUR_OVERLORDS :-p

[dizz]

A uz bude podproa instalatoru pro instalaci na LVM nad sw raidem?

[pavlix]

A to celé například nad MBR partitionami?

[dizz]

Citim v tom ironii pokud je LVM + SW RAID blbost prosim o nakopnuti spravnym smerem

[pavlix]

Není to ironie. Někteří jsou skutečně tak zakopaní v enterprise světě, že je nenapadne, že bys mohl chtít ten SW raid stavět nad systémovými disky, které z různých důvodů potřebují pod LVM či RAIDem ještě klasické schéma typu MBR nebo GPT.

Lidi jako já a mnoha dalších, kteří už nainstalovali kupu malých serverů stylem tři disky, stejně rozdělit, složit po partitionách do raidu, nad tím LVM, nad tím občas nestačí kroutit hlavou. Nehledě na to, že mi přijde jako neskutečná kokotina nutit uživatelům/administrátorům víc než jeden nástroj na rozdělování disků (tedy používat při instalaci nástroj, který později není k dispozici). Když stejný člověk vykřikuje něco o usability, to už si pak fakt zakrývám hlavu.

[MarSik]

ehm Pavlixi, aniž bych chtěl bývalé kolegy nějak obhajovat, neznám bohužel žádný nástroj, který by toho uměl tolik co partitioning v Anacondě. Partition magic byl lepší na lokální věci, ale zase neuměl LVM a síťové srandy jako iSCSI (a filtraci když jich na nějakém NASu jsou stovky).

To že některé funkce běžný domácí uživatel nikdy neuvidí je fakt se kterým se nedá nic dělat. Bohužel je taky pravda, že během přepisu GUI opravdu některé volby zmizely (snad se zase brzo objeví), ale storage backend pořád všechny tyhle hierarchie podporuje. Kickstart taky :)

A jinak s tím stejným nástrojem je to trošku ošidné, během instalace jsou potřeba některé dost specifické informace o tom layoutu, které pak už v běžném provozu moc nepotřebuješ. Takže i když vezmeš nějaký vhodný distribuční nástroj, stejně ho nemužeš použít v offline režimu. Anaconda totiž na disk sahá až těsně před instalací balíků a všechno si to předtím drží jen v paměti.

Co si ale pamatuju instalaci snad čehokoliv, tak to nikdy neumělo zaráz použít offline režim (kde se dá vrátit zpátky na začátek bez ztráty dat) a distribuční nástroj. Windows, Debian a myslím i SUSE během instalace měly specifické menu a nástroje. Gentoo a BSD prostě jen pustily fdisk nebo disk druida, který rozhodně nebyl offline (a neuměl síťové disky).

[pavlix]

ehm Pavlixi,

Potrefená husa. Ahoj.

aniž bych chtěl bývalé kolegy nějak obhajovat, neznám bohužel žádný nástroj, který by toho uměl tolik co partitioning v Anacondě.

Což je taky hlavní a jedinou podstatou mé poznámky výše.

A jinak s tím stejným nástrojem je to trošku ošidné, během instalace jsou potřeba některé dost specifické informace o tom layoutu, které pak už v běžném provozu moc nepotřebuješ.

Souhlasím s tím, že instalace může do určité míry vyžadovat specifické chování, ač nevím, které informace máš přesně namysli.

Takže i když vezmeš nějaký vhodný distribuční nástroj, stejně ho nemužeš použít v offline režimu.

Kdysi jsem používal nástroje v offline režimu, ale to bylo ještě na windows. Hádám, že Linux jako platforma tomu nijak nebrání, takže jde jen o to, zda takový nástroj někdo připravil či nikoliv.

Co si ale pamatuju instalaci snad čehokoliv, tak to nikdy neumělo zaráz použít offline režim (kde se dá vrátit zpátky na začátek bez ztráty dat) a distribuční nástroj. Windows, Debian a myslím i SUSE během instalace měly specifické menu a nástroje.

Přece nebudeme nejinovativnější™ distribuci srovnávat s Debianem nebo Windows ;).

[little.owl]

Tak urcite by bylo hezke, kdyby Anaconda byla modularni a moduly sly pouzit i mimo vlastni instalaci - nebo na nich postavit podobne nastroje - a zrovna operace nad disky a ulozisti je dobry kandidat.

[MarSik]

Pracuje se na tom :) Storage už je skoro vysekané do knihovny (1), která by měla jít použít nezávisle na instalátoru. Pak to chce ještě aby někdo udělal aplikaci s jednotným GUI, což bude větší problém..

1) https://fedoraproject.org/wiki/Blivet a https://git.fedorahosted.org/git/blivet.git

A co se GUI týče, Anaconda v F19 už podporuje pluginy. A nový firstboot (initial-setup) přes ten mechanizmus z Anacondy přebírá obrazovky.

Ten přepis GUI (vnitřnosti se moc neměnily) v F18 byl už strašlivě dlouho nutný. Byla tam logika rozházená všude, nedalo se to pořádně testovat.. holt starý projekt. První (a zrovna GUI) commit v Anacondě je totiž z roku 1999 a architekura toho GUI kódu se za celou tu dobu prakticky nezměnila.

[pavlix]

Pracuje se na tom :) Storage už je skoro vysekané do knihovny (1), která by měla jít použít nezávisle na instalátoru. Pak to chce ještě aby někdo udělal aplikaci s jednotným GUI, což bude větší problém..

Je vidět, že sovička má v sobě skutečné charisma. Já jsem od tebe takovouto reakci nedostal.

1) https://fedoraproject.org/wiki/Blivet a https://git.fedorahosted.org/git/blivet.git

Pěkné.

A co se GUI týče, Anaconda v F19 už podporuje pluginy. A nový firstboot (initial-setup) přes ten mechanizmus z Anacondy přebírá obrazovky. Byla tam logika rozházená všude, nedalo se to pořádně testovat.. holt starý projekt.

Velmi pěkné.

Ten přepis GUI (vnitřnosti se moc neměnily) v F18 byl už strašlivě dlouho nutný.

Tomu věřím.

První (a zrovna GUI) commit v Anacondě je totiž z roku 1999 a architekura toho GUI kódu se za celou tu dobu prakticky nezměnila.

Je docela zajímavé sledovat, kolik věcí získává buď od začátku nebo postupem času tak špatnou architekturu, že je nutné to zahodit a ještě vyměnit takhle nadivoko.

[lmb]

Sorry za OT, ale je tu debata o Fedoře a v patičce máš link na NetworkManager, na kterej se chci zeptat. Nevíš náhodou proč je tak paměťově náročnej ? Po Firefoxu s cca 20 extensions je to druhej nejnenažranější proces v systému na kterým běží i celý GNOME.

[pavlix]

Nevíš náhodou proč je tak paměťově náročnej? Po Firefoxu s cca 20 extensions je to druhej nejnenažranější proces v systému na kterým běží i celý GNOME.

Neměl by být. A třeba v topu ho nikdy nevidím. Znám v něm pár podezřelých míst, která by zasloužila odhnojit, ale nic, co by způsobovalo nárůst na úroveň desktopových aplikací.

O jakou verzi se jedná? Srovnával jsi to s nějakou jinou (ideálně novější) verzí? Pokud je to relativně nová verze (>= 0.9.6), tak by stálo za to zkusit vyzískat nějaká data o využívání paměti, zadat bugreport na bugzilla.gnome.org a spolupracovat na odhalení příčiny.