Skip to main content
  1. Planet
  2. Global
  3. Page 180

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

FreeCAD Project Asociation anuncia subvenciones para desarrolladores

Creo que es la primera vez que publico una entrada de este tipo y que merece toda nuestra atención: la FreeCAD Project Asociation anuncia subvenciones para desarrolladores que impulsen FreeCAD, uno de los mejores programas de diseño CAD de código abierto. ¿Quieres saber más? Sigue leyendo.

FreeCAD Project Asociation anuncia subvenciones para desarrolladores

Para quienes no lo conozcan, Freecad es un programa de diseño gráfico en 3D libre pensado principalmente para el diseño mecánico pero que también sirve para todos los demás usos en los que se necesita modelar objetos 3D con precisión y control sobre el historial de modelado.

FreeCAD Project Asociation anuncia subvenciones para desarrolladores

FreeCAD ha estado en desarrollo desde 2002, y ofrece una gran lista de características. Aún le faltan capacidades, pero es lo suficientemente potente para uso de aficionados y pequeños talleres.

En el blog ha aparecido en varias ocasiones, como por ejemplo, promocionar los video-tutoriales de Juan Gonzalez Gomez (conocido en la red y en el mundo maker como Obi Juan) o cuando Linux Center organizó un taller de diseño e impresión en 3D en 2022.

Dado que le faltan características la Asociación del Proyecto FreeCAD (FPA), una asociación internacional sin ánimo de lucro creada por administradores y desarrolladores del núcleo de FreeCAD en noviembre de 2021, ha pensado que lo mejor es invertir parte del dinero que manejan en subvencionar el trabajo de sus colaboradores. Algo que me parece sumamente interesante.

Para que quede todo claro lo mejor es leer íntegro el anuncios de la FreeCAD Project Asociation ya que de esta forma no hay dudas de esta nueva iniciativa.

La Asociación del Proyecto FreeCAD se complace en anunciar la creación del Fondo de Desarrollo de la FPA (FPADF). El FPADF ofrece subvenciones a individuos para contribuciones a FreeCAD.

Las subvenciones tienen un límite de 5000 dólares y se concederán sólo para trabajar en el código base de FreeCAD.

El límite podrá aumentarse a medida que la FPA adquiera experiencia en la concesión de subvenciones y los fondos disponibles lo permitan.

Cualquier colaborador que desee ser considerado para una subvención debe presentar una propuesta por escrito a la FPA. La propuesta debe indicar claramente cuánto dinero se solicita y qué pretende crear/mejorar/arreglar el contribuyente. Deberá incluirse un calendario estimado con los principales hitos, junto con criterios claros de finalización.

Las propuestas serán consideradas por el órgano general de la FPA y aprobadas por votación.

A la Asociación de Proyectos FreeCAD le gustaría ampliar el número y tipo de subvenciones concedidas. Las donaciones realizadas a la FPA y designadas FONDO DE DESARROLLO se utilizarán para este propósito.

Las solicitudes de subvención pueden ser enviadas a cualquier miembro de la FPA para su consideración.

En resumen, una iniciativa más que interesante ya que es una forma de potenciar el desarrollo del software libre pocas veces vista pero que estoy seguro que será muy positiva.

Más información: FreeCAD Project Asociation

La entrada FreeCAD Project Asociation anuncia subvenciones para desarrolladores se publicó primero en KDE Blog.

the avatar of SUSE Community Blog
the avatar of SUSE Community Blog

The Year of Agama – an outlook to the 2024 roadmap

The following article has been contributed by Ancor González Sosa and the YaST team at SUSE.       At the end of 2023, we announced Agama 7, a new service-based installer for Linux. That version was the first prototype we could consider to be ‘functional enough’ for our purposes, as it covers areas such […]

The post The Year of Agama – an outlook to the 2024 roadmap appeared first on SUSE Communities.

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

Planes de Agama, el nuevo instalador de #openSUSE, para 2024

Con la publicación de la versión 7 de Agama a finales de 2023, se llegó a una versión lo suficientemente funcional, que en este 2024 se seguirá puliendo y dando forma

Por el blog ya he escrito algunos artículos sobre Agama, pero hagamos un recordatorio rápido sobre qué es Agama.

Agama es un nuevo instalador de Linux nacido en el seno del equipo de YaST. Está diseñado para ofrecer reutilización, integración con herramientas de terceros y la posibilidad de construir interfaces de usuario avanzadas sobre él.

Nace de YaST, el atual instalador de openSUSE, al que se le quiere adaptar, y eliminar barreras de un código que ya tiene bastantes años.

El equipo de desarrollo de Agama, quiere que en este 2024, haya un cambio significativo y sustancial en su software. Para ello se ha marcado un par de hitos en el año, para tener unos objetivos hacia los que encaminar sus esfuerzos.

Las fechas clave corresponden una a mediados de abril y otra a mediados de julio de este año 2024. Cada cita centrada en unos objetivos distintos.

El primer hito corresponde a cambios en la arquitectura propia del código. Desde el inicio del proyecto se han apoyado en Cockpit, pero llegados a este punto de desarrollo de Agama, esa dependencia es muy limitante.

Por lo que se explorarán nuevas alternativas que hagan que Agama pueda crecer en funcionalidades.

El segundo hito se refiere a la propia interfaz y las opciones de almacenamiento durante el proceso de instalación.

Detrás de estos cambios de la nueva herramienta, habrá mucha discusión y horas de implementación de código, pero no solo eso, también a la hora de recolectar ideas sobre la mejor manera de realizar tal o cual tarea.

Y el proyecto openSUSE y SUSE, tienen como marca de la casa el que todo el código es libre y abierto, por lo que podemos participar en el nuevo desarrollo de Agama, con contribuciones u opiniones.

Ya sea en listas de correo, canales IRC o en la plataforma GitHub que es donde se desarrolla el código, tu opinión cuenta y tus aportes pueden hacerse realidad.

Agama se basa en trabajo realizado en YaST, pero al que se le quiere daruna segunda vida, adaptándolo a un presente que ha cambiado mucho y en el que tienes voz y voto y donde puedes aprender y compartir tus conocimientos.

Enlaces de interés

the avatar of rickspencer3's Blog
the avatar of rickspencer3's Blog

Can you run SUSE on a $65 Laptop?

Can you run SUSE on a $65 Laptop?

Yeah, but you might not want to.

Of all of the computers that I have owned over the years, the two that remember the most fondly are netbooks. I was one of the first to get an eeePC. I put Ubuntu on it, and a friend at work was able to do some firmware cutting to get all of the hardware enabled. I moved on to the next eeePC version, and then on to one of the most useful computers I ever had, a Dell Mini 10v. I actually bought one for myself, and one for each of my kids. If I remember correctly, I was able to buy them through the Dell partner portal or something. I had a black one, but one of my kids got red, and one got blue. The “10” stood for the 10 inch screen, and the “v” meant that it was a “value” model, which, for me, meant that the graphics were supported with open source intel drivers instead of binary nvidia goo.

The beauty of these computers was that they were small and reasonably light, so I could lug them around to conferences and work trips quite easily. I am sad that I don’t really see anyone making netbooks anymore, but when I saw that you could get an $80 eleven inch computer at Microcenter, and that some folks had some luck installing Linux on it, I decided to go for it. You see, I have some work trips coming up, and I thought it would be nice to have a compact and cheap computer with me for these trips, rather than my expensive high performance laptop that I use as my daily at work.

I’ve always been an early adopter of tech when it reaches new levels of access. For example, my 3D printer was one of the first low drama, low cost printers (thanks Monoprice). I also bought the first sub $500 laptop,which had about 40 minutes of battery life.

“Wait”, you say? The title says $65, but you said it was $80? That’s right, Evolve III Maestro is on sale for $80 at Microcenter. When I went to look at it, I didn’t see it out on display, so I asked about it. It turns out that they don’t have it out, you have to know to ask, and you can’t see it, you have to buy it “sight unseen.” Yikes. The technician helping me said he could check if there was an open box in the back, and if so, he could let me have a look before I bought it. He brought it out, and sure enough, it was a small, cheap computer. I asked if there was a discount for buying the open box, and sure enough, $15 off. So there you go, I got a computer for $65.

Open Evolve III Box

The device is … erm … bare bones. For example, no USB-C ports. The keyboard is not exactly an IBM Selectric feel. I have a 5 year old 11 inch MacBook Air that I bought for like $2,000, and let’s just say, the build quality of Evolve III is “not quite at the same level.”

So, how did it go getting Leap on there? Getting into the bios and adjusting the boot menu to boot from my USB install media was pretty easy, after I did some web searches to find that “delete” is the magic key to get into the bios. Unfortunately, the wifi driver for the wifi module is too new, and so the built-in wifi is not supported in Leap 15.5s kernel, and of course there is no Ethernet port. After some confusing loops in the installer trying to get it to install without a network connection, I pulled out a random USB hub with an ethernet adapter that I had in my closet, and then used a USB-C to USB 3 connector. This actually worked.

Janky Ethernet connection

Given the small screen and the low specs, I opted for xfce for the desktop rather than my normal GNOME choice. Having an easy choice of “roles” at install is sweet.

The install wasn’t exactly fast, but it installed just fine. It occurred to me that instead of struggling with the unsupported built in wifi, I had some wifi dongles lying around, I could use one of those. The first one I tried was RALINK something something, and I looked it up, and there was a kernel module for it, but no package for it. I figured if I was going to go through that much pain, I would rather focus on getting the internal wifi module to work.

After some epic scrounging through a box of rpis, sensors, motors, and other crap, I found an official rpi dongle, that turned out to be an already supported Broadcom wifi modem, so now I have wifi. The dongle doesn’t see my “5g” network, but it works. I figure that making the real wifi work (and documenting it) will be an irresistible challenge for one of the Linux engineers I am surely going to meet up with in the next few months.

rpi wifi dongle

So that’s it, it’s mostly running. I installed Cheese to test the webcam, it works just fine.

On the audio side, Pulse doesn’t detect built in speakers or the built in microphone, but it works just fine with my Plantronics headset that SUSE sent me. I can’t really be bothered to make the built in audio work, because I assume that the hardware is going to produce terrible results anyway. There is an 1/8 inch pin connector as well, but I haven’t tried that or bluetooth yet. The bluetooth dialog works so I trust that bluetooth works generally. I barely use bluetooth with laptops, so I leave it off.

desktop with pulse audio working

Lastly, the computer came with mini HMDI, and I don’t seem to have an adapter for that around, so I will need to pick one up. Because the computer came with Intel graphics, I am confident that it will “just work”, but you never know.

Fortunately, I wrote a blog post about getting my real power house work machine set up, so I was able to follow those steps to get chrome, vscode,and slack installed and running. Xfce-wise I read up on how to do some light configuration, especially getting the apps that I use most on the panel.

All told, I'm thinking this machine might suit for travel. The keyboard is a little awkward, so I miss a lot of characters when I type. When typing in resource hungry web pages, like google docs or slack, it is very laggy. It really makes me miss the days of real netbooks. It’s great that it’s so cheap, but what I wanted was small. I would have rather have a smaller machine with a better build.

the avatar of Efstathios Iosifidis
the avatar of Efstathios Iosifidis

Γιατί οι προγραμματιστές δεν γράφουν τεκμηρίωση;

Γιατί οι προγραμματιστές δεν γράφουν τεκμηρίωση
Όσοι με γνωρίζουν, επιμένω συνέχεια στους προγραμματιστές να γράψουν σχόλια στον κώδικά τους αλλά και να γράφουν τεκμηρίωση γενικότερα.
Πιστεύω ότι υπάρχουν δύο κύριοι λόγοι που οι προγραμματιστές δεν γράφουν τεκμηρίωση. Τα εργαλεία παίζουν το ρόλο τους, αλλά είναι άλλοι λόγοι.

Το γράψιμο είναι δύσκολο

Οι "μηχανικοί λογισμικού" δεν γράφουν γιατί η σαφής γραφή είναι πολύ, ΠΟΛΥ δύσκολη.

Η συγγραφή είναι ένα δύσκολο, απαιτητικό έργο. Απαιτεί να οργανώνουμε με σαφήνεια τις σκέψεις μας, να τις εξετάζουμε κριτικά και να τις εκφράζουμε καθαρά. Το εκφραστικό μέρος μπορεί να απλοποιηθεί σε κάποιο βαθμό (ανάλογα με την ποιότητα γραφής που απαιτείται).

Στον κόσμο του προγραμματισμού, όπου το "εξαρτάται" είναι συχνά η καλύτερη απάντηση και όλα βασίζονται σε συμβιβασμούς, το γράψιμο γίνεται πολύ πιο δύσκολο. Πρέπει να καθοριστεί το πλαίσιο, να αιτιολογηθούν οι αποφάσεις και στη συνέχεια, να ενισχυθεί τη σκέψη χαμηλού επιπέδου που οδηγεί στον κώδικα. Αυτός ο τύπος γραφής είναι χρήσιμος μόνο εάν γίνεται καλά, και επειδή το γίνει καλά είναι δύσκολο, συχνά δεν γίνεται καθόλου. Ο κακός κώδικας θα συνεχίσει να δουλεύει, η κακή τεκμηρίωση μπερδεύει.

Αυτός είναι ο λόγος για τον οποίο πολλοί άνθρωποι διαφωνούν σχετικά με την αξία των σχολίων στον κώδικα και τα πλεονεκτήματα της αυτο-τεκμηρίωσης κώδικα (ό,τι κι αν σημαίνει αυτό). Ο Kevlin Henney λέει ότι "το να ζητάμε σχόλια γύρω από περίπλοκο κώδικα είναι μάταιο, επειδή περιμένουμε από τους ίδιους ανθρώπους που δεν μπορούσαν να εκφραστούν καθαρά στον κώδικα να εκφραστούν καθαρά και κατανοητά με κείμενο (Αγγλικά)".

Η μη τεκμηρίωση δεν εμποδίζει την κυκλοφορία

Εάν ένας προγραμματιστής δεν γράψει τεκμηρίωση, η δουλειά του εξακολουθεί να έχει ολοκληρωθεί. Το να μην γράψει τεκμηρίωση δεν εμποδίζει την κυκλοφορία του προγράμματος (τουλάχιστον όχι αμέσως). Η ζημιά που προκαλείται από τη μη τεκμηρίωση τεχνικών αποφάσεων είναι σωρευτική. Όπως το τεχνικό χρέος, δεν προκαλεί ζημιά εδώ και τώρα.

Όπως ειπώθηκε και παραπάνω, η συγγραφή είναι πρωτίστως θέμα σκέψης και ανάλυσης. Στα περισσότερα μέρη, η συγγραφή κώδικα μπορεί να γίνει εύκολα. Ένας αποδιοργανωμένος σωρός κλάσεων και μεθόδων στον κώδικα μπορεί να λειτουργήσει - ένας σωρός λέξεων και παραγράφων δεν θα λειτουργήσει. Η γραφή ΠΡΕΠΕΙ να είναι σαφής εάν πρόκειται να είναι χρήσιμη. Ο κώδικας θα γίνει αποδεκτός (σε κάποιο βαθμό) αρκεί να κάνει τη δουλειά του. Και δεδομένου ότι οι περισσότεροι οργανισμοί επικεντρώνονται μόνο στην κυκλοφορία του προϊόντος, αυτό που δεν εμποδίζει την κυκλοφορία αγνοείται.

Οι δοκιμές (unit tests) αντιμετωπίζουν παρόμοιο πρόβλημα σε πολλές ομάδες. Για να ελέγξουμε τον κώδικα πρέπει να τον κατανοήσουμε (που απαιτεί περισσότερη προσπάθεια από τη σύνταξη του) και η απουσία δοκιμών δεν εμποδίζει την κυκλοφορία. Επομένως, συνήθως δεν υπάρχουν δοκιμές σε κώδικα.

Υπάρχει και το θέμα της παλαιότητας. Ακόμη και τα καλά έγγραφα είναι παρωχημένα, επομένως οι προγραμματιστές πρέπει να συνεχίζουν να επαναλαμβάνουν το σκέφτομαι-αναλύω-εκφράζω ξανά και ξανά καθώς κατασκευάζουν συστήματα. Έτσι, η αποφυγή της συγγραφής της τεκμηρίωσης είναι εύκολη. Έτσι, ακόμη και με τις καλύτερες προθέσεις, η τεκμηρίωση συμβαίνει συχνά μόνο σε στιγμές συγγραφής και καθαρισμού.

Τι γίνεται με τα εργαλεία

