Shaman 2 SVN - KDE 4 nadstavba nad Pacman

Grafická KDE 4 nadstavba nad správce balíčků pacman se dočkala rozsáhlých změn. Shaman 2, zatím dostupný v podobě aktuálních snímků z SVN, si klade za cíl spolupráci nejen s pacmanem, ale i dalšími správci balíčků, širokou rozšiřitelnost pluginy, zcela asynchronní chování a skriptovatelnost. Uživatelé Arch Linuxu mohou zkoušet z repozitáře [kdemod-playground].

18.12.2009 14:03 | Nicky726 | Nová verze

Komentáře

[Rezza]

Hlavni je, ze Dario a Lukas se na to pekne vrhli, skutecne makaji, jakakoliv pripominka neni problem a chteji to dostat do co nejvic dister, jak jen to pujde. Asi bych mel udelat snapshot pro Fedoru. Podpora PackageKitu uz je celkem slusna.

[gtz]

Pro Suse je prozatím 3.2-4.3.rpm , pro fedoru(12) také 3.2-4.

[qwertz]

Nechcete mi říct, k čemu bude tato aplikace v SUSE? Kvalit Yastu se zypper backendem to při správě balíčků stejně nedosáhne.

[belisarivs]

Dovolil bych si nesouhlasit.

Satsolver je tam vyveden dobre, ale jinak je treba Synaptic lepsi. A Shaman, kdyz jsem ho kdysi davno zkousel (v dobe snad kolem KDE 4.0) nebyl vubec spatny.

[qwertz]

jinak je treba Synaptic lepsi

Smím vědět v čem? Oba mezi package managery vynikají praktickým zpracováním seznamů balíků malými fonty s checkboxy (žádné ikony velikosti 48 typu packagekit, kde se vejde na monitor seznam s 5 balíky), podobně široké konfigurační možnosti balíků, imho Yast jich má ještě o něco více, ale rozdíly možná padnou na vrub rozdílným backendům zypp/RPM vs. apt/DEB. Není to spíš o zvyku?

[belisarivs]

Treba v tom, ze kdyz chci nainstalovat/odinstalovat/... 20 baliku, tak je v Synapticu oznacim, kliknu pravym mysitkem a vyberu cinnost.

V yastu vybiram jeden po druhem jak blbec. Fakt nadhera.

[qwertz]

Nerozumím. Neznám Synaptic dost podrobně. Jak označíš? Něco jako myš + shift? Tohle umí Yast taky, přičemž použitá klávesa rovnou definuje akci, která bude s balíkem provedena, takže nakonci nemusíš volit, jaká akce bude s balíky provedena. V kontextové nabídce mám navíc volbu pro všechny balíky v daném seznamu (instalovat, aktualizovat nainstalované, smazat nainstalované) a seznamy balíků můžu generovat nejen podle skupin, ale i podle požadovaného názvu.

[belisarivs]

Ano. Myslel jsem mys+shift (nebo ctrl).

Tohle yast neumi, protoze to neumi yui. Feature bugreport, ktery jsem hodil do bugzilly byl tusim zavren jako wontfix protoze se prechazi na webyast.

Ano, ty veci kolem skupin balicku znam. Zaplat pan Buh, za ne. Jinak by to bylo na zblazneni. Ale proste neexistuje, abych se shiftem vybral X baliku a zvolil jejich instalaci/reinstalaci/whatever.

[qwertz]

Tak to se mi zdá, že Yast umí ještě něco lepšího:

 "mys" nebo "mys"+"+" označí balík k instalaci.
 "mys"+"-" balík označí k odinstalaci.
 "mys"+"!" balík zakáže.
 "mys"+"*" balík zamkne.
 "mys"+">" balík upgraduje.
 "mys"+"<" balík ponechá.

Nemusím tedy shiftem označovat balíky a pak volit akci k provedení, ale místo shiftu tuto akci určit rovnou klávesami + - ! * < >.

[belisarivs]

Pro mne je teda lepsi kliknout jednou, pak o 20 baliku dale jeste jednou se shiftem a pak si zvolim co chci.

20 baliku byl priklad. Uz jsem takhle resil treba stovku.

