Názory k článku
Fedora 20 dostane nového správce software
-
Zdenek (neregistrovaný)
Myslím, že nejlepší bude si nejprve něco přečíst o plánech a současném vývoji této aplikace, než projekt pouze urážet.
Blogy vývojářů:
1) http://en.eladalfassa.com/2013/09/gnome-software/
2) http://blogs.gnome.org/hughsie/Ano, fonty a ikonami se zde skutečně nikdo nezabývá... A pokud se design nezdá ok, proč místo ironických komentářů nenareportovat bug...???
-
Yenya (neregistrovaný)
Podle mě zásadní otázka je, jestli vůbec tohle patří do distribuce jako takové. A můj názor je že nepatří. Distribuce má být zabalený third-party software s minimem vlastní invence (instalátor, initscripts, ...). Ale nechápu proč by každá distribuce měla mít svoji klikací nadstavbu nad RPM a podobně. Ať se taková věc vyvíjí nezávisle na Fedoře nebo OpenSUSE, a ve volné soutěži prokáže, které distribuce ji budou chtít zařadit (nebo dokonce použít jako implicitní).
No a další věc je to neustálé přepisování softwaru "od začátku a tentokrát určitě lépe" (ve skutečnosti "tentokrát trochu jinak a s daleko menším množstvím funkcionality, než ke kterému nás uživatelé v průběhu vývoje předchozí verze proti naší vůli dokopali"). Anaconda, PackageKit, GNOME 2, GNOME 3, gdm-2.20, epiphany, ... furt se to opakuje. U GNOME 2 dokonce při zveřejnění tvrdili, že fakt nemohli v průběhu vývoje tušit, kam to dospěje, a že teď už to konečně udělají pořádně. No, neudělali, a máme GNOME 3. Viděl někdo že by se od začátku přepisoval kernel Linuxu? Nebo Glibc? (tam byly problémy s binárním formátem, ale přepisování nikoliv).
Já samozřejmě nemám co kecat do toho, kdo jak využívá svůj čas. Ale podle mého názoru by se to přepisování nemělo brát jako "bude něco nového a zajímavého", ale jako "autor bude zřejmě neschopný, když to nedokáže udělat inkrementálně".
-Yenya, http://www.fi.muni.cz/kas/blog/
-
Yenya (neregistrovaný)
Pointa je v tom slově "část".
Když to zahodíte _celé_ s tím, že teď to napíšete lépe, tak za dva roky zjistíte, že gdm pořád ještě neumí XDMCP, protože pochopitelně při tom přepisování je největší motivace u toho "postavit tu infrastrukturu tentokrát lépe". Ale už se nedostanete k tomu udělat pomocí té infrastruktury to všechno, co původní systém uměl. A když už se to začne blížit původnímu rozsahu schopností, nazná přepisovač, že je nutné začít přepisovat znovu. Protože - světe div se - nový kód na tomto rozsahu funkcionality opět není nejhezčí. Linux taky zahodil IEEE1934 stack a zavedl nový, WiFi stack totéž. Ale vždy to bylo dělané inkrementálně, bez ztráty funkcionality, s postupnou migrací.
Samozřejmě není sporu o tom, že každý kus kódu který dělá něco reálného bude mít v sobě dost míst, k jejichž čtení je potřeba předchozí užití Kinedrylu. Problém je, že i ten nový kód by dopadl stejně, pokud by uměl všechno to, co umí předchozí. Čili podle mého názoru je rozumná strategie "zahodit část kódu a napsat ho znovu", pokud ta část je dostatečně malá na to, aby jednak celek nepřišel o funkcionalitu, a jednak abych se mohl kdykoli vrátit zpět, pokud třeba nový směr není ten správný nebo na něho nenajdu dostatek času.
-Yenya
-
Yenya (neregistrovaný)
Jasně, ale tohle je argumentace ad absurdum.
Jsou - velmi zřídka - situace, kdy je původní návrh celý špatný. Ani jedna z těch které jsem zmiňoval to ale není. Jak by mohl být původní návrh Anacondy (například) celý špatný, když se používala skoro 20 verzí Fedory a předtím ještě několik verzí Red Hat Linuxu? A po celou tu dobu si vystačila s inkrementálními změnami.
Každopádně i změny v jádru aplikace lze většinou dělat inkrementálně. Je to pracnější, ale zase uživatel nepřijde o funkcionalitu.
