Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Vyšlo Pharo 8.0. Přináší lepší nástroje pro refactoring či spoluráci s Gitem. Pharo je programovací jazyk a vývojové prostředí s řadou pokročilých vlastností.
Tiskni
Sdílej:
22.1.2020 12:46
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Nechcete o tom napsat někdo článek (nebo spíš seriál)? Rád bych to viděl na příkladech z praxe.Viz ten štítek smalltalk, tam nějaké ty články najdeš.
Na jednu stranu to vypadá jako úžasné sci-fi (myšleno v dobré), ale na druhou stranu mne to nutí přemýšlet: v čem je sakra háček? Proč se to víc nepoužívá?Ze své zkušenosti musím říct, že to minimálně v minulosti vyžadovalo docela netriviální časovou investici a dokumentace nebyla moc dobrá. Taky máš super prostředí, kde ovšem musíš používat všechno úplně neznámé, od způsobu verzování po grafickou knihovnu. A spousta z těch věcí měla bugy a spousta dalších věcí byla v oficiální image v několika historických verzích a pro začátečníka bez učitele byl docela bordel se v tom vyznat. Ve stylu "a mám používat metacello, nebo monticello, nebo nějaký další projekt X", protože vesměs to vypadá, že fungují všechny všechny přístupy. A pak dáš commit a ono ti to sigsegvne na
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
libgit2 a tak.
Jinak to co popisuji byla verze 4, teď se to hodně zlepšilo a mám v plánu tomu dát někdy další šanci na nějaký projekt, až si uvolním ruce od těch současných.
Na jednu stranu to vypadá jako úžasné sci-fi (myšleno v dobré), ale na druhou stranu mne to nutí přemýšlet: v čem je sakra háček? Proč se to víc nepoužívá?Nechcete o tom napsat někdo článek (nebo spíš seriál)? Rád bych to viděl na příkladech z praxe.
Seriál o smalltalku by určitě nebyl problém (lidi co to umí by se našli třeba Pavel Křivánek .), i jiní zde vypadají, že už do toho nějaký čas investovali, něco umím i já). Jinak je možné najít články na root(u) - např. squeak případně na zdrojáku a našli by se určitě další další. Stačí více pohledat a těch článků je poměrně dost.
V čem je háček?
Tady je nutné se podívat do historie.
Kupodivnu hlavním problémem Smalltalku v počátcích nebyl vůbec technický, ale lidský. Byla to obyčejná lidská hamižnost. Na začátku této cesty stála A. Goldberg, která účtovala nehorázné poplatky za licence, pak chtěla podíl na zisku z firem, které používaly smalltalk (opravdu!) a zastavení vývoje společností, které měli sublicencovaný smalltalk - více doporučuji čtení na první wiki c2.com. Absurně vysoké poplatky byl podle mého hlavní důvod proč se Smalltalk od počátku lavinovitě neprosadil.
Druhá háček byl vstup modré smrti alias IBM. IBM je obrovský mamut a chtěl se prostadit v oblasti Smalltalk s produktem VisualAge for Smalltalk. Čehož se zalekly firmy Digitalk a ParcPlace. Ty se rozhodly provést sloučení, které dopadlo spíše jako boj na život a na smrt. Pěkný člának o tom jeTale of Terror
.A pak přišlel Sun se svojí Javou zdarma a IBM se rozhodlo, že nebude soutěžit s Javou (kam přešla většina vývojářů VM z IBM). Díky IBM se Smalltalk dostal třeba do bank jako je J.P.Morgan nebo na Wallstreet a jinde, ale najednou nebyla žádná firma schopná to podporovat. Následně vznikl pohrobek Cincom (výsledek spojenom Digitalk a ParcPlace), kterému teď zvoní umíráček.
Po IBM jeho smalltalk převzala firma Instantiations a ta se o něj stará a stále vybírá absurdně velké poplatky za licence. Ale je skutečně komečně nasazen a používá se.
Nejschopnější smalltalk je v součastnosti asi GemStone/S, který chvíli vlastnil i VmWare, což byl docela úlet. Nicméně se po této epizodě opět osamostatnil a stále existuje a vyvíjí se dál. Tady je také poměrně široké nasazení
Další reálně nasazený smalltalk je Smalltalk/X od firmy eXcept. Existuje dokonce i odnož, kde lze najít českou stopu Honzy Vraného a jeho Smalltalk/X-jv.
V problémech jsou Pharo a Cincom VisualWorks. Odešli od nich vývojáři VM a tudíž se VM nevyvíjí. Pharo uvádí nové blištivé fičury jako git integraci (Iceberg), ale není tam chuť ani vůle se zastavit a opravovat chyby, které se nakupili. A Cincom také upadá, i když dovnitř nevidím asi tam nebude nic moc atmosféra, když lidé co tam pracovali roky firmu najednou opouští.
Pak jsou zde další jako Dolphin, Squeak, GNU Smalltalk a Amber. Tyhle jsou spíše okrajové důležitosti a spíše na naučení jak to funguje a nevím jestli jsou někde více nasazeny.
Co Smalltalku chybí?
Nyní asi nějaká větší firma či komunita co by se do toho obula. Microsoft má svůj .NET, Google Go a spoustu dalších, SUN (Oracle) má Javu, Facebook má PHP. Pak jsou zde víceméně komunitní věcí jako Python, Ruby či Rust, kolem kterých se utvořila životaschopná komunita a začalo to fungovatl. Smalltalk nic takového bohužel neměl a zatím podle mého nemá (šanci mělo Pharo, ale zde to dle mého názoru nevypadá úplně slibně).
Další důležitým aspektem jsou pracovní příležitosti. Nějaké jsou, ale moc jich není a pokud chce nováček vstoupit do světa Smalltalku není to tak jednoduché, protože většinu pozic mají zkušení matadoři.
Osobně si myslím, že je spíše zázrak, že Smalltalk přežil své několikateré klinické smrti a stále se v něm programuje. Spíše to vypovídá o tom, jak se ve smalltalku dobře programuje a celý ten koncept je výborně vymyšlen.
Co se týká Smalltalk image. Ta je, v současné podobě, dle mého názoru již překonaná myšlenka (vznikla v době, kdy sdílení kódu ve formě VCS vůbec neexistovalo, internet byl v plenkách) - tato myšlenka by potřebovala zásadní inovaci a spojit CVS s image by bylo úžasné.
Diky za shrnutí
Cincom je společnost, co skupuje staré technologie s "vendor lock-in" a ždímá zákazníky, dokud to jde. Bez toho, aby svoje produkty nějak zásadně rozvíjela. Bohužel se do jejích spárů dostala i největší komerční implementace Smalltalku. To, že chtějí podíl na zisku svých zákazníků, platí do dneška. Těm se to samozřejmě moc nelíbí a aktivně pokukují po alternativách, Především po Pharu.
Takže tyto firmy buď aktivně pracují na přechodu nebo se alespoň spolupodílejí na financování vývoje Phara jako své budoucí potenciální platformy. I díky tomu Pharo docílilo stavu, kdy je schopné ufinancovat několik full-time vývojářů.
Co se virtuálních strojů týká, od Cincomu vývojáři neodešli, byli odejiti. Situace ohledně virtuálního stroje Phara se točí hlavně kolem osoby Eliota Mirandy, což je hlavní vývojář OpenSmalltalk VM, kterou Pharo používá, ale on sám Pharo otevřeně nesnáší. V důsledku toho nakonec letos Pharo de-facto vytvořilo fork této VM, na což Eliot zareagoval vyloženě nepřátelsky, viz licence k tomuto balíčku: http://www.squeaksource.com/ClosedVMMaker/
Díky tomu ale vývoj virtuálního stroje Phara pokročil za pár měsíců víc než za několik let. Eliot blokoval tak základní infrastrukturní kroky jako sjednocení všech zrojových kódů v jednom Git repozitáři, použití cmake atd.. Pharo VM má nyní konečně fungující headless VM, threaded FFI, virtuální stroj je použitelný jako dynamická knihovna, má skutečně fungující CI, pročištěné závislostmi balíčků, řadou nových testů atd. Takže bych to tak černě neviděl.
Nemyslím si, že by VCS a koncept image byl v nějakém rozporu, ale chvíli trvalo najít způsob, jak je sloučit do funkčního celku. Čímž netvrdím, že by koncept image nezasloužil inovovat, ale kvůli VCS to nutné není.
Cincom je společnost, co skupuje staré technologie s "vendor lock-in" a ždímá zákazníky, dokud to jde. Bez toho, aby svoje produkty nějak zásadně rozvíjela. Bohužel se do jejích spárů dostala i největší komerční implementace Smalltalku. To, že chtějí podíl na zisku svých zákazníků, platí do dneška. Těm se to samozřejmě moc nelíbí a aktivně pokukují po alternativách, Především po Pharu.
Takže tyto firmy buď aktivně pracují na přechodu nebo se alespoň spolupodílejí na financování vývoje Phara jako své budoucí potenciální platformy. I díky tomu Pharo docílilo stavu, kdy je schopné ufinancovat několik full-time vývojářů.
Ano, společnost Cincom je nyní takový parazit, který se snaží ze svých zákazníků vysát co nejvíce za co nejméně úsilí. To, že se do spárů dostala v roce 1999 může právě spackané spojení ParcPlace and Digitalk, vznik javy a IBM. Cincom to stálo prý kolem $3m což byla směšná částka. Více na VisualWorks selling to Cincom. Když tam byl zesnulý James Robertson, tak se vývoj konal a vypadalo to na světlé zítřky - takže parazitem nebyly vždy a nějaký vývoj se skutečně konal. V současnosti pouze paběrkují a nejspíše je očekává se hořký konec, ostatně všechny firmy co rezignují na inovace a vlastní vývoj.
Co vím, tak se aktnivně koukají po alternativách, ale Pharo často mezi nimi chybí. Důvody jsou různé, ale s těma firmami co jsem mluvil vadí následující:
1] problém se stabilitou prostředí, což jsem si ověřil sám na vlastní kůži. Není vůbec žádný problém shodit prostředí. Stabilita je nutnost pokud to člověk na tom má běžet produkční prostředí. Tým kolem Pharo by měl věnovat hodně soustředěného úsilí na stabilizaci prostředí. Nic takové ale nevidím, což se možná špatně dívám, rád se nechám poučit.
2] chybí dlouhodobé plánování (roadmap) a z toho těžko předvídatelný vývoj.
3] Díky bodu 2] Tudíž tendence na produkcích zůstat u původního Pharo a nezkoušet nové věci, protože se bojí, a asi oprávněně, budou trávit hodně časo migrací a objevovat chyby nové a žít s těmi starými. Na staré chyby už mají způsoby jak se jim vyhnout.
4] problém překompilovaní nové verze knihoven oproti staršímu Pharu. Například libgit2 na RedHat(u).
5] na spoustě funkcionalit dělá pouze jeden člověk, který když odejde tak není kdo by ho udržoval a tudíž chyby se kupí a celé to chřadne.
6] rekompilace celého Pharo ze zdrojáků je práce spíše pro šamany než inženýry. Je to opravdu oříšek to zkompilovat.
7] neexistence migrační schématu v případě migrace ze starší verze (co přesně má člověk očekávat, jaké problémy mohou nastat, atd.).
8] závislost na historických verzích gcc - chybí podpora pro novější. Teď je stable gcc 9.x, lze zkompilovat Pharo s gcc 8, 7 atd. co jsem koukal tak to nejde. Možná mě opravíte?
Co se virtuálních strojů týká, od Cincomu vývojáři neodešli,Děkuji za upřesnění. V konečném důsledku je to to samé, žádný vývoj neprobíhá, případně možná opravy. Cincom je loď co jde ke dnu.
Tady pravděpodobně budeme zpět u lidských vztahů a ne technických, což se u Smalltalku obecně dost často vyskytuje, protože lidí co se profesně věnují Smalltalku moc není. Domnívám se, nebyl jsem u toho, že je to spíše osobní nevraživost mezi šéfem projektu Stephanem Ducasse a Eliotem Mirandy. Ostatně u Phara předtím skončil další VM vývojář Clément Béra, ten nyní pracuje u Googlu, předpokládám, že se opět nějakým způsobem neshodli na osobní rovnině. Docela by mě zajímalo, kdo nyní pracuje na u Pharo na jeho VM? Pokud bránil rozvoji a vývoji VM, tak je asi jenom dobře, že nechce sdílet svojí práci s Pharo, ne? To co popisujete jako jsou (jeden git repository, cmake, atd.) to jsou spíše údržbové záležiosti, kterou jsou důležité, ale nejde o vývoj VM jako JIT, multi-threaded VM, atd. Jak mě říkal jeden kamarád, dnešní Javascript VMky jsou prakticky všechny lepší než-li nejlep39 Smalltakové. Je to svým způsobem daň za úspěch Smalltalku, ale také to vypovídá něco o komunitě. Místo soustředění se na nedůležité detaily jako implementace #become: se soustředit na to v čem byl opravdový pokroj a kde ujel vlak.Situace ohledně virtuálního stroje Phara se točí hlavně kolem osoby Eliota Mirandy, což je hlavní vývojář OpenSmalltalk VM, kterou Pharo používá, ale on sám Pharo otevřeně nesnáší. V důsledku toho nakonec letos Pharo de-facto vytvořilo fork této VM, na což Eliot zareagoval vyloženě nepřátelsky, viz licence k tomuto balíčku: http://www.squeaksource.com/ClosedVMMaker/
Díky tomu ale vývoj virtuálního stroje Phara pokročil za pár měsíců víc než za několik let. Eliot blokoval tak základní infrastrukturní kroky jako sjednocení všech zrojových kódů v jednom Git repozitáři, použití cmake atd..
Pharo VM má nyní konečně fungující headless VM, threaded FFI, virtuální stroj je použitelný jako dynamická knihovna, má skutečně fungující CI, pročištěné závislostmi balíčků, řadou nových testů atd. Takže bych to tak černě neviděl.
To rád slyším, tohle pročisťování je klíčem ke stabilitě, po které všichni volají. Kde je nyní místo, kde se sbírají případné chyby? Držím palce, ať se to podaří.
Nemyslím si, že by VCS a koncept image byl v nějakém rozporu, ale chvíli trvalo najít způsob, jak je sloučit do funkčního celku. Čímž netvrdím, že by koncept image nezasloužil inovovat, ale kvůli VCS to nutné není.
Tady jsme si nerozumněli. Netvrdím, že image je v rozporu s VCS. Psal jsem jenom o tom, že Smalltalkový image je v původní verzi v současnosti těžko použitelný pokud, by někdo chtěl sdílet právě ten image mezi více uživateli a pak ten kód nějakým způsobem v té image udržovat. t.j. aby každý vývojář si mohl stáhnout současnou image a přidat k ní své rozdíly, s tím pak pracovat a následně uložit změny a aktualizovat image, aby z ní mohli ostatní vycházet.
Pokusů o verzovacích systémů má Smalltalk za sebou několik, ale moderní verzovací systémy jako git či mercurial všechny daleko přesahují, proto Pharo pochopitelně pracovalo na itegraci s git, což je jen dobře. (Pro ostatní původní verzovací systémy u Smalltalku: Monticello (Pharo), ENVY (VA Smalltalk) a Store (VisualWorks))
V současnosti pouze paběrkují a nejspíše je očekává se hořký konec, ostatně všechny firmy co rezignují na inovace a vlastní vývoj.
Naposledy, když jsem slyšel o situaci v Cincomu, tak se tvrdilo, že majitel umírá a zbylý management se snaží urvat, co se dá. Což pro jejich budoucnost nevěští nic dobrého a světu Smalltalku to také nepřidá.
1] problém se stabilitou prostředí, což jsem si ověřil sám na vlastní kůži. Není vůbec žádný problém shodit prostředí. Stabilita je nutnost pokud to člověk na tom má běžet produkční prostředí. Tým kolem Pharo by měl věnovat hodně soustředěného úsilí na stabilizaci prostředí. Nic takové ale nevidím, což se možná špatně dívám, rád se nechám poučit.
V posledních verzích se to zlepšilo, ale, abych byl upřímný, s příchodem headless VM v Pharo 9.0 se to pravděpodobně zase zhorší, alespoň tedy u image s IDE.
2] chybí dlouhodobé plánování (roadmap) a z toho těžko předvídatelný vývoj.
Osobně jsem neviděl roadmap na víc než jedno vydání dopředu ani u komerčních impmlementací, ale u Phara byly původní cíle definovány v dokumentu "Pharo’s Vision", který je ovšem už překonaný, protože se tam nastíněné vize dočkaly realizace. Devátá verze přinese Threaded FFI, headless image, Spec 2 (s podporou Gtk), nový skriptovatelný object-centric debugger, všechny nástroje se upraví (pravděpodobně ne hned ve verzi 9) tak, aby nový Spec používaly, takže se vývojové nástroje stanou nezávislými na Morphicu.
3] Díky bodu 2] Tudíž tendence na produkcích zůstat u původního Pharo a nezkoušet nové věci, protože se bojí, a asi oprávněně, budou trávit hodně časo migrací a objevovat chyby nové a žít s těmi starými. Na staré chyby už mají způsoby jak se jim vyhnout.
Pharo používá mechanismy, které umožňují automaticky opravovat konstrukce a volání označené jako "deprecated" i nástroje na migraci, které se zkoušely na reálných projektech a dařilo se jim migrovat kód někdy od verze 1.2. Navíc je kód základního systému v posledních verzích bez větších změn. Mimochodem, JP Morgan migruje z verze VisualWorks 7 na verzi 8 už dva roky, co jsem se doslechl. Jeden z cílů, které Pharo Consortium má, je přímo zajišťovat migraci aplikací pro zákazníky.
4] problém překompilovaní nové verze knihoven oproti staršímu Pharu. Například libgit2 na RedHat(u).
Pharo zatím nemá žádnou LTS. O problémech s VM jsme již mluvili a tohle s nimi přímo souvisí.
5] na spoustě funkcionalit dělá pouze jeden člověk, který když odejde tak není kdo by ho udržoval a tudíž chyby se kupí a celé to chřadne
To není problém jen Phara. Ale Pharo samotné spíš trpí tím, že se deklaruje náhrada nějakého subsystému (např. Morphic), což spolehlivě zabije nějakou motivaci ten subsystém udržovat, aníž ta náhrada skutečně v rozumné době příjde.
6] rekompilace celého Pharo ze zdrojáků je práce spíše pro šamany než inženýry. Je to opravdu oříšek to zkompilovat.
Bootstrapping se dělá při každém pull requestu a je tedy přímo automatizovaný a reprodukovatlený. Na druhou stranu uznávám, že by si zasloužil mnohem lépe zdokumentovat, aby bylo jednodušší jej upravovat pro vývojáře bez šamanských zkoušek.
7] neexistence migrační schématu v případě migrace ze starší verze (co přesně má člověk očekávat, jaké problémy mohou nastat, atd.)
Viz předchozí body, Pharo se snaží označovat věci jako deprecated a likvudují se až ve verzi následující.
8] závislost na historických verzích gcc - chybí podpora pro novější. Teď je stable gcc 9.x, lze zkompilovat Pharo s gcc 8, 7 atd. co jsem koukal tak to nejde. Možná mě opravíte?
Minimálně s verzí 7 to určitě jde. Na CI servery, které Pharo VM kompilují, se historické verze GCC rozhodně cíleně nedávají. Případné problémy, prosím, reportujte na https://github.com/pharo-project/opensmalltalk-vm
Domnívám se, nebyl jsem u toho, že je to spíše osobní nevraživost mezi šéfem projektu Stephanem Ducasse a Eliotem Mirandy.
To značné míry. Ducasse se občas nechová mic diplomaticky a někdy reaguje přehnaně, takže když se střetne s osobností, která je na tom podobně, je oheň na střeše. Clémentovi se asi vidina toho, že by pod ním měl dlouhodobě pracovat, příliš nezamlouvala, ale nezažil jiné šéfy, tak doufám, že neskočil z bláta do louže. Musím říct, že Stéphane toho pro něj udělal skutečně hodně.
Na VM pracuje především Pablo Tesone. Dále Esteban Lorenzano a Guillermo Polito. Nejsou to takové superstar jako Eliot, ale jsou hodně dobří a dát do pořádku infrastrukturu kolem VM je teď nejdůležitější pro další rozvoj. JavaScriptové VMky jsou samozřejmě mnohem výkonější než Smalltalkové, vzhledem k investicím a některým nižším nárokům JavaScriptu. Osobně si nemyslím, že je reálné, aby Pharo mělo v brzké budoucnosti klasickou vícevláknovou VM. Musí jít cestou víceméně samostatných komunikujících image.
Psal jsem jenom o tom, že Smalltalkový image je v původní verzi v současnosti těžko použitelný pokud, by někdo chtěl sdílet právě ten image mezi více uživateli a pak ten kód nějakým způsobem v té image udržovat. t.j. aby každý vývojář si mohl stáhnout současnou image a přidat k ní své rozdíly, s tím pak pracovat a následně uložit změny a aktualizovat image, aby z ní mohli ostatní vycházet.
Pracují v malém týmu, kde v přesně tohle děláme (jen s tím rozdílem, že vývojáři nikdy nesdílí své image, protože je sestavuje CI)
Naposledy, když jsem slyšel o situaci v Cincomu, tak se tvrdilo, že majitel umírá a zbylý management se snaží urvat, co se dá. Což pro jejich budoucnost nevěští nic dobrého a světu Smalltalku to také nepřidá.To Smalltalku rozhodně nepřidá, zase na druhou stranu mohlo by to narušit status quo a mohli by se ledy pohnout a konečně se uvolnit některé věci které byly zatuhlé mnoho let. Cincom k jedné takové zatuhlé věci patřilo, od doby co James Robertson odešel.
1] problém se stabilitou prostředí, což jsem si ověřil sám na vlastní kůži. Není vůbec žádný problém shodit prostředí. Stabilita je nutnost pokud to člověk na tom má běžet produkční prostředí. Tým kolem Pharo by měl věnovat hodně soustředěného úsilí na stabilizaci prostředí. Nic takové ale nevidím, což se možná špatně dívám, rád se nechám poučit.
V posledních verzích se to zlepšilo, ale, abych byl upřímný, s příchodem headless VM v Pharo 9.0 se to pravděpodobně zase zhorší, alespoň tedy u image s IDE.
To rád slyším, naposledy jsem to testoval ve verzy 6/7 a spadlo mě to tak do minuty. Samozřejmě když člověk ví co "nemá" dělat, když už to používá dlouho, tak se tomu dokáže vyhnout, ale to by nemělo být účelem.
Docela by mě zajímalo, proč headless VM zhorší stabilitu prostředí? Přidání nové funkcionality, pokud se ví, že způsobuje zhoršení stability, by se mělo odložit dokud se neopraví bolestivá místa a vydat to v okamžiku, kdy nejsou známy žádné takovéto vedlejší účinky (to samozřejmně neznamená, že tam chyby nebudou, některé jako "race conditions" se nedají jednoduše odhalit). Stabilita prostředí je klíčem k úspěchu v podnikové oblasti, bez stability nemůže být o větším nasazovaní moc řeč.
2] chybí dlouhodobé plánování (roadmap) a z toho těžko předvídatelný vývoj.
Osobně jsem neviděl roadmap na víc než jedno vydání dopředu ani u komerčních impmlementací, ale u Phara byly původní cíle definovány v dokumentu "Pharo’s Vision", který je ovšem už překonaný, protože se tam nastíněné vize dočkaly realizace. Devátá verze přinese Threaded FFI, headless image, Spec 2 (s podporou Gtk), nový skriptovatelný object-centric debugger, všechny nástroje se upraví (pravděpodobně ne hned ve verzi 9) tak, aby nový Spec používaly, takže se vývojové nástroje stanou nezávislými na Morphicu.
U těch komerčních Smalltaků, co jsem stačil zaznamenat tak je to spíše na nějaký časový úsek a následně nějaké zhodnocení či prezentace jak se co povedlo. Komerční Smalltalk implementace Například: VAST má roadmap na každý rok na VAST roadmap. U GemStone/S jsem to viděl spíše ve formě prezentací (pro rok 2015, 2017). Ono by přesně stačilo udělat jednoduchý seznam co se dá očekávat u 9ky:
To zní jako HODNĚ...HODNĚ moc práce. U toho threaded FFI se trochu bojím, jak to bude s těma threadama a stabilitou. Nebudou tam vznikat zámky (deadlocks) nebo problémy se souběhem (race condition)? Headless image je super (divím se, že to přichází tak pozdě), ale zase ne za cenu snížení stability prostředí. Nový debugger, to je skvělé, ale pořádný debugger je na roky práce ne? spec2 s gtk (doufám, že gtk3) tak pokud se to udělá pořádně, tak to bude v oblasti GUI krok správným směrem! To přepsání všeho do spec2 to zní jako hodně moc práce. Trochu mě napadá jestli to není moc změn na jednu verzi? Jenom ten debugger by stačil na verzi 9.
3] Díky bodu 2] Tudíž tendence na produkcích zůstat u původního Pharo a nezkoušet nové věci, protože se bojí, a asi oprávněně, budou trávit hodně časo migrací a objevovat chyby nové a žít s těmi starými. Na staré chyby už mají způsoby jak se jim vyhnout.
Pharo používá mechanismy, které umožňují automaticky opravovat konstrukce a volání označené jako "deprecated" i nástroje na migraci, které se zkoušely na reálných projektech a dařilo se jim migrovat kód někdy od verze 1.2. Navíc je kód základního systému v posledních verzích bez větších změn. Mimochodem, JP Morgan migruje z verze VisualWorks 7 na verzi 8 už dva roky, co jsem se doslechl. Jeden z cílů, které Pharo Consortium má, je přímo zajišťovat migraci aplikací pro zákazníky.
To rád slyším, i když o nich čtu poprvé. Možná by stálo za úvahu mít nějaký ukázkový projet a ukázat jak se to dělá. Nevím jestli zákazníci budou chtít, aby pro ně Pharo Concortium dělalo migraci, někteří si z povahy dat, se kterými zacházejí budou muset udělat migraci sami. U JP Morgan nemají kam odmigorvat, když Cincom přestal s vývojem. Takže odmigrovat sice můžou zkusit, ale když nebude nikdo kdo je bude podporovat, tak mají asi smůlu.
4] problém překompilovaní nové verze knihoven oproti staršímu Pharu. Například libgit2 na RedHat(u).
Pharo zatím nemá žádnou LTS. O problémech s VM jsme již mluvili a tohle s nimi přímo souvisí.
LTS verze by vyřešila řadu problémů, proč vlastně není žádná LTS verze?
5] na spoustě funkcionalit dělá pouze jeden člověk, který když odejde tak není kdo by ho udržoval a tudíž chyby se kupí a celé to chřadne
To není problém jen Phara.
To asi není, ale když o tom tak přemýšlím (marně přemýšlím, který další projekt je Ph.D. projekt driven, kde se něco vyvine v rámci Ph.D. a pak ten člověk odejde), tak každý projekt ala Linux Kernel (o dost větší projekt), Git, OpenBSD(tam má nejvyšší autoritu Theo, mají pravidelné hackatlony, chyba v dokumentaci či chybějící dokumentace je rovna chybě v kódu), Wireshark atd. mají fáze vývojové a fáze udržovací. Každý může poslat návrh na změnu (patch), ale záleží na správci daného substému, případně celého projektu jestli danou změnu přijme nebo ji nechá k přepracovaní nebo ji zamítne zcela s nějakým rozumným odůvodněním. Takovýto systém by asi slušil i Pharu. Jde o to, že když se něco vyvine, tak by to automaticky mělo mít správce, který je s funkcionalitou dostatečně obeznámen a dokáže kód udržovat, zkontrolovat, až pak se přidá do hlavní větve. Správce(i) pak udržují danou funkcionalitu a jsou za ní zodpovědní.
Ale Pharo samotné spíš trpí tím, že se deklaruje náhrada nějakého subsystému (např. Morphic), což spolehlivě zabije nějakou motivaci ten subsystém udržovat, aníž ta náhrada skutečně v rozumné době příjde.
To je právě ten problém s plánováním a je to přirozená skutečnost. Pokud se uvede, že bude přechod ala gtk2 na gtk3, tak je jasné, že aktivita u gtk2 bude upadat a věnujese většina energie na gtk3. Pokud se odhadne, že gtk3 tu bude za zhruba 5 let, tak je jasné, že je potřeba udržovat gtk2 ještě 5 let, ale je jasné, že nový vývoj u něho moc nebude, bude se pouze udržovat. Proto je potřeba takovéto zásadní změny opravdu dobře naplánovat.
6] rekompilace celého Pharo ze zdrojáků je práce spíše pro šamany než inženýry. Je to opravdu oříšek to zkompilovat.
Bootstrapping se dělá při každém pull requestu a je tedy přímo automatizovaný a reprodukovatlený. Na druhou stranu uznávám, že by si zasloužil mnohem lépe zdokumentovat, aby bylo jednodušší jej upravovat pro vývojáře bez šamanských zkoušek
To rád slyším, že je to automatizované a reprodukovatelné. Když jsem to před nějakým časem zkoušel tak to opravdu nešlo a nechtěl jsem tomu věnovat čas, protože jsem si říkal, že se to postupně stejně musí nějakým způsobem automatizovat, jinak ten vývoj jde dělat opravdu těžko. Teď ještě nějakou dokumentaci, pro ty z nás co nejsou v srdci projektu.
8] závislost na historických verzích gcc - chybí podpora pro novější. Teď je stable gcc 9.x, lze zkompilovat Pharo s gcc 8, 7 atd. co jsem koukal tak to nejde. Možná mě opravíte?
Minimálně s verzí 7 to určitě jde. Na CI servery, které Pharo VM kompilují, se historické verze GCC rozhodně cíleně nedávají. Případné problémy, prosím, reportujte na https://github.com/pharo-project/opensmalltalk-vm
Co mě chybí je seznam jaké přesně gcc verze jsou podporávny a co není. U toho gcc 7 je podporáno vše, tedy 7.x? Nebo je to jenom 7.0 nebo pouze nejnovější 7.3.x? Když si vezmu dokument HowToBuild opensmalltalk-vm tak je tam zmínka o problémech s gcc version > 4.2.1.
Pamatuji si dokonce, tak 2-3 roky zpět kdy se na mailing listu psalo něco takovéhoto:
My understanding is that gcc 4.8(.4) is the default version in trusty, so if anyone else wants to build the VM with the same compiler, they'll need gcc 4.8. At the moment it is needed because a few people have found that the VM doesn't work properly if compiled with gcc 5.4
Děkuji a za link, až to bude opět zkoušet určitě to tam nahlásím.
Domnívám se, nebyl jsem u toho, že je to spíše osobní nevraživost mezi šéfem projektu Stephanem Ducasse a Eliotem Mirandy.
To značné míry. Ducasse se občas nechová mic diplomaticky a někdy reaguje přehnaně, takže když se střetne s osobností, která je na tom podobně, je oheň na střeše. Clémentovi se asi vidina toho, že by pod ním měl dlouhodobě pracovat, příliš nezamlouvala, ale nezažil jiné šéfy, tak doufám, že neskočil z bláta do louže. Musím říct, že Stéphane toho pro něj udělal skutečně hodně.
Také mám takový pocit, že reaguje přehnaně. Šéf projektu by měl bý i diplomat a umět se domluvit, což přiznávám může být občas složité. Trochu mě to připomíná situaci s Lennart(em) Poettering(em) a jeho systemd, kde problém není technický ale osobnostní. Nevím jak se daří Clémentovi, ale protože vypadá, že tam stále pracuje snad je i spokojen. Do zákulisí skutečně nevidím a nedokážu ocenit kolik pro něj S. Ducasse udělal či neudělal.
Na VM pracuje především Pablo Tesone. Dále Esteban Lorenzano a Guillermo Polito. Nejsou to takové superstar jako Eliot, ale jsou hodně dobří a dát do pořádku infrastrukturu kolem VM je teď nejdůležitější pro další rozvoj.
Děkuji za jména, nějak jsem ztratil pojem kdo tam teď zbyl. Měl jsem pocit, že Esteban pracuje na celém projektu a nejen na VM. On se teď věnuje hlavně VM? G. Polita jsem ještě někde zahlédl. P. Tesone neznám, ale našel jsem si práci GildaVM: a Non-Blocking I/O Architecture for the Cog VM, kterou si musím pročíst, která je k tématu. Trochu se obávám toho, že vývoj VM zpomalí, protože odchod 2 schopných VM vývojářů je těžko nahradit a další nerostou na stromech. Rád se budu mýlit.
JavaScriptové VMky jsou samozřejmě mnohem výkonější než Smalltalkové, vzhledem k investicím a některým nižším nárokům JavaScriptu. Osobně si nemyslím, že je reálné, aby Pharo mělo v brzké budoucnosti klasickou vícevláknovou VM. Musí jít cestou víceméně samostatných komunikujících image.
JavaScript je samozřejmně díky prohlížečům teď na výslunní a nelze porovnávat množství prostředků vložených do jeho VM vs. Smalltalkových. Jelikož je u Smalltalku mnohem méně prostřeků je daleko důležitější je investovat správným směrem Jde mě o to, že je možné se inspirovat u těchto "našlápnutých" VM a přestat lpět na některých detailech, které v konečném důsledku nejsou vůbec důležité.
Co se týká vícevláknové VM, tak její vytvoření představuje hodně práce nejen na VM, ale i na základních knihovnách, které musí být bezpečné pro vícevláknové použití. Nejsem si jist jestli je cesta samostatně komunikujících image jediná možné, určitě je nejjenodušší. Vím, že Matz (tvůrce ruby), s podobným principem již delší dobu koketuje, ale není s výsledky spokojen - je tam přiliž velká penalizace mezi komunikujícími procesy.
Možná, že zajímavější a prespektivnější cestou by byla implementace IBM OMR (zdrojové kódy: omr github), kde je možnost využít obrovské práce IBM, které zobecnila svojí JVM pro využití v ostatních jazycích. Už mimochodem implemntovali ukázkovou Smalltakovou VM SOM smalltalk.
Pracují v malém týmu, kde v přesně tohle děláme (jen s tím rozdílem, že vývojáři nikdy nesdílí své image, protože je sestavuje CI)Ano, to už se blíží tomu co jsem myslel! To je významný pokrok. Já jsem přemýšlel to dotáhnout ještě o krok dále, kde by se takováto vygenerovaná image spojená s vývojářovím diffem (kde by byly zaznamenámy pohy oken, stav debuggeru atd.) otevřela podobně jak se otevírá uložená image na jednotlivých počítačích.
Předně děkuji za podnětnou diskuzi.
Nápodobně
To Smalltalku rozhodně nepřidá, zase na druhou stranu mohlo by to narušit status quo a mohli by se ledy pohnout a konečně se uvolnit některé věci které byly zatuhlé mnoho let. Cincom k jedné takové zatuhlé věci patřilo, od doby co James Robertson odešel.
VA Smalltalk se v poslední době začal hýbat správným směrem. Třeba nakonec VisualWorks od Cincomu koupí nějaký stávající zákazník jako Lam Research a oživí to.
Docela by mě zajímalo, proč headless VM zhorší stabilitu prostředí?
Protože více práce přejde na image, třeba zpracování událostí okenního manažeru. Nedělám si iluze, že to bude mít jen pozitivní dopady. Osobně headless VM používám téměř výhradně už asi půl roku a žádné větší problémy jsem s ní nezaznamenal, ale na některé krizové situace je prostě z principu citlivější. Přínosy by to ale měly vyvážit.
To zní jako HODNĚ...HODNĚ moc práce
Prezentace roadmap pro Pharo je napříkad zde: https://www.youtube.com/watch?v=6vax47zC47Y. Je to hodně práce a vše z toho je již v pokročilé fázi vývoje. Pharo 8 mělo alespoň část z toho obsahovat, ale raději jsme přistoupili k vydání víceméně opravné verze a získali více času na dokončení těch věcí, než se to vše snažit urychleně dokončit a neustále vydání odkládat. ThreadedFFI je na tom se stabilitou velmi dobře a teď potřebuje spíš už jen výkonnostní optimalizace. Pozdě přichází proto, protože Eliot. Ano, jedná se o Gtk3. Přepis všech nástrojů do Spec2 se určitě ve verzi 9 ještě nestihne, pokud se nestane nějaký zázrak.
JP Morgan na migraci na Pharo aktivně pracuje, víceméně se snaží ho ohnout tak, aby co nejvíc odpovídalo VisualWorks, takže např. implementovali jmenné prostory a podobné VW specifické konstrukce. Má to ale několik ale. Je to velký byrokratický moloch, který neumí spolupracovat s open-source světem. Také největší ořišek je migrace UI a vhledem k tomu, jak rychle postupují při migraci v rámci verzí VisualWorks, je to ještě na dlouho. Na migraci na Pharo pracuje aktivně třeba ještě Lifeware (cca 8000 tříd jen datového modelu) a Schmidt.
Takovýto systém by asi slušil i Pharu
Ano, ale to samozřejmě naráží na lidské zdroje. Pharo pořádá každý měsíc setkání, kde se opravují chyby a s přechotem na GitHub je i podstatně jednodušší dělat posouzení pull-requestů, takže to dělá více lidí. Ale jednoznačně přiřaditelné správce má jen několik podsystémů.
je tam zmínka o problémech s gcc version > 4.2.1.
pharo-project/pharo-vm není aktuální repozitář. Podle Pabla funguje překlad na GCC 9.3.
Do zákulisí skutečně nevidím a nedokážu ocenit kolik pro něj S. Ducasse udělal či neudělal.
Stéphane dělal vše možné, aby mu zajistil stabilní místo kde by si do důchodu mohl dělat téměř cokoliv, co by chtěl, které ale nakonec Clément (z výše uvedených důvodů) odmítnul, což Stéphane vzal jako kudlu do zad. Chápu oba.
Měl jsem pocit, že Esteban pracuje na celém projektu a nejen na VM. On se teď věnuje hlavně VM? G. Polita jsem ještě někde zahlédl. P. Tesone neznám, ale našel jsem si práci GildaVM: a Non-Blocking I/O Architecture for the Cog VM, kterou si musím pročíst, která je k tématu. Trochu se obávám toho, že vývoj VM zpomalí, protože odchod 2 schopných VM vývojářů je těžko nahradit a další nerostou na stromech. Rád se budu mýlit.
Na VM pracuje především Pablo, což je opravdu prvotříní všestranný programátor. ThreadedFFI a dokončení headless VM je jeho zásluha. Esteban se na VM podílí především v oblastech, které se dotýkají spolupráce s Gtk (např. aby VM běžela ve vedlejším vlákně a ne hlavním). Guillermo je tak od všeho něco, pracuje, mimo jiné, na vylepšení způsobu překladu Slangu.
Co se týká vícevláknové VM, tak její vytvoření představuje hodně práce nejen na VM, ale i na základních knihovnách, které musí být bezpečné pro vícevláknové použití. Nejsem si jist jestli je cesta samostatně komunikujících image jediná možné, určitě je nejjenodušší.
Ano, GC a základní knihovna představují asi největší problém. Na druhou stranu, Pharo ma velmi slušný jednovláknový GC i celkový výkon, takže by byla toho nevyužít a spíše se snažit image rozdělit na řadu menších. Hnát se ale za co nejvyšším výkonem není ta nejlepší cesta, protože žene vývoj do lokálního maxima, ze které je nemožné přeskočit skutečně dále.
¨Já jsem přemýšlel to dotáhnout ještě o krok dále, kde by se takováto vygenerovaná image spojená s vývojářovím diffem (kde by byly zaznamenámy pohy oken, stav debuggeru atd.) otevřela podobně jak se otevírá uložená image na jednotlivých počítačích.
Zatím jen přizpůsobujeme image konkrétním lidem (změní se nastavení, otevřou se požadovaná okna...), ale něco takového je samozřejmě možné.
Hnát se ale za co nejvyšším výkonem není ta nejlepší cesta, protože žene vývoj do lokálního maxima, ze které je nemožné přeskočit skutečně dále.V čem spočívá to lokální minimum ze kterého je možná přeskočit (ochladit, žíhat) dále? Pokud mám framework jako OMR, který už ma zasebou jistě mnoho tisíců hodin běhu, tak je nějakým způsobem odzkoušen, tak by to mohlo podstatně ušetřit práci na dosáhnutí vícevláknového prostředí.
Já zkoušel třeba vytvářet sítě 128 takových uzlů, kde každý je obousměrně propojen s každým a má na ostatní uzly proxy objekty, takže jim může přirozeně zasílat zprávy. Dokonce i s vypracovanou distribucí kódu mezi takové uzly. Ale to není jediná možná cesta.
S Marcusem Denkerem se teď nezávazně snažíme načrtnout architekturu, která by Pharo mohla posunout někam dál. Jde o to alespoň mít nějaou konrétnější představu, jakým směrem se ubírat. Momentální představy jsou asi takové: