Varovný příklad vývoje a řízení open-source projektu

28.7.2010 23:34 | Přečteno: 3446× | | poslední úprava: 29.7.2010 06:57

Každý open-source projekt, na kterém se podílí velká skupina lidí, kteří se často v reálu ani nikdy nesetkali, zákonitě musí čelit problémům, které tento způsob vývoje přináší. Neuškodí se proto podívat na jeden špatný příklad z minulosti a pokusit se poučit z jeho chyb.

Jako tento příklad nám bude sloužit Squeak, implementace Smalltalku přímo vývojově navazující na Smalltalk-80. Jeho vývoj jakožto komunitního open-source projektu započal již v roce 1996, takže si prožil už lecos. Od počátku měl velké cíle (z čehož plyne velké množství práce) a relativně nevelkou komunitu složenou z velmi inteligentních, ale často nesouznících lidí.

Pozor na startéry

I hired finishers because I’m a good starter and a poor finisher. -- Alan Kay

Prvek, který svým způsobem velmi negativně ovlivnil vývoj Squeaku, je jeho otec, věhlasný pionýr z PARC, laureát Turingovy ceny a geniální vizionář Alan Kay. Je to prvotřídní příklad startéra, člověka, co rozjede projekt, dokáže namotivovat lidi a velmi rychle ho uvede v život. Takoví lidé jsou nezbytní, ale Alan opakovaně ukázal, jaké nebezpečí představují. S energií sobě vlastní se nejdříve vrhnul na samotný Squeak a vdechl mu život. Jeho velkým cílem je vytvořit ideální systém, který umožní pracovat s počítači a programovat je i dětem. Protože již koncem sedmdesátých let mu začalo být jasné, že Smalltalk je pro tento účel stále příliš složitý, převzal ze Selfu do Squeaku uživatelské rozhraní Morphic a začal nad ním stavět EToys.

Objektová paměť Squeaku snese kde co, přidávat do něj novou funkcionalitu je velmi snadné a ještě snazší je zapomínat na důslednou modularitu, případně se spolehnout na to, že ono se to někdy v nedaleké budoucnosti nějak udělá. V důsledku toho se EToys do Squeaku pořádně zažraly. Také vytvořit fork je velice jednoduché, takže brzy se aktivita kolem EToys začala soustředit kolem SqueakLand image určené pro děti a výuku programování a synchronizace se Squeakem začala váznout.

Později se Alan s veškerou energií vrhl na Croquet, 3D kolaborativní prostředí, aby následně v souvislosti s OLPC opět zaměřil svou pozornost na EToys a později na projekt Reinvention of Programming.

Prakticky při každém tomto přelití jeho kreativity se vytvořil nový fork Squeaku a odčerpala se část energie, která by jinak byla vynaložena na vývoj samotného Squeaku. A ten začal pomalu váznout.

Říká se, že revoluce požírá své děti. V tomto případě se tak nestalo a děti začaly požírat revoluci. Podobných příkladů, kdy iniciátor nějakého projektu začne později vytvářet konkurenční, je celá řada.

Osobně si Alana Kaye samozřejmě velmi vážím a jeho startérství není chyba, ale vlastnost. Každý projekt by si měl včas najít cestu, jak se s takovými lidmi pokud možno v dobrém vypořádat.

Žít a nechat zemřít

Díky bobtnání Squeaku začala být jeho správa stále problematičtější. Na udržování takového množství rozličného kódu prostě nebylo dost lidí a jeho původní autoři svůj zájem posunuli jinam. Na jedné straně se do jeho údržby nechtěl nikdo pouštět, na druhé straně zase nebyla vůle jej vyřadit, protože všem bylo jasné, že jeho vyloučení ze základního systému by znamenalo jeho definitivní konec. Proto se situace dále prohlubovala.

Kdyby bylo modulárnosti Squeaku věnováno více pozornosti hned od prvních verzí, bylo by tenkrát mnohem snazší ji zajistit a navazující projekty by byly vystaveny přirozenému vývoji, kdy ty, o které nikdo nemá zájem ať už jako vývojář či jako uživatel, upadnou v zapomnění.

O první velký pokus o modularizaci Squeaku se pokusil mladý seveřan Henrik. Jeho práce vypadala velmi slibně a obecně se předpokládalo, že se stane základem další majoritní verze Squeaku. Nicméně po čase přestal bez vysvětlení Henrik s komunitou komunikovat a jeho práce díky tomu nakonec přišla vniveč. Až po letech se zjistilo, že jeho odmlka byla způsobena tím, že zemřel.

Poučení pro ostatní projekty: předvídejte budoucí problémy a neodkládejte pracné, avšak nezbytné úkony. Nesnažte se za každou cenu udržovat starý kód. Snažte se svoji práci zpřístupnit i ostantím členům projektu, ať nejste jediní, na kom závisí její další vývoj. Udržujte sociální vazby mezi přispěvateli projektu.

Doers decide

Časem bylo zjevné, že původní tahouni projektu jako Alan Kay, Dan Ingalls či Andreas Raab soustředili svoje zájmy jinam. Nicméně oficiálně vývoj Squeaku stále kontrolovali. Ten bez vedení přešlapoval na místě. Když bylo jasné, že se na této situaci nic brzy nezmění, chopila se iniciativy francouzsko-švýcarská část komunity pod vedením Stéphana Ducasseho, kteří už dlouhodobě byli těmi, kdo vývoj Squeaku někam posouval. Samozřejmě převzetí velkého projektu sebou přináší řadu starostí s právní, finanční a technickou infrastrukturou, ale všechny se podařilo překonat.

Zdědili nemodularizovaný rozsáhlý systém používaný pro celou řadu cílových oblastí. Existovalo několik faktických forků Squeaku pro tyto oblasti, ale i lidi kolem nich se snažili vývoj Squeaku stále ovlivňovat a jádro vývojového týmu se jim přizpůsobovalo, ač jejich vlastní představy s nimi nesouznily. Málokdo si chtěl připustit, že Squeak jakožto sjednocující základní “distribuce” už je minulostí.

Situace se vyhrotila s vydáním Squeaku 3.9, který mimo jiné přišel s Traits. Andreas Raab toto rozhodnutí silně kritizoval. Forky jako EToys a Croquet dále pokračovaly ve svém vývoji na základě Squeaku 3.8. Neustálé dohadování se už Stéphana a lidi kolem něj unavilo a otrávilo natolik, že odmítli vést vývoj další verze.

Vedení vývoje se ujal uznávaný Ralph Johnson a Edgar J. De Cleene z Argentiny. Oba bohužel přecenili své síly. Ralph vedení zřejmě časově nezvládal a komunikoval velmi málo, Edgarova na to zejména jazykově nestačil.

Po několika měsících to Ralph vzdal a hlavní slovo tak získal Edgar a Keith Hodges. Keith udělal spoustu práce, ale stylem one-man-show a nebyl schopen ji v komunitě patřičně publikovat. Navíc k útočnému stylu vyjadřování neměl nikterak daleko.

Vývoj Squeaku se ne a ne pohnout dál, až to původní vývojáři jako Ducasse nevydrželi, vrátili se ke svému Squeaku 3.9 a vytvořili fork, který pojmenovali Pharo.

S ním pak začali dělat věci, které již dlouho považovali za důležité a které ve Squeaku nebyly politicky průchodné - odstraňovat MVC, EToys, podporu projektů a udělali řadu systémových zásahů více či méně ovlivňujících zpětnou kompatibilitu. Velká část komunity (především lidé okolo Seaside) se přidala na jejich stranu a vývoj tohoto Smalltalku postupuje rychle kupředu.

Squeak samotný tento odliv zájmu přivedl do krize, proti které zakročil Adreas Raab tím, že v podstatě “násilně” převzal vývoj Squeaku, což např. Keith neustál a rozešel se s komunitou ve zlém (“If I email to squeak-dev again shoot me”).

