Mi scias, ke en Varsovio estas ulica Ludwika Zamenhofa kaj ulica Esperanto. Indaj omaĝoj. Sed mi pensas, ke ne estas multe por vidi en tiuj lokoj.

Ĉi-semajne mi turismis en Varsovio kun amiko. Inter multaj konversaciaj temoj, mi menciis, ke ĉi-jare mi lernis Esperanton. Mi klarigis, ke mi daŭre lernas ĝin ĉar mi ŝatas la decidojn en la dezajno de la lingvo. Mi diris al li, ke oni lernas Esperanton per 180 horoj da studado, la anglan per 900 horoj da studado, la pola per 2000 horoj da studado, kaj la ĉina per 2400 horoj da studado.

Ne unu minuton poste, ni vidis buson nomatan "Esperanto" sur la strato. Simpla normala ĉiutaga buso, verŝajne kondukanta pasaĝerojn al la Esperanto-strato. Irante en la direkto de la malnova urbocentro.

Profesiuloj pri merkatado scias, ke kutime necesas 3 aŭ pli da impresoj por fari vendon. Konsumanto aĉetos la aferon post kiam li vidis ĝin kelkajn fojojn. Tiusence, la forpaso de la buso certe helpis min ne aspekti freneza nerdo al mia amiko, kiu neniam antaŭe aŭdis pri Esperanto.

Poste mi rakontis tion al mia edzino, kiu ne studus Esperanton. Ŝi ŝercis:

— Kaj tiam vi signalis, ke la buso haltu, kaj kiam la pordo malfermiĝis, vi kantis al la ŝoforo: "Buenan diooooon!"... kaj li turnis sin al la alia flanko, murmurante "Mi ĵuras, ĉi tiu buslinio estas la plej malbona en la lando"...

"Buenan diooooon"! Mi ne kapablas elpensi ĉi tiun aĉon! (Ĝusta Esperanto estus "Bonan tagon".)

Kaj ŝi eĉ pravas, ĉar mi elektas miajn vestaĵojn kiel 4-jara knabo, kiu vidas ĉemizon kun dinosaŭro sur ĝi kaj sentas, ke ĝi reprezentas lin. En Varsovio mi aĉetis Chopin-markitan ĉapon kaj Chopin-markitan t-ĉemizon. Mi certe ankaŭ surportus vestaĵojn pri Esperanto, se mi trovus ilin. Mirinda estas vivi en escepta tempo, kiam oni ne devas kaŝi siajn frenezetojn!

⁂

Sed la rakonto ne finiĝis. Mia amiko kaj mi trovis urban bicikloskemon kaj mi atentigis:

— Ĉu vi vidas tiun vorton, "Veturilo", la nomon de la reto de urbaj bicikloj?

— Jes.

— Tio estas Esperanta vorto. Ĝi signifas "ilo por veturi".

— Kial la nomo estas en Esperanto?

— Antaŭ pli ol jardeko, kiam la urba bicikloreto estis efektivigita, la urbo permesis al civitanoj sugesti nomojn, kaj poste voĉdoni. La ĉefo de la Pola Esperanto-Junularo proponis "Veturilo". Simplaj varsovianoj ne zorgis pri la aferon, kiu ne gravis; kaj li organizis ke la monda Esperanto-komunumon en la interreto voĉdonu por ĝi. Do venkis "Veturilo".

Poste, kiam ni tagmanĝis, mi volis kolaon, sed mendis Mirinda anstataŭe...

⁂

Ĉiuokaze, ne estas vero, ke la Esperanto-buso pasis. Ni povas eniri ĝin iam ajn. Dum la dolaro kaj la angla lingvo flankeniras por ke la eno kaj la ĉina lingvo pasu, la mondo farus al si grandegan favoron konsentante uzi Esperanton anstataŭe, ŝparante miliardojn da dolaroj kaj bilionojn da horoj da studado.

Alivorte, pli aŭ malpli frue, ekonomio garantias la finan venkon.

