Librsvg is almost rustified now
Since a few days ago, librsvg's library implementation is almost 100% Rust code. Paolo Borelli's and Carlos Martín Nieto's latest commits made it possible.
What does "almost 100% Rust code" mean here?
-
The C code no longer has struct fields that refer to the library's real work. The only field in
RsvgHandlePrivateis an opaque pointer to a Rust-side structure. All the rest of the library's data lives in Rust structs. -
The public API is implemented in C, but it is just stubs that immediately call into Rust functions. For example:
gboolean
rsvg_handle_render_cairo_sub (RsvgHandle * handle, cairo_t * cr, const char *id)
{
g_return_val_if_fail (RSVG_IS_HANDLE (handle), FALSE);
g_return_val_if_fail (cr != NULL, FALSE);
return rsvg_handle_rust_render_cairo_sub (handle, cr, id);
}
-
The GObject boilerplate and supporting code is still in C:
rsvg_handle_class_initandset_propertyand friends. -
All the high-level tests are still done in C.
-
The gdk-pixbuf loader for SVG files is done in C.
Someone posted a chart on Reddit about the rustification of librsvg, comparing lines of code in each language vs. time.
Rustifying the remaining C code
There is only a handful of very small functions from the public API still implemented in C, and I am converting them one by one to Rust. These are just helper functions built on top of other public API that does the real work.
Converting the gdk-pixbuf loader to Rust seems like writing a little glue code for the loadable module; the actual loading is just a couple of calls to librsvg's API.
Rsvg-rs in rsvg?
Converting the tests to Rust... ideally this would use the rsvg-rs bindings; for example, it is what I already use for rsvg-bench, a benchmarking program for librsvg.
I have an unfinished branch to merge the rsvg-rs repository into librsvg's own repository. This is because...
- Librsvg builds its library,
librsvg.so - Gobject-introspection runs on
librsvg.soand the source code, and produceslibrsvg.gir - Rsvg-rs's build system calls gir on
librsvg.girto generate the Rust binding's code.
As you can imagine, doing all of this with Autotools is... rather convoluted. It gives me a lot of anxiety to think that there is also an unfinished branch to port the build system to Meson, where probably doing the .so→.gir→rs chain would be easier, but who knows. Help in this area is much appreciated!
An alternative?
Rustified tests could, of course, call the C API of librsvg by hand,
in unsafe code. This may not be idiomatic, but sounds like it could
be done relatively quickly.
Future work
There are two options to get rid of all the C code in the library, and just leave C header files for public consumption:
-
Do the GObject implementation in Rust, using Sebastian Dröge's work from GStreamer to do this easily.
-
Work on making gnome-class powerful enough to implement the librsvg API directly, and in an ABI-compatible fashion to what there is right now.
The second case will probably build upon the first one, since one of my plans for gnome-class is to make it generate code that uses Sebastian's, instead of generating all the GObject boilerplate by hand.
KDE Connect CLI | A gift to Future Self
Beautiful GitHub labels with Terraform
On GitHub there are the GitHub issues, and they have become quite powerful over time. Just recently GitHub added the capability to show related issues, pin issues to repositories and to move them between repositories.
One important tool to manage issues on GitHub are labels, those nicely colored badges you can add to issues to get a better overview, to filter lists and queries, or to build further automation such as the presentation of good first issues to people new to the project.
If you have a lot of labels it tends to become a bit of effort to manage them well, especially if you want to keep colors consistent and descriptions up to date. It becomes even more effort when you try to do so across different repositories. We have all seen the psychedelic potpourri of colorful labels which tends to happen when you use labels generously.
Last year I saw Mitchell Hashimoto's excellent talk about anything as code at the Open Source Datacenter Conference in Berlin. He showed there how to use Terraform to manage infrastructure as code beyond the typical management of computing infrastructure such as servers or networks. He showed how to use it for more administrative tasks such as managing teams on GitHub.
This is a great approach because it replaces clicking around in a user interface by a more programming-like approach of maintaining configurations, preferably version controlled, and applying the same rules on them as on code. So you can do pull requests, review changes, have the history of what happened in git, run tests and other automation easily, etc.
The GitHub provider for Terraform also handles labels so I thought I would give it a try to manage labels as code. Directly doing this in the Terraform configuration is possible but it's a bit cumbersome and limited in what you can do with the data in this format. So I decided to put the data into a good old YAML file and writing a bit of Python code to deal with it.
The result is beautiful-labels, a small tool to manage GitHub labels from a YAML description via Terraform. It scans your repository for existing labels and their data, creates a YAML description from it, and then provides you the tools to turn it into a Terraform configuration.
Terraform is great in handling the state of things in the cloud, it takes care of operating the API in an effective way, figuring out what needs to be updated, and gives the user control, for example by providing a dry run which tells what would change without applying the changes yet. This is all quite convenient and powerful.
One thing beautiful-labels is supposed to make easy is the management of label colors. In addition to the convenience of managing them in YAML instead of having to use the UI, it also adds the option to generate an overview of the labels as SVG, nicely grouped in categories. This helps in grouping things together using colors and generally can augment documentation about how you intend labels to be used.
The tool is in an early state but it works. I use it to manage the labels in the inqlude repository on GitHub.
You could add another step of automation by letting CI run Terraform on commits to the YAML file. Maybe something to try for the future. As managing labels is not something you usually do on a daily basis, some manual step might also be good enough.
One caveat with labels is that GitHub uses the name of the label as identifier. That usually works great but can be a bit tricky when changing the name of a label. For this case I recommend to do it in the GitHub UI for now.
There are some other approaches how to do this kind of stuff. One of them is labeler which is a nice tool written in Go to manage labels from a YAML description. It directly operates the GitHub API. The advantage is that it's self-contained but it lacks the power of Terraform in terms of state management. Another is Zach Dunn's post "How we organize GitHub issue: A simple styleguide for tagging" which introduces the notion of color-coded categories.
It's wonderful when pieces come together, such as the GitHub API, Terraform, YAML, git, and people writing open source code around that. They result in a way to beautifully manage labels without having to put in too much effort.
If you have feedback or input please don't hesitate to drop me a line. I would be happy if beautiful-labels would be useful for you as well. Let me know how it goes. :-)
Ultimate 64 | A New Commodore 64 main board
The worst ANSI art renderer, except for all the others