Δεν υπάρχει αμφιβολία ότι το σύνολο εργαλείων που χρησιμοποιούνται συνήθως για την τεκμηρίωση λογισμικού σήμερα είναι θλιβερά ανεπαρκή. Δεν σκεφτόμαστε τα έγγραφα ένα-ένα. Σκεφτόμαστε με όρους ιδεών και στόχων συγκεντρώνοντας πολλές έννοιες ταυτόχρονα. Το έγγραφο που προκύπτει είναι μόνο μια εκδήλωση της διαδικασίας σκέψης. Χρειαζόμαστε εργαλεία που μπορούν να μας βοηθήσουν να συγκεντρώνουμε ιδέες διαχρονικά για να λύσουμε το πρόβλημα. Τα Έγγραφα Google, το Confluence, το Markdown είναι όλα κακά εργαλεία για αυτόν τον τύπο γραφής.

Ωστόσο, μια νέα γενιά εργαλείων όπως το Notion και το Roam αντιμετωπίζουν αυτό το πρόβλημα της αξιοποίησης των εργαλείων. Ας ελπίσουμε ότι αυτά θα λειτουργήσουν όπως προβλέπεται και θα βοηθήσουν στη σκέψη που οδηγεί στη συγγραφή.

Ωστόσο, η έλλειψη δεύτερου εγκεφάλου δεν μπορεί πραγματικά να χρησιμοποιηθεί ως δικαιολογία για τη μη χρήση του πρώτου. Τα εργαλεία παίζουν το ρόλο τους, αλλά η προθυμία να αναλάβει τη διαδικασία είναι το πραγματικό εμπόδιο.

Πώς να δημιουργείτε λοιπόν τεκμηρίωση

Το λογισμικό γραφής μας δίδαξε ένα πράγμα. Αν θέλετε πραγματικά οι χρήστες σας να κάνουν κάτι, τότε αυτό θα πρέπει να είναι ένα βήμα που τους εμποδίζει στο ταξίδι τους με το προϊόν σας. Με τον ίδιο τρόπο, η προσαρμογή τεκμηρίωσης σε γραπτό κώδικα δεν πρόκειται ποτέ να λειτουργήσει. Ακόμα χειρότερα, είναι άχρηστη. Η συγγραφή έχει να κάνει με την κριτική σκέψη. Σκοπός της είναι να εξηγήσετε τη διαδικασία σκέψης και την πρόθεσή σας στον εαυτό σας και στο ακροατήριό σας (π.χ. την ομάδα σας). Η διαδικασία σκέψης είναι το σημείο όπου η τεκμηρίωση/συγγραφή προσθέτει αξία, όχι ως στατική καταγραφή ήδη υλοποιημένου κώδικα.

Οι υποστηρικτές του προγραμματισμού mob/pair και των XP συχνά υποτιμούν την τεκμηρίωση. Αλλά αν δεν υιοθετηθούν αυτές οι τεχνικές, η πρακτική της συγγραφής και της αναθεώρησης των τεχνικών εγγράφων είναι ο μόνος τρόπος με τον οποίο οι ομάδες οικοδομούν μια συλλογική κατανόηση αυτού που προσπαθούν να οικοδομήσουν. Αυτή η κοινή οικοδόμηση του κόσμου είναι που καθιστά αυτή τη διαδικασία κρίσιμη για τη μακροπρόθεσμη υγεία της ομάδας και της βάσης κώδικα.

Ο μόνος τρόπος για να καταστεί βιώσιμη η διαδικασία συγγραφής τεκμηρίωσης είναι να την καταστήσουμε ανασταλτικό παράγοντα για την ανάπτυξη λογισμικού. Να την κάνουμε ελαφριά αλλά υποχρεωτική. Θα πρέπει να γίνει μέρος της διαδικασίας αντί να είναι ένα ακόμη πράγμα που πρέπει να κάνουμε. Μερικά πράγματα που έχουν λειτουργήσει για αυτό από την εμπειρία μου.
  • Γράψτε τεκμηρίωση πριν τον κώδικα. Εκτός αν η αλλαγή είναι ασήμαντη, κάθε προγραμματιστής γράφει ένα σημείωμα για το τι πρόκειται να κάνει και το περνάει από την υπόλοιπη ομάδα. Στο τέλος της συζήτησης, η πραγματική συγγραφή κώδικα θα πρέπει να γίνει ασήμαντη.
  • Γράψτε απλά. Μην περιπλέκετε το κείμενο, τουλάχιστον μέχρι να γίνει συνήθεια. Τα διαγράμματα, οι φανταχτερές ενότητες κ.λπ. μπορούν να περιμένουν. Γράψτε πολύ απλά για το τι σκεφτήκατε, τι κάνετε και γιατί. Ακόμη και αν το έγγραφο μπορεί να χρησιμεύσει ως βασικός δείκτης για την υπόλοιπη ομάδα τώρα και στο μέλλον, είναι εξαιρετικά πολύτιμο.
  • Τεκμηριώστε την απόφαση με τις εναλλακτικές τους - Αντί να τεκμηριώνετε λεπτομερώς την πραγματική υλοποίηση (η οποία μπορεί να αλλάξει με την πάροδο του χρόνου), επικεντρωθείτε στην τεκμηρίωση των επιλογών και του λόγου για τον οποίο έγιναν. Αυτό είναι κάτι που ο κώδικας δεν μπορεί ποτέ να εξηγήσει και ως εκ τούτου η καταγραφή του τον κάνει πολυτιμότερο. Οι λεπτομέρειες μπορούν να τεκμηριωθούν με βάση τον χρόνο που είστε διατεθειμένοι να επενδύσετε.
  • Κάντε την αναζητήσιμη - Καμία ποσότητα τεκμηρίωσης δεν θα έχει καμία χρησιμότητα εάν οι χρήστες δεν μπορούν να την βρουν. Χρησιμοποιήστε εργαλεία που υποστηρίζουν την αναζήτηση κειμένου. Αυτός είναι ένας από τους λόγους για τους οποίους δεν μου αρέσουν τα Έγγραφα Google για τεκμηρίωση. Είναι εξαιρετικό για τη συγγραφή, αλλά απλά απαίσιο για τη συνεργασία και την ανακάλυψη της πληροφορίας.
  • Παρακολουθήστε τις αλλαγές. Ορισμένοι οργανισμοί χρησιμοποιούν τον έλεγχο εκδόσεων (version control όπως πχ github) για να παρακολουθούν τις αλλαγές στο σχεδιασμό του συστήματος με την πάροδο του χρόνου. Αυτό είναι υπέροχο. Αλλά αν δεν έχετε φτάσει ακόμα εκεί, κρατήστε ένα έγγραφο ανά χαρακτηριστικό και συνεχίστε να βάζετε σε αυτό ενημερώσεις με ημερομηνία, ώστε η εξέλιξη να μπορεί να παρακολουθείται σε ένα μέρος με ελάχιστη ταλαιπωρία.
Γιατί οι προγραμματιστές δεν γράφουν τεκμηρίωση
Η ελπίδα είναι ότι καθώς η ομάδα φαίνεται να αντιλαμβάνεται τα πλεονεκτήματα της ύπαρξης και της αναθεώρησης ορισμένων εγγράφων (π.χ. τα νέα μέλη χρειάζονται λιγότερη βοήθεια) και η συγγραφή γίνεται συνήθεια, η πρακτική θα γίνει αυτοσυντηρούμενη. Μέχρι τότε, θα πρέπει να αντιμετωπίζεται όπως η γυμναστική ή η δίαιτα - επώδυνη αλλά απαραίτητη.
a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

Escape to Freedom, vídeo de la Free Software Foundation

Me complace presentar» Escape to Freedom», un vídeo de la Free Software Foundation que publicó en el 2022 y que intenta hacernos reflexionar sobre la necesidad de tener un control sobre nuestra vida digital para tener nuestros derechos fundamentales protegidos.

Escape to Freedom, vídeo de la Free Software Foundation

El mundo del Software Libre es mucho más grande de lo que pensamos, y es que para los humanos el número de humanos que hay en el mundo es un concepto que no podemos procesar bien. Solo tenéis que ir un día a una estación de tren o a un aeropuerto para comprobar la cantidad de trenes/aviones que circulan, pensar que la mayoría van llenos y después reflexionar que cada una de las personas que veis tiene una vida similar a la vuestra, con sus familiares, amigos y conocidos para poder vislumbrar cuánta gente somos.

Esta reflexión da pie a entender que en esto del Software Libre, a pesar de que cuando se hace algún evento parece que somos cuatro gatos, en realidad detrás hay centenares de personas que sí están interesadas y que participan activamente en su desarrollo.

Esto explica cosas como la gran cantidad de proyectos de Software Libre que hay en el mundo, un número creciente a pesar de las dificultades tecnológicas y, por qué no decirlo, políticas que en vez de remar a favor de la protección de los derechos de los individuos buscan como sacar provecho económico de cualquier circunstancia.

Todo lo anterior era un poco para justificarme por no presentar este vídeo antes ya que cualquier cosa que sea por promocionar el Software Libre a niveles bajos es fundamental si alguna vez queremos que nuestra sociedad se vuelva mucho más seria y responsable.

Pero bueno, me voy del tema. Hoy quería compartir con vosotros un vídeo que ya tiene dos años y que lleva por título «Escape To Freedom». Una creación de la Free Software Foundation (FSF) y que pretende ser una introducción a los conceptos que subyacen a la libertad del software: qué ganamos con ella y qué derechos están en juego.

Escape to Freedom, vídeo de la Free Software Foundation

En palabras de la FSF:

Este vídeo es la última incorporación a la serie de vídeos animados creados por la FSF sobre el tema del software libre. Pensamos en Escape to Freedom como una fábula que demuestra las consecuencias demasiado reales de no tener control sobre tu propia informática, y lo importante que es nuestra lucha colectiva por la liberación digital.

Al trabajar esta vez con un estilo de animación surrealista, esperamos haber ilustrado de forma evocadora algunos de los efectos emocionales que el software no libre y la falta de control sobre la propia autonomía digital pueden tener en la vida cotidiana.

Escape to Freedom muestra a los enemigos monopolistas del movimiento con una lente inquietante, pero esperamos que esta distorsión de la realidad ayude a mostrarlos tal y como son en realidad. Escape to Freedom presenta el movimiento siguiendo la tradición de la alegoría, y describe la necesidad de la libertad del software de forma que capte la atención de los usuarios de ordenadores sin conocimientos técnicos.

Help others find free software: Watch and share Escape to Freedom by Greg Farough

Bien, no os mareo más y os dejo el vídeo, el cual creo que es un buen material para poder concienciar a aquellas personas que todavía no son conscientes de la importancia del Software Libre en sus vidas.

¿Que es la FSF?

Por no hacer más larga la entrada, la La Free Software Foundation (FSF) es una entidad sin ánimo de lucro con la misión de promover mundialmente la libertad de los usuarios de computadores y defender los derechos de todos los usuarios de software libre.

Tiene una intensa actividad y os aconsejo visitar su página web para poder sacar provecho de todo lo que ofrece: información, materiales, contactos, etc.

Más información: FSF