Poučení z této kapitoly se hledá těžce, ale asi by znělo: “Nechte rozhodovat ty, co skutečně něco užitečného dělají, jinak sice budete mít mnoho lidí, co budou rozhodovat, ale nikoho, kdo bude něco dělat.”

Licence

Vývoj Squeaku začal pod Apple licencí, protože vyšel z původní verze Samlltalku-80, kterou si pro své potřeby Apple upravil. Tato licence není moc standardní a měla některé problematické body, takže se postupně vykrystalizovala snaha tuto licenci změnit na MIT či podobnou. Silnou vzpruhou byl Alanův úspěch, když se mu podařilo zajistit změnu licence první verze Squeaku na Apache licenci. Shromažďovala se svolení všech vývojářů, kteří mezi tím ke Squeaku přispěli, se změnou licence a přepisoval se kód, u kterého to nebylo možné zajistit.

Nakonec VPRI toto úsilí ukončilo tím, že (trochu riskantně) vydalo celou EToys image (založenou na Squeaku 3.8) pod MIT licencí s tím, že za celou dobu se proti změně licence nikdo ani slůvkem neozval.

I z příkladu GPL v.3 je vidět, jak je boj s licencemi někdy problematický. Proto např. zmiňované Pharo připouští jen kód, který je zaslán vývojáři, kteří podepíší licenční ujednání, které má jednou pro vždy takovýmto nejasnostem a zbytečnému přepisování zabránit.

Nutné zlo

Moje role v tom všem byla nepatrná. Snažil jsem se vyhnout politickým bojům a spíše názorně ukazovat, že i obtížné věci jsou možné. Podařilo se mi například vytvořit image bez EToys, do které bylo možné EToys dohrát jako externí balík. Ukázat, že je možné forky sjednotit na společném základu. Další modularizací jsem dospěl až do stavu, kdy jsem byl schopen vytvořit velmi malou image, která uměla v podstatě jen nahrát další kód a vytvořit tzv. ImageMap - statickou HTML reprezentaci obsahu image, kde je vypsán a popsán každý objekt včetně dopředných i zpětných hypertextových referenci na odkazované resp. odkazující objekty. Ta slouží k vyhledání a vymetení objektového smetí i v tom nejzapadlejším koutě.

Politikaření je zlé, ale občas je asi potřeba. Místo cíle, kterým bylo určité sjednocení forků, jsem dosáhl pravého opaku - vytvořil jsem de facto fork nový. Přestože se k mé práci vývojáři Squeaku otevřeně hlásili a snažil jsem se svůj kód synchronizovat, udržovat, dokumentovat a rozvíjet, přesto se mi podařilo do mainstreamu prosadit jen část nutných změn. Osobně se domnívám, že změny, které jsem provedl, byly příliš radikální na to, aby mohly být adoptovány jako celek, a příliš rozsáhlé na to, aby se v nich někomu chtělo přehrabovat.

Neberu to nijak tragicky, prostě se snažím nezbytné změny tlačit dál do Phara, což se ostatně i celkem daří.

O nic mrtvější než obvykle...

Budoucnost Squeaku jako takového je ve hvězdách. Jeho cíl, být univerzálním open-source Smalltalkem, se vyčerpal. Možná v budoucnu skončí jako "distribuce" projektu Pharo. Momentálně nevidím, že by měl konkrétní životaschopnou vizi toho, čím chce být.

Pharo má vyhlídky mnohem příznivější. Jeho vývoj postupuje rychle kupředu a může se poučit z výše popsaných špatných zkušeností. Jeho vývojáři neztrácejí motivaci a litují přdevším toho, že zbytečně ztratili čas tím, že se od Squeaku neodtrhli už dávno. Doufejme, že tím se výčet špatných zkušeností, které Squeak může nabídnout k poučení, uzavřel.

       

Komentáře

[Trained.Monkey]

Velmi pekny post. Dovolil bych si ale nesouhlasit s terminem 'starter/finisher'. Podle me je problem ze od zacatku nebyl u projektu nekdo, kdo vyvoj pribrzduje, tvrdy pragmatik jako Linus. Nekdo kdo by Alana klepnul pres prsty a donutil ho napred udelat rozumny modul system.

Pokud se uz totiz vetsi projekt rozjede, nabere setrvacnost a neni mozne uz ho 'finishovat'. Pak nastupuje obycejne korporatni kidani hnoje. Od neceho takoveho radeji ruce pryc.

[Miloslav Ponkrác]

Myslíte Linuse, který udělal i z kernelu jeden z nejdražších a na lidské zdroje nejnáročejších projektů. Poměr počet_člověkoroků_práce / výsledek je u Linuxu asi nejmizernější ze všech projektů co jsem kdy viděl.

Kromě toho Linus, co vidím zvolil kernel velmi konzervativně, tedy bez posunu vpřed. Programovací jazyk C, makrojádro, koncepce prakticky shodná jako u prvního Linuxu. Kopie toho, co tu už desítky let bylo bez jediné změny.

Pak je otázka také použitelnosti Linuse. Ten člověk moc projektů mimo kernel neudělal, zkušenosti s více projekty nemá. Například implementace gitu je příkladem docela zprasenosti, byť myšlenka je vynikající.

Linus navíc podléhá značné fanatičnosti. Když obhajuje své kroky, opírá se spíše o nekritickou komunitu a absolutní právo veta. A jeho obhajoba C proti C++ – to svědčilo o ne zrovna objektivní sebereflexi Linuse.

[Trained.Monkey]

Jo, presne toho. Ten clovek to vede 17 roku, zatim nikdo nevytvoril zivotaschopny fork, takze asi vi co dela. Mikrojadro je mozna teoreticky fajn, ale ukazte mi projekt kteremu se povedlo ho dotahnout do pouzitelne podoby. Kdyby tady nebyl Linus, tak to skonci podobne jako Squeak nebo BSD.

[ext3fs]

>> výsledek je u Linuxu asi nejmizernější ze všech projektů co jsem kdy viděl.

Docela by mne zajimalo cim je tento Vas subjektivni pohled podlozen.

>> Kromě toho Linus, co vidím zvolil kernel velmi konzervativně, tedy bez posunu...Programovací jazyk C, makrojádro, koncepce prakticky shodná jako u prvního Linuxu

Jazyk C nebyl imho co se tyce systemoveho programovani prekonan. Linux ciste makrojadro neni...ale spis kombinace mikrojadra a monolitickeho jadra. Ukazte mi koncept podobny Unixu, ktery by byl schopny prezit vice jak 20 let. Co je stare neznamena ze je spatne. A co je nove, zenzamena ze se uchyti nebo vydrzi vice jak par let.

>> Pak je otázka také použitelnosti Linuse. Ten člověk moc projektů mimo kernel neudělal, zkušenosti s více projekty nemá.

Tohle take o nicem nevypovida. Vetsina tzv projekt manageru co znam stridaji jeden projekt za druhym a podle toho to take tak vypada. Ja jim rikam turisti v IT.

Na posledni vety mne napada jen poznamka...OOP pristup je velmi efektivni,ale neni samospasny...

[alblaho]

Ponkráci, Váš negativistický pohled na svět bych opravdu mít nechtěl

Manažerský výkon Linuse Torvaldse považuji za něco neuvěřitelného. Udržet tolik chytrých ale svéhlavých lidí z různých mocných korporací, to prostě nechápu. A jak tu někdo řekl, nikdo Linux neforknul.

Linux je navržen konzervativně, ale je to proto, že to není žádný výzkumný projekt. Samozřejmě že mikrojádro má teoretické výhody, snad je to i prakticky použitelné (QNX, je Mach z OSX opravdové mikrojádro). Ale to je jedno, protože Linux opravdu se stabilitou problémy nemá a díky modulům je i slušně modulární.

Linux běží od telefonů po superpočítače, to je něco, co taky pořádně nechápu.

No a s C++ v jádře je to stejně jako s mikrojádrem. Pravděpodobně to za to nestojí.