En 1986, Ĉinio eĉ proponis, ke Esperanto fariĝu la ĉefa lingvo en Unuiĝintaj Nacioj.

Vi ne plu diru ke "muziko estas matematiko".

Kiom da matematiko estis necesa por disvolvi muzikinstrumentojn? Tro multe da matematiko, certe! Tamen, same okazis al kuirilaro, sed neniu diras, ke "kuirado estas matematiko", aŭ ke "veturado de veturilo estas matematiko"...

Matematiko estas la bazo de ĉiuj sciencoj. Ne ekzistas eĉ unu fako, kiu havas nenion komunan kun matematiko. Ĉio bezonas nombrojn.

Kiam homoj pensas pri la informo en muziko, ili esence pensas:

1. Ke la muziko trairas tempon, kaj tempo estas mezurata, kaj la plej multaj muzikoj uzas frakciojn por specifi daŭrojn -- muzika partituro estas ĉefe funkcio de notoj laŭlonge de la tempo, kaj la daŭro de ĉiuj notoj estas planita.
2. Ke samtempe, la melodiaj linioj aŭ muzikaj eventoj (tonoj) havas alian dimension: tonalto, kie estas specifata per la muzika skalo (do re mi fa sol la ti) aŭ mezurata en Herz; ekzemple, la plej kutima tonalto de La estas 440 Hz.
3. Ke tonoj samtempe havas intensecon, kio signifas, ke sonoj povas esti akcentataj aŭ kaŝitaj, kaj ili povas esti laŭtaj aŭ mildaj. Intenseco ankaŭ estas dinamika, signifante ke ununura daŭra noto de latuna instrumento povas, ekzemple, komenci kun akcento, fali rapide al malalta volumeno, kaj poste kreski denove pli laŭta.
4. Ke tonoj samtempe esprimas tembron (sonkoloro), kiu ĉefe dependas de la muzikilo kaj de la ludmaniero. Tembro estas la plej mistera kaj malfacile mezurebla parametro, sed scienco ja mezuras ĝin... uzante matematikon.

Resume, muzikaj notoj havas 4 parametroj: daŭro, tonalto, intenseco kaj sonkoloro. Rezulte ankaŭ muziko havas pli-malpli la samajn 4 parametrojn. Dum muzikaĵo, ĉi tiuj parametroj ŝanĝiĝas sendepende kaj konstante, kaj grandaj komponistoj establas rilatojn inter ĉiuj ĉi partoj.

Sed, ĝis nun, ni nur konkludis, ke la tekniko de muziko dependas de nombroj. Jes, la bazaj parametroj povas esti esprimitaj en nombroj -- oni nombras la taktojn dum oni ludas: 1, 2, 3, 4, ripetu. Tamen, la mesaĝo ĉiam estas homa kaj ofte okazas en alia dimensio.

Hmm, tre matematika komponisto... Ĉu vi iam aŭdis la muzikon de Iannis Xenakis? Li disvolvis komponteknikon nomatan stokasta muziko, kiu uzas statistikon dum komponado. Li estis arkitekto kaj li skribis komputilajn programojn por helpi lin komponi. En ĉi tiu kazo, mi konsentas, ke tiu muziko havas profundan rilaton al matematiko. Sed la komputilo ne komponis -- Xenakis komponis.

Cetere, verŝajne vi neniam aŭdis lian muzikon; verŝajne vi eĉ malŝatas tian muzikan modernismon; do, kial vi ripetas, ke muziko estas matematiko?

Plej multaj komponistoj ne estas matematikistoj, ili faras malmulte pli ol kalkuli: "1 2 3 1 2 3"...

Ni prenu alian ekzemplon: Frédéric Chopin. La unua afero pri Chopin estas ke lia muziko enhavas sentimentalecon, kiu estas nekontestebla. Iu Chopin-muziko transdonas la malgajon de malgajo, la malfeliĉon de malfeliĉo. Por atingi sian unikan nostalgian efikon, li evoluigis kombinaĵon de ekzistantaj teknikoj (kiel ekzemple pedaltonoj, kromataj harmoniaj ŝanĝoj ktp.). Sed eĉ en la feliĉaj pecoj estas tenero, kiu ne troviĝas ĉe aliaj komponistoj.

El la kvar parametroj, la kvara estas rekta en Chopin: li ĉiam uzas la pianon. La tembro nur ekzistas en Chopin tiom kiom la piano estas simfonia instrumento, kapabla je esprimrimedo komparebla al tuta orkestro, sub nur du manoj.

Chopin ŝatis 4 aferojn: la pianon, Bach, operon, kaj polan muzikon.

1. Chopin evoluigis pianoteknikon, sed li ne faris ĝin sola. Li konis tiamajn pianistojn kaj komponistojn, kiuj ankaŭ postulis pli ol Beethoven en siaj partituroj.
2. De Bach li lernis, ke la graco en la arto de muziko kuŝas en samtempeco -- samtempaj melodioj kaj la rilatoj inter ili. La polifonio de la plej brilaj komponistoj ofte estas pli kompleksa. Tio estas la kazo en Chopin. Sed kelkaj aŭskultantoj ne rimarkas tion -- ili ne konscias pri la kompleksa polifonio kaŝita en la "akompano" de Chopin, kiu estas multe pli ol akompano. Bona pianisto klarigos ĉi tiun polifonion kaj bona aŭskultanto scios aŭdi ĝin.
3. El opero li amis belkantajn melodiojn. Li precipe aprezis Vincenzo Bellini. Opero estas la plej populara ĝenro de klasika muziko. Se polifonio estas kompleksa aspekto, la melodio de la opero estas tio, kion ĉiu muzikamanto ja komprenas. Ĝi estas tio, kion la homoj forportas per siaj fajfoj. Melodioj sur la piano devas esti luditaj donante la impreson de kantisto kantanta. Kaj la aŭskultanto povas helpi per sia imago...
4. Chopin estis naciisto kaj en ekzilo li esprimis sian amon al sia lando en siaj polonezoj kaj mazurkoj, kiuj fakte enhavas influon de la pola muziko, kiun li aŭdis kiel infano.

La ritmo en Chopin estas komplete nova. Se vi pensas, ke tempo en muziko estas ekzata kiel en matematiko, vi tute eraras. La pianisto devas ludi romantikan muzikon kiel homo, ne kiel roboto. Tiu signifas, ke la tempo ne estas kiel skribita, estas divinata de la interpretisto, kiu plirapidigas la komencojn de frazoj kaj plilongigas la finojn de frazoj, kreante ian spiradon inter frazoj, pri kiu matematiko ne havas ideon. Ritme simpla ludado de Chopin fariĝas malvera kaj neeltenebla.

Kaj tiel ludi Chopin povas fariĝi nacia sporto. Sed ili ludas Chopin de memoro. Supre mi diris, ke oni povas kalkuli la taktojn kiam oni ludas muzikon. Nu, eble pianistoj iom kalkulis dum lernado de certaj pecoj... sed ne kiam ili fine ludas ĝin vive de memoro. En tiu momento, ili certigas, ke ili estas liberaj. Do la notitaj daŭroj estas ekzemplo de la ŝtupetaro de Wittgenstein. Vi uzas la ŝtupetaron por grimpi la muron, sed kiam vi supreniras tien, vi forĵetas la ŝtupetaron kaj fariĝas libera.

En la mazurkoj tre gravas la tempo. La ritmo de la mazurkoj estas stranga ĉar la dua pulso de la takto ofte daŭras iom pli longe, kreante senton de lamado. Fakte, ŝanĝoj en la ritmo estas multe pli kompleksaj ol la ĝeneraligo, kiun mi ĵus faris. Kaj ĉi tio ne estas skribita en la partituroj. Eĉ la valsoj de Chopin bezonas ĉi tiun liberecon en la ritmo, kiu estas pli granda ol en aliaj valsoj. Se vi donus la partituron al eksterterano, li ne komprenus ĝin. Muziko estas parto de kultura kaj homa tradicio.