[qwertz]

To je to co nechápu:

Synaptic: 20 balíků "shift" + "myš" -> kontextová nabídka -> odinstalace balíků -> provést akci

Yast: 20 balíků "-" + "myš" -> provést akci

A na základě toho mi tvrdíš, že Synaptic to má lepší?

[belisarivs]

Ne.

Jak rikam, v Yastu nejde vybrat 20 (nebo treba sto) baliku tak, ze oznacis prvni a pak posledni se Shiftem. Tohle v Synapticu jde.

Takze by to melo byt takto:

Synaptic: klik 1. balik -> shift + klik posledni balik -> pravy klik -> instalovat Yast: 20x pravy klik na balik -> instalovat

Cili, ja tvrdim, ze Synaptic je lepsi na zaklade tohoto.

[qwertz]

Právě že to v Yastu jde a to ještě lépe. Řekněme, že chci zamknout 100 balíků (instalovat, odinstalovat, upgradovat... dosaď si co chceš. V synapticu zmáčkneš Shift, a označíš 100 balíků. Pak vlezeš do kontextové nabídky a vybereš uzamknout.

V Yastu místo klávesy shift stiskneš klávesu * a úplně stejně označíš 100 balíků, které se tímto rovnou označí za zamknuté (protože * definuje akci uzamknout). Takže na rozdíl od Synapticu nemusíš do kontextové nabídky (pravým) nikdy a o tuto akci je tedy úkon kratší.

Yast má proto oproti synapticu 2 výhody:

1) Označení 100 balíků pro danou akci je v Yastu kratší, protože nelezeš do kontextové nabídky ani jednou, v Synapticu tam jednou musíš - na konci označování.

2) Synaptic neumí najednou 50 balíků zamknout a 50 upgradovat, protože musíš shiftem označit jednu skupinu, vlezt do kontextové nabídky, pak druhou skupinu a vlázt do kontextové nabídky. V yastu držíš místo shiftu příslušnou klávesu pro každý balík.

[belisarivs]

No tak to musim vyzkouset. Co si vzpominam, tak mi to neslo minimalne v poslednich 2 openSUSE (v Qt4 verzi) a jak rikam, nahlasil jsem to do bugzilly a bylo to zavreno jako low priority.

[qwertz]

Coze? Chces rict ze Yast-Qt bude nahrazen webovým rozhraním, který vyvíjejí? Já myslel že to bude jen příjemný doplněk pro remote control....

[belisarivs]

Ne nahrazen, proste neni tak prioritni. Mam za to, ze zustane.

[Espinosa]

Mimochodem, jak je na tom Synaptic. Vyvíjí se ještě vůbec? Kdypak vyšla poslední stabilní verze? Podle wikipedie tomu budou pomalu dva roky.

Používal jsem ho jak s Fedorou, Ubuntu i s PClinuxem. Pouze na SUSE (apt měl bugovou podporu repo-mp formátu) se nezadařilo. Byl to můj oblíbený program, nějaké výtky by tam byly, nic zásadního co by se nedalo s trochou úsilí opravit. Uměl vše co jsem potřeboval a co zvládalo apt, a to téměř bez chyb. O kolika programech tohle můžu říct. Snad jen ta svázanost s APT, nemodulárnost.

Používá dnes ještě jako primární GUI package manager v nějaké distribuci? I Debian oficiálně tlačí aptitude místo apt. Napadá mě jen PCLinux, ale to je dost malá distribuce.

Mrzelo by mě kdyby další zdařilý program šel do kytek. Zahynul utopením se v moři duplikátů :(

[belisarivs]

No, na mailing listu se sem tam nejaka hlaska objevi a nejaka nova ficura taky. Cili mrtvy neni. Jenom proste nema porad nove verze. Proc taky?

Ja jsem s nim spokojen. Jeste bych uvital, kdyby mel tak naslaply sat-solver jak je v yastu. Ten je vazne vyborny. Na reseni drsnejsich zavislosti nema snad konkurenci.

[marvn]

koukam, ze zatim pouze pro x64. v chakre se z toho pomalu stava tradice...

[belisarivs]

s/x64/x86_64/g

[dark]

Ale no tak:)

