Planet Debian

Mexico’s education sector had one of the longest lockdowns due to COVID: As everybody, we “went virtual” in March 2020, and it was only by late February 2022 that I went back to teach presentially at the University.

But for the semester starting next Tuesday, I’m going back to a full-online mode. Why? Because me and my family will be travelling to Argentina for six months, starting this October and until next March. When I went to ask for my teaching to be “frozen” for two semesters, the Head of Division told me he was actually looking for teachers wanting to do distance-teaching — With a student population of >380,000 students, and not being able to grow the physical infrastructure, and with such a big city as Mexico City, where a person can take ove 2hr to commute daily… It only makes sense to offer part of the courses online.

To be honest, I’m a bit nervous about this. The past couple of days, I’ve been setting up again the technological parts (i.e. spinning up a Jitsi instance, remembering my usual practices and programs). But… Well, I know that being videoconference-bound, my teaching will lose the dynamism that comes from talking face to face with students. I think I will miss it!

(but at the same time, I’m happy to try this anew: to go virtual, but where students choosing this modality do so by choice rather than because the world forced them to)

I used to rely on ifupdown to bring up my iptables firewall automatically using a config like this in /etc/network/interfaces:

allow-hotplug eno1 iface eno1 inet dhcp pre-up iptables-restore /etc/network/iptables.up.rules iface eno1 inet6 dhcp pre-up ip6tables-restore /etc/network/ip6tables.up.rules

but I wanted to modernize my network configuration and make use of systemd-networkd after upgrading one of my servers to Debian bookworm.

Since I already wrote an iptables dispatcher script for NetworkManager, I decided to follow the same approach for systemd-networkd.

I started by installing networkd-dispatcher:

apt install networkd-dispatcher

and then adding a script for the routable state in /etc/networkd-dispatcher/routable.d/iptables:

#!/bin/sh LOGFILE=/var/log/iptables.log if [ "$IFACE" = lo ]; then echo "$0: ignoring $IFACE for \`$STATE'" >> $LOGFILE exit 0 fi case "$STATE" in routable) echo "$0: restoring iptables rules for $IFACE" >> $LOGFILE /sbin/iptables-restore /etc/network/iptables.up.rules >> $LOGFILE 2>&1 /sbin/ip6tables-restore /etc/network/ip6tables.up.rules >> $LOGFILE 2>&1 ;; *) echo "$0: nothing to do with $IFACE for \`$STATE'" >> $LOGFILE ;; esac