A ještě k tomu Gitu. Uživatelské rozhraní je místy trochu divoké (příkaz checkout lze použít jako revert a branch), ale ten soft je geniální. Na něm naopak Linus dokázal, jak umí být progresivní. Git je na vrcholu potravního řetězce free VCSs, nevím kolik se Vám povedlo napsat softwaru, který by byl ve své kategorii nejlepší na světě.

[osvc1]

negativisticky sem nebo tam, pan Ponkrac psal o software do Linuxoskych novinek, kdy vetsina zde pritomnych jeste delala do plenek. Jeho nazory si se zajmem vzdy prectu.

[Semo]

Jeho nazory si se zajmem vzdy prectu.

Obcas aj ja, ale skoro vzdy stoja za hovno.

[iki]

Eh? Linux je tu od '91, a silne pochybuji, ze vetsina pritomnych je pod 20.

... btw taky si je take se zajmem prectu a podivam se na svet kritickyma ocima, ale jsem dalek tomu zamenovat je s pravdou ;)

[mirec]

Ale to je jedno, protože Linux opravdu se stabilitou problémy nemá a díky modulům je i slušně modulární.

LOL. Asi preto musím pred hibernáciou ostrániť zopár modulov z jadra aby mi náhodou kernel počas preberania sa nehavaroval, že. Alebo preto mi občas ovládač sieťovky zhodí celý kernel. Alebo preto mi niečo (nie vždy sa dá zistiť čo vďaka tomu, že kernel má nulové zabezpečenie) občas zhodí kernel. Mikrojadro je možno utopistické, ale linux by mohol byť aspoň hybridný.

No a C++ v jadre ... hrabal som sa v zdrojákoch Linuxu a hrabal som sa v zdrojákoch nejakého OS (už nepamätám akého) prevažne v C++. Rozdiel v rýchlosti pochopenia, čo sa v tom kerneli vlastne deje bol obrovský.

[Martin Mareš]

Asi preto musím pred hibernáciou ostrániť zopár modulov z jadra aby mi náhodou kernel počas preberania sa nehavaroval, že.

Bugy v driverech jsou ve všech OS a v mikrojádrových systémech mohou být úplně stejně fatální jako v monolitických, alespoň do té doby, než někdo začne stavět rozumně izolovaný hardware (v dnešních PCčkách například síťovka může zapisovat naprosto kamkoliv do paměti).

Mikrojadro je možno utopistické, ale linux by mohol byť aspoň hybridný.

On překvapivě už dlouho k hybridnímu modelu konverguje. Všimněte si, kolik vám v systému běží kernelových threadů

[mirec]

Zopár kernel threadov tam beží, ale to mojim problémom so sieťovkou moc nepomôže ;) Neviem prečo, ale zdá sa mi, jadro v takom stave v akom je naráža na limity. Nie len preto, že podporuje obrovské množstvo hardvéru, ale aj pre jeho samotný návrh.

[Arnošt Málek]

Ja vidim pouziti cisteho C v co nejvetsi mozne mire naopak za velkou vyhodu. C je relativne jednoduchy jazyk, ma defacto par prikazu, vyrobit jeho kompiloator na nejruznejsi architektury je relativne jednoduche. Vemte si, ze prave diky tomu dnes nejake klony jadra bez problemu bezi v kazde druhe "krabicce" co maji lidi doma.

Muj nazor je ten, ze jadro operacniho systemu by melo byt psano v jednoduchem a proceduralnim jazyce - a na to se C skvele hodi. A nazory naznacujici, ze Unix (Linux) je "spatny", protoze jeho koncepce (nebo cokoli jineho) je stara nechapu. Neni to naopak dukaz toho, ze je to dobre vymysleno, kdyz to dokaze tak dlouho fungovat?

[Marek Bernát]

Ad druhý odstavec: Návrh UNIXu _je_ zlý z kopy rôznych dôvodov; k tomu sa už vyjadril nejeden odborník na kernely (vrátane tvorcov pôvodného UNIXu). Ale funguje dostatočne dobre, aby to nikoho (okrem pár vizionárov) moc netrápilo. Úplne rovnako je to s tým C. A tiež makrojadrom. Dalo by sa pokračovať...

[Martin Mareš]

Problém je, že většina z těch odborníků na kernely nikdy žádný kernel, který by slušně fungoval na dnešním hardwaru, jaksi nenapsala. Proto je pro ně snadné vymýšlet teoreticky elegantní architektury, které ovšem zapomínají na to, že dnešní hardware prostě je ošklivý, takže snaha fungovat na něm efektivně vede k nepříliš hezky strukturovanému systému. Linuxová architektura určitě není vrcholem elegance, ale funguje a navíc rychle.

[Marek Bernát]

S tým sa dá súhlasiť.

[JS]

A i kdyby ten hardware osklivy nebyl z jinych duvodu (treba zpetna kompatibilita nebo marketing), patrne by byl osklivy i tak.

Podle me zkusenosti jsou jednoduche a elegantni architektury/algoritmy casto rozumne rychle, ale lze je jeste dale zrychlit, a pak to hodne rychle elegantni byt prestane. Svet je asi moc slozity na jednoduche poucky.

[tomfi]

Návrh UNIX je zlý? Až mě zamrazilo z představy že by mohla někdy jedna entita zla mít takovou penetraci do společnosti jako linux :D

Ad odborníci... takových tlučhubů co umí chytračit, protože vědí že od ztrapnění je dělí obrovský rozdíl mezi teorií a praktickým příkladem, který nikdo nebude překonávat... takových odborníků jsou plné nejen univerzity ;)

[Michal Vyskočil]

Návrh UNIX je zlý?

Návrh Unixu je dobrý, spíše ta implementace dělá problémy. Předřečník možná myslel něco jako Plan9, ale to je spíše Unix dotažený k dokonalosti.

[Marek Bernát]

Ok, neni zlý, ale má kopu problémov. Nielen implementačne, ale aj teoreticky.

Plan9 je jedna z vecí, ktoré som mal na mysli a ukazuje, že mnohé z problémov UNIXu sa dajú vyriešiť elegantnejšie. Ale dokonalosťou by som to zasa nenazýval

[Marek Bernát]

Nejedná sa o tlčhubov, jedná sa napr. o niektorých autorov pôvodného UNIXu. Stačí pogoogliť niečo o Plan9

[podlesh]

No ano, v UNIXu je tolik chyb a špatných rozhodnutí...

Celá tato diskuse se jen točí okolo toho, jaká jsou vlastně kritéria pro "dobré" a "špatné". Jiná jsou pokud soudíme UNIX jako umělecké dílo, jiná pokud soudíme masově používaný nástroj.

Totéž pak platí když chceme soudit Linux jako produkt: někdo soudí umělecký dojem, někdo soudí spotřebované zdroje při vedení projektu (více člověkohodin znamená větší znečištění planety, například), většina pak prostě jenom soudí zda je projekt úspěšný nebo ne.

[Marek Bernát]

Ja som sa vyjadroval k samotnému konceptu a teórii. Že v reále sa často presadí aj horšie riešenie (stačí ak je ľubovoľným spôsobom dosť dobré pre daný účel) ma až tak nezaujíma.

[podlesh]

Jistě, jak říkám: jsou to různé pohledy, všechny mají ledacos do sebe.

[Marek Bernát]

No, v podstate je to idealizmus vs. pragmatizmus

[Martin Mareš]

Plan9 je moc pěkná hračka, ale bohužel stále z toho hračkového stavu nevyrostl... opravdový OS postavený na myšlenkách Planu9 by mohl být prima, až ho jednou někdo napíše.

[Michal Kubeček]

s/až/jestli/

[Marek Bernát]

Je to smutné, ale je to tak. Všetky pokročilé a zaujímavé technológie sú odsúdené na pomaly zánik v komunite pár nadšencov. Výnimky spočítam na jednej ruke. S odtrhnutými prstami

[podlesh]

Návrh UNIX je zlý? Až mě zamrazilo z představy že by mohla někdy jedna entita zla mít takovou penetraci do společnosti jako linux :D