La entrada Escape to Freedom, vídeo de la Free Software Foundation se publicó primero en KDE Blog.

the avatar of Open Build Service
the avatar of Open Build Service

Build Results Summary Chart Links to Build Results Overview

A quick update on the Request Page Redesign: the build summary chart bars are now clickable. A simple click on the bar will open an overview of the builds, which will be displayed under the Build Results tab on the request page and will have the corresponding filters applied. You can see a build summary chart on the request page only when the submitted packages build against a long list of repositories. Clickable build summary...

a silhouette of a person's head and shoulders, used as a default avatar
a silhouette of a person's head and shoulders, used as a default avatar

Vuelve el evento24H24L edición 2024

Todo cambia, y esa es la constantedel evento 24H24L, que ha pasado de ser un evento intensivo a una serie de charlas puntuales publicadas en un solo día a los mismo pero que no espera y que se van publicando a medida que se graban. En otras palabras, vuelve el evento 24H2L edición 2024 donde destacados (o no tnato porque participo yo) miembros de la Comunidad hablan de forma distendida sobre diversos aspectos del mundo del Software Libre. Estos audios tienen la intención de ser una puerta de entrada para todo el mundo, así que son 10%% recomendable a los nuevos o potenciales usuarios.

Vuelve el evento24H24L edición 2024

Este año José Jiménez, promotor de esta iniciativa, vuelve a dar otra vuelta y se está dedicando a realizar charlas puntuales y las va publicando poco a poco. De hecho, os comporto el rss para que las vayáis escuchando a medida que se van publicando a que después se acumulan y colapsan de GNU/Linux nuestros podcaster.

Debo reconocer que tengo pendiente de escuchar todavía muchas de ellas, incluso de la edición del 2021, pero que todos los que escucho me parecen de los más interesantes por la variedad de temas y la calidad de los contertulios.

Además, este año, debido a que algunos se han grabado en febrero los participantes han destacado algún proyecto de Software Libre al que darle las gracias, lo cual hace que no solo se hable de los temas especializados de los colaboradores sino que se multilpique por dos o tres las iniciativas presentadas, aunque sea solo dando una pincelada.

En palabras de su promotor:

El evento 24H24L consiste en la grabación de 24 audios de 1 hora sobre una temática especifica, en esta tercera edición se centrará en GNU/Linux. El propósito es cualquier usuario independientemente de su nivel descubra que le puede aportar este sistema operativo y le facilite el camino para empezar a utilizar este sistema.

Y, como es habitual en este tipo de entradas, os pongo aquí mismo la charla extraída del canal de PeerTube de 24H24L que tiene en FediverseTV, al cual os pido encarecidamente que le deis un vistazo.

Aprovecho para poner algunos enlaces de interés para poder disfrutar de esta iniciativa que ya lleva mucho tiempo promocionando el Software Libre y en la que espero poder partcipar pronto.

Más información: 24H24L

La entrada Vuelve el evento24H24L edición 2024 se publicó primero en KDE Blog.

the avatar of Federico Mena-Quintero
the avatar of Federico Mena-Quintero

Rustifying libipuz: character sets

It has been, what, like four years since librsvg got fully rustified, and now it is time to move another piece of critical infrastructure to a memory-safe language.

I'm talking about libipuz, the GObject-based C library that GNOME Crosswords uses underneath. This is a library that parses the ipuz file format and is able to represent various kinds of puzzles.

The words "GNOME CROSSWORDS" set inside a crossword puzzle

Libipuz is an interesting beast. The ipuz format is JSON with a lot of hair: it needs to represent the actual grid of characters and their solutions, the grid's cells' numbers, the puzzle's clues, and all the styling information that crossword puzzles can have (it's more than you think!).

{
    "version": "http://ipuz.org/v2",
    "kind": [ "http://ipuz.org/crossword#1", "https://libipuz.org/barred#1" ],
    "title": "Mephisto No 3228",
    "styles": {
        "L": {"barred": "L" },
        "T": {"barred": "T" },
        "TL": {"barred": "TL" }
    },
    "puzzle":   [ [  1,  2,  0,  3,  4,  {"cell": 5, "style": "L"},  6,  0,  7,  8,  0,  9 ],
                  [  0,  {"cell": 0, "style": "L"}, {"cell": 10, "style": "TL"},  0,  0,  0,  0,  {"cell": 0, "style": "T"},  0,  0,  {"cell": 0, "style": "T"},  0 ]
                # the rest is omitted
    ],
    "clues": {
        "Across": [ {"number":1, "clue":"Having kittens means losing heart for home day", "enumeration":"5", "cells":[[0,0],[1,0],[2,0],[3,0],[4,0]] },
                    {"number":5, "clue":"Mostly allegorical poet on writing companion poem, say", "enumeration":"7", "cells":[[5,0],[6,0],[7,0],[8,0],[9,0],[10,0],[11,0]] },
                ]
        # the rest is omitted
    }
}

Libipuz uses json-glib, which works fine to ingest the JSON into memory, but then it is a complete slog to distill the JSON nodes into C data structures. You need iterate through each node in the JSON tree and try to fit its data into yours.

Get me the next node. Is the node an array? Yes? How many elements? Allocate my own array. Iterate the node's array. What's in this element? Is it a number? Copy the number to my array. Or is it a string? Do I support that, or do I throw an error? Oh, don't forget the code to meticulously free the partially-constructed thing I was building.

This is not pleasant code to write and test.

Ipuz also has a few mini-languages within the format, which live inside string properties. Parsing these in C unpleasant at best.

Differences from librsvg

While librsvg has a very small GObject-based API, and a medium-sized library underneath, libipuz has a large API composed of GObjects, boxed types, and opaque and public structures. Using libipuz involves doing a lot of calls to its functions, from loading a crossword to accessing each of its properties via different functions.

I want to use this rustification as an exercise in porting a moderately large C API to Rust. Fortunately, libipuz does have a good test suite that is useful from the beginning of the port.

Also, I want to see what sorts of idioms appear when exposing things from Rust that are not GObjects. Mutable, opaque structs can just be passed as a pointer to a heap allocation, i.e. a Box<T>. I want to take the opportunity to make more things in libipuz immutable; currently it has a bunch of reference-counted, mutable objects, which are fine in single-threaded C, but decidedly not what Rust would prefer. For librsvg it was very beneficial to be able to notice parts of objects that remain immutable after construction, and to distinguish those parts from the mutable ones that change when the object goes through its lifetime.

Let's begin!

In the ipuz format, crosswords have a character set or charset: it is the set of letters that appear in the puzzle's solution. Internally, GNOME Crosswords uses the charset as a histogram of letter counts for a particular puzzle. This is useful information for crossword authors.

Crosswords uses the histogram of letter counts in various important algorithms, for example, the one that builds a database of words usable in the crosswords editor. That database has a clever format which allows answering questions like the following quickly: What words in the database match ?OR?? — WORDS and CORES will match.

IPuzCharset is one of the first pieces of code I worked on in Crosswords, and it later got moved to libipuz. Originally it didn't even keep a histogram of character counts; it was just an ordered set of characters that could answer the question, "what is the index of the character ch within the ordered set?".

I implemented that ordered set with a GTree, a balanced binary tree. The keys in the key/value tree were the characters, and the values were just unused.

Later, the ordered set was turned into an actual histogram with character counts: keys are still characters, but each value is now a count of the coresponding character.

Over time, Crosswords started using IPuzCharset for different purposes. It is still used while building and accessing the database of words; but now it is also used to present statistics in the crosswords editor, and as part of the engine in an acrostics generator.

In particular, the acrostics generator has been running into some performance problems with IPuzCharset. I wanted to take the port to Rust as an opportunity to change the algorithm and make it faster.

Refactoring into mutable/immutable stages

IPuzCharset started out with these basic operations:

/* Construction; memory management */
IPuzCharset          *ipuz_charset_new              (void);
IPuzCharset          *ipuz_charset_ref              (IPuzCharset       *charet);
void                  ipuz_charset_unref            (IPuzCharset       *charset);

/* Mutation */
void                  ipuz_charset_add_text         (IPuzCharset       *charset,
                                                     const char        *text);
gboolean              ipuz_charset_remove_text      (IPuzCharset       *charset,
                                                     const char        *text);

/* Querying */
gint                  ipuz_charset_get_char_index   (const IPuzCharset *charset,
                                                     gunichar           c);
guint                 ipuz_charset_get_char_count   (const IPuzCharset *charset,
                                                     gunichar           c);
gsize                 ipuz_charset_get_n_chars      (const IPuzCharset *charset);
gsize                 ipuz_charset_get_size         (const IPuzCharset *charset);

All of those are implemented in terms of the key/value binary tree that stores a character in each node's key, and a count in the node's value.

I read the code in Crosswords that uses the ipuz_charset_*() functions and noticed that in every case, the code first constructs and populates the charset using ipuz_charset_add_text(), and then doesn't modify it anymore — it only does queries afterwards. The only place that uses ipuz_charset_remove_text() is the acrostics generator, but that one doesn't do any queries later: it uses the remove_text() operation as part of another algorithm, but only that.

So, I thought of doing this:

  • Split things into a mutable IPuzCharsetBuilder that has the add_text / remove_text operations, and also has a build() operation that consumes the builder and produces an immutable IPuzCharset.

  • IPuzCharset is immutable; it can only be queried.

  • IPuzCharsetBuilder can work with a hash table, which turns the "add a character" operation from O(log n) to O(1) amortized.

  • build() is O(n) on the number of unique characters and is only done once per charset.

  • Make IPuzCharset work with a different hash table that also allows for O(1) operations.

Basics of IPuzCharsetBuilder

IPuzCharsetBuilder is mutable, and it can live on the Rust side as a Box<T> so it can present an opaque pointer to C.

#[derive(Default)]
pub struct CharsetBuilder {
    histogram: HashMap<char, u32>,
}

// IPuzCharsetBuilder *ipuz_charset_builder_new (void); */
#[no_mangle]
pub unsafe extern "C" fn ipuz_charset_builder_new() -> Box<CharsetBuilder> {
    Box::new(CharsetBuilder::default())
}

For extern "C", Box<T> marshals as a pointer. It's nominally what one would get from malloc().

Then, simple functions to create the character counts:

impl CharsetBuilder {
    /// Adds `text`'s character counts to the histogram.
    fn add_text(&mut self, text: &str) {
        for ch in text.chars() {
            self.add_character(ch);
        }
    }

    /// Adds a single character to the histogram.
    fn add_character(&mut self, ch: char) {
        self.histogram
            .entry(ch)
            .and_modify(|e| *e += 1)
            .or_insert(1);
    }
}

The C API wrappers:

use std::ffi::CStr;

// void ipuz_charset_builder_add_text (IPuzCharsetBuilder *builder, const char *text);
#[no_mangle]
pub unsafe extern "C" fn ipuz_charset_builder_add_text(
    builder: &mut CharsetBuilder,
    text: *const c_char,
) {
    let text = CStr::from_ptr(text).to_str().unwrap();
    builder.add_text(text);
}