Kiom da fojoj mi bezonis ciferojn por paroli pri la plej bazaj trajtoj de la arto de Chopin? Nulo. Li kalkulis trioletojn kaj poliritmojn kiel ĉiu komponisto, sed tio ne gravas. En kaj Xenakis kaj Chopin, kion ni perceptas estas du tre malsamaj mondkonceptoj. Tekniko estas tre grava en arto kaj ĝi ĉiam dependas de matematiko, sed mondrigardo estas same grava. Ili havis sincerajn, novajn, gravajn aferojn por diri.

La enhavo de muziko certe ne estas matematiko. La lingvoj de muziko estas multaj, do ili ankaŭ ne povas esti matematikaj. Ili estas sistemoj evoluigitaj de tutaj popoloj, ĉiu en malsama kulturo.

La arto de muziko estas la plej profunda kaj potenca arto kiun la homo elpensis. Ĝi povas rakonti abstraktajn rakontojn kaj kortuŝos vin ĝis larmoj, se vi atentos ĝin. Chopin kaj Xenakis estas du el la plej novigaj komponistoj. La tuta dua sonato de Chopin parolas pri morto, sen unu vorton, kompreneble. La kvina Polonezo estas koŝmaro de milito kun idilio en la mezo por doni al vi senton pri tio, kion la milito detruis. Sed estante abstrakta rakonto, eble ĝi estas io analoga al milito. La Berceuse estas hipnote tenera, kun ornamoj kiel artfajraĵo el petaloj... Mi povus daŭrigi. Se eksterterano demandus al mi, kiel estas esti homo, mi donus al li la registradojn de Chopin de Adam Harasiewicz.

Kiam vi diras, ke "muziko estas matematiko", mi scivolas, ĉu vi havis ian kontakton kun ĝia vera potenco. Vi aŭskultu komponistojn kiuj kreas tutajn mondojn, kiel Mahler...

Muziko estas la plej okulfrapa atesto pri la krea libereco de homo; en tiu urbo, matematiko estas nur unu el la brikoj.

Se via Linuksa distribuo uzas tradician pakaĵadministrilon (ekzemple, apt en Debian Linukso), vi povas fari sekurecan revizion ekzamenante la fontkodon de ĉiu pako instalita en via sistemo. Ĉi tio daŭros longege, ĉar ĝi estas tiom da pakoj... Sed almenaŭ vi revizios ĉiun programbibliotekon nur unufoje. Tio estas ĉar en tia sistemo ĉiu biblioteko estas trovita nur unufoje, kaj reuzata en ĉiuj aplikaĵoj kiuj bezonas tiun bibliotekon per dinamika ligo. (Ne absolute tiel, sed superforte.)

Ĉu vi scias, kio estas multe pli malbona? Uzi pakaĵadministrilon en kiu ĉiu pakita aplikaĵo venas kun ĉiuj siaj dependecoj. Tiam pakaĵoj estas multe pli grandaj, kaj ili ripetas la samajn bibliotekojn, anstataŭ reuzi tiun jam instalitan en via baza sistemo.

Hodiaŭ neniu plu havas paciencon por la sendanka laboro de pakado de programaro, do ili serĉas ŝparvojojn.

Bildaj pakoj

En ĉi tiu artikolo, mi uzos la esprimon "bildaj pakoj" por rilati al ĉi tiu speco de pakaĵoj - ampleksante snaps, flatpaks, appimages kaj docker images.

La programlingvoj Go kaj Rust, kiam ili estis novaj, ne povis dinamike ligi bibliotekojn; ili nur funkciis kompilante la bibliotekojn rekte en la binaron de la apo. Ĉi tio damaĝas sekurecon en du manieroj: 1) kiam cimkorekto en biblioteko estas distribuita, la programo daŭre uzas la bugversion kiu estis statike ligita; 2) estas pli malfacile scii, kiu versio de biblioteko estas uzata de la aplikaĵo duuma.