[Scarabeus IV]

Mnohem efektnejsi by podle me bylo pomoct s vyvojem kpackagekitu, pokud ma teda arch moznosti vyuzivat packagekit (my v gentoo treba nemame, ale vim ze na tom jeden vyvojar dela a rikal ze uz to i castecne funguje :]).

[belisarivs]

Mne se Kpackagekit nelibi.

Synaptic mi proste hodne sedi. Je jednoduchy a prehledny. A Shaman, alespon v te starsi verzi, ze jim hodne inspiroval. Pokud bude pro vice dister, budu jenom rad.

[Espinosa]

> Mne se Kpackagekit nelibi.

Něco se mi nelíbí -> založím nový duplicitní projekt. Ach jo, kdy už se vývojáři FOSS zbaví tohoto myšlenkového viru.

Dobré GUI mají jednu skvělou vlastnost - konfigurovatelnost vzhledu. A KDE vychází vstříc. Rekonfigurovatelné rozložení panelů, tear off panely, rekonfigurovatelné toolboxy a do značné míry i menu. Na výmluvy není místo.

Něco se mi nelíbí -> vylepším stávající perspektivní projekt. Dopíšu chybějící funkčnost, přidám plugin, přidám volitelný vzhledový profil.

[belisarivs]

Mne se Kpackagekit nelibi.

Něco se mi nelíbí -> založím nový duplicitní projekt. Ach jo, kdy už se vývojáři FOSS zbaví tohoto myšlenkového viru.

Osobne doufam, ze nikdy. On totiz ten duplicitni projekt muze nakonec prevladnout protoze se ukaze jako lepsi. Oni totiz vyvojari toho stavajiciho nejsou vzdy nakloneni navrhovanym zmenam.

Dobré GUI mají jednu skvělou vlastnost - konfigurovatelnost vzhledu. A KDE vychází vstříc. Rekonfigurovatelné rozložení panelů, tear off panely, rekonfigurovatelné toolboxy a do značné míry i menu. Na výmluvy není místo.

Tak to pak musis mit ze Shamana zakonite radost .

Něco se mi nelíbí -> vylepším stávající perspektivní projekt. Dopíšu chybějící funkčnost, přidám plugin, přidám volitelný vzhledový profil

Jiste. Pokud ovsem autor opravy prijme. A co kdyz neprijme? Co bys pak navrhnul? Hozeni napadu do kose? Ministerstvo lasky, ktere autorovi obuchem vysvetli nevyhody jeho nazoru?

Jake OO.o preferujes? Ty od Sunu nebo ty od Novellu? Pouzivas jeste XFree86 a Open Sound System?

[Espinosa]

> On totiz ten duplicitni projekt muze nakonec prevladnout protoze se ukaze jako lepsi.

To klidně může. Já mám rád optimisty. Může klidně převládnout ten horší, Gwenview vs Showimage.

Nebo ještě pravděpodobněji budou oba projekty existovat vedle sebe a drolit komunitu (apt, aptitude, yum, urpmi, zypper..) Každý bude mít nějakou tu výhodu ale o žádném nejde říct že by natolik oslnil a přešli na něj všichni.

Ale i když nastane ta pozitivní varianta a převládne jeden, bude mu to trvat daleko déle, než kdyby se vývojáři společně pustili do vylepšování stávajícího.

Je to velmi neohleduplné k uživatelům. A já jsem převážně uživatel. Nemám rád, když si musím zvykat na nový program, sice podobný, ale přesto odlišný, který má svoje bugy, vrtochy, nedostatky, a když už už si opět zvyknu, už už se to začne blížit mým představám kde to mohlo být dávno, buch, na scéně je třetí projekt, se stejným cílem, a cyklus se opakuje. Možná pravověrný Hinduista by z toho byl nadšený, věčný cyklus převtělování, ale já bych jako prostý uživatel nejraději co dosáhl stavu mókša a měl svůj vytoužený funkční program. To by byla Nivána!

> Oni totiz vyvojari toho stavajiciho nejsou vzdy nakloneni navrhovanym zmenam. A co kdyz neprijme?

Kdyby bylo tolik verzí jádra jako bylo neúspěšných přispěvatelů, bylo by dnes nekompatibilních jader linuxu víc než je distribucí a linux by snil o 0.001% na trhu serverů o desktopu ani nemluvě. Stačí se podívat jak je na tom nevalně BSD, a to jsou jí tak 4 (?) varianty.

OpenOffice je dobrým příkladem, jak se s takovou situací vypořádat. Komunita vytvořila patchset - go-ooo, našla si financování (Ximian a později Novell), který s mateřským projektem spolupracuje a v rámci možností se snaží upstream. Většina (všechny) distribuce pak staví na této

Kernel je na tom podobně. Existuje řada patchsetů, ac, mm (nebo jak se to teď jmenuje) já kdysi používal ck. Snad žádná distribuce nepoužívá vanilla kernel, ale svoji sadu patchů. Řada z nich se nikdy nedostane a nedostala do upstreamu, zaslouženě či ne (supermount, splashy, ..).

Xorg je ukázkou té horší situace - fork projektu - ale bravurně zvládnuté! Smutný příběh s dobrým koncem, pro uživatele určitě. Fork přetáhl drtivou většinu vývojářů a uživatelů, vývoj to nijak nenarušilo, a Xorg je de facto prostě novou verzí XFree, či dokonce jen estetickou změnou jména mezi dvěma verzemi.

> OSS

Já bych milerád stále používal OSS, kdyby ho udržovali. Oni byly s ALSou dlouhou dobu (roky) spíš trable než výhody, podobně jako je tomu s řadou dalších projektů které vám cpou aniž by se vás moc kdo ptal na názor (NetworkManager, PulseAudio, Phonon, KDE4, ..)

[thingie]

Jo, máme spoustu různých implementací, která má každá jiné výhody a nevýhody, každá je založená na jiném přístupu, žádná není rozhodně lepší než všechny ostatní. Takže se sejdeme, a dohromady napíšeme jednu úžasnou, která bude lepší než všechny ostatní dohromady.

A to bylo jako myšleno vážně?

[Espinosa]

Pokud je tím myšleno vytvoříme další NOVÝ projekt, další Ntou duplikaci, tak to samozřejmě NE. I kdyby motivy byly sebelepší. To je přesný opak toho co tu vykládám.

[thingie]

Slovo projekt v podstatě vůbec nic neznamená -- proto se jím taky označuje dneska úplně všechno. To je jedna z vtipných skutečností v podobných diskusích.

Nicméně. Dejme tomu, že máme několik různých implementací velmi podobné věci, ale každá je v něčem trochu jiná, má jiné vlastnosti, v něčem je lepší, něco nezvládá. Žádná není tak dobrá, aby se dala označit za jasného vítěze. Ty se zřejmě domníváš, že pokud se jedna vybere a věnuje se jí to zaklínané „veškeré úsilí“, tak se z ní ta nejlepší stane. Což je samozřejmě kravina, Do patnácti minut se narazí na zásadní omezení v návrhu, která si vynutí úplně novou implementaci, už jenom proto, aby mohla zvládnout všechno co ty, které má nahradit. A ve výsledku to nejspíš bude provar. Jako vždycky.

Ale furt budou chodit lidi a navrhovat tyhle nesmysly. Achjo.

[Espinosa]

Ach jo, ach jo, taky si říkám že blbost je věčná, ale z opačného pohledu ;)

> projekt

Dříve se používalo slovo program, případně aplikace. V současné době, ale v mnoha případech je to zavádějící (omezující) termín. Vezměte si jen příklad zmiňovaného PackageKitu. Co je to: aplikace? dva GUI klienty to má, hromada nezávislých může (bohužel) ještě vzniknout. Je to utilita, tool, nástroj? Ten je přiložen také. Samostatná knihovna? To je samozřejmě také. Systém, framework, implementace, protokol, technologie, myšlenka, idea, website, komunita? I to by se dalo tvrdit. Takže je nutné použít o něco abstraktnější termín, který by tohle všechno dokázal zahrnout a nediskriminovat žádný z aspektů. Termín "projekt" vyhovuje.

http://en.wikipedia.org/wiki/Project Definice na wikipedii z těch slabších, ale stále použitelná je. Hlavně diskutovatelné je to "*carefully* planned". A chybí specifické vymezení pro software project.

> Ty se zřejmě domníváš, že pokud se jedna vybere a věnuje se jí to zaklínané "veškeré úsilí", tak se z ní ta nejlepší stane.

Zaručené to není, to není koneckonců nikdy nic, ale větší šance to má. Dokonce i kdyby zmíněný výsledek nebyl nejlepší, stačí když bude použitelně dobrý, tak samotná jednotnost přinese svoje výhody. Stabilní API, tvorba extenzí a pluginů pro specifické požadavky, zpravidla i lepší dokumentace, více popularizačních článků, jednodušší radění v poradně atd.

Mimochodem, neagituji tady za naprostou jednotnost, že se musí zůstat jeden právě JEDEN projekt, stačilo by výrazněji omezit množství. Například v případě KDE a Gnome, Firefoxu a WebKitu, Java vs .Net, má soupeření i svoje zřetelně pozitivní stránky. Musí být ale splněny určité předpoklady - dostatek vývojářů, dlouhodobá kontinuita jednotlivých projektů (platforem). To GUI a ani balíčkovací manažery nesplňují.

Pokud jste měl na mysli ekonomický zákon o "klesajících výnosech" (http://en.wikipedia.org/wiki/Diminishing_returns) V našem případě míněno klesající výstup při rostoucí koncentraci vývojářů po dosažení určité meze, ten můžeme u FOSS klidně opominout, této meze není dosaženo v žádném mě známých projektů. FOSS trpí přesným opakem. V této souvislosti upozorňuji na článek Michaela Meekse nad stavem OOo na které souhrnně pracuje 60 lidí místo potřebných odhadovaných 600ti, pro porovnání na Linuxu pracuje snad okolo 300 lidí a je to projekt s polovičním rozsahem codebase.

> Do patnácti minut se narazí na zásadní omezení v návrhu, která si vynutí úplně novou implementaci

Implementace do patnácti minut? Něčeho složitosti balíčkovacího systému? Wow, to by jste u vás zvládli? To u nás i úvodní analytická studie trvá déle o implementaci ani nemluvě. Gratuluji, jste vývojáři-Stachanovci. Bohužel po nich se ta práce opravdu často musela předělávat.

[Espinosa]

> Tak to pak musis mit ze Shamana zakonite radost

Podle toho co o něm píší, pak ano. Reálná zkušenost ale může být jiná. Za ta léta s linuxem a FOSS jsem se naučil být k novým projektům skeptický. V krátkodobém výhledu nepřinášejí nic moc dobrého a v dlouhodobém - ten většinou není protože přijde nový projekt no a jsme zase na začátku.

Ale zpět k šamanovi. Připusťme, že je to bomba, že ty dva autoři jsou borci jako FOSS už dlouho nevidělo. Stále tu je ta hořkosladká příchuť faktu - kdyby ti dva borci dali ruce k dílu na KPackageKitu, nemohli jsme být dneska ještě dál? Vždycky je co zlepšovat.

> Pokud ovsem autor opravy prijme. A co kdyz neprijme? Co bys pak navrhnul?

Ta nejlepší varianta je, pokud je program navržen modulárně, tak mě názor autora nemusí zajímat. Prostě vytvořím nový modul a nechám na uživatelích, zda ho budou používat nebo ne. Musím jen doufat, že nezmění API.

S modularitou bohužel FOSS & linux dost zápasí. No jsou tam i světlejší místa: Kernel (Nvidia, ATI, ), Firefox, OO.o, KDE (KIO, KParts, Phonon, KIPI,..) ale bolístek je hodně (možnosti OO.o extenze jsou omezené, KIPI jsou špatně integrované, a nejhorší jsou změny API - Kernel, KDE4, ..).

Suma sumárum, neochota autorů původní aplikace není problém. Pokud je to modulární aplikace - pak je to vůbec brnkačka, pokud ne - i pak je neinvazivních možností hodně.

[qwertzuiop]

Kdo vymýšlí ty názvy? Nějaká liduška?