Chafa (github) started out as a small piece of supporting code for an obscure personal project I may announce at some indefinite point in the future. Then I decided to release it as a tongue-in-cheek thing for the VT100 anniversary last year, and, well… it gathered a bit of steam.
Chafa 1.0
Since I'm not one to leave well enough alone, I packaged it up over the holidays for the 1.0 release. It brings a pile of improvements, e.g. new symbol ranges like ASCII and Braille, better image preprocessing and a new --fill option for halftone/dithering. It's also, like, real fast now, and the build is much less brittle.
Big thanks to everyone who contributed to this release: Adam Borowski, Felix Yan, Lajos Papp, Mo Zhou, Ricardo Arguello, Robert-André Mauchin, @dcb314 and @medusacle.
You'll find packages out there for Arch, Debian, Fedora, Gentoo and Ubuntu now; check your repositories. Extra big thanks to the package maintainers.
As the post title implies, I think Chafa is now the least bad tool in this tiny but tradition-rich niche. So what's so not-quite-terrible about it?
Only the best for your aixterm
If you've been around text terminals for a while, you'll know what this means:
Up until fairly recently, the most colorful terminal applications would operate within the confines of some variant of the above palette, and many still do. It's a nice and distinct (not to mention cheerful) set of colors, but it's not a great match for most image material you'll come across, which makes legible Chafa output a challenge. And that is precisely why I had to try (here with a nice woodblock print):
The top left image is the best reproduction you can get with Chafa using a modern 24-bit color terminal emulator (in this case, GNOME Terminal) at 60 characters wide. At top right is the 16-color mapping you get without applying any tricks; this is pretty close to the mark given the muted moonlight colors of the input image, but it doesn't make good use of our palette, nor does it convey the essence of the scene very well. Blue sky, rolling hills, green grass. A shady waterfront pavilion. Given our limitations, the output will look nothing like the original anyway, so we're better off trying to capture the gist of it.
We do this simply by cranking up the contrast and saturation to levels where our cheerful old palette can do a decent job (bottom left). Chafa no longer relies on ImageMagick for this, so it's available in the library API, and integer-only math makes it performant enough to run in real time on animations and video (more on this in a later post, perhaps).
It gets even better if you do color assignment in DIN99d space (bottom right), but that's way slow, so you have to explicitly enable it.
No ANSI? No problem
You can generate varied output without any color codes at all. The above examples also demonstrate use of the --fg option, which, along with --bg, exists to tell Chafa what your terminal's default colors look like so it can target those, but is equally useful for tweaking monochrome output thresholds.
So if for some reason your terminal can't handle ANSI or you still have one of those warm & fuzzy monochrome tubes sitting around, we've got you covered. Or break out your civil rights-era dot-matrix printer and make some precision banners to hang in your lab!