Kiam unue aperis Linuksaj distribuoj, ĉiuj konsciis, ke sekureco estas ilia ĉefa laboro. Se vi elektas ruli Debian, vi sciis, ke via programaro estis validigita, vi povus fidi ĝin. Debian stabila malrapidas ĝisdatigi programaron, vi daŭre rulas la saman version de programo dum longa tempo, kio donas al vi pli da kialo por fidi tiun version. Ĉi tio estas bona, sed ĝi enuigas la nuntempajn spektantarojn, ĉar ilia konsumismo ankaŭ manifestas sin en konstante ĝisdatiganta la labortablan medion kaj vidante la plej novajn sencelajn ikonojn, bildojn kaj animaciojn. En la 2000-aj jaroj Linukso kreskis preter grupoj da homoj sufiĉe prudentaj por aprezi liberan programaron. Multaj kreintoj de malfermkoda programaro hodiaŭ uzas komputilojn de Apple anstataŭ Linukso, permesante al Apple spioni ilin konstante. Tio estas ĉar la prioritatoj de ĉi tiuj homoj mem eraras.

Specifaj Snap-aferoj

Eĉ en ĉi tiu malbona spirito, la komunumo protestis kontraŭ la insisto de Ubuntu antaŭenpuŝi siajn Snap-pakaĵojn. Jen listo de la problemoj kun Snap, de malplej gravaj ĝis plej gravaj:

1. Canonical estis kritikita ĉar la servilo de la pakaĵvendejo estas proprieta programaro. (Mi ne certas, ke iu ajn alia volus reuzi tiun malantaŭan finon ĉiukaze.)
2. Canonical devigas snap pakojn al ĉiuj Ubuntu-uzantoj; Firefox sur Ubuntu estas nuntempe pako snap.
3. Snap-pakaĵo estas pli malrapida por komenci – kaj mi ne scias ĉu tio povas esti helpita, ĉar la plej multaj snap-pakaĵoj devus ruliĝi en sablokesto (kiu rezultigas pli bonan sekurecon) kaj ĝi estas multe pli granda programara blobo kun ĉiuj ĝiaj dependecoj.
4. Ĉiuj snap-pakoj estas multe pli grandaj ĉar ili enhavas ĉiujn siajn dependecojn, malŝparante diskospacon.
5. Canonical decidis, ke la ĝisdatigo de snap-pakoj estu tute aŭtomata; en ĉi tiu paŝo ili forgesas, kiu estas ilia spektantaro, ĉar Linukso-uzantoj volas esti en kontrolo de sia komputilo, anstataŭ kontrolita de grandaj teknologiaj kompanioj.
6. Kiel ni vidis antaŭe, snap-pako enhavas ĉiujn ĝiajn dependecojn, igante sekurecan revizion koŝmaro.

Ĉi tiuj aferoj estu rezervitaj nur por nepopulara programaro. Ekzemple, vi volas frue adopti ion, kio ne estis pakita; la programisto, kvankam ŝi ne havas tempon por paki, faris snap-pakaĵon; do vi kontraŭvole uzas ĝin (fidante la programiston).

Linux Mint estas distribuo bazita sur Ubuntu, sed ili vidis la skribaĵon sur la muro kaj decidis ne akcepti snap-pakojn. Ĉi tio signifas, ke ili faras la laboron, kiun Ubuntu nun rifuzas fari: ĝuste meti Firefox en pakaĵon .deb. Plue, Mint komencis labori pri "Debian Edition", kiu ne baziĝas sur Ubuntu. Mint rimarkas, ke por Linukso-distribuo ekuzi bildpakaĵojn anstataŭ sia tradicia pakadministranto... estas terure misgvidita kaj havos sekvojn.

Kaj nur 3 horojn post kiam mi skribis "havos sekvojn"... Mi kaptis vorton pri la okazaĵo:

La okazaĵo

Jutuba filmeto: Malware malkovrita en la Snap-butiko de Ubuntu

