This post is part of a series about trying to setup a gitlab runner based on systemd-nspawn. I published the polished result as nspawn-runner on GitHub. New goal: make it easier to configure and maintain chroots. For example, it should be possible to maintain a rolling testing or sid chroot without the need to manually log into it to run apt upgrade. It should be also be easy to have multiple runners reasonably in sync by carrying around a few simple configuration files, representing the set of images available to the CI. Ideally, those configuration files could simply be one ansible playbook per chroot. nspawn-runner could have a 'chroot-maintenance' command that runs all the playbooks on their corresponding chroots, and that would be all I need. ansible and systemd-nspawn ansible being inadequate as usual, it still does not have a nspawn or machinectl connector, even though the need is there, and one can find requests, pull requests, and implementation attempts by all sorts of people, including me. However, I don't want to have nspawn-runner depend on random extra plugins. There's a machinectl become plugin available in ansible from buster-backports, but no matter how I read its scant documentation, looked around the internet, and tried all sorts of things, I couldn't manage to figure out what it is for. This said, simply using systemd-nspawn instead of chroot is quite trivial: use ansible_connection: chroot, set ansible_chroot_exe to this shellscript, and it just works, with things properly mounted, internet access, correct hostnames, and everything: I guess that's a, uhm, plan, I guess? Running playbooks As an initial prototype, I made nspawn check the list of chroots in /var/lib/nspawn-runner, and for each directory found there, check if there's an equivalent .yaml or .yml file next to nspawn-runner. For each chroot+playbook combination, it creates an inventory with the right setup, including the custom chroot command, and runs ansible-playbook. As a prototype it works. I assume once it will see usage there's going to be feedback and fine tuning; meanwhile, I have the beginning of some automated maintenance for the CI chroots. Next step It would be nice to also have nspawn-runner create the chroots from configuration files if they are missing, so that a new runner can be deployed with a minimal effort, and it will proceed to generate all the images required in a single command. For this, I'd like to find a clean way to store the chroot creation command inside the playbooks, to keep just one configuration file per chroot. I'd also like to have it flexible enough to run debootstrap, as well as commands for different distributions. Time will tell. This is probably enough for study/design posts on my blog. Further updates will be in the issue tracker.

I had thought that Emacs C-t was mainly about correcting typos. It turns out to be extremely useful when working on Lisp macros which themselves write macros. This typically involves nested quasiquotation, where you can have multiple alternating sequences of open parentheses and backticks, or of commas, quotation marks and ampersats. While you re working on it you often need to reorder these character sequences and C-t does a great job.

I got a dynamo hub for my bike and a fancy headlight. It's sweet, but I'm discovering that there're no standards for making tail lights work, so I just had to do some light reverse-engineering and soldering. And this is the findings. Different manufacturers do tail lights differently. Most tail lights are not connected directly to the dynamo, but to the headlight instead. Busch+M ller tail lights take an AC signal that looks very similar to what the hub is producing. You're not supposed to hook it up to the hub directly, but it does appear to work, and it's not clear how the headlight's tail-light output is different from the hub input. I haven't scoped it. Supernova tail lights work differently. Some guy on the internet reverse-engineered the headlight circuit showing an LM317 regulator producing 5.9V for the tail light. I have a Supernova E3 tail light (original one; model E161). The case says "6V", which is close to the 5.9V they give it. It wants its 6V, but I don't have a Supernova headlight, so I don't have 6V to give it. I do have a USB charger, so I have 5V instead. Giving it 5V does appear to work, but that results in less brightness than I would like. Presumably the voltage difference is to blame? I took apart the tail light. The circuitry is encased in hot glue. Scraping that off, we can see the action: The circuit looks like this: More or less, this is as expected. The circuit was designed to receive 6V, so the resistances (180 ohms) were selected to produce a certain amount of current. Given 5V, there's less current and less brightness. I can fix this by reducing the amount of resistance to bring the current levels up. I hooked up a power supply to produce 5V and 5.9V, and I measured the voltages in the circuit in those two states. Assume little accuracy in all of this

	5V	5.9V
V across input diode	0.8V	0.8V
V across the resistors	2.37V	3.25V
V across the LEDs	1.83V	1.85V

As expected, the voltages across the diodes are stable, and the resistors see the bulk of the voltage difference. The circuit designers wanted 3.25/180 ~ 18mA. With my reduced voltage I was getting 2.37/180 ~ 13mA instead. So I was 28% less bright than I should have been. That doesn't sound like a lot, but it's hard to tell by just looking at the thing. In any case, I can reduce the resistances to get the higher current at 5V: I want a resistance R of 180/3.25*2.37 ~ 131 ohms. In the interest of doing less work, I simply added more resistors in parallel instead of replacing the existing ones. So I need to add in parallel a resistance R such that 180R/(180+R) = 131. So I want a parallel R ~ 485 ohms. Looking through my box of parts, I don't have any nice surface-mount resistors with anywhere near the right resistance. But I do have through-hole ones at 470 ohms. Close-enough. I did some soldering gymnastics: And I'm done. Haven't done any night rides outside yet with this setup, but in theory this should be bright-enough. And since the resistors are just burning off the excess voltage, and I'm giving it less voltage to burn off, I'm being more efficient than I would have been with 6V and the stock resistors.