Jazykové okénko: zlý (slovensky) = špatný (česky)

Tedy možná to bylo míněno jenom jako offtopic vtip, ale obávám se že někteří později narození by to nemuseli pochopit

Ad odborníci... takových tlučhubů co umí chytračit, protože vědí že od ztrapnění je dělí obrovský rozdíl mezi teorií a praktickým příkladem, který nikdo nebude překonávat... takových odborníků jsou plné nejen univerzity ;)

Nejlepší je, když tito lidé nadávají na to jak tato civilizace končí protože všichni (tedy všichni ostatní, samozřejmě!) jenom okecávají a nic nedělají.

[R]

Na jednu vec si zabudol: Linux funguje a funguje uz peknych par rokov. To sa neda povedat o "krasnom" (lebo mikrokernel) HURDe.

Git obcas pouzivam - jeho implementaciu som nevidel a vobec ma nezaujima. Z mojho pohladu vznikol prakticky okamzite a hned funguje. Po precitani par riadkov navodu viem urobit git bisect a najst regresiu v tych milionoch riadkov kodu Linuxu radovo v hodinach.

[multi]

vidim to stejne jako Trained.Monkey a R

osobne si myslim, ze asi jednou Linux(kernel) postupne umre, ale to bude za dlouho, a prave pak bude prilezitost pro HURD, a diky opensource, me to ani nebude vadit, protoze nad tim porad budu mit ty same aplikace, a to co je podtim me ve vedsine pripadech zajmat nebude hlavne aby to fungovalo.

[Václav HFechs Švirga]

Heh, zrovna HURDu bych fakt nefandil :). Myslím že tu linux bude hodně dlouho a pokud ztratí své postavení, opravdu to nebude hurd, co ho smete.

[multi]

vzdyt netvrdim, ze to bude dovijak brzo, ba naopak ze nekdy jednou v budoucnu ...

samozrejme bude prilozitost prosadit i dalsi kernely treba se prosadi vice BSD, nebo uplne novy, ale treba to bude takova doba ze uz i HURD bude pouzitelny

[hanzz]

marne se namahate :) ten uz ted k tematu neodpovi :)

[Martin Mareš]

Myslíte Linuse, který udělal i z kernelu jeden z nejdražších a na lidské zdroje nejnáročejších projektů.

Myslím Linuse, který udělal z kernelu OS, který funguje na takové šíři hardwaru, které se nejspíš žádný jiný dnešní systém nedokáže vyrovnat, a který je proklatě rychlý. Až dokážete totéž, budu vaši kritiku brát vážně.

Pokud to umíte udělat lépe, pak zanechte plkání o kvalitách kernelu, protože je nestoudným mařením vašeho času nepustit se ihned do psaní lepšího OS

Pokud to lépe udělat neumíte, pak byste také měl plkání o kvalitách kernelu zanechat, protože to jsou jenom hloupé řeči

[Miloslav Ponkrác]

Já jsem nemluvil o kernelu, ale o kvalitách Linuse jakožto vedoucího projektu.

Jsem si naprosto jist, že Linus jako vedoucí projektu by žalostně selhal – možná více, než Ti zmínění v článku.

Linus nikdy nebyl skutečně prozkoušen ohněm co se vedení projektu týká. V zásadě má nezpochybnitelnou autoritu, kterou by v žádném projektu neměl. Stejně tak právo veta, které uplatňované stejně v jiném projektu by mu zaručilo odchod nejlepších vývojářů.

Stejně tak leckterý průměrný programátor má větší zkušenosti, než Linus. A účastnil se většího množství projektů, než on.

Chápu, že jsem sáhl na svatého, ale jsem přesvědčen, že Linus jako normální vedoucí projektu by skončil tragicky a projekt s ním.

Je zajímavé, jak se kritici mého postu taktně vyhli mé poznámce o neefektivním poměru výsledek / počet_člověkoroků_práce. Holt to se nehodí do krámu co?

Představa, že by někdo, třeba Linus vedl a využíval síly lidí stejně „efektivně“ jako je to v případě Linuxu, tak by projekt pohřbil už předem. Tak špatnou bilanci využití lidských sil najdete sotva kde.

[ext3fs]

>>Stejně tak leckterý průměrný programátor má větší zkušenosti, než Linus. A účastnil se většího množství projektů, než on.

Ucastnit se jeste nic neznamena...ucastnik je i ten co jen hloupe keca jak a co by se melo,ale jinak neudela sam nic (vetsina IT manageru).

Btw..odkud tak dobre Linuse znate, ze muzete na jeho osobu psat tyhle nazory?

[R]

Problem je akurat v tom, ze Linus nie je "normalny veduci projektu". a tiez sa neda hovorit o "efektivnom" vyuzivani ludi. Vytvoril projekt, pre ktory ludia robia na _vlastne_ naklady. Ci uz su to jednotlivci alebo firmy, ktore kvoli prace na Linuxe zamestnavaju ludi.

[Ondrej 'SanTiago' Zajicek]

V zásadě má nezpochybnitelnou autoritu, kterou by v žádném projektu neměl. Stejně tak právo veta, které uplatňované stejně v jiném projektu by mu zaručilo odchod nejlepších vývojářů.

A proc ji asi ma? Protoze si ostatni vyvojari o nem mysli, ze to dela dobre. U free/open-source projektu obvykle neni problem vymenit 'vedouciho', kdyz s ni ostatni vyvojari nesouhlasi. Viz treba xfree86/x.org nebo GCC/EGCS.

Je zajímavé, jak se kritici mého postu taktně vyhli mé poznámce o neefektivním poměru výsledek / počet_člověkoroků_práce. Holt to se nehodí do krámu co?

Protoze neni podlozena zadnou smysluplnou argumentaci.

[osvc1]

..Protoze neni podlozena zadnou smysluplnou argumentaci. ..

je sice pravda, ze pan P. nedodava zadna konkretni cisla, ale o tom vysledku muzeme vseobecne prece jen hovorit.

Zkuste dostat do firmy linux-desktopy, pracuje se na tom uz 15 let a vysledek je znam.

V roce 1994 jsme nasadili u zakaznika nas prvni linux server. Funcionalita se od te doby vpodstate nezmenila, kdybych vzal ten slackware od tenkrat, tak mohu ten server vpodstate provozovat dnes zrovna tak (at zije SCSI).

Rekl bych tedy zhruba, ze nevim, co ty tisice lidi delali tech 15 let?

[ext3fs]

Ty jsi trubka.

[R]

Linus nemoze za to, ze linuxovy desktop tvori fasisticke GNOME alebo znicene KDE.

[Ondrej 'SanTiago' Zajicek]

Zkuste dostat do firmy linux-desktopy, pracuje se na tom uz 15 let a vysledek je znam.

Bavime se o vyvoji linuxoveho jadra. Takze tohle je uplne irelevantni.

Rekl bych tedy zhruba, ze nevim, co ty tisice lidi delali tech 15 let?

Vyvijeli a ladili ovladace pro ty tuny noveho hardware, ktery od te doby vznikl? Pokud bys vzal tehdejsi Slackware a snazil se ho rozjet na soucasnem bezne dostupne hardware, tak by pravdepodobne prevazna vetsina nefungovala. Vyvoj (minoritniho) OS je v podstate vytrvaly zapas s vyrobci hardware o to, zda vyvojari OS stihnou vyvijet ovladace rycheji nez vyrobci hardware nove nekompatibilni verze hardware. A i jenom setrvavani na miste je uspech a stoji obrovske usili.

[Trained.Monkey]

> Je zajímavé, jak se kritici mého postu taktně vyhli mé poznámce o neefektivním poměru výsledek / počet_člověko roků_práce.

Nepovazoval jsem to za relevatni. Mohu se zeptat v cem presne Linus zpusobil neefektivitu? Podle me naopak vyrazne pomaha k jejimu zvyseni. Viz treba nasazeni BitKeeperu navzdory cele komunite. A schvalne si zkuste najit cisla o vyvoji Windows, Solaris nebo BSD.