Esence, iu fiulo alŝutis snap-pakon de kripta programo, kiu petis uzantojn pri ilia plej baza kripta pasvorto, kaj iu perdis dek mil dolaroj tiamaniere. La programo teorie eble ankaŭ legis hejmajn dosierojn de la uzantoj. Canonical instigas ĉiujn kaj iun ajn fari snap-pakaĵojn kaj alŝuti ilin al sia snap-vendejo, sen sekureca revizio.

Preskaŭ ĉiuj pensas, ke snap-pakaĵoj estas sablokestaj (sen aliro al kelkaj aferoj en la sistemo), sed la vero estas, sablokesto estas ĝuste rekomendita, sed povas esti malŝaltita de la persono faranta la pakaĵon. Tiel la video ricevas komentojn kiel ĉi tio:

@act.13.41: La tuta kialo, kiun ni ricevis por havi snap-pakoj disponeblaj NUR en la Ubuntu Snap Store, estis la sekureco de la programoj. Ĉi tio neniam devus okazi. Kaj tio estas fina.

Ĉu tio povus okazi en apt?

Ĉu ankaŭ malware povus invadi tradician pakaĵadministradon? Jen 2 bonegaj komentoj pri tio, el la supra video:

de @skynetisreal: Tipa kazo de kvalito aŭ kvanto. Tiuj estas elektoj, kiujn vi devas fari kiel deponejo prizorganto.

de @knghtbrd: Jes, snap estas malbona, sed ĉi tiu problemo povus ekzisti sur flatpak, ĝi okazis en PPA-oj, okazis en hazardaj speguloj de fidindaj distribuoj... Ĝi eĉ povus okazi en la AUR se iu estus singarda aŭ lerta. Vi devas esti damne singarda, kie vi ricevas vian programaron.

La ĉefa deponejo de Debian neniam havis malware en ĝi – sed hazarda spegulo estis hakita kaj ricevis iom da malware en ĝi unufoje. Tial ĉiu Debian-pakaĵo estas kriptografie subskribita kiam ĝi estas alŝutita. Post kiam alŝutite, la subskribo estas kontrolita, protokoloj registras kiu ŝlosilo subskribis ĝin, la pakaĵo estas haŝita kaj la haŝo estas stokita en la paklisto. La listo kaj eldondosiero tiam estas subskribitaj por malhelpi mistraktadon de deponejoj. Por meti malbon-programon en la pakaĵaron de Debiano postulas ricevi ies GPG-ŝlosilon aŭ ricevi malican programon per la procezo de Debian, kiu inkluzivas kontroli la veran nomon de ies sur registara identigilo.

Do Debian ne estas sekura kontraŭ ĉi tia afero... sed ĝi prenis raciajn paŝojn. Se vi aldonas triajn deponejojn, vi malfortigas tiun sekurecon. Do kiel mi diris: Homoj devas esti singardaj de kie ili ricevas sian programaron.

Estingi la fajron

La respondo de Canonical al la okazaĵo (kovrita en la video) estas ke kriptaj programoj (kaj nur kriptaj programoj) nun provizore trapasos revizion. Ĉi tio faras nenion pri ĉiuj aliaj programoj, kiuj povas legi viajn hejmajn dosierojn.

Plue, komento de @alexhajnal107 tekstas: 06:04 La nova sistemo kiel priskribita ankoraŭ estas misa. Kun ilia nova sistemo oni povus alŝuti pirata sed senŝanĝan version de programo. Ĉar ĝi ne estas malica ĝi povas bone trapasi revizion. Atendu ĝis ĝi ricevas amason da instaloj kaj alŝutu malican ĝisdatigon. Laŭ ilia deklarita politiko ĉi tio ne estos reviziita.

Tamen, la politiko de Ubuntu devigi ĝisdatigitajn versiojn al uzantoj efektive helpas ilin forigi la malbonan-programon de la komputiloj de homoj. Ili simple kreis pli novan version de la tuŝitaj pakaĵoj sen programaro ene. Kiom mi povas diri, estas alie neniu mekanismo por eĉ lasi homojn scii kio okazas.

