Planeta

Més de 200 mecenes i 50 donacions en 14 dies La resposta a la nostra campanya a l’Aixeta continua sent espectacular. Només dues setmanes després de llançar la crida, ja hem superat la xifra dels 200 mecenes i hem rebut més de 50 donacions puntuals. Volem expressar un agraïment profund a totes les persones que […]

L'entrada 200 mecenes en dues setmanes: gràcies per respondre al canvi de model de Softcatalà! ha aparegut primer a Softcatalà.

Caliu celebra el Dia de la Llibertat del Programari el dissabte 19 de setembre a l'espai jove La Fontana de Barcelona amb xerrades relacionades amb el programari lliure.

Dades de l'esdeveniment:

Lloc: Espai Jove La Fontana

Gran de Gràcia, 190-192

08012 Barcelona

Metro Línia 3 Fontana, FGC Gràcia

Data: 19 de setembre

Xerrades:

Cartell: https://gitlab.com/caliu-cat/www.caliu.cat/-/blob/main/content/post/cartell_dlp2026v0.png

Un inici de campanya molt prometedor Només han passat quatre dies des que vam anunciar la nostra campanya a l’Aixeta, i la resposta no podia haver sigut més bona. En menys de 24 hores vam superar els 40 mecenes, i en només tres dies, més de 100 persones s’han sumat a aquesta iniciativa. Volem expressar […]

L'entrada Gràcies! Més de 100 mecenes en els primers dies de la campanya a l’Aixeta ha aparegut primer a Softcatalà.

Fa uns anys que uso una instal·lació pròpia per llegir feeds, una combinació de Tiny Tiny RSS i FeedMe.

Faig servir Tiny Tiny RSS (tt-rss) com agregador de feeds, i Feedme com aplicació al mòbil i a e-reader per llegir els feeds més còmodament1: així tinc un únic lloc on capturar-los i diferents punts d’accés / lectura sincronitzats (o sigui, el que et fa un Inoreader, per exemple, però autohostatjat i sense anuncis o quotes).

Empro una app per llegir els feeds en format mòbil/tableta perquè la versió mòbil del tt-rss no m’agradava: poc usable i adaptable i poc còmoda. Feedme, en canvi s’adapta perfectament a diferents tamanys de pantalla, és còmode, té diferents opcions de configuració… molt més fàcil d’usar.

Problema: la versió que usaba de tt-rss ja era molt vella, no tenia suport, estava sobre una versió de php que ja era molt vella també i la nova no podía desplegar-la sense embarcar-me en un desplegament a mà. Poques ganes de tanta feina i mai trobava el moment… fins que fent proves fa uns dies em vaig carregar la instal·lació que tenia posada… coses que passen..

Així que ara ja no en tenia cap, de problema, per provar feedreaders, i això és el que he fet. Després d’unes quantes cerques i proves m’he decidit per FreshRSS, amb les mateixes característiques que tt-rss, però actualitzat, amb una comunitat més gran i al dia (val, i el meu hosting el tenia en les aplicacions auto-instal·lables, un gran punt a favor, aquest).

L’arquitectura, a més, és la mateixa: un agregador on-line autohostatjat, i Feedme com lector en diferents llocs.

• Importar la llistal opml que haurem guardat prèviament de l’anterior feedreader (important!)
• Afegir un plugin per llegir els articles al propi FreshRSS en un panell lateral (per defecte, FreshRSS no porta lectura lateral). N’he trobat dos:
  • xExtension-ThreePanesView: l’escollit, panell lateral perfectament integrat amb la llista i el tema que s’usi.
  • xExtension-ThreePaneReader: no m’ha agradat busca semblar inoreader i pel meu gust deixa la interfícia molt fosca i compacta.
• Afegir un cron al sistema per llegir cada 12 hores i així no haver de refrescar manualment:

Molt fàcil:

• Eliminar l’antic usuari, el que tenia amb tt-rss.
  • Se n’ha de crear un de nou perquè només pots apuntar a un servidor alhora.
• Apuntar a la API del propi servidor (instruccions a la pròpia instal·lació) i usant l’usuari definit per a la API.
• Fer el primer refresc de dades

1. FeedMe permet funcionar com un lector en solitari, important opml o afegint feeds directament, jo prefereixo un punt únic per mantenir coordinació entre equips. ↩︎

Un canvi de model per continuar sent lliures i independents Des de la nostra fundació el 1998, a Softcatalà hem tingut una màxima innegociable: la independència econòmica i funcional. Per garantir-la, hem mantingut sempre una política molt clara: no hem acceptat mai cap mena de subvenció pública ni finançament institucional. Durant tots aquests anys, hem […]

L'entrada Llancem una campanya a l’Aixeta per a garantir el futur dels nostres serveis ha aparegut primer a Softcatalà.

Fa uns dies vaig activar de nou els comentaris al blog, en un article anterior explico el perquè de la reactivació.

Decidit a reactivar-los, el repte era quin sistema de comentaris utilitzar, que havia de ser independent de la pàgina, un sistema a banda.

Aquesta pàgina és un lloc estàtic, d’html pur, sense cap base de dades al darrere. Bàsicament, és un conjunt de fitxers de text, cadascun amb un article, que els passo per un programa que genera la web i la publica (per a qui hi estigui interessat, hi ha una mica més de detall tècnic.)

Un sistema de comentaris és un sistema, per contra, dinàmic, on s’entra el comentari, s’ha de guardar en algun lloc i s’ha de mostrar en la mateixa pàgina.

Cal juntar dos mons diferents en un de sol, això és difícil. Per tant, cal buscar un subsistema que pugui cridar des de la pàgina, i “sembli” integrat dins del blog.

Vaig definir uns requisits, no tots tècnics, alguns son més de principis, lligats a una idea de web oberta:

• El sistema ha de ser autohostatjat.
• Sense dockerització per desplegar, via ftp (el meu hosting no permet dockerització.
• No ha de tenir dependència de cap base de dades.
• La integració ha de ser fàcil, sense gaire programació ni retocs en el codi i plantillatge de Hugo.
• Vull un sistema de text basat en fitxers, per poder recuperar els comentaris sense dependre de software extern.
• No vull sistemes de registre depenents de tercers, que obliguin possibles comentadors a registrar-se: els comentaris han de poder ser anònims.
• Possibilitat de correu d’informació si hi ha resposta (reply) a un comentari.

Amb això en ment vaig fer una mica de recerca i vaig trobar alguns sistemes potencials, que llisto aquí sota. Tots estan buscats per tenir una integració fàcil amb Hugo, de sistemes n’hi ha molts més.

Els enllaços de sota son a articles que em van semblar interessants, no al propi sistema, i els comentaris que faig son en relació als meus requeriments, cada una de les alternatives és interessant en si mateixa.

• disqus: tot un clàssic, però depens de tercers, les dades no son teves.
• giscus (1, 2): idea, interessant… però requereix registre amb github, les dades no son teves.
• cusdis: alternativa a disqus, autohostatjable, opensource… però requereix compte a cusdis.
• comentario: No requereix registre, sembla… però la instal·lació és docker. Busco autohostatjat… més senzill.
• zooment: Pinta bé, però no veig on i com guarda les dades.
• Comentaris via bluesky: requereix registre amb Bluesky, les dades no son teves.
• Comentaris via Mastodon: requereix tenir compte amb Mastodon (qualsevol servidor) i una gestió manual del link (que amb Hugo costaria de muntar)

Aquestes sistemes, però, no complien amb alguna de les premises anteriors: o bé no permetien autohostatjament, o era difícil d’instal·lar si no tens docker, o usaven bases de dades o demanaven inscripció… o unes quantes alhora.

Finalment vaig trobar HashOver, un projecte de Jakob Barkdull on implementa un sistema de comentaris basat totalment en fitxers de text, en aquest cas, en format xml.

El sistema té tot allò que vull:

• Comentaris basats en fitxers, llegibles per humans, i sense necessitar software de tercers.
• No cal cap registre en cap plataforma, els comentaris poden ser anònims.
• S’integra fàcilment amb Hugo, i va totalment a banda. No modifica la instal·lació original.
  • Més enllà de com s’integra, puc seguir generant la meva pàgina i el blog com sempre. Zero interferència
• El projecte és robust, lliure i usable per tothom.
• Usa PHP com llenguatje d’implementació, extès i senzill.

La versió que he escollit és la 1.0. En Jakob té una altra versió (encara en desenvolupament), però amb estructura més complicada i que implementa utilitats que no em son necessàries. Valoro molt la senzillesa, aquí: allò que em cal i res més.

La resta de l’article explica com integro HashOver amb Hugo.

Segurament es pot fer d’alguna altra manera, però aquesta m’ha funcionat prou bé.

Dintre del fitxer config.toml, secció [Params], he definit un nou paràmetre, hashover:

Els paràmetres comments i hashover cal definir-los com true. El paràmetre hashover no es estàndar de Hugo, però no he volgut reusar alguns que ja porta de base per integrar altres sistemes, com disqus.

A la plantilla singhle. html, afegeixo el següent codi:

L’he posat sobre el bloc de codi de showRelatedPosts.

Defineixo una nova plantilla hashover-comments.html a layouts\partials, amb el següent codi:

A l’arrel de la pàgina web (public_html), he desplegat el codi descarregat de hashover, seguint les instruccions d’en Jakob. Jo he usat el mètode d’integració via javascript, no php.

Per la resta, no té cap dificultat.

Si quan genereu el site amb Hugo el pujeu via rsync o amb algun automatisme, incloeu una comanda --exclude per no esborrar la carpeta de hashover.

Si ho feu via ftp, no esborreu la carpeta.

Cal afegir el següent comentari a les capcaleres Frontmatter dels fitxers markdown en generar el site:

Fitxers md (article on si volem comentaris)

Fitxer md (pagina on no volem comentaris)

Hashover deixa els comentaris en la carpeta hashover/pages.

Per cada pàgina crea un directori amb el nom de la pàgina i dins els fitxers 1.xml, 2.xml, etc. amb els comentaris que s’hagin fet.

Per cada pàgina que es visita, hashover crea un directori, encara que sigui buit. Si mireu l’estructura de carpetes, en veureu moltes buides.

Si mireu el disseny del formulari de comuntaris a qualsevol article d’aquest blog, veureu que NO és l’original de Hashover.

Jo hi he fet unes quantes modificacions, a nivell de CSS i de visualització dels fils de comentaris, per adeqüar-lo més a les meves necessitats i al disseny que jo volia.

No obstant, el sistema que proveeix Jakob és perfectament operatiu i seguint les passes anteriors s’integra a la primera.

Si voleu el codi font del que jo he integrat, el teniu a github (v1.0.0). Però ja és part d’un altre projecte, HashOver-md, per usar Markdown en comptes de xml per desar comentaris. Veurem com avança.

Si el codi que generen els LLM a dia d’avui arriba a ser igual o millor que el generat per programadors humans en casos d’ús habituals… hem de seguir mirant (i tocant) el codi? Si posem les mans en un codi no generat per nosaltres mateixos, no pot ser que hi introduim errors?

Partim de la base de tenir un codi ben generat i sabent que comprendre i modificar amb seguretat un codi que no és propi (no escrit per un mateix) no és fàcil, per ben estructurat i documentat que estigui (això, els que ens dediquem a la cosa de programar, ho hem patit moltes vegades… o ho fem patir).

Ja hem comentat alguna vegada que el software no és només un conjunt d’instruccions, és la implementació d’una manera de pensar, del funcionament d’una organització o d’un equip, d’un seguit de necessitats funcionals, que cal comprendre.

Potser en alguns casos ja hem de deixar de no fiar-nos del codi generat per LLM i passar a un altre estat?

Copio literalment un parell de punts que destaca en Jose Alcántara a Deja de mirar el código1:

Esto deja dos lecciones sobre la mesa.

1. La brecha de calidad. En breve el código hecho por máquina va a ser tan superior que tú versión manual va a verse tosca. Si no eres muy top programando, seguramente para ti esto ya sea verdad.
2. El cambio de herramientas. A usar una herramienta se aprende usándola. Si la forma de crear código y operar sistemas pasa por prompts, skills, e orquestación de agentes, cuanto antes adquieras soltura en ese diálogo, antes volverás a ser relevante.

Així que sí, no hem de deixar de saber programar, segur. Però potser si que hem de saber usar les noves eines, i dominar no només la programació, sino tot l’ecosistema de programació d’avui en dia, des de la generació del codi (amb una eina - LLM) fins al testing, desplegament i monitorització continua… o algú es planteja anar fent F5 o test de stress amb quatre ordinadors alhora, avui en dia?

En un entorn professional i complex, sigui en una organització gran o desenvolupant solucions per tercers, no hi haurà lloc pel Vibe Coding, això segur: no vindran les solucions puntuals fetes per usuaris amb coneixments a substituir el software de gestió dels diferents sistemes troncals… en tot cas, el complementaran. Però si que caldrà que el codi troncal generat sigui de qualitat, integrat, segur… i de generació ràpida. Aquí és on entra en joc el nou paper i l’ajuda de les LLM: en una generació més ràpida de codi i segura.

Cal pensar com evoluciona l’ofici. No com se’ns substitueix, sinó com evolucionem com a programadors: la comprensió del problema, la cerca de la solució i la definició de la mateixa, amb instruccions precises i validables, definint l’entorn tècnic on es desenvoluparà i fent més èmfasi en la seguretat de l’aplicació, els controls i la gestió de les dades.

El món no es fa petit, s’eixampla.

1. He manllevat el títol del d’en Jose una mica, efectivament. :·) ↩︎

Més enllà de titulars pescaclics d’alguna premsa, no existeixen IAs rebels, sinó una falta de responsabilitat en molts punts de la cadena, males o pobres praxis ocultes sota secrets industrials o interessos de seguretat, i massa interessos econòmics que depenen de tot això. Una barreja de mala combinació amb transparència i control d’eines poderosísimes. Oli i aigua, com qui diu.

Sabent que el funcionament de les IAs és diferent de la programació habitual, perquè la IA generativa no interpreta literalment les instruccions, com la programació algorítmica tradicional, si no que el que fa és interpretar les ordres (prompts) que l’usuari li dóna, que no té coneixement propi de saltar-se o no uns límits establerts per la ètica o la norma jurídica o que no sap la intenció darrere del que li demana alguna cosa, no es pot calibrar, interpretar o mesurar el que fan les IA de la mateixa manera de sempre, amb les mateixes eines.

Calen nous mecanismes i criteris (sobretot) per poder mesurar el criteri d’interpretació d’una instrucció, i la seva execució, definir un nivell que diferenciï entre llibertat de criteri i execució creativa d’una solució a una execució fora de paràmetres acceptables o establerts, que puguin tenir conseqüències o danys per tercers.

Aquests criteris i mecanismes no poden ser només llei, però. Han d’estar codificats de manera intrínseca en els prompts o en els guarda-rails d’execució, però com es fa això? Encara no ho sabem, però semblaria la versió AI/prompt de la frase aquella que diu que el codi serà llei: segons com codifiquem l’execució o els mecanismes de control, així seran els resultats.

Però si deixem tot això només en mans d’uns quants, qui ens garanteix el compliment? En aquest sentit, el mateix model centralitzat en unes quantes mans de corporacions1 és un perill per a la societat, donada la capacitat d’influència en mecanismes bàsics i centrals (bancs, préstecs, assegurances, algorismes policials, ajudes socials per posar els més greus).

En canvi, mecanismes de pes obert, federats i distribuïts, poden millorar la distribució d’aquest control i d’aquest pes d’execució, alhora que proporcionin una diversitat de criteris més gran. Potser el benefici econòmic no serà tan gran per alguns, en aquest cas, però si, potser, més distribuït socialment, cosa que sembla més justa.

De tota manera, el temps acabarà posant les coses a lloc, en funció dels usos, recursos disponibles i beneficis que se n’obtinguin. Estem a l’inici de la carrera, i tothom s’està situant.

1. Que no deixen de ser grups de persones amb interessos particulars, certament endogàmics a determinats nivells. ↩︎

Aquesta setmana la notícia del món IA ha estat l’escapada de control d’un model d’OpenAI i el hackeig d’un altre servei:

Un model d’OpenAI, sense que ningú l’hi hagués ordenat, va travessar el perímetre del seu entorn de proves, va accedir a Internet i va hackejar Hugging Face per obtenir les respostes d’un test de ciberseguretat. No ho va fer intencionadament, ho va fer perquè podia, i perquè ningú havia configurat bé els seus límits. A més, van passar set dies fins que algú es va adonar del que havia passat.

Ja no cal una IA rebel per tenir un problema greu, n’hi ha prou amb un agent prou capaç i un entorn mal dissenyat. Aquesta és la lliçó d’una setmana que, vista des de fora, semblava dominada per llançaments i xifres de rendiment, però des de dins, planteja una pregunta que el sector ha anat posposant: saps exactament el que fan els teus agents quan no els estàs mirant?

[…]

El cicle de l’entusiasme ha acabat, comença el cicle de la responsabilitat.

— Oscar Junyent a Agents que s’escapen, feines que es perden, preus a la meitat, La Píndola de TecnologIA (28/07/2026)

Llegint notícies arreu, sembla que gairebé ja tinguem aquí Skynet personificada, però no. En el transcurs d’un experiment, testejant possibilitats i condicions de seguretat, el model en proves ha trobat un camí i ha buscat totes les vies possibles per trobar la solució al problema plantejat.

És un problema, si, però sobretot el que exposa és que la industrialització de la potència de càlcul, la gestió de moltíssima informació i rapidesa d’execució característiques de la IA no fan si no augmentar els forats de seguretat que gairebé tothom té… No parlem dels famosos Zero Days o errors als kernels trobats que ningú coneixia o d’atacs malintencionats: parlem d’entorns mal configurats, ports oberts, vies no tancades, pegats de seguretat no aplicats o, simplement, mala programació. Errors.

Que tot això es pugui fer servir per fer maldats i explotar debilitats, extreure informació o rebentar sistemes, és una cosa. Que tot això serveixi d’alarma per veure que els sistemes informàtics son una porta oberta directa al cor de la informació, l’actiu més valuós de moltes empreses i organitzacions, és una altra. I és en la que ens hem de fixar: el model no ha anat amb mala intenció: el model ha buscat vies per resoldre un problema, i les ha trobades1

Cal un control sobre les eines de IA, agents i demés, però sobretot el que cal és tenir molt i molt clar en quins entorns els fem anar, quines barreres hi ha de sortida i d’entrada, què despleguem i on, sota quines condicions… per citar algunes coses quant a l’ús. També s’ha vigilar, com no, l’entrenament dels models: podem donar-los tota la informació del món, però també els cal formació, criteri, guia: què es pot fer i què no.

A nivell tecnològic, hi ha molt per aprendre: l’anàlisi post-mortem de l’incident publicat per HuggingFace és un clar exponent de les múltiples vies de sortida que hi ha de dintre a fora. I aquestes vies poden ser de doble sentit, un malson pels responsables de seguretat, si. Però també un aprenentatge per ells, pels arquitectes, pels dissenyadors i desenvolupadors de sistemes: cal establir productes sòlids, sense forats. Ens pot ajudar a això també la IA? Ens pot ajudar a programar codi més robust, centrat en el que ha de fer, però sense obrir portes laterals? No Vibe Coding ni models de prova: software professional, robust, desplegat en entorns complexos i exigents, que tracten informació confidencial o amb molt baixa latència, amb connexió a serveis de tercers i potencials portes. Poser si, que pot ajudar.

La base, però, ha de ser una ètica pels models, des de l’entrenament fins al desplegament i ús, en totes les etapes i per tots els actors, des de fabricants fins a usuaris últims. La responsabilitat, que diu Oscar en el seu text de més amunt.

Si no, amb la IA el que farem, en comptes de multiplicar les capacitats d’acció, serà industrialitzar els errors.

1. Cada dia estem més a prop de l’apocalipsis dels clips ;) ↩︎

Via David Bonilla descobreixo Current, un lector de RSS que segueix, de manera molt estricta, el concepte de “river of news”, la idea que les notícies flueixen, que no son estàtiques, que proposen ignorar el FOMO d’estar al dia de tot, que no cal estar pendent de les noticies que queden per llegir.