Dale jak to nekdo napsal Git vyrostl a stal se funkcnim ve velmi kratke dobe. V porovnani s porodnimi bolestmi SVN, ktere je jednodussi, je to obdivohudne.

[Semo]

právo veta, které uplatňované stejně v jiném projektu by mu zaručilo odchod nejlepších vývojářů.

A co teda sposobuje, ze neodchadzaju? Su nuteni tam ostavat a trpiet pod Linuxom? Pokial viem, tak nie su. Myslim, ze skoro kazdy z nich by si dokazal zarobit rovnake prachy aj inych projektoch ako Linux. Takze tam asi ostat chcu, pretoze ten cely projekt povazuju za lepsi ako ine.

[osvc1]

...Takze tam asi ostat chcu, pretoze ten cely projekt povazuju za lepsi ako ine. ..

to je kravina na treti. 99.9% vsech vyvojaru jadra jsou zamestnani u firem, ktere cely ten vyvoj plati. To vyvojari si mohou myslet co chteji, pokud chteji jist, tak musi zpivat pisnicku svych chlebodarcu.

[Ondrej 'SanTiago' Zajicek]

Znacna cast vyvojaru jadra (i kdyz asi ne 99.9 %) je placena za vyvoj Linuxoveho jadra, ale ne nutne za vyvoj Linusova jaderneho stromu. Koneckoncu zmenu ve vedeni GCC spojenou s forkem EGCS take, co jsem slysel, zpusobili lide placeni za vyvoj GCC u firem.

[Semo]

Pokial ti pod Linusom trpiaci vyvojari neziju v krajine, kde je legalizovany otrokarsky system, tak preco neodidu z firiem, ktore ich nutia robit na takom "zvratku" ako je Linux? Nie ze by som bol nejaky kronikar vyvoja Linuxu, ale tie dolezitejsie mena sa tam tocia uz aspon 8 rokov a stale neodchadzaju. Dokonca pribudaju dalsi, namiesto toho, aby sli do menej despotickych projektov, alebo si forkli Linux a sefovali sami sebe. Nic z toho sa nedeje, tak si myslim, ze tvoje a ponkracove paranoicke teorie o despotickej krutovlade su blbosti z tepla.

[Michal Kubeček]

Ty firmy se ovšem nezabývají zdaleka jen sponzorováním vývoje linuxového jádra. Kdyby nic jiného, tak nejdřív ty peníze musejí někde vydělat. Takže pro ty kvalitní vývojáře je tu vždy možnost přejít na jiný projekt v rámci firmy.

[GR]

99.9%? To jen velmi těžko. http://www.abclinuxu.cz/clanky/jaderne-noviny-14.-7.-2010-kdo-napsal-jadro-2.6.35#vyvojove-statistiky-jadra-2.6.35

[Martin Mareš]

Je zajímavé, jak se kritici mého postu taktně vyhli mé poznámce o neefektivním poměru výsledek / počet_člověkoroků_práce. Holt to se nehodí do krámu co?

No jo, když ta poznámka byla tak evidentně nesmyslná, že ani nestálo za to s ní polemizovat.

Jak můžete mluvit o efektivitě vývoje tam, kde nemáte žádný podobný projekt, se kterým byste mohl srovnávat?

Stejně tak leckterý průměrný programátor má větší zkušenosti, než Linus.

Zejména vy, že?

Linus má značnou autoritu hlavně proto, že evidentně ví, o čem mluví, a že když dojde na lámání chleba, je to často právě on, kdo obtížný problém rychle prokoukne, zatímco ostatní tápou.

Zatímco o vašich schopnostech nevíme vůbec nic, pokud tedy nepočítám schopnosti řečnické (mám-li zůstat v mezích slušnosti).

jsem přesvědčen, že Linus jako normální vedoucí projektu by skončil tragicky a projekt s ním.

To je možné. Stejně jako je možné, že kernel by s normálním vedoucím projektu skončil také tragicky.

[Bluebear]

Stejně tak leckterý průměrný programátor má větší zkušenosti, než Linus. A účastnil se většího množství projektů, než on.

Ale odkud víte, kolika projektů se Linus zúčastnil a co všechno zažil? Pokud nejste anděl, démon nebo zaměstnanec tajné služby, tak to prostě vědět nemůžete; řada věcí, které člověk zná, umí a viděl, není nikde napsaná.

Je zajímavé, jak se kritici mého postu taktně vyhli mé poznámce o neefektivním poměru výsledek / počet_člověkoroků_práce.

Ta poznámka má ale smysl teprve tehdy, když uvedete svůj názor na to, jak by měl vypadat ideální výsledek - tedy jak by to mělo vypadat, kdyby se lidé a čas využívali dokonale efektivně. Jinak se o tom moc debatovat nedá; je to slovo proti slovu a názor proti názoru.

(Já si například myslím, že celá lidská civilizace velmi špatně využívá schopností svých obyvatel, zahazuje úžasné talenty, nechává geniální osobnosti ve stoce a technický rozvoj je stokrát pomalejší, než by mohl být. Ale dokázat to nemůžu, protože nemám žádnou jinou civilizaci, na kterou bych ukázal a řekl "vidíte, takhle se to má dělat". Takže mi nezbývá než mlčet a myslet si svoje.)

[User682]

zdravim,

nevidel bych to tak negativne. Pridam nejaky duvod.

Jsou urcite velke veci/projekty, u kterych jsou treba zkusenosti. A ty nabyvate dlouho. Ostatni se vezou.

Nerekl bych, ze projekt je nejnarocnejsi na lidske zdroje. Do poctu zdroju mozna ano, ale ty zdroje jsou levne.

Rekl bych, ze cena projektu muze byt stejna jako u Windows. Jen rozdil je v tom, ze Windows jsme zaplatili vsichni jako zakaznici penezi, ale u kernelu to lide zaplatili casem. Zalezi, co je pro koho cennejsi. Rozdil mozna bude v tom, ze ve Windows muzete danou chybu "testovat" v mnoha verzich a cykli se to do nekonecna.

Otazku bych dal asi v tomto pripade takovouto:

Linuxovy kernel nejak jede. Rekl bych, ze velmi dobre. Vyvoj aplikaci take. Ale vyvoj zakladnich desktopovych selhava. Mozna je to tim, ze se nenasel nekdo podobny jako Linus. A proc je takovyto trend ?

Co si budeme rikat, ale nevitezi vzdy nejlepsi projekty nebo nejgenialnejsi myslenky. Spise ty zivotaschopne a optimalni myslenky, styly rizeni a tak. Nebo nejaka pridana hodnota. A malokdo dovede tu pridanou hodnotu dat, aby byla pro uzivatele zajimava. Muze to byt par tydnu prace, ale i nekolik let. No, vyberte si.....

gf

[Martin Mareš]

Mozna je to tim, ze se nenasel nekdo podobny jako Linus. A proc je takovyto trend?

Možná je pro schopné lidi prostě daleko větší intelektuální dobrodružství programovat jádro než desktopové aplikace

[JS]

To mi prijde jako zvlastni postoj. Proc tedy neprijdou s necim, co tu nudnou cast necha udelat pocitac (nebo nejakeho klikace) a nezabyvaji se jen tou nenudnou casti? Ja neverim na "nudne" problemy v programovani.

(Mimochodem, treba prave zmineny Git dokazuje, ze to tvrzeni je nepravdive.)

[Marek Bernát]

Ale veď presne to aj urobili. Tú nudnú časť (desktop) nechali klikačom a tej zaujímavej (jadru) sa venujú :-P

Git niečo dokazuje? Za prvé to nie je desktopová aplikácia, takže je to úplne OT, ale aj keby bola, tak to ukazuje len to, že Linus mal problém a vyriešil ho najlepšie, ako vedel. Nič viac, nič menej.

[JS]

Ja myslel nechat nudnou cast toho programovani klikacum, takze to si nerozumime.