Giovanni Boccaccio's Decameron is a book in which there's a pandemic, and a group of seven young women and three young men decide to practice social distancing in a secluded villa just outside of Florence. During two weeks of lockdown, they structure their time wisely, and among other things they spend the evenings telling each other stories. The book is a collection of those stories. The stories vary from the erotic to the tragic, and may trigger some reader. Boccaccio is aware of that, so he starts each chapter with a one line summary that is explicitly intended as a content warning, to give the reader a choice in whether to read the story, or skip to the next one. Boccaccio explains this in the book itself:

However, those who read these tales can leave those they dislike and read those they like. I do not want to deceive anybody, and so all these tales bear written at the head a title explaining what they contain. (link to version in original language)

On top of the very relatable setting, the diversity of stories, the empathy in the narration, the gender inclusivity, and the respect for the reader, it's a pretty good book. It should even be out of copyright! It was written around year 1350.

This post is part of a series about trying to setup a gitlab runner based on systemd-nspawn. I published the polished result as nspawn-runner on GitHub. systemd-nspawn has an interesting --ephemeral option that sets up temporary copy-on-write filesystem snapshots on filesystems that support it, like btrfs. Using copy on write means that one could perform maintenance on the source chroots, without disrupting existing CI sessions. btrfs and copy on write btrfs snapshots work on subvolumes. As I understand it, if one uses btrfs subvolume create instead of mkdir, what is inside the resulting directory is managed as a subvolume that can be snapshotted and managed in all sorts of interesting ways. I managed to delete a subvolume equally well with btrfs subvolume delete and with rm -r. btrfs subvolume snapshot src dst is similar to cp -a, but it makes a copy-on-write snapshot of a btrfs subvolume. If I change nspawn-runner to manage each chroot in its own subvolume, I should be able to build on all these features, and systemd-nspawn should be able to do that, too. There's a cute shortcut to migrate a subdirectory to a subvolume: create the subvolume, then use cp -r --reflink to populate the subvolume with the directory contents. systemd-nspawn and btrfs Passing -x/--ephemeral to systemd-nspawn makes it do all the transient copy-on-write work automatically: It also works on a directory that is not a subvolume, making reflinks of its contents instead of a subvolume snapshot, although this has a performance penalty on setup: Snapshotting a subvolume: Reflink-ing a subdirectory: Detecting filesystem type I can change nspawn-runner to use btrfs-specific features only when /var/lib/nspawn-runner is on btrfs. Here's a command to detect the filesystem type: nspawn-runner updated I've refactored nspawn-runner splitting backend and frontend code, and implementing multiple backends based on what's the filesystem type of /var/lib/nspawn-runner/. It works really nicely, and with no special configuration required: if /var/lib/nspawn-runner is on btrfs, things run faster, with less kludges, and one can do maintenance on the base chroots without interfering with running CI jobs. Next step The next step is making it easier to configure and maintain chroots. For example, it should be possible to maintain a rolling testing or sid chroot without the need to manually log into it to run apt upgrade.

This is the eleventh part in a series of blog posts. The previous post was FlashFloppy OLED display. The whole series is available here: Amiga.

It's still mostly all quiet on the Amiga project front. The last few months with both my kids at home have been too difficult and busy with no time for side projects. Primary Schools in the UK went back this week, and I've finally got around to installing the Gotek floppy emulator inside the Amiga A500's chassis. I followed A short "Internal Gotek Floppy" Installation Guide , which explains that you don't need to print (or buy) a special mount for it: Simply removing the Gotek's top plastic case is enough for it to fit inside, and you can support it with some nuts and bolts. Easy in theory, but it still took me a while, with plenty of trial and error to line it up just right. I ended up using some M4 bolts and smaller (the kind that you use in electrical sockets) to support the bottom part of the Gotek case in three places: one, at the front, re-using an original vertical support for the old floppy drive; and two at the back, screwing through two holes in the A500's outer case and mainboard. If I'd chosen short enough bolts, the back of the Gotek case could have probably just rested on the ends of those bolts, but the ones I had were another few cm longer, so I drilled holes in the Gotek case to run the bolts through, and secured it with nuts. In that guide, the author has an OLED display for their Gotek that they wanted on the top of the Amiga case, so they fed the four tiny wires through the grill. I had a go at that, but I've got the OLED display and a rotary encoder, so that's 8 wires total, and damn fiddly. Instead for now I've just routed them all out through the hole left behind by the floppy drive's Button. I'm going to try and tidy it up with some heat shrink or similar. So finally, my Amiga is one "unit" again, without dangly bits hanging off it (if you ignore those 8 tiny wires for now) that I can move around to store or use much more easily.

While I'm overall very happy about my migration to an OpenPGP hardware token, the process wasn't entirely seamless and I had to hack around some issues, for example the PIN caching behavior in GnuPG. As described in this bug the cache-ttl parameter in GnuPG is not implemented and thus does nothing. This means once you type in your PIN, it is cached for as long as the token is plugged. Security-wise, this is not great. Instead of manually disconnecting the token frequently, I've come up with a script that restarts scdameon if the token hasn't been used during the last X minutes. It seems to work well and I call it using this cron entry: */5 * * * * my_user /usr/local/bin/restart-scdaemon To get a log from scdaemon, you'll need a ~/.gnupg/scdaemon.conf file that looks like this: Hopefully it can be useful to others!

I switched from Jekyll to Hugo last week for a variety of reasons. One thing that was missing was a port of the jekyll-static-comments plugin that I used to use. I liked it because it saved readers from being tracked by Disqus or other comments solutions, and it required no javascript. To comment, users would email me their comment following a template attached to the bottom of each post. I then piped their email through a script to add it to the right post. As an added benefit, I could delegate comment spam detection to my mail server. I ve managed to reimplement this setup using Hugo. For those who are interested in a similar setup, here is what you need to do.

Pages with comments Instead of being single files, pages need to be leaf bundles. For example, this means that your blog post must be located at /content/blog/2021-03-12-static-comments-in-hugo/index.md instead of /content/blog/2021-03-12-static-comments-in-hugo.md. This lets you store the comments as page resources in the subdirectory /content/blog/2021-03-12-static-comments-in-hugo/comments/.

Partials You should create a comments.html partial and include it in the layout for the pages which should get comments:

<div class="post-comments">
  <p class="comment-notice"><b>Comments</b>: To comment on this post,
	send me an email following the template below. Your email address
	will not be posted, unless you choose to include it in
	the <span style="font-family: monospace;">link:</span> field.</p>
  <pre class="comment-notice">
To: Your Name &lt;your.email<span>@</span>example.org&gt;
Subject: [blog-comment]   .Page.RelPermalink  
post_id:   .Page.RelPermalink  
author: [How should you be identified? Usually your name or "Anonymous"]
link: [optional link to your website]
Your comments here. Markdown syntax accepted.</pre>
    $scratch := newScratch  
    $scratch.Set "comments" (.Resources.Match "comments/*yml")  
    if eq 1 (len ($scratch.Get "comments"))  
  <h2>1 Comment</h2>
    else  
  <h2>  len ($scratch.Get "comments")   Comments</h2>
    end  
    range ($scratch.Get "comments")  
  <div class="post-comment  % cycle 'odd', 'even' % ">
	  $comment := (.Content   transform.Unmarshal)  
	<span class="post-meta">
		 - $comment.date   dateFormat "Jan 2, 2006 at 15:04" - 
	</span>
	<h3 class="comment-header">
	    if $comment.link  
	  <a href="  $comment.link  ">  $comment.author  </a>
	    else  
	    $comment.author  
	    end  
	  <br />
	</h3>
	  $comment.comment   markdownify  
  </div>
    end  
</div>

Comments To associate comments received by email to posts, I pipe them from mutt (using the keybinding) to the following (admittedly janky) shell script. It takes the comment, reformats it appropriately, and puts it in the post s comments subdirectory. Note that it determines which filename to use based on the email s contents, so make sure to check that the email doesn t contain anything nefarious before you pipe it into the script!

#!/bin/sh
# Copyright (C) 2016-2021 Ryan Kavanagh <rak@rak.ac>
# Distributed under the ISC license
BLOG_BASE="/media/t/work/blog"
MESSAGE=$(cat)
EMAIL=$(echo "$ MESSAGE "   grep "From:"   sed -e 's/From[^<]*<\?\([^>]*\)>\?.*/\1/g;s/@/-at-/g')
DATE=$(echo "$ MESSAGE "   grep "Date:"   sed -e 's/Date:\s*//g'   xargs -0 date -Iseconds -u -d)
POST_ID=$(echo "$ MESSAGE "   grep "post_id:"   sed -e 's/post_id: //g')
COMMENTS_DIR="$ BLOG_BASE /content/$ POST_ID /comments/"
COMMENT_FILE="$ COMMENTS_DIR /$ DATE _$ EMAIL .yml"
# Strip out the email headers and whitespace until the start of the comment
COMMENT_WHOLE=$(echo "$ MESSAGE "   sed -e '/^\s*$/,$!d;/^[^\s]/,$!d')
# Indent everything after the comment header
COMMENT_INDENTED=$(echo "$ COMMENT_WHOLE "   sed -e '/^\s*$/,$ s/.*/  &/g ')
# And add the comment header
COMMENT_PREFIXED=$(echo "$ COMMENT_INDENTED "   sed -e '0,/^\s*$/ s/^\s*$/comment:  / ')
[ -d "$ COMMENTS_DIR " ]   mkdir -p "$ COMMENTS_DIR "
echo "Saving the comment to $ COMMENT_FILE "
echo "date: $ DATE "   tee "$ COMMENT_FILE "
echo "$ COMMENT_PREFIXED "   tee -a "$ COMMENT_FILE "