Running for openSUSE Board
You might have heard that openSUSE’s board elections are underway for three open seats to be filled. I’ve been thinking about running for board for a while and now it seems to be the right time to step up.
The following text is a plain, unedited copy of my application.
Introduction, Biography and Contributions
My name is Vinzenz Vietzke but sticking with the much short “vinz” or “vinzv” is what I prefer. I’m 34 years, live in a small town in southern Germany. Like most German Linux users around my age I made my first steps with S.u.S.E. back in the late 90s. Over the years I moved across various distributions and contributed to quite a few of them in different ways. My day job is product management and marketing at Linux hardware vendor TUXEDO Computers.
openSUSE and TUXEDO
Starting with just one laptop running openSUSE we at TUXEDO now offer around 20 different models plus a wide range of desktop PCs all with Leap 15 pre-installed. Customers also get free lifetime support for their preinstalled system. Therefore of course our free phone/email tech support team need to be trained for openSUSE as well. For this whole project I was and still am in charge as the tech and project lead so to say to “bring” openSUSE on TUXEDO’s computers. I got in touch with oS, worked out how and when we get everything done.
In addition to technical affairs I’m the pushing person at TUXEDO Computers to make our company step up supporting openSUSE. As a result since October 2018 we are officially sponsoring the openSUSE project. We offer any of our models as demo and workshop devices at no cost and take care for the logistics and event booth support. Furthermore we’re sponsoring oSC19 in Nuremberg with demo and install fest machines.
Of course these things are mainly financial efforts and company internal projects. But yet to get openSUSE a wider reception there needs to be someone coordinating, pushing and taking care. That’s why I call my contributions to openSUSE mostly “meta contributions”.
i18n
Besides the TUXEDO stuff which is partly paid and partly free time efforts I’m coordinating translation teams of upstream Xfce, actively translating openSUSE and quite a lot of other projects. For details please check my profiles at Crowdin, Gnome, Transifex as well as my personal website.
Aims/Goals
Like every volunteer-run project openSUSE has it’s issues to tackle. Most of them are obvious and already under work: consolidating web appearances, cleaning the wiki, sorting out the communication infrastructure and possible extensions to it. I don’t think there’s anything further needed to push these things besides time. The board has done a really awesome job in the past on these things and surely will in the future.
Major and Minor Issues
One of the major issues I experience is public reception like in how openSUSE as a distribution is seen. When people talk about openSUSE they’re mostly telling from their experiences they made (literally!) a decade ago. You ran into some YaST issues in 2011 and this is why you stopped recommending openSUSE and you never ever re-thought your opinion? Jeez. These memories need to get overhauled and put into correct contexts. Most of them are prejudices anyway.
On the other side people who have heard about Linux but hardly any knowledge mostly equate one specific distribution with Linux. Though it’s not technically correct end-users do this – which is fine. But they don’t equate it with openSUSE and that is shame. oS really has come a long way and is easy to install, to run and to use. People just need to know about and this is where the prejudices mentioned earlier come into play. The “tech guy” inside a circle of friends is some multiplier and needs to be convinced that openSUSE is something he totally can recommend in good conscience.
Role of the board
From my perspective the board has two main roles: First and foremost it is some kind of service provider. It serves the whole project as contact point for questions, projects coordination and pointing in directions etc. This is crucial for the whole openSUSE project and should never be changed but merely extended if possible.
The second role might be named as “ideas sparking pot”. Most ideas coming from the community are of a technical nature which is entirely logical. Just sometimes there are things that the whole project would benefit from but no one sees them or has time to do so. This is where the board could jump in throwing sparks and giving input from someone being able to take a step back for viewing the bigger picture.
My role in this board team would both being approachable and helpful for part one. But also to give thoughts and ideas when needed, especially in the second part mentioned.
Why you should vote for me?
I’ve been into Linux and open source communities for about 10 years now. Though I’m not a long term contributor for openSUSE I know how “things work” in such a big, diverse project and how to handle this stuff. If you want to get someone with no “Geeko glasses” on you should vote for me. Not that being deeply inside openSUSE’s community is a bad thing! But I can bring in new perspectives, most of them related to end-users, Windows-ditchers and curious but not tech-savvy people. I both understand developers and tech people on the one hand as well as people who are buying Linux preinstalled hardware with little will to tinker around. This way I act as some proxy between those worlds which in the end might be good for everyone involved.
Conclusion
As elaborated above my main goal boils down to people thinking of easy but powerful Linux when they hear openSUSE. The project in total is big and strong enough to really serve as “the makers’ choice for sysadmins, developers and desktop users” – all of them!
Ask me anything
If you made it this far – thanks for your time and interest. For any questions, comments or disagreements feel free to contact me. I appreciate any of it via:
PeppermintOS | Review from an openSUSE User
Marcar las patas - Dos mesitas de noche, parte 2
Dos mesitas de noche:
- Parte 1: Preparar las piezas
- Parte 2: Marcar las patas
- Parte 3: Los cajones
En la parte 1 preparé la madera para todas las piezas principales de las mesitas de noche / burós. Esto es lo que voy a construir:

Siempre me da nervios que las patas sean tan delgadas que no vayan a aguantar las cajas/espigas a 90° que las unen a los travesaños y a los faldones. Hice un dibujito a escala 1:1 de los ensambles, para ver dónde debían quedar, y para convencerme a mí mismo de que en efecto las patas son suficientemente anchas.

Aquí, los travesaños están a 90° uno del otro y se encuentran con un corte a 45° en las espigas. Todas las medidas las determina el ancho del formón, en este caso, ¼ de pulgada. ¿Por qué pulgadas? Porque las herramientas que tengo así vienen. No me importa mucho la medida numérica de las piezas, pues las marcas que hago en las piezas de madera no son con regla con numeritos, sino que se hacen a partir de un escantillón.
El dichoso escantillón
Una forma muy conveniente de marcar la madera es poner cada pieza sobre un dibujo a escala 1:1 y luego hacer las marcas, en vez de hacerse bolas con una regla con numeritos. Pero para evitarse tener dibujos tan grandes, para piezas no muy complicadas como ésta, se puede hacer un escantillón con una tira de madera: es una guía a escala 1:1 que contiene todas las medidas importantes de la pieza. El escantillón se pone junto a cada pieza y se usa para marcar directo en la pieza, sin andar midiendo con regla. Así no hay errores de medición.
Una de las caras de la tira de madera se usa para marcar las dimensiones verticales, y otra cara para las horizontales. Por ejemplo, aquí transfiero las posiciones horizontales de dónde van las espigas con respecto a las patas:

Cada marca se hace con cuchillo sobre la esquina de la tira de madera. Además, cada marca se pinta con lápiz para poder verla fácilmente, o para hacerle anotaciones y saber cuál es cuál.
Luego, marco todo el ancho del buró en esa cara de la tirita de madera: las dos patas a 40cm una de la otra, y cada pata con su espiga para el travesaño o el faldón.
En la foto siguiente sólo salen esas marcas de una de las patas, y el centro horizontal del buró — que luego me servirá para ubicar la jaladera del cajón.

De igual manera, en otra de las caras del escantillón pongo las dimensiones verticales: la altura final de las patas, y las posiciones del travesaño inferior, el travesaño debajo del cajón y los faldones.

Marcar los travesaños
Aquí es donde el escantillón entra en acción. El chiste es marcar todas las piezas iguales al mismo tiempo, para minimizar errores. Aquí tengo prensados todos los travesaños. Transfiero las marcas del largo total de los travesaños y la posición de las espigas. Para transferir la posición, el cuchillo de marcar se hace entrar en la marca que había en el escantillón, y esto hace que también quede marcada la esquina de una de las piezas.

Se pone el cuchillo de marcar en una de las ranuritas de las marcas, se hace coincidir la escuadra con el cuchillo, y se marcan todas las piezas de un jalón:

Por ahora, lo único que hay que cortar es el largo final de los travesaños. Muevo con cuidado las prensas para no desalinear los travesaños y los serrucho todos de un jalón para que queden idénticos:

Marcar las patas
De igual manera, hay que marcar las patas en su dimensión vertical, es decir, a lo largo. Aquí está la parte interesante del escantillón para las patas:

Se transfieren las marcas...

... se marcan las patas al mismo tiempo con escuadra y cuchillo. Aquí lo hice de cuatro en cuatro, porque es para lo que alcanza mi escuadrita.

Así quedan marcadas todas las patas perfectamente iguales.

¿Cómo distinguimos las patas?
Las patas izquierdas y derechas son imágenes de espejo entre sí, pues el buró es simétrico. Pero las patas traseras y delanteras no lo son: cada pata trasera une dos faldones, pero cada pata delantera une un faldón y el travesaño del cajón.
Para no hacerse bolas, se dibujan triángulos en el extremo de cada juego de patas. La mesita número 1 tiene un triángulo sencillo, y la mesita número 2 tiene un triángulo con líneas dobles:

Así, si las patas se desacomodan, podemos volver a orientarlas armando el triángulo.
Extender las marcas alrededor de las patas
Al marcar todas las patas al mismo tiempo, sólo quedo marcada una de las caras. Sin embargo, se requieren las mismas marcas en una de las caras adyacentes. Hay que tomar cada pata y transferir cada marca de forma individual. Se puede hacer así, o volviendo a prensar todas las patas según lo requieren.

Marcas con el gramil
Ahora hay que poner la posición de las espigas. Se puede ajustar el gramil junto al escantillón, o transferir las medidas al gramil con una regla; aquí hice lo segundo a partir del escantillón. La separación entre las puntas del gramil es de ¼", igual que el ancho del formón:


Ahora se marca cada pata con el gramil, en el área de cada espiga. Como la espiga no está centrada en ancho de la pata, tuve que tener cuidado de hacer las marcas con respecto a la cara exterior, pues así estaba puesto el gramil.

Así se ven las puntas del gramil al hacer las marcas:

Este proceso se lleva un buen tiempo; son 44 espigas que hay que marcar. Al final verifiqué que en efecto hubiera puesto todas las marcas en donde deben ir; es fácil confundirse y marcar con respecto a la cara incorrecta.
Cortar las cajas con el formón
Ahora hay que cortar las cajas donde van a ir las espigas. Puse cinta azul en el formón para marcar la profundidad máxima a la que debe llegar.

Hay varias técnicas para formonear cajas. Me gusta la de comenzar un corte en V al centro de la caja, con el formón inclinado, ir haciendo la V más grande hacia los extremos.

El último corte en cada extremo es con el formón vertical, para definir la pared de la caja.

Luego hay que batallar un rato con el formón para sacar la basurita.
Las cajas donde van las espigas de los travesaños se encuentran entre sí; es un túnel en la madera en forma de L. Aquí se puede ver el formón desde el otro lado.

Aquí hay un video de cómo corté una caja.
Y bien, fueron dos sesiones a lo largo de dos días de cortar y cortar cajas. Son 44 entre las dos mesitas:

Dos mesitas de noche, parte 2
En la parte 1 preparé la madera para todas las piezas principales de las mesitas de noche / burós. Esto es lo que voy a construir:

Siempre me da nervios que las patas sean tan delgadas que no vayan a aguantar las cajas/espigas a 90° que las unen a los travesaños y a los faldones. Hice un dibujito a escala 1:1 de los ensambles, para ver dónde debían quedar, y para convencerme a mí mismo de que en efecto las patas son suficientemente anchas.