before finally making that script executable (otherwise it won't run):

chmod a+x /etc/NetworkManager/dispatcher.d/pre-up.d/iptables

With this in place, I can put my iptables rules in the usual place (/etc/network/iptables.up.rules and /etc/network/ip6tables.up.rules) and use the handy iptables-apply and ip6tables-apply commands to test any changes to my firewall rules.

Looking at /var/log/iptables.log confirms that it is being called correctly for each network interface as they are started.

I designed and printed a "terrain" base for my 3D castle in OpenSCAD. The castle was the first thing I designed and printed on our (then new) office 3D printer. I use it as a test bed if I want to try something new, and this time I wanted to try procedurally generating a model.

I've released the OpenSCAD source for the terrain generator under the name Zarchscape.

mid 90s terrain generation

Lots of mid-90s games had very boxy floors

Terrain generation, 90s-style. From this article

Back in the 90s I spent some time designing maps/levels/arenas for Quake and its sibling games (like Half-Life), mostly in the tool Worldcraft. A lot of beginner maps (including my own), ended up looking pretty boxy. I once stumbled across an article blog post that taught my a useful trick for making more natural-looking terrain. In brief: tessellate the floor region with triangle polygons, then randomly add some jitter to the z-dimension for their vertices. A really simple technique with fairly dramatic results.

OpenSCAD

Doing the same in OpenSCAD stretched me, and I think stretched OpenSCAD. It left me with some opinions which I'll try to write up in a future blog post.

Final results

I've generated and printed the result a couple of times, including an attempt a multicolour print.

At home, I have a large spool of brown-coloured recycled PLA, and many small lengths of samples in various colours (that I picked up at Maker Faire Czech Republic last year), including some short lengths of green.

My home printer is a Prusa Mini, and I cheaped out and didn't buy the filament runout sensor, which would detect when the current filament ran out and let me handle the situation gracefully. Instead, I added several colour change instructions to the g-code at various heights, hoping that whatever plastic I loaded for each layer was enough to get the print to the next colour change instruction.

The results are a little mixed I think. I didn't catch the final layer running out in time (forgetting that the Bowden tube also means I need to catch it running out before the loading gear, a few inches earlier than the nozzle), so the final lush green colour ends prematurely. I've also got a fair bit of stringing to clean up.

Finally, all these non-flat planes really show up some of the limitations of regular Slicing. It would be interesting to try this with a non-planar Slicer.

Welcome to the 41th post in the $R^4 series. This post draws on joint experiments first started by Grant building on the lovely work Eitsupi as part of our Rocker Project. In short, r2u is an ideal match for Codesspaces, a Microsoft/GitHub service to run code ‘locally but in the cloud’ via browser or Visual Studio Code. This posts co-serves as the README.md in the .devcontainer directory as well as a vignette for r2u.

So let us get into it. Starting from the r2u repository, the .devcontainer directory provides a small self-containted file devcontainer.json to launch an executable environment R using r2u. It is based on the example in Grant McDermott’s codespaces-r2u repo and reuses its documentation. It is driven by the Rocker Project’s Devcontainer Features repo creating a fully functioning R environment for cloud use in a few minutes. And thanks to r2u you can add easily to this environment by installing new R packages in a fast and failsafe way.

Try it out

To get started, simply click on the green “Code” button at the top right. Then select the “Codespaces” tab and click the “+” symbol to start a new Codespace.

The first time you do this, it will open up a new browser tab where your Codespace is being instantiated. This first-time instantiation will take a few minutes (feel free to click “View logs” to see how things are progressing) so please be patient. Once built, your Codespace will deploy almost immediately when you use it again in the future.

After the VS Code editor opens up in your browser, feel free to open up the examples/sfExample.R file. It demonstrates how r2u enables us install packages and their system-dependencies with ease, here installing packages sf (including all its geospatial dependencies) and ggplot2 (including all its dependencies). You can run the code easily in the browser environment: Highlight or hover over line(s) and execute them by hitting Cmd+Return (Mac) / Ctrl+Return (Linux / Windows).

(Both example screenshots reflect the initial codespaces-r2u repo as well as personal scratchspace one which we started with, both of course work here too.)

Do not forget to close your Codespace once you have finished using it. Click the “Codespaces” tab at the very bottom left of your code editor / browser and select “Close Current Codespace” in the resulting pop-up box. You can restart it at any time, for example by going to https://github.com/codespaces and clicking on your instance.

Extend r2u with r-universe

r2u offers “fast, easy, reliable” access to all of CRAN via binaries for Ubuntu focal and jammy. When using the latter (as is the default), it can be combined with r-universe and its Ubuntu jammy binaries. We demontrates this in a second example file examples/censusExample.R which install both the cellxgene-census and tiledbsoma R packages as binaries from r-universe (along with about 100 dependencies), downloads single-cell data from Census and uses Seurat to create PCA and UMAP decomposition plots. Note that in order run this you have to change the Codespaces default instance from ‘small’ (4gb ram) to ‘large’ (16gb ram).

Local DevContainer build

Codespaces are DevContainers running in the cloud (where DevContainers are themselves just Docker images running with some VS Code sugar on top). This gives you the very powerful ability to ‘edit locally’ but ‘run remotely’ in the hosted codespace. To test this setup locally, simply clone the repo and open it up in VS Code. You will need to have Docker installed and running on your system (see here). You will also need the Remote Development extension (you will probably be prompted to install it automatically if you do not have it yet). Select “Reopen in Container” when prompted. Otherwise, click the >< tab at the very bottom left of your VS Code editor and select this option. To shut down the container, simply click the same button and choose “Reopen Folder Locally”. You can always search for these commands via the command palette too (Cmd+Shift+p / Ctrl+Shift+p).

Use in Your Repo

To add this ability of launching Codespaces in the browser (or editor) to a repo of yours, create a directory .devcontainers in your selected repo, and add the file .devcontainers/devcontainer.json. You can customize it by enabling other feature, or use the postCreateCommand field to install packages (while taking full advantage of r2u).

Acknowledgments

There are a few key “plumbing” pieces that make everything work here. Thanks to:

• My Rocker Project colleague @eitsupi for maintaining the R DevContainer Features.
• @renkun-ken and the rest of the VS Code R extension team.
• @Enchufa2 for bspm making package installation to the sysstem so seamless.
• @grantmcdermott for the initial codespaces-r2u setup from which we derived this.
• Last but not least everybody who helped me make r2u possible, tested it, or sent hints for improvement.

Colophon

More information about r2u is at its site, and we answered some question in issues, and at stackoverflow. More questions are always welcome!

If you like this or other open-source work I do, you can now sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

I have started to make private posts, accessible only to my Dreamwidth access list.

If you’re a friend of mine and would like to be on that list, please contact me with your Dreamwidth username (or your OpenID).

comments

KDE Skrooge snap

It has been a very busy couple of weeks in the KDE snap world! Here is a rundown of what has been done:

• Solved issues with an updated mesa in Jammy causing some apps to seg fault by rebuilding our content pack. Please do a snap refresh if this happens to you.
• Resolved our scanner apps not finding any scanners. Skanlite and Skanpage now work as expected and find your scanners, even network scanners!
• Fixed an issue with neochat/ruqola that relaunching the application just hangs https://forum.snapcraft.io/t/neochat-autoconnect-requests/36331 and https://bugs.kde.org/show_bug.cgi?id=473003 by allowing access to system password manager. Still working out online accounts ( specifically ubuntu-sso )
• Fixed issues with QML and styles not being found or set in many snaps.
• Helped FreeCAD update their snap to core22 ( while not KDE, they do use the kde-neon ext ) https://github.com/FreeCAD/FreeCAD-snap/pull/92
• New applications completed – Skrooge – Qrca – massif-visualizer
• Updating applications to 23.04.3 – half way through – unfortunately our priority for launchpad builders is last so it is a bottleneck until I sort out how to get them to bump that up.
• Updated our content pack to latest in snapcraft upstream for the kde-neon extension.
• Various fixes to ease updating our snapcraft files with new releases ( to ease CI automated releases )

An update to the “Very exciting news coming soon”: While everything went well, it is not (yet!) happening. I do not have the management experience the stakeholders are looking for to run the project. I understand completely! I have the passion and project experience, just not management in this type of project. So with that said, are you a KDE/C++ developer with a management background and have a history of bringing projects to the finishline? Are you interested in an exciting new project with new technologies? Talk to me! I can be reached via sgmoore on the various chat channels, sgmoore at kde dot org, or connect via linkedin and message: https://www.linkedin.com/in/scarlettgatelymoore If you know anyone that might be interested, please point them here!

As this project gets further delayed, it leaves me without an income still. If you or someone you know has any short term contract work let me know. Pesky bills and life expenses don’t pay themselves If you can spare some change ( anything helps ) please consider a donation. https://gofund.me/5d0691bc

A big thank you to the community for making my work possible thus far!

A couple of weeks ago I had to undergo surgery, because one of my kidneys malfunctioned. Everything went well and I’m on my way to recovery. Luckily the most recent local heat wave was over just shortly after I got home, which made being stuck at home a little easier (not sure yet when I’ll be allowed to do sports again, I miss my climbing gym…).

At first I did not have that much energy to do computer stuff, but after a week or so I was able to sit in front of the screen for short amounts of time and I started to get into writing Rust code again.

carl

The first thing I did was updating carl. I updated all the dependencies and switched the dependency that does coloring from ansi_term, which is unmaintained, to nu-ansi-term. When I then updated the clap dependency to version 4 I realized that clap now depends on the anstyle crate for text styling - so I updated carls coloring code once again so it now uses anstyle, which led to less dependencies overall. Implementing this change I also did some refactoring of the code.

carl how also has its own website as well as a subdomain1.

I also added a couple of new date properties to carl, namely all weekdays as well as odd and even - this means it is now possible choose a separate color for every weekday and have a rainbow calendar:

This is included in version 0.1.0 of carl, which I published on crates.io.

typelerate

Then I started writing my first game - typelerate. It is a copy of the great typespeed, without the multiplayer support.

To describe the idea behind the game, I quote the typespeed website:

Typespeed’s idea is ripped from ztspeed (a DOS game made by Zorlim). The Idea behind the game is rather easy: type words that are flying by from left to right as fast as you can. If you miss 10 or more words, game is over.

Instead of the multiplayer support, typelerate works with UTF-8 strings and it also has another game mode: in typespeed you only type whats scrolling via the screen. In typelerate I added the option to have one or more answer strings. One of those has to be typed instead of the word flying across the screen. This lets you implement kind of an question/answer game. To be backwards compatible with the existing wordfiles from typespeed2, the wordfiles for the question/answer games contain comma separated values. The typelerate repository contains wordfiles with Python and Rust keywords as well as wordfiles where you are shown an Emoji and you have to type the corresponding Github shortcode. I’m happy to add additional wordfiles (there could be for example math questions…).

marsrover

Another commandline game I really like, because I am fascinated by the animated ASCII graphics, is the venerable moon-buggy. In this game you have to drive a vehicle across the moon’s surface and deal with obstacles like craters or aliens.

I reimplemented the game in rust and called it marsrover:

I published it on crates.io, you can find the repository on github. The game uses a configuration file in $XDG_CONFIG_HOME/marsrover/config.toml - you can configure the colors of the elements as well as the levels. The game comes with four levels predefined, but you can use the configuration file to override that list of levels with levels with your own properties. The level properties define the probabilities of obstacles occuring on your way on the mars surface and a points setting that defines how many points the user can get in that level (=the game switches to the next level if the user reaches the points).

[[levels]] prob_ditch_one = 0.2 prob_ditch_two = 0.0 prob_ditch_three = 0.0 prob_alien = 0.5 points = 100

After the last level, the game generates new ones on the fly.

1. thanks to the service from https://cli.rs. ↩︎

2. actually, typelerate is not backwards compatible with the typespeed wordfiles, because those are not UTF-8 encoded ↩︎