Git podle me prave dokazuje, ze v oblasti, kterou vsichni do te doby povazovali za nudnou (napsat system spravy verzi) lze napsat neco zajimavym zpusobem. Mozna to jde i u tech "nudnych" desktop aplikaci, co ja vim?

[Marek Bernát]

Ok, tak ktorá časť desktopu podľa teba nie je nudná (nehovorím zábavná, to by som chcel moc)?

vsichni do te doby povazovali za nudnou

[citation needed] Podľa mňa to bolo tak, že do tej doby neexistoval dostatočne veľký a dynamický open source projekt, ktorý by nutne potreboval distribuovaný VCS (a dodnes podobne veľké projekty prežívajú na obyčajnom CVS). Takže nie že by tá oblasť bola nudná, ale stačilo skrátka mať centralizovaný VCS a nikto sa o nič viac nestaral.

[JS]

Ja si prave myslim, ze zajimave problemy existuji vsude. A ze "nudnost" neceho je jenom symptom, ze to delame spatne, a mohli bychom to delat lip. Otazka je jak. Ale rozhodne bych si netroufl tvrdit, ze proto, ze nevime jak na to, je to intelektualne mene podnetne.

To spis ty mi dej priklad, proc jsou desktopove aplikace nudne, a muzeme se podivat na to, jak zaridit, aby to tak nebylo.

(Ja proste vnimam software jako ultimatni moznost automatizace, neomezenou realnym svetem (jako prirodnimi zdroji nebo fyzikalnimi zakony). A takova ultimatni automatizace podle me vylucuje uz z principu existenci nudnych problemu. Je-li problem nudny, znamena to, ze neni (nebo byl spatne) automatizovan.)

[Marek Bernát]

Ok, tak napríklad browser. Konkrétne parsovanie nevalidných HTML stránok. To je typický prípad toho, kedy je niečo nudné, ale nedá sa automatizovať. Musíš holt vždy vymýšľať heuristiku na každý ďalší spôsob, ktorým nejaký webdeveloper zmrší HTML (alternatíva, že tie nevalidné stránky nezobrazíš je elegantné riešenie, ale moc by sme si toho na nete nepozreli). Podobných príkladov založených na tom, že máme reálny svet (a nie ideálny matematický, ktorý sa dá automatizovať), ti dám milión. Oni sú ostatne aj v tom jadre -- ovládače hardvéru. To by ma fakt nebavilo. Ale okrem toho sú tam aj celkom pekné teoretické veci ako sieťovanie, filesystémy, pamäť, multitasking, atď.

Obecne, sa mi zdá, že podľa teba nudné = automatizovateľné. To je zjavne blbosť. Nudné totiž neznamená len exaktne sa opakujúce (a je to častý prípad a často sa automatizovať dá), ale aj _približne_ sa opakujúce. Ako tie ovládače k hardvéru a pod. Furt je to jedno a to isté, ale vzhľadom k tomu, že neexistujú štandardy (resp. na ne každý dlabe), tak furt musíš písať dokolečka _podobný_ kód pre nové ovládače, ktoré majú pár vecí inak.

[JS]

Samozrejme, existence lidi, kteri nedodrzuji standardy (popr. prosazuji nejake silene) ponekud kazi tu moji teorii (coz zahrnuji pod ten pripad "delame to spatne", zde ovsem asi tusime, proc). Ovsem jak sam uznavas, takovi ovlivnuji i jadro. Takze, i kdybych to pripustil, stale to nevysvetluje, proc by mel byt userspace nebo GUI aplikace mene zajimavy nez kernel space.

(I kdyz mi pripada, ze si OSS vyvojari libuji v implementaci zrudnych standardu. Vzdyt se staci podivat - Firefox, SAMBA, Wine, Openoffice, MPlayer.. same velke projekty, a jejich vyznamnou casti je korektni implementace neceho zvrhleho.)

[Marek Bernát]

Rozdiel medzi desktopom a jadrom je v tom, že desktop pozostáva takmer výhradne z takýchto porušení štandardov. V jadre je kopa oblastí založená čisto na teoretickej informatike, preto je to zaujímavejšie. Výnimkou sú len tie ovládače a architektúry. Aj keď je pravda, že podľa ostatných JN to tvorí 75% kódu, ak ma pamäť neklame

Mno, to je fakt

[JS]

OK, dejme tomu, ze me nekdo postavi pred takovy problem, jak rikas. Tak se muzu ptat - je tam nejaka struktura, jak ty ruzne heuristiky vypadaji? Maji neco spolecne? Nemuzu na to natrenovat neuronovou sit? (To by byla asi blbost, je to jen priklad.) Nemohu nejake bezne dat dohromady?

A tim se z toho uz stal intelektualne zajimavy problem, nebo ne? Sice vime, ze asi nema pekne reseni, ale to neznamena, ze nedovede potrapit..

[Marek Bernát]

No tak to skús. Napíš kvalitný parser HTML

Ok, ak na to pozeráš čisto lingvisticky (snažíme sa pochopiť všetky deformácie syntakticky jednoduchého jazyka), tak to celkom zaujímave je. Problém je, že kvalitné riešenie takýchto problémov je ekvivalentné vytvoreniu umelej inteligencie. Vzhľadom k tomu, že to zatiaľ nikto nevie (a IMHO ani vedieť nebude), tak v praxi ti nakoniec zostane len tá nuda.

[podlesh]

Já osobně bych jako hlavní problém desktopu viděl, že vlastní není jasné co vlastně dělat, jak má vypadat výsledek a jak posoudit, že je ten výsledek správný.

[Gilhad]

Dalsi vec je, ze pro nekoho jako desktop plne vyhovuje neco uz hotoveho (me napriklad fluxbox) a nema potrebu delat nejaka klikadla na veci, ktere lze snaze a prehledneji resit v prikazove radce a textovych konfiguracich.

(Jako napsa algoritmus pro lepsi praci s pameti, chytrejsi multitasking, nebo novy FS je zajimavy problem, ktery pokud bych vyresil, tak tim neco ziskam. Napsat Pana Sponku, ktery bude polovzdelancum radit, jak kopirovat soubory a pritom se je bude snazit odstinit od znalosti, co to vlastne soubory a adresare jsou mi prijde jako naprosto zbytecna hovadina, kterou nikdy pouzivat nebudu - proc bych ji teda vyvyjel? Jestli ji nekdo chce ve svem pocitaci mit, ja mu branit nebudu at si to pro sebe napise, ale na mem pocitaci to fakt nema co delat a ja chci system, ktery to obsahovat nebude.)

[JS]

To ale plati i pro jadro (staci slovo "benchmark"). Je pravda, ze napsat dobre uzivatelske rozhrani je tezke, protoze kazdemu vyhovuje neco jineho. Ale to je prave to co na tom muze byt intelektualne zajimave. Je to jiny druh problemu.

[Marek Bernát]

Ale to je presne ten problém. Nie je v tom už žiadna informatika, je to len o tom, ako dať dokopy pár komponent, aby to ľuďom vadilo čo najmenej. Kedy naposledy niekto potreboval navrhnúť zaujímavý algoritmus pri tvorbe GUI?

[__dark__]

Zkus si napsat kvalitní GUI, uvidíš, že to není jen o tom jak vypadá tlačítko, ale i o tom, co běží pod tím. Potřebuješ ty widgety zobrazovat, efektivně řešit kolize a scrolling, popřípadě animace a speciální efekty pro focus popřípadě zrakově postížené.

GUI v linuxu je typický příklad právě toho špatného návrhu. Už i to, že existují 2 majoritní, vzájemně nekompatibilní toolkity, je velká chyba. Neberu jako chybu programovací model (je hezké mít možnost vybrat si API), ale právě tu nekompatibilitu. Skinování aplikací, standardní dialogy a návyky, kombinování toolkitů. Už i to, že se píšou aplikace 2x podle použitého toolkitu je podle mě velká chyba.