CStr is our old friend that takes a char * and can wrap it as a Rust &str after validating it for UTF-8 and finding its length. Here, the unwrap() will panic if the passed string is not UTF-8, but that's what we want; it's the equivalent of an assertion that what was passed in is indeed UTF-8.

// void ipuz_charset_builder_add_character (IPuzCharsetBuilder *builder, gunichar ch);
#[no_mangle]
pub unsafe extern "C" fn ipuz_charset_builder_add_character(builder: &mut CharsetBuilder, ch: u32) {
    let ch = char::from_u32(ch).unwrap();
    builder.add_character(ch);
}

Somehow, the glib-sys crate doesn't have gunichar, which is just a guint32 for a Unicode code point. So, we take in a u32, and check that it is in the appropriate range for Unicode code points with char::from_u32(). Again, a panic in the unwrap() means that the passed number is out of range; equivalent to an assertion.

Converting to an immutable IPuzCharset 

pub struct Charset {
    /// Histogram of characters and their counts plus derived values.
    histogram: HashMap<char, CharsetEntry>,

    /// All the characters in the histogram, but in order.
    ordered: String,

    /// Sum of all the counts of all the characters.
    sum_of_counts: usize,
}

/// Data about a character in a `Charset`.  The "value" in a key/value pair where the "key" is a character.
#[derive(PartialEq)]
struct CharsetEntry {
    /// Index of the character within the `Charset`'s ordered version.
    index: u32,

    /// How many of this character in the histogram.
    count: u32,
}

impl CharsetBuilder {
    fn build(self) -> Charset {
        // omitted for brevity; consumes `self` and produces a `Charset` by adding
        // the counts for the `sum_of_counts` field, and figuring out the sort
        // order into the `ordered` field.
    }
}

Now, on the C side, IPuzCharset is meant to also be immutable and reference-counted. We'll use Arc<T> for such structures. One cannot return an Arc<T> to C code; it must first be converted to a pointer with Arc::into_raw():

// IPuzCharset *ipuz_charset_builder_build (IPuzCharsetBuilder *builder);
#[no_mangle]
pub unsafe extern "C" fn ipuz_charset_builder_build(
    builder: *mut CharsetBuilder,
) -> *const Charset {
    let builder = Box::from_raw(builder); // get back the Box from a pointer
    let charset = builder.build();        // consume the builder and free it
    Arc::into_raw(Arc::new(charset))      // Wrap the charset in Arc and get a pointer
}

Then, implement ref() and unref():

// IPuzCharset *ipuz_charset_ref (IPuzCharset *charet);
#[no_mangle]
pub unsafe extern "C" fn ipuz_charset_ref(charset: *const Charset) -> *const Charset {
    Arc::increment_strong_count(charset);
    charset
}

// void ipuz_charset_unref (IPuzCharset *charset);
#[no_mangle]
pub unsafe extern "C" fn ipuz_charset_unref(charset: *const Charset) {
    Arc::decrement_strong_count(charset);
}

The query functions need to take a pointer to what really is the Arc<Charset> on the Rust side. They reconstruct the Arc with Arc::from_raw() and wrap it in ManuallyDrop so that the Arc doesn't lose a reference count when the function exits:

// gsize ipuz_charset_get_n_chars (const IPuzCharset *charset);
#[no_mangle]
pub unsafe extern "C" fn ipuz_charset_get_n_chars(charset: *const Charset) -> usize {
    let charset = ManuallyDrop::new(Arc::from_raw(charset));
    charset.get_n_chars()
}

Tests

The C tests remain intact; these let us test all the #[no_mangle] wrappers.

The Rust tests can just be for the internals, simliar to this:

    #[test]
    fn supports_histogram() {
        let mut builder = CharsetBuilder::default();

        let the_string = "ABBCCCDDDDEEEEEFFFFFFGGGGGGG";
        builder.add_text(the_string);
        let charset = builder.build();

        assert_eq!(charset.get_size(), the_string.len());

        assert_eq!(charset.get_char_count('A').unwrap(), 1);
        assert_eq!(charset.get_char_count('B').unwrap(), 2);
        assert_eq!(charset.get_char_count('C').unwrap(), 3);
        assert_eq!(charset.get_char_count('D').unwrap(), 4);
        assert_eq!(charset.get_char_count('E').unwrap(), 5);
        assert_eq!(charset.get_char_count('F').unwrap(), 6);
        assert_eq!(charset.get_char_count('G').unwrap(), 7);

        assert!(charset.get_char_count('H').is_none());
    }

Integration with the build system

Libipuz uses meson, which is not particularly fond of cargo. Still, cargo can be used from meson with a wrapper script and a bit of easy hacks. See the merge request for details.

Further work

I've left the original C header file ipuz-charset.h intact, but ideally I'd like to automatically generate the headers from Rust with cbindgen. Doing it that way lets me check that my assumptions of the extern "C" ABI are correct ("does foo: &mut Foo appear as Foo *foo on the C side?"), and it's one fewer C-ism to write by hand. I need to see what to do about inline documentation; gi-docgen can consume C header files just fine, but I'm not yet sure about how to make it work with generated headers from cbindgen.

I still need to modify the CI's code coverage scripts to work with the mixed C/Rust codebase. Fortunately I can copy those incantations from librsvg.

Is it faster?

Maybe! I haven't benchmarked the acrostics generator yet. Stay tuned!

the avatar of Hollow Man's Blog
the avatar of Hollow Man's Blog

My Igalia Coding Experience 2023 I & II at Wolvic

Wolvic is a fast and secure browser for standalone virtual-reality and augmented-reality headsets. ex. Mozilla Firefox Reality.

Project summaries

List of things I have done

PRs opened/handled

Issues opened/helped with