For example, the following comment in an email body:

post_id: /blog/2021-03-12-static-comments-in-hugo/
author: Ryan Kavanagh
link: https://rak.ac/
Dear self,
Here is a test comment for your blog post.
It supports *markdown* **syntax** and  stuff .
Best,
Yourself

results in a file content/blog/2021-03-12-static-comments-in-hugo/comments/2021-03-12T18:47:25+00:00_rak-at-example.org.yml containing:

date: 2021-03-12T18:47:25+00:00
post_id: /blog/2021-03-12-static-comments-in-hugo/
author: Ryan Kavanagh
link: https://rak.ac/
comment:  
  Dear self,

  Here is a test comment for your blog post.
  It supports *markdown* **syntax** and  stuff .

  Best,
  Yourself  

You can see the rendered output at the bottom of this page.

The diffoscope maintainers are pleased to announce the release of diffoscope version 169. This version includes the following changes: You find out more by visiting the project homepage.

I've decided to post regular summaries of all the articles written here about QSoas; this is the first post of this kind. All the articles related to QSoas can be found here also. The articles written here can be separated into several categories. Tutorials to analyze real data These are posts about how to reproduce the data analysis of published articles, including links to the original data so you can fully reproduce our results.

• how to determine the \(K_m\) of enzymes working with gaseous substrates with electrochemistry, as in Domnik et al, Angewandte Chemie 2017.

These posts all have the label tutorial. All about fits QSoas has a particularly powerful interface for non-linear least square minimisations (fits):

• See here to learn how you can take advantage of the fit interface to explore easily how a parameter influences the shape of a function.
• See here how you can produce smooth curves for a fit on jaggy data.

Meta-data Meta data describe the conditions in which experiments were performed.

• You can see here how to use them in data analysis, to plot for instance peak position as a function of meta-data;
• You can see here how to permanently store meta-data for files.

Quiz and their solutions Quiz are small problems that take some skill to solve; they can teach you a lot about how to work with QSoas.

• Quiz #1: computing the standard deviation of spectra, along with the solution. This quiz can teach you a lot about combining data from different datasets and manipulating data row-by-row.

Other tips and tricks

• See here how to find the 0s of experimental data.
• See here how one can save just the selected points in a baseline, and reuse them.
• See here to learn how to generate many datasets in one go from a mathematical formula.
• See here how to define a custom mathematical function using Ruby.
• See here how one can take advantage of Ruby, the underlying programming language to sum columns, extend the values of columns with lots of missing values and rename datasets using a pattern.
• See here how you can use QSoas without starting the graphical interface !

Release annoucements These have generally lot of general information about the possibilities in QSoas:

• initial release;
• version 2.0;
• version 2.1;
• version 2.2;
• and, finally, version 3.0.

About QSoas QSoas is a powerful open source data analysis program that focuses on flexibility and powerful fitting capacities. It is released under the GNU General Public License. It is described in Fourmond, Anal. Chem., 2016, 88 (10), pp 5050 5052. Current version is 3.0. You can download its source code there (or clone from the GitHub repository) and compile it yourself, or buy precompiled versions for MacOS and Windows there.

I d like to briefly introduce my new project, Consfigurator:

Consfigurator is a system for declarative configuration management using Common Lisp. You can use it to configure hosts as root, deploy services as unprivileged users, build and deploy containers, and produce disc images. [not all of these are implemented yet, but the design permits them to be] Consfigurator s design gives you a great deal of flexibility about how to control the hosts you want to configure. If there is a command you can run which will obtain input and output streams attached to an interactive POSIX sh running on the target host/container, then with a little glue code, you can use much of Consfigurator s functionality to configure that host/container. But if it is possible to get an implementation of Common Lisp started up on the host, then Configurator can transparently execute your deployment code over on the remote side, rather than exchanging information via POSIX sh. This lets you use the full power of Common Lisp to deploy your configuration. Configurator has convenient abstractions for combining these different ways to execute your configuration on hosts with different ways of connecting to them. Connections can be arbitrarily nested. For example, to combine SSHing to a Debian machine as an unprivileged user, using sudo to become root, and then starting up a Lisp image to execute your deployment code, you would evaluate

    (deploy ((:ssh (:sudo :as "spwhitton@athena.example.com") :debian-sbcl)) athena.example.com)

Declarative configuration management systems like Consfigurator and Propellor share a number of goals with projects like the GNU Guix System and NixOS. However, tools like Consfigurator and Propellor try to layer the power of declarative and reproducible configuration on top of traditional, battle-tested unix system administration infrastructure like apt, dpkg, yum, and distro package archives, rather than seeking to replace any of those. Let s get as much as we can out of all that existing distro policy-compliant work!

Please check out the user s manual, which includes a tutorial/quick start guide, and come join us in #consfigurator on irc.oftc.net. It s early days but you can already do a fair few things with Consfigurator. It s a good time to come help get all the basic properties defined!

5 years ago today, I was declaring Iceweasel dead, and Firefox was making a come back in Debian. I hadn t planned to make this post, and in fact, I thought it had been much longer. But coincidentally, I was binge-watching Mr. Robot recently, which prominently featured Iceweasel. Mr. Robot is set in the year 2015, and I was surprised that Iceweasel was being used, which led me to search for that post where I announced Firefox was back and realizing that we were close to the 5 years mark. Well, we are at the 5 years mark now. I d normally say time flies, but it turns out it hasn t flown as much as I thought it did. I wonder if the interminable pandemic is to blame for that.

Armadillo is a powerful and expressive C++ template library for linear algebra aiming towards a good balance between speed and ease of use with a syntax deliberately close to a Matlab. RcppArmadillo integrates this library with the R environment and language and is widely used by (currently) 841 other packages on CRAN. This release brings us a second update within the Armadillo 10.2 series, one month after the initial release. Upstream work has commenced at a 10.3 series with first pre-releases which we are currently testing. If possible, CRAN release will continue to be at least one month apart (such as this time) but we continue to make interim releases available on the Rcpp drat repo repo. The full set of changes follows.

Changes in RcppArmadillo version 0.10.2.2.0 (2021-03-09)

• Upgraded to Armadillo release 10.2.2 (Cicada Swarm)
  • faster handling of subcubes
  • added tgamma()
  • added .brief_print() for abridged printing of matrices & cubes
  • expanded forms of trimatu() and trimatl() with diagonal specification to handle sparse matrices
  • expanded eigs_sym() and eigs_gen() with optional shift-invert mode
• Removed debian/ directory from repository as packaging is on salsa.debian.org.
• Relaxed tolerance on two cube tests on Windows to accomodate new 'gcc10-UCRT' builder.

Courtesy of my CRANberries, there is a diffstat report relative to previous release. More detailed information is on the RcppArmadillo page. Questions, comments etc should go to the rcpp-devel mailing list off the R-Forge page. If you like this or other open-source work I do, you can 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.

(Edit: this is CVE-2021-1000002)

Linksys produces a series of wifi mesh routers under the Velop line. These routers use MQTT to send messages to each other for coordination purposes. In the version I tested against, there was zero authentication on this - anyone on the local network is able to connect to the MQTT interface on a router and send commands. As an example:
mosquitto_pub -h 192.168.1.1 -t "network/master/cmd/nodes_temporary_blacklist" -m ' "data": "client": "f8:16:54:43:e2:0c", "duration": "3600", "action": "start" '
will ask the router to block the client with MAC address f8:16:54:43:e2:0c from the network for an hour. Various other MQTT topics pass parameters to shell scripts without quoting them or escaping metacharacters, so more serious outcomes may be possible.

The vendor has released two firmware updates since report - I have not verified whether either fixes this, but the changelog does not indicate any security issues were addressed.

Timeline:

2020-07-30: Submitted through the vendor's security vulnerability report form, indicating that I plan to disclose in either 90 days or after a fix is released. The form turns out to file a Bugcrowd submission.
2020-07-30: I claim the Bugcrowd submission.
2020-08-19: Vendor acknowledges the issue, is able to reproduce and assigns it a P3 priority.
2020-12-15: I ask if there's an update.
2021-02-02: I ask if there's an update.
2021-02-03: Bugcrowd raise a blocker on the issue, asking the vendor to respond.
2021-02-17: I ask for permission to disclose.
2021-03-09: In the absence of any response from the vendor since 2020-08-19, I violate Bugcrowd disclosure policies and unilaterally disclose.

comments

Until this week I did not know about the column command.

$ head -5 zillow.csv
"Index", "Living Space (sq ft)", "Beds", "Baths", "Zip", "Year", "List Price ($)"
1, 2222, 3, 3.5, 32312, 1981, 250000
2, 1628, 3, 2, 32308, 2009, 185000
3, 3824, 5, 4, 32312, 1954, 399000
4, 1137, 3, 2, 32309, 1993, 150000