Je 9 minutoj en la video ni ekscias, ke tre simila okazaĵo jam okazis en majo 2018. Tio estas antaŭ 5 jaroj - en la tuta tempo, praktikoj ŝajnas tute ne pliboniĝi. Kial ili pliboniĝus ĉi-foje?

Lecionoj por ni

Ĉi tiu okazaĵo estas la fina ŝtono sur la tombo de la projekto Snap de Ubuntu, kiom mi koncernas. Kiu uzas bildpakaĵojn, nun provu kompreni la riskojn kaj serĉu alternativojn. Sed la ĝenerala publiko hodiaŭ ial malfacilas lerni certajn lecionojn.

Fido je la programarpakaĵoj estas la plej grava servo provizita de Linukso-distribuo. Forgesante ĉi tion, Ubuntu meritas ilian daŭran perdon de publiko - kaj ekzistas multaj alternativoj tie.

Kiam mi uzas Linukson, nomu min freneza, sed... mi volas, ke pluraj homoj aprobis la programaron, kiun mi funkcias. Pro tio verŝajne la sendanka laboro de pakado de programaro meritas eĉ pli da dankon ol ni sciis.

Ĉi tio okazis al Snap, sed mi ne scias ĉu FlatHub havas malsamajn politikojn.

Kaj se vi uzas proprietan programaron, vi finfine ne havas ideon, kion ĝi faras en via maŝino, ĉar neniu havas aliron al la fontkodo, kaj la binaroj estas neesploreblaj. Neniu granda teknologia kompanio nuntempe meritas esti fidinda, ĉar ili ĉiuj spionas nin kaj kolektas faktojn pri ni kaj konstruas eĉ ombrajn profilojn pri ni. Se mi sonas paranoja al vi, pardonu, la vero estas ke vi estas nur malbone informita.

Nix kiel bona komplemento

La ĉefa problemo kun bildpakaĵoj estas sekureco; estas multe pli facile revizii kaj fidi ununuran pakaĵmanaĝeron en kiu dependecoj estas reuzataj. Kiam dependecoj estas inkluzivitaj en bildo, vi devas fidi la bildon, do la laboro ne nur triobligas aŭ kvarobligas, ne -- la laboro estas multobligita per la nombro da bildoj kiujn vi uzas, oble la nombro da versioj en tempo.

Jen unu el la kialoj, kial mi uzas nix kiel duan pakaĵadministrilon por kompletigi la ĉefan en distribuo. Mi povas trovi ĉiujn programojn, kiujn mi bezonas en aŭ apt aŭ nix. Tio estas pli bona ol uzi bildpakaĵojn.

NixOS estas Linukso-distribuo bazita sur la pakaĵmanaĝero nix, kiu havas bonegajn funkciojn por sekurecaj revizioj. nix generas identigon (vere haŝon) por ĉiu pakaĵo, surbaze de ĝia fontkodo interalie. Se la binaro ne plu disponeblas ial, nix konas la git commit kaj la adreson de kiu akiri la fontkodon, kaj tuj elŝutas la fontkodon, kompilu ĝin sur via maŝino kaj produktas la bit-post-bitan ĝustan saman pakon, kies binaro estis perdita en tempo. Mi ankoraŭ lernas pri nix sed mi vetus, ke ĝi estas la plej bona afero por sekureco.

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:

1. sklava laboro en Ĉinio
2. ili intence faras ĉion malkongrua
3. ili amas DRM
4. ili provis puŝi video DRM al retaj normoj
5. ili provis puŝi siajn proprajn patentitajn kodekojn al retaj normoj
6. Safaro estas nuntempe la plej malkongrua retumilo (ĝi vere estas la nova Interreta Esplorilo), kostante al ĉiuj amasojn da disvolva tempo
7. 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
8. 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
9. kiel rezulto ĉiuj retumiloj sur Apple aparatoj estas nur haŭtoj super Safaro
10. Apple ankaŭ inventis la telefonon sen kapaŭskultilo
11. La aŭdiloj de Apple estas teknike malbonaj kaj multekostaj
12. 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...