Ĉiuj vojoj kondukas al malfermaj platformoj
Antaŭparolo: bonega programisto
Estas kelkaj programistoj, kiujn mi vere admiras, sed unu kiu elstaras. Tio estas Chris McDonough, kreinto de Pyramid, la plej bona kadro por disvolvi TTT-aplikaĵojn en Python.
Mi ne konas lin krom 1 aŭ 2 demandoj, kiujn li persone respondis al mi en la IRC-babilejo pri Pyramid. Sed per la ekzemplo de Pyramid mi lernis pli bone kodi ― estas kvazaŭ mi akiris ian bonan guston legante la kodon de Pyramid kaj vidante kiel aferoj estis apartigitaj kaj rilataj. Mi akiris ĉi tiun scion el libroj de Martin Fowler kaj aliaj, sed vidi la ekzemplon en Pyramid estis grava peco por efektive lerni ĝin.
McDonough estas grava kreinto de libera programaro en Python. Li ankaŭ kreis Colander kiu eĉ hodiaŭ estas unu el la 3 plej bonaj skemvalidigaj bibliotekoj en Python certe.
Mia ĉefa punkto
Mi neniam sciis ĉi tion, sed mia historio kiel programisto spegulas la de McDonough kun pluraj jaroj da prokrasto. Mi nur hodiaŭ konsciis pri tio, kiam mi trovis...
ĉi tiu lia video, kiu enhavas 3 aŭ 4 anekdotojn el lia kariero, kiuj ĉiuj pruvas ununuran punkton.
La spegulo estas speciale forta en ke, dum la jaroj, ni amasigis kialojn por malami Microsoft, tiam Apple, tiam Google. Kaj konsciante, ke la liberkoda alternativo respektata por libereco ĉiam estas pli bona, eĉ kiam ĝi estas teknike pli malbona nuntempe.
Kiel li diras, ĉiuj vojoj kondukas al malfermitaj platformoj. Do foriru.
Liajn interesajn rakontojn mi ne ripetos ĉi tie; bonvolu spekti la videon. Anstataŭe, mi resumos mian propran historion per miaj propraj anekdotoj.
La elekto: C# aŭ Ĝavo?
Mikrosofto unue provis mortigi Ĝavo per sia fama tekniko brakumi kaj etendi. Ĝi faris Microsofta Ĝavo. Kaj ĉi tio jam havis iom da merkatparto kiam Mikrosofto estis jurpersekutita de Sun Microsystems. Unu ne povas nomi ion "Ĝavo", kiu havis trajtojn, kiuj ne ĉeestis en ĉiuj aliaj aferoj nomataj "Ĝavo", tiel malobeante la fundamentan promeson de Ĝavo: "skribi unufoje, kuri ien ajn". Mikrosofto perdis la kazon kaj pagis grandegan kompenson al Sun. Ĉi tio verŝajne estis la unua fojo "brakumi kaj etendi" malsukcesis.
Komence de la 2000-aj jaroj mi forlasis mian unuan profesion (advokato) kaj revenis al programado en Visual Basic 6. Nun mi decidis, ke estas tempo por mi lerni objekt-orientitan programadon, do mi devis elekti novan lingvon. La ĉefaj 2 elektoj estis Ĝavo kaj la nova C#, kiu estis la dua atako de Mikrosofto kontraŭ la Ĝavo platformo, kiam la unua ne sukcesis. La elekto tute ne estis klara, ĉar:
- Ĝavo estis bone establita kaj malfermita fonto, kion mi jam sciis sufiĉe por ŝati.
- C# estis kopio de Ĝavo, krom ĝi havis kelkajn pli bonajn lingvajn funkciojn, mankis la misfunkcioj de Ĝavo, kaj ĉiuj diris, ke la norma biblioteko estas tre bone organizita.
- Python interesis min, sed ne estis labormerkato por ĝi en Brazilo.
La dilemo estis, ĉu mi elektas kio estas teknike pli bona, aŭ ĉu mi elektas kio estas verda. Ĉi tie mi faris la malĝustan elekton (kiel McDonough) kaj lernis de ĝi.
Mi elektis C#, kaj la kialo estis, ke la Mono-projekto ekzistis ― malfermfonta efektivigo de la platformo Dot Net de Mikrosofto. Mi volis havi ĉion: la pli bonan lingvon, en malfermkoda medio.
Mia Microsoft-fazo
Do mi akiris laborpostenojn disvolvante en C#, kaj mi estis bona pri ĝi, ĉar mi estis entuziasma kiam mi lernis ĝin. Tamen, mi estis malfeliĉa, ĉar la komunumo ĉirkaŭ C# estis Mikrosofta centrita, malofte uzis iun malfermfontan bibliotekon, kaj finfine mi ne rajtis uzi Mono eĉ unufoje. Hejme mi prizorgis Linuksajn versiojn, kies nomojn vi ne memorus hodiaŭ, kaj faris miajn proprajn aferojn per Mono. Sed ĉe la laboro, neniu ŝanco. Estis multaj homoj tiam, kiuj ne komprenis la neceson de malferma fonto, kaj mi pensas, ke ili nur jarojn poste ŝanĝiĝis, kiam Mikrosofto finfine diris al ili, ke estas bone fari malferman fonton.
Male, la malfermkoda komunumo jam havis la alergion al Mikrosofto, kiun mi estis disvolvonta, do ili timis la projekton Mono. Ili timis, ke Mikrosofto elportus siajn advokatojn (eĉ se ne juste) por ataki la teknike mirindan projekton Mono. Do ĝi neniam estis akceptita.
Nun mi deziras rakonti la plej buntan epizodon de ĉi tiu tempo. Sed mi devas starigi la scenejon.
Havu paciencon kun mi en ĉi tiu sekcio
Ĉirkaŭ 2005 mi jam delonge kodis sed mi ankoraŭ ne sciis kelkajn esencajn aferojn. Mi jam faris plurajn retejojn antaŭ ol mi lernis kiel HTTP funkciis. Ĉi tio certe estis la kulpo de Mikrosofto. Visual Studio strebis kaŝi HTTP kaj igi la programiston pensi, kvazaŭ ĝi estus labortabla aplikaĵo. Vi povus disvolvi sufiĉe da aferoj sen scii kiel funkcias la reto, kaj subite kiam vi finfine devus scii... vi estus en malbona loko.
McDonough sentas honton dum li memoras la tagon kiam li demandis iun, kio estas transakcio. Ankaŭ mi memoras ĉi tiun momenton en mia vivo! Vi vidas, verŝajne ne estis mia kulpo, nek lia. Ni estis en Mikrosofta ekosistemo, kaj ĝis tiam, Mikrosofta programaro neniam estis transakcia, pri kio mi scias. Ĉi tio estis granda parto de kiel Microsoft-programaro estis tiel nefidinda. Microsoft ja zorgis pri transakcioj, sed nur de alia speco.
Mi lernis la koncepton de transakcio de Subversion / SVN.
Subversion estis la plej bona afero antaŭ git. Ĝi estis reefektivigo de CVS (la versio-kontrolsistemo kiu estis fama antaŭe) kun kelkaj funkcioj aldonitaj. Subversion estis transakcia sistemo: kiam la programisto sendis ŝiajn ŝanĝitajn dosierojn al la deponejo de Subversion, la operacio aŭ sukcesis aŭ malsukcesis entute ― ne estis maniero por ke kelkaj dosieroj estu akceptitaj de Subversion sed ke la aliaj dosieroj malsukcesus. Ĉi tio estas bona ĉar ĝi certigas, ke ĉiu versio en la deponejo ĉiam estas konsekvenca.
La rakonto pri SourceSafe
Vi scias, kio NE estis transakcia? Microsoft Visual SourceSafe, la versio-sistemo inkluzivita kun Visual Studio ĉirkaŭ 2005.
Mi laboris ĉe Unibanco, mi kodis en C# en teamo de ĉirkaŭ 20 homoj. Kaj ĉiuj luktis kun SourceSafe. Ĉiun posttagmezon iu finis funkcion, sendis la dosierojn al SourceSafe, duono de la dosieroj estis skribitaj, tiam iu reta eraro okazis, kaj la alia duono ne trapasis. Nun plia komunikado inter kliento kaj servilo estis malsukcesa, kaj la plej nova versio en la centra deponejo estis malkonsekvenca kaj verŝajne eĉ ne kompilus. Imagu trakti ĉi tiun problemon ĉiutage!
Mi scivolis pri ĉi tiu problemo ― kiun neniu ŝajnis provi vere solvi ĉe la banko. Mi trovis artikolon, kiu diris, uzi SourceSafe-n ekvivalentas al presi vian kodon, forigi la kodon de via malmola disko, bruligi ĉiujn disketojn kaj forĵeti la presitan kopion sur paperoŝranĉilon. La artikolo diris, unufoje ĉiun 6 monatojn, SourceSafe mortos kaj tute ne funkcios, la sistemadministranto funkcios la MS-ilaĵon por reakiri ĝin (jes, SourceSafe havis ĝian propran chkdsk-ilaĵon!!!), la reakiro faros malsukcesas, kaj nova SourceSafa deponejo estos starigita de ies loka kopio, do perdante la tutan historion.
Nu, ĉu vi scias, kio okazis ĉe Unibanco? Mi laboris tie dum ĉirkaŭ 5 monatoj, kaj unu tagon mi venis al laboro kaj oni diris, ke la tuta teamo ne povas labori, ni devus eliri por kafo aŭ io, ĉar estis problemo kun SourceSafe kaj ili funkciis ilo por reakiri ĝin. La teamo pli bone konis unu la alian tiun tagon. Posttagmeze, la ilo malsukcesis kaj ili staris novan SourceSafe-deponejon de ies loka kopio de la sistemo, kio signifis ke la tuta antaŭa historio estis por ĉiam perdita.
Ĉi-momente mi resumis la artikolon en la portugala, sendis la ligilon al kelkaj estroj kaj komencis montri informojn pri Subversion al miaj kolegoj. Sed ili ne estis konvinkitaj! Ili havis kelkajn problemojn:
- "Subversion" estas nomo, kiun bankoj ne ŝatas.
- Ĉiuj kutimis "kontroli" la dosierojn, kiujn ili bezonis ŝanĝi. En SourceSafe, tio signifis provizore ŝlosi la dosierojn por ke neniu alia en la teamo povu redakti ilin. Se vi bezonis ŝanĝi dosieron kaj iu alia jam laboris pri ĝi, vi devis atendi ĝis ili finiĝos. Ĉi tio estis vidita kiel io bona! La branch, diff, merge maniero de Subversion, kiu poste estis plibonigita en git kun pli bonaj kunfandaj (merge) algoritmoj, estis malfacile por ĉi tiuj homoj kompreni, kaj ili timis ĝin.
- Subversion estis malferma fonto, tial ne estis pagita subteno. Kiun ili povus voki se io malbona okazus? (Kontrastu ĉi tion kun la tuta subteno kiun MS donis al SourceSafe!)
Pri ĉi tiu lasta punkto, mi memoras frazon diritan de la projektestro. Li diris, "eĉ estas malkonvene por granda riĉa kompanio kiel Unibanco uzi malferman fonton". Mi ne povis kredi tion, kion mi aŭdis ― kompreneble estis ĝuste male, estis krime por tiaj institucioj NE nutri kaj uzi malferman fonton. Lia pensmaniero estis ofta tiam ― la ideo ke malferma fonto mortigas malgrandajn entreprenojn en programaro (kio neniam vere okazis). Ĉi tiuj homoj tre ŝatis reinventi radojn – problemon, kiun solvas nur libera programaro.
Mi insistis pri Subversion iom pli, ĉar la nova SourceSafe-deponejo misfunkciis ĉiutage same kiel la malnova. Fine okazis kunveno pri versio-kontrolo, sed mi ne estis invitita; mi pensas, ke nur unu aŭ du programistoj de la teamo ĉeestis.
Kaj nun la stampilo.
La kolego rakontis al ni kiel okazis la kunveno, pli-malpli tiel:
"Estas plibonigo, sed ĝi ne estas tio, kion vi antaŭvidas. Unue, Subversion estas for." (Mi ne povas memori precize kial, verŝajne ĉiuj "kialoj" supre.) Mi estis seniluziigita.
"Tamen", li daŭrigis, "la banko licencos de IBM ilian version-kontrolsistemon, nomitan Rational ClearCase". Mi pensis, "bone, almenaŭ ni provos ion novan, la IBM-afero ne povas esti pli malbona ol SourceSafe".
"Nur unu plia afero. Ĉar la permesilo estas multekosta, ClearCase ne estos licencita por ĉiu teamano. Fakte, la teamo daŭre uzos SourceSafe, kaj fine de ĉiu tago, unu dungito de la banko metos la plej nova versio en ClearCase."
"Vi ŝercas", ni respondis.
Mi kredas, ke jen kiel plej multaj bankoj funkcias eĉ hodiaŭ: teamoj ne rajtas solvi siajn proprajn problemojn. Mi neniam prenis tiun laboron serioze post ĉi tio. Mi tuj komencis serĉi alian laboron, kaj estis tempo lerni tiun Python-lingvon, kiu havis tiel belan kaj elegantan sintakson, estis malferma fonto, havis nenion komunan kun Microsoft, kaj finfine havis kelkajn laborojn en la brazila merkato.
Plej bona decido iam ajn. Uzante Python, nenio el C# mankis al mi.
Problemoj kun Apple
Multaj aliaj kialoj por malami Microsoft, se vi legas pri la kompanio kaj ĝiaj komercaj krimoj. Nun ni parolu pri Apple.
La ĉeesto de Apple en niaj vivoj estas karakterizita per la sekvaj praktikoj:
- sklava laboro en Ĉinio
- ili intence faras ĉion malkongrua
- ili amas DRM
- ili provis puŝi video DRM al retaj normoj
- ili provis puŝi siajn proprajn patentitajn kodekojn al retaj normoj
- Safaro estas nuntempe la plej malkongrua retumilo (ĝi vere estas la nova Interreta Esplorilo), kostante al ĉiuj amasojn da disvolva tempo
- ili havas malbonan skemon por igi ĉiun programiston aĉeti Mac por evoluigi ajnan retejon; tio estas, Safaro ne donos al vi ajnan sencimigan informon krom se vi uzas la evoluilojn de Apple en Mac
- Ili havas malbonan skemon por malhelpi realan konkuron al Safaro en siaj platformoj, kiu konsistas el regulo, kiu diras, ke retumilo ne povas esti ofertita en la app-vendejo krom se ĝi uzas por bildi Safari-komponenton
- kiel rezulto ĉiuj retumiloj sur Apple aparatoj estas nur haŭtoj super Safaro
- Apple ankaŭ inventis la telefonon sen kapaŭskultilo
- La aŭdiloj de Apple estas teknike malbonaj kaj multekostaj
- Apple ne lasas homojn ĝisdatigi aŭ servi rompitajn telefonojn aŭ komputilojn, ili elvojas por fari ĉion malebla, malfacila aŭ multekosta por ke oni ne povu ripari la aferojn ― kaj tio originis la movadon Rajto al Riparo.
La nova fiulo: Guglo
Guglo, dum longa tempo, estis la sola teknika giganto kun serioza "ne estu malbona" konduto, sed tio estas klare historio. Nun vi estas la produkto, vi ne havas privatecon, ili scias precize kie vi estas en la mondo, vi ne povas malhelpi ĉi tion okazi, ili foriras ne por solvi viajn problemojn sed por mortigi AdBlock kaj igi vin pagi, la reklamoj estas pli multnombraj ol iam ajn, Guglo-projektoj ofte estas mortigitaj kaj uzantoj restas sen elektoj, ili faris la evoluon de novaj, malgrandaj retumiloj neebla per multobligo de ekstreme kompleksaj retaj normoj (kiel la normo Web Component kiu havas teruran API), kaj finfine, sed plej grave, ili atakas la malfermitan reton mem puŝante DRM por retejoj al retumiloj. Ili ne plu opinias, ke enhavo devus esti malfermita (kiu estis ilia opinio kiam ili estis serĉilo) ― nun kiam ili havas la tutan enhavon, ili opinias, ke ĝi estu fermita, tre fermita.
La rompo de la reto venas, bedaŭrinde. Avideco ne aŭskultas moralajn argumentojn. Mozilo estas la sola kiu ankoraŭ meritas iom da respekto.
La video de McDonough estas de antaŭ 7 monatoj; la perfido de Guglo (kreado de DRM por retejoj), kiu estas la fina akvoguto por mi, ankoraŭ ne okazis, sed li jam diris, "Google sendube sekvas". Nun mi rigardas eblojn por sengugli mian vivon, inkluzive de retpoŝto, poŝtelefonoj, serĉiloj kaj videoplatformoj.
Nextcloud estas la ŝlosilo por anstataŭigi Google-servaĵojn per io malfermita fonto kaj mem-gastigita.
Konkludo
Kiel McDonough, mi scivolas kiel eblas, ke homoj restu ĉe ĉi tiuj kompanioj, daŭre fortigas ilin, nur por oportuno, anstataŭ subteni alternativon pli frue. La prezo estas alta, kaj estos eĉ pli alta.
McDonough tute pravas: Malfermaj platformoj ĉiam venkos ĉe la fino. Estu la ŝanĝo kaj foriru.
Mi sekvis NixOS je certa distanco. Mi vidas, ke McDonough nun havas pli ol 50 filmetojn pri NixOS. Mi sentas kiel profetaĵo pri tio, kion mi faros poste...