Aquí, los travesaños están a 90° uno del otro y se encuentran con un corte a 45° en las espigas. Todas las medidas las determina el ancho del formón, en este caso, ¼ de pulgada. ¿Por qué pulgadas? Porque las herramientas que tengo así vienen. No me importa mucho la medida numérica de las piezas, pues las marcas que hago en las piezas de madera no son con regla con numeritos, sino que se hacen a partir de un escantillón.
El dichoso escantillón
Una forma muy conveniente de marcar la madera es poner cada pieza sobre un dibujo a escala 1:1 y luego hacer las marcas, en vez de hacerse bolas con una regla con numeritos. Pero para evitarse tener dibujos tan grandes, para piezas no muy complicadas como ésta, se puede hacer un escantillón con una tira de madera: es una guía a escala 1:1 que contiene todas las medidas importantes de la pieza. El escantillón se pone junto a cada pieza y se usa para marcar directo en la pieza, sin andar midiendo con regla. Así no hay errores de medición.
Una de las caras de la tira de madera se usa para marcar las dimensiones verticales, y otra cara para las horizontales. Por ejemplo, aquí transfiero las posiciones horizontales de dónde van las espigas con respecto a las patas:

Cada marca se hace con cuchillo sobre la esquina de la tira de madera. Además, cada marca se pinta con lápiz para poder verla fácilmente, o para hacerle anotaciones y saber cuál es cuál.
Luego, marco todo el ancho del buró en esa cara de la tirita de madera: las dos patas a 40cm una de la otra, y cada pata con su espiga para el travesaño o el faldón.
En la foto siguiente sólo salen esas marcas de una de las patas, y el centro horizontal del buró — que luego me servirá para ubicar la jaladera del cajón.

De igual manera, en otra de las caras del escantillón pongo las dimensiones verticales: la altura final de las patas, y las posiciones del travesaño inferior, el travesaño debajo del cajón y los faldones.

Marcar los travesaños
Aquí es donde el escantillón entra en acción. El chiste es marcar todas las piezas iguales al mismo tiempo, para minimizar errores. Aquí tengo prensados todos los travesaños. Transfiero las marcas del largo total de los travesaños y la posición de las espigas. Para transferir la posición, el cuchillo de marcar se hace entrar en la marca que había en el escantillón, y esto hace que también quede marcada la esquina de una de las piezas.

Se pone el cuchillo de marcar en una de las ranuritas de las marcas, se hace coincidir la escuadra con el cuchillo, y se marcan todas las piezas de un jalón:

Por ahora, lo único que hay que cortar es el largo final de los travesaños. Muevo con cuidado las prensas para no desalinear los travesaños y los serrucho todos de un jalón para que queden idénticos:

Marcar las patas
De igual manera, hay que marcar las patas en su dimensión vertical, es decir, a lo largo. Aquí está la parte interesante del escantillón para las patas:

Se transfieren las marcas...

... se marcan las patas al mismo tiempo con escuadra y cuchillo. Aquí lo hice de cuatro en cuatro, porque es para lo que alcanza mi escuadrita.

Así quedan marcadas todas las patas perfectamente iguales.

¿Cómo distinguimos las patas?
Las patas izquierdas y derechas son imágenes de espejo entre sí, pues el buró es simétrico. Pero las patas traseras y delanteras no lo son: cada pata trasera une dos faldones, pero cada pata delantera une un faldón y el travesaño del cajón.
Para no hacerse bolas, se dibujan triángulos en el extremo de cada juego de patas. La mesita número 1 tiene un triángulo sencillo, y la mesita número 2 tiene un triángulo con líneas dobles:

Así, si las patas se desacomodan, podemos volver a orientarlas armando el triángulo.
Extender las marcas alrededor de las patas
Al marcar todas las patas al mismo tiempo, sólo quedo marcada una de las caras. Sin embargo, se requieren las mismas marcas en una de las caras adyacentes. Hay que tomar cada pata y transferir cada marca de forma individual. Se puede hacer así, o volviendo a prensar todas las patas según lo requieren.

Marcas con el gramil
Ahora hay que poner la posición de las espigas. Se puede ajustar el gramil junto al escantillón, o transferir las medidas al gramil con una regla; aquí hice lo segundo a partir del escantillón. La separación entre las puntas del gramil es de ¼", igual que el ancho del formón:


Ahora se marca cada pata con el gramil, en el área de cada espiga. Como la espiga no está centrada en ancho de la pata, tuve que tener cuidado de hacer las marcas con respecto a la cara exterior, pues así estaba puesto el gramil.

Así se ven las puntas del gramil al hacer las marcas:

Este proceso se lleva un buen tiempo; son 44 espigas que hay que marcar. Al final verifiqué que en efecto hubiera puesto todas las marcas en donde deben ir; es fácil confundirse y marcar con respecto a la cara incorrecta.
Cortar las cajas con el formón
Ahora hay que cortar las cajas donde van a ir las espigas. Puse cinta azul en el formón para marcar la profundidad máxima a la que debe llegar.

Hay varias técnicas para formonear cajas. Me gusta la de comenzar un corte en V al centro de la caja, con el formón inclinado, ir haciendo la V más grande hacia los extremos.

El último corte en cada extremo es con el formón vertical, para definir la pared de la caja.

Luego hay que batallar un rato con el formón para sacar la basurita.
Las cajas donde van las espigas de los travesaños se encuentran entre sí; es un túnel en la madera en forma de L. Aquí se puede ver el formón desde el otro lado.

Aquí hay un video de cómo corté una caja.
Y bien, fueron dos sesiones a lo largo de dos días de cortar y cortar cajas. Son 44 entre las dos mesitas:

Running for the openSUSE Board again…
One period is more quickly left than you can imagine and I am running for re-election for the openSUSE Board!
My name is Sarah Julia Kriesch and I am a work experienced Student in Computer Science at 2 universities.
I am completing my Study Abroad Semester at the University of Bristol at the moment and I have a running IT project at my home university Nuremberg Institute of Technology Georg Simon Ohm. In addition, I am working as a Student Research Assistant at my home university.
- Email: sarah.kriesch@opensuse.org
- Blog: https://sarah-julia-kriesch.eu (my blog)
- facebook: https://www.facebook.com/sarahjulia.kriesch
- LinkedIn: https://www.linkedin.com/in/sarah-julia-kriesch-16874b82
- Connect: https://connect.opensuse.org//pg/profile/AdaLovelace
- Github: https://github.com/skriesch
A lot has happened in the last years and I try to combine my studies with openSUSE Contributions as best as possible. I am the Founder of the Working Group Open Source at the Faculty of Computer Science of the Nuremberg Institute of Technology. We offer workshops in Linux and Open Source bi-weekly. These are open for Students by other Faculties, too. I am the Educator for our Orga Team with Linux Trainers. We have presentations and workshops in cooperation with openSUSE every semester. I want to forward such Open Source education everywhere in Germany.
Our IT project is a migration of our Linux Laboratory from Ubuntu to openSUSE Leap. We automate that with Salt and that all have to work with Kerberos authentication. So our Students are able to use their AD accounts and special sums have to be debited against our student cards for printing with Kerberos tickets then. We are working in cooperation with SUSE here.
I have occupied myself with different units in Bristol. I have HPC, Embedded & Real-Time Systems, Security and Sustainability. I am glad to be allowed to combine a part of my exam in Sustainability with openSUSE. I wanted to create a project plan to improve our Sustainability for my next period in the openSUSE Board. My election pledge is the switch from DVDs to USB flash drives in the marketing material.
My efforts within openSUSE is mainly an education part at our university to receive new openSUSE/ Open Source Contributors and being active as an Advocate at different conferences and expos. I have switched from Germany to the United Kingdom for this semester. This year I will return to Germany. Another role is the Global Coordinator Localization incl. German translations and the Wiki.
Going forward and joining Germany again, I want to concentrate more on the well-being of the openSUSE Community. You don‘t receive new Contributors if you don‘t have the correct climate in the community and some would be unsatisfied. I want to build that on the introduction of the Board publicity by our elected Board Members in the last year. That would improve the collaboration and respect within openSUSE.
I am much obliged to be an elected Board Member for 2 years. I appreciate receiving your votes for a second term.
Thank you in advance!