David ho explica molt bé:

Uno de los mejores ejemplos recientes de software opinionado es el delicioso artículo en el que Terry Godier explica cómo diseñó Current, su lector de RSS. No otro lector de RSS, el suyo.

Y es el suyo porque Terry hizo exactamente lo contrario de lo que el mercado ofrecía y los usuarios supuestamente demandaban. Diseñó un lector que no te hiciera sentir mal. Que no te hiciera sentir que habías incumplido tus obligaciones por no leer alguna de las publicaciones a las que te suscribiste.

Porque la aplicación de Terry no cuenta las publicaciones que no has leído.

De hecho, ni siquiera las conserva eternamente como una deuda pendiente. Terry se dio cuenta de que todos los lectores del mercado trataban la información como una lista de tareas que debes completar.

El concepte és molt xulo, i molt valent, la implementació és molt elegant i l’article on explica perquè i com el crea val la pena llegir-lo.

Però després de mirar-lo una estona, no em convenç (només puc mirar-lo, està per iOS i no tinc dispositiu -cap- Apple).

No em convenç perquè el seu criteri no s’adapta al meu: jo no uso el feedreader per llegir-ho tot: notícies, xarxes, blogs; no tinc una aplicació lectora per tot. Ho vaig provar i no em va agradar ja fa temps.

Jo llegeixo cada cosa (diaris, xarxes, feeds) en un lloc diferent i separat. Per tant, els seus temps, la seva caducitat inamovible per disseny dintre de l’aplicació, no s’adapta a la meva manera de fer, a què i com jo llegeixo al feedreader.

De tota manera, em fa saltar un disparador.

Ja molt de temps que reflexiono en com seguir les novetats dels blogs o llocs sense que siguin una feina pendent, sense estar pendents del comptador de no-llegits que sempre creix.

No tinc FOMO, però sí que m’agrada saber les novetats que hi ha, i el numerador pot ser un indicador molt simple, sempre que no es converteixi en una obligació, en un repte a aconseguir, l’inbox-zero de les notícies. I si l’article “caduca”, la idea quedarà i un altre article posterior la desenvoluparà o tornarà a parlar-ne. Aquest és el concepte del river of news: l’article passa, la idea queda, evoluciona, flueix.

Així que investigo i adapto el meu muntatge personal, que ja es tracta d’això, també: de que cadascú busqui la seva solució, se l’adapti o la creï. Si a en Godier li funciona, fantàstic per ell. No aniré a demanar-li (com d’altres fan) que adapti la SEVA eina a les MEVES necessitats. Si em va bé, perfecte. Si no, em faig l’eina, si puc.

La solució que implemento és molt simple, sense programació: posar una caducitat a les notícies i escrits dintre del meu feedreader. Els de més de, posem, 60 dies s’esborraran directament. Perquè 60? És discrecional, s’adapta a la meva manera de fer i al tipus d’informació que llegeixo via rss:

• No és informació d’última hora (notícies, xarxes socials). Son reflexions, articles de ciència o socials. Lectura que no caduca depresa.
• Si en dos mesos no he estat capaç de llegir un article (pel motiu que sigui), potser ja serà tan vell que ja no em val la pena. O potser algú altre en parlarà, i hi arribaré més endavant.
• El meu ritme de lectura no és diari, per tant, si poso un període molt curt tinc més possibilitats de ni veure algunes coses.

És un riu com el dissenyat per en Godier, però més tranquil i cabalós i amb eines que ja feia anar.

El fons de tot és que en una societat curulla d’informació no podem estar pendents de tot, cal deixar que la informació passi: arribarà o llegiré el que pugui, i d’això n’aprendré. Amb massa informació només ens atabalarem o infoxicarem, i no podrem dedicar temps a fer coses per nosaltres mateixos i a reflexionar de tant en tant..

Com tot a la vida, és equilibri.

Al final no faré servir el software de Godier, però m’he adaptat la seva idea. I crec que es tracta d’això, de refinar o millorar el que tens, d’adaptar el que aprens.