Řešení v tuto chvíly nemožné.

[__dark__]

i

[Marek Bernát]

Nehovorím, že je to jednoduché. Len že to nie zaujímavé. Aspoň pre mňa nie

Tak isto máš N distribúcií Linuxu, ktoré sú poväčšinou vzájomne nekompatibilné a plnia prakticky rovnaký účel. Je to chyba? Ja to volám možnosť voľby

[pavlix]

Už i to, že existují 2 majoritní, vzájemně nekompatibilní toolkity, je velká chyba.

Ono těch toolkitů je víc a není to specifikum světa Linuxu.

Dejme tomu, že bys mohl tvrdit, že je špatné, že jsou dva podobně oblíbené toolkity (tvrdíš to nebo ne?). Potom ale dojdeš jenom ke dvěma řešením:

1) Jeden toolkit zakázat/zničit -- to úplně s opensource světem neladí.

2) Udělat jeden toolkit, který se z obou poučí a bude lepší -- to by pravděpodobně dopadlo jako se dvěma papeži.

Neberu jako chybu programovací model (je hezké mít možnost vybrat si API), ale právě tu nekompatibilitu. Skinování aplikací, standardní dialogy a návyky, kombinování toolkitů.

Nějaká konvergence existuje... ale je s tím dost práce, do které se jen tak každému nechce.

Řešení v tuto chvíly nemožné.

Podle mě vycházíš z předpokladu dokonalosti. Jenže svět se dynamicky mění. Není dokonalý.

[__dark__]

Jak jsem psal, já nevidím problém ve více toolkitech, ono například pod Windows je těch toolkitů taky víc, jenže uživatel to nepozná a kombinace toolkitů je v některých případech možná. V Linuxu jde někdy až o náboženství.

[pavlix]

jenže uživatel to nepozná

Spíš je uživatel zvyklý, že každá aplikace může vypadat úplně jinak, takže mu ty rozdíly už ani nepřijdou.

[vlastikroot]

Qt programy dokážou vypadat přesně jako GTK, celkově je Qt modernější a dokonalejší. To, že je GTK hrozný toolkit, do kterého se Qt špatně implementuje, je věc druhá. Stejně si myslím, že GTK by mělo zmizet z open source světa. Už i E17 knihovny jsou o něco lepší. Jasně že se tu na mě sběhne kupa GTK fandů, kteří se ho budou zastávat, víceméně je GTK ale dané historií GUI na linuxu a ne kvalitou.

[__dark__]

Ono když porovnám E17 (EWL a ETK) s GTK, tak moc rozdíl nevidím - vypadá to sice jinak, ale API je skoro stejné. A pokud porovnám Elementary, tak ten toolkit není na psaní klasických desktop-app.

Qt se sice může jevit jako modernější, ale podívej se někdy, co se musí odehrát, aby to Qt vypadalo jak Gtk, nebo proč Gtk nikdy nevypadá jak Qt. Toto je ta vzájemná nekompatibilita, o které mluvím. Pod Linuxem nikdy nikdo neřešil otázku, že vznikne jiný toolkit, který bude chtít zapadnout do desktopu, otázku sdílených konfikuračních souborů pro různé toolkity (nechci říct něco jako registry pod Windows, ale nějaký systém, který mi umožní si dát něco do oblíbených v Gtk dialogu a najít to tam i v Qt aplikaci nebo openoffice).

[Marek Bernát]

Ten druhý bod čiastočne začal riešiť freedesktop.org štandardizáciou rôznych oblastí desktopu. Ale potrvá ešte dlho, kým sa to nejak presadí to existujúcich technológií.

[pavlix]

GTK má oproti Qt výraznou výhodu z hlediska licencčních podmínek.

[Randy_Sh]

QT už je nějaký čas pod LGPL, takže žádnou nevýhodu nevidím.

[pavlix]

Fíha, tak tuhle změnu jsem jaksi zaspal. Teď na to čumim jako blbec.

Díky.

[Marek Bernát]

K tomu poslednému odstavcu: to je úplne naivný pohľad na svet. V podstate tvrdíš, že neexistujú nudné problémy, lebo v princípe sa dá skonštruovať algoritmus, ktorý ich rieši. S realitou to bohužiaľ nemá nič spoločné...

[Martin Mareš]

A není to tak, že nudný je i samotný výsledek? Když spočítám desktopové aplikace, které běžně používám, dojdu k překvapivému číslu 3

(Git se dá sotva za desktopovou aplikaci považovat. To už bych za ni asi musel počítat cokoliv, co běží v uživatelském prostoru :) Ale je to hezký příklad toho, že i user-spacový program muže být hodně zajímavý a přitáhnout ke svému vývoji řadu schopných programátoru.)

[JS]

Zase, me to proste pripada logicke, ze pokud je nejaka cast toho vysledku "nudna", pak by prave jeji vyvoj melo byt mozne zautomatizovat (nebo alespon prenechat klikacum, v horsim pripade), cimz se z toho, jak toho dosahnout, stava "nenudny" problem?

Vzdyt i ty sam jsi se zabyval treba typografii. Coz je ciste zalezitost esteticka, a tedy dalo by se rict nudna. Proc jsou podle tebe desktopove aplikace nudne? Protoze nepouzivas vysledek?

Ano, s tim Gitem jsem to presne tak mel na mysli.

[User682]

zdravim,

je otazkou, zda programovani desktopovych aplikaci take neni dobrodruzstvi. Ze je kernel vyssi meta o tom nepochybuji.

Osobne si myslim, ze dobrych programatoru, co umi programovat desktopove aplikace je velmi malo. A je to vcelku veda tomu rozumet do hloubky. Vytvorit jednoduchou tabulku nebo formular s par prvky je hracka. Nebo to "natahat" v nejakem designeru.

gf

[disorder]

zatialco ostatni sa tu hadaju o fazulky, ja polozim otazku, ci nie je pozicia Squeaku prilis specificka aby sa to dalo generalizovat?

Smalltalk ma porovnatelnu konkurenciu v podobe inych jazykov a to GUI ako omalovanka nevonia mne, ani mnohym inym, hoci ta previazanost iste pomohla stvoreniu velmi dobrych pomocnych nastrojov v tom prostredi. ako bolo spomenute, svojmu tvorcovi sluzil najma ako hracka/vyskum, na experimentovanie

ma Pharo sancu aj toto zmenit? taky Lisp je na tom s IDE podobne, ale SLIME ci komercne Common Lispy maju celkom akceptovatelne prostredie oproti Squeaku...

[Pavel Křivánek]

Squeak určitě není úplně běžný projekt, ale k většině zmíněných bodů mě napadají obdobné případy, takže určitě nejsou pro Squeak specifické.

Squeak není jediná implementace Smalltalku a ve způsobu vykreslování GUI je mezi nimi spíše výjimkou. Budeme-li se ale bavit o Squeaku, jistá infantilnost a nestandardnost jeho vzhledu mu určitě příznivce spíše ubírala než přinášela.

Přirozeně se vyrojilo několik (i použitelných) pokusů o svázání Squeaku s nativním GUI. Já sám jsem už někdy před sedmi lety nějaké aplikace s nativním a poměrně složitým GUI ve Squeaku vytvořil. Jenže tyto pokusy se nikdy v hlavním proudu vývoje neprosadily. On ani dnes není výběr mezi multiplatformními GUI frameworky právě jednoduchý, zvlášť pokud člověk požaduje snadnou slučitelnost se Smalltalkem.

Já osobně jsem zastáncem toho, že o vykreslování GUI se má starat specializovaný "prohlížeč" komunikující s vlastní aplikací pokud možno přes HTTP. Viz SeasideXUL. Poměrně zajímavý detail je, že ty vývojové nástroje demonstrované v SeasideXUL jsou standardní vývojové nástroje Squeaku definované ve frameworku OBBrowser a jsou na konkrétním GUI frameworku zcela nezávisllé. Dokonce existuje malá image Squeaku, která nemá žádné nativní GUI a používá vývojové nástroje zobrazované pouze přes XULBrowser.