Turned out this file is much more readable with a good pipe (and a large screen)
$ head -5 zillow.csv column --table --separator ,
"Index" "Living Space (sq ft)" "Beds" "Baths" "Zip" "Year" "List Price ($)"
1 2222 3 3.5 32312 1981 250000
2 1628 3 2 32308 2009 185000
3 3824 5 4 32312 1954 399000
4 1137 3 2 32309 1993 150000

column is part of util-linux and is thus available in all distributions.
Example file taken from this example list.

tldr: Rust/coreutils ( https://github.com/uutils/coreutils/ ) is now available in Debian, good enough to boot a Debian with GNOME, install the top 1000 packages, build Firefox, the Linux Kernel and LLVM/Clang. Even if I wrote more than 100 patches to achieve that, it will probably be a bumpy ride for many other use cases.
It is also a terrific project to learn Rust. See the list of good first bugs. Even if I see Rust code every day at Mozilla, I was looking for an actual personal project (i.e. this isn't a Mozilla project) to learn Rust during the various COVID lockdowns. I started contributing to the alternative Coreutils developed in Rust. The project aims at proposing a drop-in replacement of the C-based GNU Coreutils, and I wanted to evaluate if this could be used to run a regular Debian. Similar to what I have done with clang.debian.net a few years ago (rebuilding the Debian archive using clang instead of gcc). I expect that most of the readers know what is the Coreutils. It is a set of programs performing simple operations (copy/move file, change permissions/ownership, etc). Even if some commands are from the 70s, they are at the base of Linux, Unix and macOS. While different implementations can be found, they are trying to remain compatible in terms of arguments, options, etc. This implementation of Coreutils isn t different! If you want to learn more about the history of Unix, I recommend this great Corecursive podcast with Brian Kernighan. While a lot of people contributed to this project, much was left to be done:

• missing programs to be implemented. See https://github.com/uutils/coreutils#utilities
• missing options in the various programs
  
• code not following latest Rust best practices
• lack of consistency in the code base (ex: functions with too many arguments)
• lack of tests/low code coverage
  
• Lots of failures when running the GNU Coreutils testsuite (141 tests pass on 613) - Some trivial to fix, some others harder A good way to start on a Rust project!
  
  

To start easy, I defined 4 goals for this work:

1. Package Coreutils in Debian/Ubuntu
2. Boot a Debian system with a Rust-based coreutils
3. Install the top 1000 packages in Debian - including GNOME
4. Build Firefox, the Linux Kernel and LLV/Clang
   

Packaging of Coreutils in Debian Packaging in Debian isn't a trivial or even simple task. It requires uploading independently all the dependencies in the archive. Rust, with its new ecosystem and small crates, is making this task significantly harder. The package is called rust-coreutils - https://tracker.debian.org/pkg/rust-coreutils For Debian/Ubuntu users, to have an idea of the complexity of packaging such applications, just run
debtree --build-dep rust-coreutils dot -Tsvg > coreutils.svg (should be around 1M). Since it isn't production ready, the rust-coreutils is installable in parallel with coreutils. This package does NOT replace the GNU/coreutils files (yet?), the new files are installed in /usr/lib/cargo/bin/. They can be used with: export PATH=/usr/lib/cargo/bin/:$PATH Or, uglier, overriding the files with the new ones.

Booting Debian with rust-coreutils To achieve this, because I knew I would likely break the image a few times, I created a new project to quickly install a full Debian with PXE and preseed. The project is available here: https://github.com/opencollab/qemu-debian-install-pxe-preseed/ A script to create the full qemu image: build_qemu_debian_image.sh A second script to boot on the newly created image: boot.sh Then, building and installing coreutils on the system (yeah, it is ugly - don t do that at home): apt install rust-coreutils
cd /usr/lib/cargo/bin/
for f in *; do
cp -f $f /usr/bin/
done
First surprise, unlike the old init.d init system, as systemd is not relying on a series of scripts (it is mostly written in C), replacing the coreutils did not have an impact. Therefore, I didn't experience any issue during the boot process

Installing the most popular Debian packages Debian packages rely a lot on post-install scripts (stored in /var/lib/dpkg/info/*) to finalize and configure packages. They are (almost?) all using /bin/sh (or /bin/bash) to perform these actions. They intensively call coreutils applications. For example, in /var/lib/dpkg/info/exim4-base.postinst, we can find: install -d -oDebian-exim -gadm -m2750 /var/log/exim4 With an ugly script, we can test the installations of the 1000 most popular packages one by one. Running this, some classes of issues in Rust/coreutils could be easily identified.

Implementing missing options A significant number of problems could be easily identified as a lack of support for some options. Here is a list of most of the fixes I had to implement to make this plan work:

• Implement ln --relative: https://github.com/uutils/coreutils/pull/1540
  update-initramfs: Generating /boot/initrd.img-4.19.0-12-amd64
ln: error: Unrecognized option: 'r'
  
  

• Implement cp --archive: https://github.com/uutils/coreutils/pull/1580
  cp: error: Option 'archive' not yet implemented.
  
  

• Implement cp --no-dereference: https://github.com/uutils/coreutils/pull/1528
  cp: error: Option 'dereference' not yet implemented.
  
  
• Implement sync -fs: https://github.com/uutils/coreutils/pull/1639

• Implement install --owner & --group: https://github.com/uutils/coreutils/pull/1641

• Implement mktemp -t https://github.com/uutils/coreutils/pull/1677
• ...

Different behavior Most of the programs behaved as expected. Here is a list of differences:

• install doesn't support using /dev/null as source file
  Setting up libreoffice-common (1:6.1.5-3+deb10u6) ...
install: error: install: cannot install /dev/null to /etc/apparmor.d/local/usr.lib.libreoffice.program.oosplash : the source path is not an existing regular file A limitation of rust itself https://github.com/rust-lang/rust/issues/79390

• mkdir --parent is sometime used (instead of --parents) - https://github.com/uutils/coreutils/commit/dbc716546b352c8b81af1952915137049ed12239

• "install foo.txt bar.txt" didn't work - https://github.com/uutils/coreutils/pull/1644
  install: error: target bar.txt is not a directory

• install -d won't fail if a directory already exists - https://github.com/uutils/coreutils/pull/1643

• ls non-existing-file wasn't returning an error code. "if ls" was used by some scripts - https://github.com/uutils/coreutils/pull/1654

• One of the issue was that install -d /tmp/foo could not be executed twice (while the second run with the gnu version wouldn't trigger an error if already existing) - https://github.com/uutils/coreutils/pull/1641
• ...

Compile Firefox, Clang and the Linux Kernel Build systems can vary significantly one from the other. To verify their usage of coreutils, I built these three major projects

Firefox As Firefox relies mostly on Python as a build system, it went smoothly. I didn t encounter any issue. The only unrelated issue that I noticed working on it was apt-key was broken because the script relied on a buggy option of mktemp.

Linux Kernel I identified only two issues compared to GNU Coreutils:

• The chown command on a non-existing symlink target doesn t fail on the GNU version, the Rust one was triggering an error.
  https://github.com/uutils/coreutils/pull/1694
  
• Linux kernel
  ln -fsn ../../x86/boot/bzImage ./arch/x86_64/boot/bzImage
ln: error: Unrecognized option: 'n'

LLVM/Clang The llvm toolchain relies on Cmake. Just like for Firefox, I didn t face any issue.

Comparing with GNU coreutils using its testsuite Recently, James Robson added a new test to run the GNU testsuite on the Rust/coreutils.

# TOTAL: 611
# PASS: 144
# SKIP: 86
# XFAIL: 0
# FAIL: 342
# XPASS: 0
# ERROR: 39
compared to 546 test passing with the GNU version. Even if a bunch of errors are just different outputs, it demonstrates that there is still a long road ahead.

Next steps & contribute First, we will need more motivated contributors to work on this project. Many features remain to be implemented, optimizations to be done (e.g. decreasing the memory usage), etc.
I started to create a list of good first bugs for newcomers: https://github.com/uutils/coreutils/issues?q=is%3Aissue+is%3Aopen+label%3A%22Good+first+bug%22
I will update this list of there is some interest for this project.
Helping improve the support of the GNU coreutils testsuite would be a huge step while being a great way to learn Rust! Then, once it is in a better state, we will be able to make it a reliable alternative in Debian/Ubuntu to the GNU/Coreutils. This might be also interesting for other folks who prefer a BSD license over a GPL.

Timeline of women in science - Wikipedia

this is a timeline of women in science, spanning from ancient history up to the 21st century. While the timeline primarily focuses on women involved with natural sciences such as astronomy, biology, chemistry and physics, it also includes women from the social sciences (e.g. sociology, psychology) and the formal sciences (e.g. mathematics, computer science), as well as notable science educators and medical scientists. The chronological events listed in the timeline relate to both scientific achievements and gender equality within the sciences.

List of women's firsts - Wikipedia

This is a list of women's firsts noting the first time that a woman or women achieved a given historical feat. A shorthand phrase for this development is "breaking the gender barrier" or "breaking the glass ceiling." Other terms related to the glass ceiling can be used for specific fields related to those terms, such as "breaking the brass ceiling" for women in the military and "breaking the stained glass ceiling" for women clergy. Inclusion on the list is reserved for achievements by women that have significant historical impact.

List of Women in Technology International Hall of Fame inductees - Wikipedia

The Women in Technology International Hall of Fame was established in 1996 by Women in Technology International (WITI) to honor women who contribute to the fields of science and technology.

Women in Chemistry Compound Interest

8 March is International Women s Day. As in previous years, I ve put together another edition of this series looking at underappreciated women from chemistry history.

And some men, too:

• I started to write small bios of famous (male) scientists as they'd be written had they been women

FTP master This month I accepted 162 and rejected 28 packages, which is again a small increase compared to last month. The overall number of packages that got accepted was 291. Debian LTS This was my eightieth month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian. This month my all in all workload has been 30h. During that time I did LTS and normal security uploads of:

• [DLA 2551-1] slirp security update two CVEs
• [DLA 2552-1] connman security update two CVEs
• [DLA 2567-1] unrar-free security update three CVEs
• [DLA 2566-1] libbsd security update one CVE
• [DLA 2571-1] openvswitch security update six CVEs
• [DLA 2572-1] wpa security update for one CVE

I also prepared debdiffs for golang-github-appc-cni, wpa and libbsd, which for one reason or another did not result in a DLA yet. Moreover I did some NEW processing and other stuff on security-master. Last but not least I did some days of frontdesk duties. Debian ELTS This month was the thirty-second ELTS month. During my allocated time I uploaded:

• ELA-367-1 for libbsd
• ELA-368-1 for unrar-free
• ELA-370-1 for wpa

Last but not least I did some days of frontdesk duties. Other stuff This month I uploaded new upstream versions of:

• libosmocore
• pyicloud

A recent upload of electrum suffers from the serious bug #981374. On the face of it this is just a missing package dependency: can you help with testing and preparing an updated package to fix this? You don t need to be a Debian Developer to get stuck into this one!

XDG Just throwing this out for wider talk perhaps. I have been silently watching a list called xdg@lists.freedesktop.org. Now the list talks about freedesktop standards which basically is trying to have some sort of standards that all desktop environments can follow. One of the discussions on the specific list shared above is and was about New MimeType fields in .desktop . It is a fascinating thread with many people giving loads of interesting view points. If you are into desktops even casually, you would enjoy the discussions thoroughly. Seriously thinking, I shared the below on the list Hi all, I read quite a bit of the fascinating thread. As a user I have often had to fix the same at my end and at times had to re-fix it again. For me it s the mkv and related media file types. Now I have different applications which are for different things, For e.g. mpv is exclusively the player (followed at times by vlc) for playing the content. Mediainfo to have technical knowledge/bits about the content. ffmpeg for doing some basic stuff (extracting subtitles or adding subtitles etc.) to the content, re-encoding into smaller resolution etc etc. Sadly, none of the solutions as of date tell me if I hover or even go into properties of a mkv file which application does what. I do know this is perhaps a bit outside the discussion having, but does anybody have any ideas? At the very least, it should make the user more aware of what he can do with particular applications perhaps. One way is to perhaps have a database so if I ask in a way that the system understands which are the editors which can be used to manipulate or edit mkv files, it should give me a list available from debian database. I do know that apt, aptitude etc. do try to do something on those lines but it has many shortcomings. And as somebody else mentioned, don t think the solution would be done tomorrow but at least sometime in future. While I stopped at the above on the list, allow me to extrapolate or share a bit more where I am coming from. Somebody did share that this should be actually done by the desktop provider, and GNOME 1 did provide a solution in the early days, now then they have moved to being a more dumb desktop or in their words simplifying. In any case, while I haven t hadn t had the opportunity to see the new MAC desktop, Windows 10 desktop interface is nothing to write home about. All our DE s starting from GNOME, MATE, XFCE, could and should be giving us much more than it has, making users having richer and better experiences than they have today. And while I shared about .mkv (the Matroska Multimedia Container), the above applies and can apply to any file format which can be manipulated in different ways using different tools. I just shared the one I use most often as a use-case scenario. And this should be made easier now that we have processors have multiple cores (for e.g. Intel and AMD quad cores are now there at decent prices) . So would it be too much of an ask to have something which helps people be more productive. As of today, for anybody who is new to either Debian or any X desktop, there is still such a substantial learning curve and more so applications and how they fit in the puzzle and what can be done and what cannot be done. A much screwy thing to add to the mix is file format and which file format version can a particular app. read. The biggest and the most common culprit here is pdf. A good webpage which shares the versions and the comments which tell how people are still having issues with various versions of pdf. Most of the foss tools I use top out at pdf 1.4 which is quite an old format . I am open to testing and debugging if somebody does try decoding the new versions. For me, this is also an issue as most I.T. notices and what not we get, at times I have to try and figure out things, at times go to MS and use an acrobat reader and that is dumb.

Banking There are also lot of banking stuff that we cannot do on free software, especially in India as lot of powerful proprietary interests are there which make sure that no public API s are available, or even if there is, it would be something half-done or after back and forth, they say, this is just for show, as had shared last year. I would probably add another section later to talk about it. From what little I know, in Europe the law mandates that there are public API s not only for banking but wherever public money (read taxpayer money) is involved. Again, not all countries, but some more than others. At least, that is what I had seen over the years. Till later.