Pharo i Squeak jsou pomocí UIManagerů a podobných mechanismů stále více nezávislé na konkrétním GUI (mimo jiné jako malý bonus k mým snahám o to, aby žádné GUI nemusely mít). Pak se třeba konečně uchytí i vazby na GTK, wxWidgets nebo třeba kompexní GUI přímo ve webovém prohlížeči.

[disorder]

Zaujimave informacie. Keby sa podarilo previazat to s GTK, to by ma potesilo.

Velmi by prospela nejaka databaza kniznic. Ked som skusal Squeak, tak som nic take nenasiel a zda sa mi, ze aj dnes je to problematicke.

Ale Seaside a continuation web frameworky vseobecne sa mi celkom pacia (blog s linkom na pekny clanok bol aj tu http://www.abclinuxu.cz/blog/seaside/2007/9/pekny-clanek-o-seaside, ale tiez UnCommon Web a Weblocks).

[Pavel Křivánek]

Většinou stačí dotaz na SqueakSource

http://www.squeaksource.com

[Marek Bernát]

Tiež som fanúšik UCW a Weblocks. Ale to prvé vyzerá byť už dlhú dobu prakticky mŕtve a to druhé vedie jeden človek a komunita a počet vytvorených webov sa dá spočítať na prstoch jednej ruky. Bohužiaľ. Seaside má aspoň nejakú šancu sa presadiť v širšom merítku a prilakať ľudí k tomuto typu programovania a možno časom hrozí aj portovanie niektorých myšlienok do iných jazykov.

[disorder]

Ja to sledujem len tak s odstupom. Problem je, ze tie jazyky aj frameworky maju svoje poziadavky na hardver, takze to uplatnenie je tiez limitovane. Ked sa prida ista nevyladenost a "ezoterickost" jazykov, tak si kazdy lahko vyberie. Podla wikipedie ale doslo k celkom peknej optimalizacii v Seaside 2.8.

Obycajne REST aplikacie zatial budu panovat, to je iste.

[Marek Bernát]

Tak Lisp dokáže byť pomerne svižný. Skôr vidím problém v tom, že v Lispe dokopy nikto neprogramuje. A ak áno, tak väčšinou sú to teoretickí informatici, umelí inteligenti, návrhári jazykov a pod., takže sa určite nebudú venovať webovému frameworku

Smalltalk na druhej strane vnímam ako relatívne pomalý jazyk. Ale netuším, či je to principiálne kvôli jeho návrhu, alebo či je málo ľudí/vôle na lepšie optimalizácie. Tipujem to druhé.

No, ja som niekedy pred rokom čítal o tom, že sa niekto snažil kontinuácie dohackovať do JVM. Resp. emulovať kontinuácie v JVM call stacku (ktorý na to nie je extra stavaný). Netuším aký to malo výsledok, ale minimálne niektorí ľudia o tieto pokročilé webframeworky záujem majú. Možno už o takých 10, 20 rokov sa to presadí

[disorder]

VisualWorks je podla language shootout na tom dost dobre (vs Python). Ale za to si zaplatis. Aj Common Lisp ma dobre komercne implementacie.

O 10-20 rokov to nebude taky problem, ked porastie vykon (obsluznost uzivatelov jednym CPU) a pamat. Vyhoda tychto frameworkov je, ze su ekvivalentom "stateful" aplikacii, len bezia cez HTTP.

[Marek Bernát]

Aha, dík za odkaz.

Nerozumiem, ako to súvisí s výkonom. Problém je v tom, že ľudia štandardné webové prostredie (HTTP, HTML, browser), určené pre statické stránky, používajú čoraz viac pre normálne aplikácie. Tento problém by sa najčistejšie dal redefiníciou toho, čo to má vlastne browser byť a všetkých príslušných technológií. To sa pochopiteľne nestane, takže ešte desiatky rokov budeme mať webové aplikácie v browseroch určených prakticky len na prezeranie statických stránok

[disorder]

Continuation frameworky maju naroky na reziu, pretoze obchadzaju to, ze HTTP je stateless. Normalna aplikacia si nemusi pamatat nic, lebo vsetko ma v URL/GET/POST pripadne cookies, obsluzi request a moze uvolnit vsetku pamat.

Ak ma ten optimalizovany Seaside footprint 50 kB, tak to mas ~20000 sessions na 1 GB pamate (pricom uzivatel moze mat viac sessions). Nemam predstavu ako osetruju DoS, hlavne ked dnes ide vela ludi cez NAT a proxy.

Iba pokial je to platena alebo inak limitovana aplikacia, tak to nebude velky problem.

[Marek Bernát]

No dobre, ale pamätať si kontinuácie, to musí byť podľa mňa pár byteov. Len zabalíš call-stack. Koľko to môže mať?

Ten Seaside myslíš tak, že pre každú session zvlášť komplet všetky Seaside objekty v pamäti? To mi pripadá desne neefektívne. V podstate stačí aby každá session mala len pár vlastných inštancií hlavných objektov. Bežný používateľ nebude chcieť upravovať základné objekty, takže tie môžu byť zdieľané. Nakoľko je to prakticky realizovateľné ale netuším.

[disorder]

Neviem ti povedat co vsetko to obnasa. Informacia na wikipedii je "a formerly typical 200 KB footprint becomes 50 KB", takze vyrazny pokrok uz ucinili.

A dalsi problem je horizontalne skalovanie, pretoze jednu session musi vzdy ten isty server spracovavat.

[Marek Bernát]

Horizontálne? Ten pojem nepoznám. Čo to obnáša?

[disorder]

Ako som napisal, ked si pridas viac serverov ("horizontalne") aby si mohol viac uzivatelov obsluzit, tak jedna session ti musi ist vzdy na ten isty server. Pri stateless aplikacii ti je jedno, ktory ta obsluzi.

Nasiel som nejake clanky ohladne Seaside na tuto temu, urcite tam najdes konkretnejsie informacie nez by som ti vedel dat ja: http://onsmalltalk.com/scaling-seaside

[Marek Bernát]

Aha, zaujímavé. Týmto load-balancingom a ďalším serverovým veciam vôbec nerozumiem, tak je fajn sa trochu podučiť.

[Marek Bernát]

K tej wiki inak nie je citácia, takže netuším, čoho všetkého sa ten footprint týka. Alebo či je to vôbec pravda.

[Hynek (Pichi) Vychodil]

Tak to je fakt špatné, když to srovnám z ~800B "kontinuace" v Erlangu

[Marek Bernát]

Otázka je, čo presne sa tými 50kB a 200kB v Seaside myslí. Citácie nie sú a vygooglil som len jeden mail, kde sú tie čísla spomenuté tiež len tak pomimo. IMHO 50kB sa ani omylom nemôže týkať kontinuácií samotných, to je proste moc. 800B už znie rozumnejšie, aj keď stále sa mi to zdá byť moc. Dajme tomu, že priemerná hĺbka volaní bude ~10 a potrebujeme ~20B na pamätania jedného volania (4B na adresáciu funkcie a 4B na každý argument; pre jednoduchosť máme pamäť adresovanú 32 bitmi) na stacku. Mám niekde chybu v počtoch?

[Pavel Křivánek]

Stále častější používání Ajaxu výhody kontinuačních frameworků nečiní tak zjevnými, i když se kontinuace setsakramentsky hodí i tam. Třeba zmiňovaný SeasideXUL je v podstatě plně ajaxová Seaside aplikace (myslím, že i jediná, přes Ajax řeší i call/answer mechanismus komponent), takže poměrně přesně vím, jaké vlastnosti Seaside tím postrádají na důležitosti. Nicméně o dobrém návrhu Seaside lecos vypovída i to, že se tak brutální změna dala naimplementovat bez zásahu do zdrojových kódů Seaside a je to pouhé rozšíření.

[Marek Bernát]

Dostávam chuť sa znova na Seaside trochu pozrieť