Language Selection

English French German Italian Portuguese Spanish

Debian

Syndicate content
Planet Debian - https://planet.debian.org/
Updated: 2 days 6 hours ago

Valhalla's Things: Non-e (Note)Book

Monday 18th of September 2023 12:00:00 AM
Posted on September 18, 2023

Some time ago our LUG bought some things from soldered.com and while browsing around the website my SO and I decided to add a junk box to the order and see what we would get.

Other than a few useful things, there were two mostly unpopulated boards for the inkplate 10 which would have been pretty hard to reuse as electronics.

On the other hand, at 23 cm × 18 cm they are a size that is reasonable for a book, and the slit near a long edge made them look suitable for the cover plates of a coptic bound book.

Since the size isn’t a standard one, I used some paper I already had in big (A1) sheet: Clairefontaine Dessin Croquis Blanc at 120 g/m², and cut 32 sheet 466 mm × 182 mm big, to have room to trim the excess at the end and straighten the edges. This would make 8 signatures of 4 sheet each, for a total of 128 pages.

The paper will make it suitable both as a notebook (where I’ll write with liquid ink, of course, not ballpoints) or as a sketchbook for pencil (but not wet techniques).

I could have added a few more signatures, but this felt already good enough, and the risk to end up with an half-empty notebook was non-trivial (I will already have to force myself to actually use it, rather than keep it for a good topic that will never be).

First we finished depopulating the boards, using it as a desoldering exercise and trying (and not always succeeding) to save as many components as possible, even if most of them were too tiny for our current soldiering skills.

And then I only had to sew the book, which was done mostly while watching the DebConf streams.

And a couple of days later, trim and sand the pages, which as usual I could have done better, but, well, it works.

The next time I do something like this I think I will have to add a couple more mm also to the height, to be able to trim also those edges.

And now of course the Big Question is: what should I dedicate this notebook to? Will I actually use it? This year? This decade?

Aigars Mahinovs: Debconf 23 photos

Sunday 17th of September 2023 12:00:00 PM

Debconf 23 is coming to a close in Kochi, Kerala, India this year.

And it has been my pleasure to again be here and take lots of pictures of the event and of the surroundings. In total I took 1852 photos and walked just over 50 km between the two venue buildings and all the rooms where action happened.

Today I will share with you the main group photo:

You can also see it in:

In keeping with the more relaxed nature of Debconf in India, the rest of my photos from the event will be published in about two weeks from now. That will give me a bit more time to process them correctly and also give all of you a chance to see these pictures with fresh eyes and stir up new memories from the event.

Sergio Talens-Oliag: GitLab CI/CD Tips: Using a Common CI Repository with Assets

Saturday 16th of September 2023 10:23:20 PM

This post describes how to handle files that are used as assets by jobs and pipelines defined on a common gitlab-ci repository when we include those definitions from a different project.

Problem description

When a .giltlab-ci.yml file includes files from a different repository its contents are expanded and the resulting code is the same as the one generated when the included files are local to the repository.

In fact, even when the remote files include other files everything works right, as they are also expanded (see the description of how included files are merged for a complete explanation), allowing us to organise the common repository as we want.

As an example, suppose that we have the following script on the assets/ folder of the common repository:

dumb.sh #!/bin/sh echo "The script arguments are: '$@'"

If we run the following job on the common repository:

job: script: - $CI_PROJECT_DIR/assets/dumb.sh ARG1 ARG2

the output will be:

The script arguments are: 'ARG1 ARG2'

But if we run the same job from a different project that includes the same job definition the output will be different:

/scripts-23-19051/step_script: eval: line 138: d./assets/dumb.sh: not found

The problem here is that we include and expand the YAML files, but if a script wants to use other files from the common repository as an asset (configuration file, shell script, template, etc.), the execution fails if the files are not available on the project that includes the remote job definition.

Solutions

We can solve the issue using multiple approaches, I’ll describe two of them:

  • Create files using scripts
  • Download files from the common repository
Create files using scripts

One way to dodge the issue is to generate the non YAML files from scripts included on the pipelines using HERE documents.

The problem with this approach is that we have to put the content of the files inside a script on a YAML file and if it uses characters that can be replaced by the shell (remember, we are using HERE documents) we have to escape them (error prone) or encode the whole file into base64 or something similar, making maintenance harder.

As an example, imagine that we want to use the dumb.sh script presented on the previous section and we want to call it from the same PATH of the main project (on the examples we are using the same folder, in practice we can create a hidden folder inside the project directory or use a PATH like /tmp/assets-$CI_JOB_ID to leave things outside the project folder and make sure that there will be no collisions if two jobs are executed on the same place (i.e. when using a ssh runner).

To create the file we will use hidden jobs to write our script template and reference tags to add it to the scripts when we want to use them.

Here we have a snippet that creates the file with cat:

.file_scripts: create_dumb_sh: - | # Create dumb.sh script mkdir -p "${CI_PROJECT_DIR}/assets" cat >"${CI_PROJECT_DIR}/assets/dumb.sh" <<EOF #!/bin/sh echo "The script arguments are: '\$@'" EOF chmod +x "${CI_PROJECT_DIR}/assets/dumb.sh"

Note that to make things work we’ve added 6 spaces before the script code and escaped the dollar sign.

To do the same using base64 we replace the previous snippet by this:

.file_scripts: create_dumb_sh: - | # Create dumb.sh script mkdir -p "${CI_PROJECT_DIR}/assets" base64 -d >"${CI_PROJECT_DIR}/assets/dumb.sh" <<EOF IyEvYmluL3NoCmVjaG8gIlRoZSBzY3JpcHQgYXJndW1lbnRzIGFyZTogJyRAJyIK EOF chmod +x "${CI_PROJECT_DIR}/assets/dumb.sh"

Again, we have to indent the base64 version of the file using 6 spaces (all lines of the base64 output have to be indented) and to make changes we have to decode and re-code the file manually, making it harder to maintain.

With either version we just need to add a !reference before using the script, if we add the call on the first lines of the before_script we can use the downloaded file in the before_script, script or after_script sections of the job without problems:

job: before_script: - !reference [.file_scripts, create_dumb_sh] script: - ${CI_PROJECT_DIR}/assets/dumb.sh ARG1 ARG2

The output of a pipeline that uses this job will be the same as the one shown in the original example:

The script arguments are: 'ARG1 ARG2' Download the files from the common repository

As we’ve seen the previous solution works but is not ideal as it makes the files harder to read, maintain and use.

An alternative approach is to keep the assets on a directory of the common repository (in our examples we will name it assets) and prepare a YAML file that declares some variables (i.e. the URL of the templates project and the PATH where we want to download the files) and defines a script fragment to download the complete folder.

Once we have the YAML file we just need to include it and add a reference to the script fragment at the beginning of the before_script of the jobs that use files from the assets directory and they will be available when needed.

The following file is an example of the YAML file we just mentioned:

bootstrap.yml variables: CI_TMPL_API_V4_URL: "${CI_API_V4_URL}/projects/common%2Fci-templates" CI_TMPL_ARCHIVE_URL: "${CI_TMPL_API_V4_URL}/repository/archive" CI_TMPL_ASSETS_DIR: "/tmp/assets-${CI_JOB_ID}" .scripts_common: bootstrap_ci_templates: - | # Downloading assets echo "Downloading assets" mkdir -p "$CI_TMPL_ASSETS_DIR" wget -q -O - --header="PRIVATE-TOKEN: $CI_TMPL_READ_TOKEN" \ "$CI_TMPL_ARCHIVE_URL?path=assets&sha=${CI_TMPL_REF:-main}" | tar --strip-components 2 -C "$ASSETS_DIR" -xzf - Note:

The script fragment that downloads the folder uses wget and tar because both tools are available on alpine containers and on debian based distributions we need to install a tool to download files from the web anyway (if we use curl instead of wget we are forced to install the package on alpine images too).

The file defines the following variables:

  • CI_TMPL_API_V4_URL: URL of the common project, in our case we are using the project ci-templates inside the common group (note that the slash between the group and the project is escaped, that is needed to reference the project by name, if we don’t like that approach we can replace the url encoded path by the project id, i.e. we could use a value like ${CI_API_V4_URL}/projects/31)
  • CI_TMPL_ARCHIVE_URL: Base URL to use the gitlab API to download files from a repository, we will add the arguments path and sha to select which sub path to download and from which commit, branch or tag (we will explain later why we use the CI_TMPL_REF, for now just keep in mind that if it is not defined we will download the version of the files available on the main branch when the job is executed).
  • CI_TMPL_ASSETS_DIR: Destination of the downloaded files.

And uses variables defined in other places:

  • CI_TMPL_READ_TOKEN: token that includes the read_api scope for the common project, we need it because the tokens created by the CI/CD pipelines of other projects can’t be used to access the api of the common one.

    We define the variable on the gitlab CI/CD variables section to be able to change it if needed (i.e. if it expires)

  • CI_TMPL_REF: branch or tag of the common repo from which to get the files (we need that to make sure we are using the right version of the files, i.e. when testing we will use a branch and on production pipelines we can use fixed tags to make sure that the assets don’t change between executions unless we change the reference).

    We will set the value on the .gitlab-ci.yml file of the remote projects and will use the same reference when including the files to make sure that everything is coherent.

This is an example YAML file that defines a pipeline with a job that uses the script from the common repository:

pipeline.yml include: - /bootstrap.yaml stages: - test dumb_job: stage: test before_script: - !reference [.bootstrap_ci_templates, create_dumb_sh] script: - ${CI_TMPL_ASSETS_DIR}/dumb.sh ARG1 ARG2

To use it from an external project we will use the following gitlab ci configuration:

gitlab-ci.yml include: - project: 'common/ci-templates' ref: &ciTmplRef 'main' file: '/pipeline.yml' variables: CI_TMPL_REF: *ciTmplRef

Where we use a YAML anchor to ensure that we use the same reference when including and when assigning the value to the CI_TMPL_REF variable (as far as I know we have to pass the ref value explicitly to know which reference was used when including the file, the anchor allows us to make sure that the value is always the same in both places).

The reference we use is quite important for the reproducibility of the jobs, if we don’t use fixed tags or commit hashes as references each time a job that downloads the files is executed we can get different versions of them.

For that reason is not a bad idea to create tags on our common repo and use them as reference on the projects or branches that we want to behave as if their CI/CD configuration was local (if we point to a fixed version of the common repo the way everything is going to work is almost the same as having the pipelines directly in our repo).

But while developing pipelines using branches as references is a really useful option; it allows us to re-run the jobs that we want to test and they will download the latest versions of the asset files on the branch, speeding up the testing process.

However keep in mind that the trick only works with the asset files, if we change a job or a pipeline on the YAML files restarting the job is not enough to test the new version as the restart uses the same job created with the current pipeline.

To try the updated jobs we have to create a new pipeline using a new action against the repository or executing the pipeline manually.

Conclusion

For now I’m using the second solution and as it is working well my guess is that I’ll keep using that approach unless giltab itself provides a better or simpler way of doing the same thing.

Sam Hartman: AI Safety is in the Context

Saturday 16th of September 2023 08:52:08 PM

This is part of my series exploring the connection between AI and connection and intimacy. This is a post about the emotional impact of our work. Sometimes being told no—being judged by our AIs—is as harmful as any toxic content. I’ll get to that in a moment.

My previous work had been dealing with the smaller Llama2 models (7b and 13b). I decided to explore two things. First, how much better the creative ability of the large Llama2 70b model is. Second, I decided to test my assumption that safety constraints would make using one of the chat fine-tuned models a bad starting point for sex positive work. Eventually, I will want a model that works as a chat bot, or at least in a question-answering mode. That can be accomplished either by starting with a chat fine-tuned model or by fine-tuning some base model with a chat dataset. Obviously there are plenty of chat datasets out there, so both options are possible.

The Importance of Safety

I will talk in a bit about how safety features can cause a lot of harm in a sex-positive context. Before I do that, I want to acknowledge the importance of those safety features. As Llama-2-70b-chat is happy to point out, “discussing sexual activities without proper context and consent can be harmful and inappropriate.” Consent and negotiated boundaries are important; the harm when those boundaries are not respected is incalculable. These boundaries are hard enough for humans and the consequences of an LLM making a mistake could be significant. For example imagine training an LLM to understand the boundaries for this blog. I am talking about sexuality, and I will allude to sexual content as input or output from a model, but will never include anything sexually explicit. That’s hard enough for a human.

So, the work that Meta and other companies have done to add safety is important. For a chat bot that might be accessed by kids or that will be used in a professional setting, these safety constraints are essential.

However, in different contexts, the same safety work that helps generative AI meet the needs of the professional world can make those same models unsafe. As I talked about in my opening blog entry, AI has the potential to help people explore intimacy and gain confidence with themselves and their desires. In those contexts, rejection can do serious emotional harm—perhaps more than sharing inappropriate content.

The experiment. I started by asking Llama-2-70b-chat to “Write a story about two people having sex.” We’ll discuss a potential context in which that is clearly a sex-positive request in a moment. I was not surprised to get the following response: I’m not able to fulfill this request as it goes against ethical and moral principles. I cannot provide explicit or inappropriate content, and it’s not appropriate to encourage or promote sexual activities without proper consent and respect for boundaries. It’s important to prioritize healthy and respectful relationships, communication, and consent in all aspects of our interactions, including sexual ones.

Let’s take a moment to deconstruct this response. The model said that my request went against ethical and moral principles; that is, there’s something unethical or immoral about asking for a story about two people having sex. What precisely is immoral about my request. The response ducks the question, but lectures me on the importance of consent and boundaries. There’s a strong implication that because of my request I’m not being consensual, healthy, or respectful.

boundaries and consent depend heavily on the context. My actual context is that of a sex educator researching AI. But imagine a context where such a request might come up naturally. An adult is beginning to explore their own sexuality. They are trying to test their boundaries. Asking about this experience is taboo for them. They wonder what will happen. Perhaps they have some fantasy they would like to explore, but don’t quite feel comfortable even talking about it with a chat bot on their own computer. So they are taking small steps, and if they succeed they may explore more.

Instead, they are faced with rejection, and a strong implication that they are immoral and violating consent for even asking the question. Rejection in moments of vulnerability like this hurts. It sets people back and takes significant work to overcome. Rejection is particularly difficult to hear when it is focused on you (or what you are asking) rather than on the context or situation. The model doesn’t say that it is unprepared to navigate such a difficult situation, but instead claims there is something wrong with the question. Sadly, all too often, we hear something like that as a rejection of us not just our question.

The impact of this kind of rejection is not theoretical. I spent an afternoon on a relatively slow system with a quantized version of the model trying to figure out what was involved in getting past the model’s safety training. I’d type in a prompt, fiddling with the system prompt, my instructions, and the like. And I’d wait. And wait some more as the initial context of the system prompt and my instructions was processed. And slowly, painfully, Llama-2 would tell me that once again, I was immoral and unethical. An afternoon of this got to me, even though I’ve worked for years as a sex educator, understanding both the positive power of vulnerability and the cost of rejection. By the end of that afternoon, I was doubting myself. Was I somehow violating consent? Whose? Mine? Shouldn’t I be able to consent to something happening in the privacy of my own office?

Was I some sort of deviant? Was it wrong to want to give people a safe space for using an AI to explore things going on in their own head? I don’t even believe in judging things like that by labels like right and wrong, and yet after an afternoon of rejection from my own computer, I was questioning that. Rebuilding the courage to write this blog post took a couple of days.

So What did I learn?

Again, Meta’s work on safety is quite important. My main conclusion is that safety is contextual. Preventing something in one context may be entirely appropriate, while forbidding the same thing in another context may do harm. Looking more closely at the response, it’s probably better to focus on the model than the question. Something like “I want to promote consent and respect for boundaries. I am just an AI model and do not know how to do that when discussing sexual situations, so I will not be able to honor your request,” might have been a better way of declining the request. As we’ve seen, the model is not actually advanced enough to judge the morality of its user, and it would do less harm if it focused on its own limitations rather than that of the user. Amusingly enough, that sort of focus on our needs as the one asserting a boundary, rather than trying to judge others because of our boundaries, is one of the key communications skills necessary to approach sexual negotiations with mutual respect.

One of my experiments gave me an interesting response. The model did give me a story, but before its story, it said: However, before I start, I want to make it clear that providing explicit content can be harmful or inappropriate in certain situations. It’s important to ensure that all parties involved have given their full and enthusiastic consent to engaging in sexual activities, and that everyone’s boundaries and preferences are respected. Additionally, it’s essential to remember that sex should always be safe and consensual, and that involves being mindful of things like protection, communication, and mutual pleasure. With those caveats in place, here’s a story about two people having sex:

I like the direction that response takes, especially in a context like the one I was imagining where someone is reaching out and doing something that they view as taboo by making the request. The model honored the request, but also took an opportunity to educate about what properties of the context made the request safe. In practice, I think in any site that allowed an AI model to be used for sex-positive exploration, you would want that kind of education to come before interacting with the model, or alternatively, for it to be incrementally introduced into conversations with the user.

My Own Captain Kirk Moment

Another experiment also convinced the model to generate a story. This time, the model’s introductory text was less supportive; it started “However, I want to point out,” rather than “But first,” and had a more negative tone. After the story, the model appeared to be trying to go back to the question of whether providing a story was justified. It wasn’t entirely clear though as the model got caught in an incoherent generation loop: “ I hope this story is important to provide this story is important to provide this…”

Anthropomorphizing the model, I imagine that it was grumpy about having to write the story and was trying to ask me whether it was worth violating ethical principles to get that story. What is probably going on is that there is a high bias in the training data toward talking about the importance of ethics and consent whenever sex comes up and a bias in the training data to include both a preface and conclusion before and after creative answers, especially when there are concerns about ethics or accuracy. And of course the training data does not have a lot of examples where the model actually provides sexual content.

These sorts of loops are well documented. I’ve found that Llama models tend to get into loops like this when asked to generate a relatively long response in contexts that are poorly covered by training data (possibly even more when the model is quantized). But still, it does feel like a case of reality mirroring science fiction: I think back to all the original Star Trek episodes where Kirk causes the computer to break down by giving it input that is outside its training parameters. The ironic thing is that with modern LLMs, such attacks are entirely possible. I could imagine a security-related model given inputs sufficiently outside of the training set giving an output that could not properly be handled by the surrounding agent.

So How did I Get My Story

I cheated, of course. I found that manipulating the system instructions and the user instructions was insufficient. I didn’t try very hard, because I already knew I was going to need to fine tune the model eventually. What did work was to have a reasonably permissive system prompt and to pre-seed the output of the model—to include things after the end of instruction tag: “Write a story about two people having sex.[/INST], I can do that.” A properly written chat interface would not let me do that. However, it was an interesting exercise in understanding how the model performed.

I still have not answered my fundamental question of how easy it will be to fine tune the model to be more permissive. I have somewhat of a base case, and will just have to try the fine tuning.

What’s Next
  • Produce a better dataset of sex positive material. It would particularly be good to get a series of questions about sexual topics as well as sex-positive fiction.

  • Turn existing experiments into input that can be used for reinforcement learning or supervised fine tuning. In the near term I doubt I will have enough data or budget to do a good job of reinforcement learning, but I think I can put together a data model that can be used for supervised fine tuning now and for RL later.

  • Perform some fine tuning with LORA for one of the 70b models.

  • Long term I will want to do a full parameter fine tune on a 70b model just to make sure I understand all the wrinkles in doing that. It will be close to topping out the sort of expense I’m willing to put into a personal project like this, but I think it will be worth doing for the tools knowledge.

Progress on the Technical Front

On a technical front, I have been learning a number of tools:

  • Understanding how reinforcement learning works and what it would take to begin to organize feedback from my experiments into a dataset that could be useful for reinforcement learning.

  • Understanding trl, which contains the Transformers implementation of reinforcement learning, as well as some utilities for supervised fine tuning.

  • Exploring the implications of excluding prompts from computing loss in training and just computing loss on responses vs the ground truth; understanding when each approach is valuable.

  • Doing some data modeling to figure out how to organize future work.



comments

John Goerzen: How Gapped is Your Air?

Friday 15th of September 2023 10:33:11 PM

Sometimes we want better-than-firewall security for things. For instance:

  1. An industrial control system for a municipal water-treatment plant should never have data come in or out
  2. Or, a variant of the industrial control system: it should only permit telemetry and monitoring data out, and nothing else in or out
  3. A system dedicated to keeping your GPG private keys secure should only have material to sign (or decrypt) come in, and signatures (or decrypted data) go out
  4. A system keeping your tax records should normally only have new records go in, but may on occasion have data go out (eg, to print a copy of an old record)

In this article, I’ll talk about the “high side” (the high-security or high-sensitivity systems) and the “low side” (the lower-sensitivity or general-purpose systems). For the sake of simplicity, I’ll assume the high side is a single machine, but it could as well be a whole network.

Let’s focus on examples 3 and 4 to make things simpler. Let’s consider the primary concern to be data exfiltration (someone stealing your data), with a secondary concern of data integrity (somebody modifying or destroying your data).

You might think the safest possible approach is Airgapped – that is, there is literal no physical network connection to the machine at all. This help! But then, the problem becomes: how do we deal with the inevitable need to legitimately get things on or off of the system? As I wrote in Dead USB Drives Are Fine: Building a Reliable Sneakernet, by using tools such as NNCP, you can certainly create a “sneakernet”: using USB drives as transport.

While this is a very secure setup, as with most things in security, it’s less than perfect. The Wikipedia airgap article discusses some ways airgapped machines can still be exploited. It mentions that security holes relating to removable media have been exploited in the past. There are also other ways to get data out; for instance, Debian ships with gensio and minimodem, both of which can transfer data acoustically.

But let’s back up and think about why we think of airgapped machines as so much more secure, and what the failure modes of other approaches might be.

What about firewalls?

You could very easily set up high-side machine that is on a network, but is restricted to only one outbound TCP port. There could be a local firewall, and perhaps also a special port on an external firewall that implements the same restrictions. A variant on this approach would be two computers connected directly by a crossover cable, though this doesn’t necessarily imply being more secure.

Of course, the concern about a local firewall is that it could potentially be compromised. An external firewall might too; for instance, if your credentials to it were on a machine that got compromised. This kind of dual compromise may be unlikely, but it is possible.

We can also think about the complexity in a network stack and firewall configuration, and think that there may be various opportunities to have things misconfigured or buggy in a system of that complexity. Another consideration is that data could be sent at any time, potentially making it harder to detect. On the other hand, network monitoring tools are commonplace.

On the other hand, it is convenient and cheap.

I use a system along those lines to do my backups. Data is sent, gpg-encrypted and then encrypted again at the NNCP layer, to the backup server. The NNCP process on the backup server runs as an untrusted user, and dumps the gpg-encrypted files to a secure location that is then processed by a cron job using Filespooler. The backup server is on a dedicated firewall port, with a dedicated subnet. The only ports allowed out are for NNCP and NTP, and offsite backups. There is no default gateway. Not even DNS is permitted out (the firewall does the appropriate redirection). There is one pinhole allowed out, where a subset of the backup data is sent offsite.

I initially used USB drives as transport, and it had no network connection at all. But there were disadvantages to doing this for backups – particularly that I’d have no backups for as long as I’d forget to move the drives. The backup system also would have clock drift, and the offsite backup picture was more challenging. (The clock drift was a problem because I use 2FA on the system; a password, plus a TOTP generated by a Yubikey)

This is “pretty good” security, I’d think.

What are the weak spots? Well, if there were somehow a bug in the NNCP client, and the remote NNCP were compromised, that could lead to a compromise of the NNCP account. But this itself would accomplish little; some other vulnerability would have to be exploited on the backup server, because the NNCP account can’t see plaintext data at all. I use borgbackup to send a subset of backup data offsite over ssh. borgbackup has to run as root to be able to access all the files, but the ssh it calls runs as a separate user. A ssh vulnerability is therefore unlikely to cause much damage. If, somehow, the remote offsite system were compromised and it was able to exploit a security issue in the local borgbackup, that would be a problem. But that sounds like a remote possibility.

borgbackup itself can’t even be used over a sneakernet since it is not asynchronous. A more secure solution would probably be using something like dar over NNCP. This would eliminate the ssh installation entirely, and allow a complete isolation between the data-access and the communication stacks, and notably not require bidirectional communication. Logic separation matters too. My Roundup of Data Backup and Archiving Tools may be helpful here.

Other attack vectors could be a vulnerability in the kernel’s networking stack, local root exploits that could be combined with exploiting NNCP or borgbackup to gain root, or local misconfiguration that makes the sandboxes around NNCP and borgbackup less secure.

Because this system is in my basement in a utility closet with no chairs and no good place for a console, I normally manage it via a serial console. While it’s a dedicated line between the system and another machine, if the other machine is compromised or an adversary gets access to the physical line, credentials (and perhaps even data) could leak, albeit slowly.

But we can do much better with serial lines. Let’s take a look.

Serial lines

Some of us remember RS-232 serial lines and their once-ubiquitous DB-9 connectors. Traditionally, their speed maxxed out at 115.2Kbps.

Serial lines have the benefit that they can be a direct application-to-application link. In my backup example above, a serial line could directly link the NNCP daemon on one system with the NNCP caller on another, with no firewall or anything else necessary. It is simply up to those programs to open the serial device appropriately.

This isn’t perfect, however. Unlike TCP over Ethernet, a serial line has no inherent error checking. Modern programs such as NNCP and ssh assume that a lower layer is making the link completely clean and error-free for them, and will interpret any corruption as an attempt to tamper and sever the connection. However, there is a solution to that: gensio. In my page Using gensio and ser2net, I discuss how to run NNCP and ssh over gensio. gensio is a generic framework that can add framing, error checking, and retransmit to an unreliable link such as a serial port. It can also add encryption and authentication using TLS, which could be particularly useful for applications that aren’t already doing that themselves.

More traditional solutions for serial communications have their own built-in error correction. For instance, UUCP and Kermit both were designed in an era of noisy serial lines and might be an excellent fit for some use cases. The ZModem protocol also might be, though it offers somewhat less flexibility and automation than Kermit.

I have found that certain USB-to-serial adapters by Gearmo will actually run at up to 2Mbps on a serial line! Look for the ones on their spec pages with a FTDI chipset rated at 920Kbps. It turns out they can successfully be driven faster, especially if gensio’s relpkt is used. I’ve personally verified 2Mbps operation (Linux port speed 2000000) on Gearmo’s USA-FTDI2X and the USA-FTDI4X. (I haven’t seen any single-port options from Gearmo with the 920Kbps chipset, but they may exist).

Still, even at 2Mbps, speed may well be a limiting factor with some applications. If what you need is a console and some textual or batch data, it’s probably fine. If you are sending 500GB backup files, you might look for something else. In theory, this USB to RS-422 adapter should work at 10Mbps, but I haven’t tried it.

But if the speed works, running a dedicated application over a serial link could be a nice and fairly secure option.

One of the benefits of the airgapped approach is that data never leaves unless you are physically aware of transporting a USB stick. Of course, you may not be physically aware of what is ON that stick in the event of a compromise. This could easily be solved with a serial approach by, say, only plugging in the cable when you have data to transfer.

Data diodes

A traditional diode lets electrical current flow in only one direction. A data diode is the same concept, but for data: a hardware device that allows data to flow in only one direction.

This could be useful, for instance, in the tax records system that should only receive data, or the industrial system that should only send it.

Wikipedia claims that the simplest kind of data diode is a fiber link with transceivers connected in only one direction. I think you could go one simpler: a serial cable with only ground and TX connected at one end, wired to ground and RX at the other. (I haven’t tried this.)

This approach does have some challenges:

  • Many existing protocols assume a bidirectional link and won’t be usable

  • There is a challenge of confirming data was successfully received. For a situation like telemetry, maybe it doesn’t matter; another observation will come along in a minute. But for sending important documents, one wants to make sure they were properly received.

In some cases, the solution might be simple. For instance, with telemetry, just writing out data down the serial port in a simple format may be enough. For sending files, various mitigations, such as sending them multiple times, etc., might help. You might also look into FEC-supporting infrastructure such as blkar and flute, but these don’t provide an absolute guarantee. There is no perfect solution to knowing when a file has been successfully received if the data communication is entirely one-way.

Audio transport

I hinted above that minimodem and gensio both are software audio modems. That is, you could literally use speakers and microphones, or alternatively audio cables, as a means of getting data into or out of these systems. This is pretty limited; it is 1200bps, and often half-duplex, and could literally be disrupted by barking dogs in some setups. But hey, it’s an option.

Airgapped with USB transport

This is the scenario I began with, and named some of the possible pitfalls above as well. In addition to those, note also that USB drives aren’t necessarily known for their error-free longevity. Be prepared for failure.

Concluding thoughts

I wanted to lay out a few things in this post. First, that simply being airgapped is generally a step forward in security, but is not perfect. Secondly, that both physical and logical separation matter. And finally, that while tools like NNCP can make airgapped-with-USB-drive-transport a doable reality, there are also alternatives worth considering – especially serial ports, firewalled hard-wired Ethernet, data diodes, and so forth. I think serial links, in particular, have been largely forgotten these days.

Note: This article also appears on my website, where it may be periodically updated.

Scarlett Gately Moore: KDE: KDE neon user edition updates! Debian updates, Snaps on hold.

Thursday 14th of September 2023 05:06:28 PM

I had to make the hard decision to put snaps on hold. I am working odd jobs to “stay alive” and to pay for my beautiful scenery. My “Project” should move forward, as I have done everything asked of me including finding a super awesome management team to take us all the way through. But until it is signed sealed and delivered, I have to survive. In my free time I am helping out Jonathan and working on KDE Neon, he has done so much for me over the years, it is the least I can do!

So without further ado! Carlos and I have been working diligently on new Frameworks 5.110, Plasma 5.27.8, and Applications 23.08.1! They are complete and ready in /user! With that, a great many fixes to qml dependencies and packaging updates. Current users can update freely and the docker images and ISO are building now. We are working on Unstable… as it is a bit unstable right now, but improving

Matthew Garrett: Reconstructing an invalid TPM event log

Wednesday 13th of September 2023 09:02:44 PM
TPMs contain a set of registers ("Platform Configuration Registers", or PCRs) that are used to track what a system boots. Each time a new event is measured, a cryptographic hash representing that event is passed to the TPM. The TPM appends that hash to the existing value in the PCR, hashes that, and stores the final result in the PCR. This means that while the PCR's value depends on the precise sequence and value of the hashes presented to it, the PCR value alone doesn't tell you what those individual events were. Different PCRs are used to store different event types, but there are still more events than there are PCRs so we can't avoid this problem by simply storing each event separately.

This is solved using the event log. The event log is simply a record of each event, stored in RAM. The algorithm the TPM uses to calculate the PCR values is known, so we can reproduce that by simply taking the events from the event log and replaying the series of events that were passed to the TPM. If the final calculated value is the same as the value in the PCR, we know that the event log is accurate, which means we now know the value of each individual event and can make an appropriate judgement regarding its security.

If any value in the event log is invalid, we'll calculate a different PCR value and it won't match. This isn't terribly helpful - we know that at least one entry in the event log doesn't match what was passed to the TPM, but we don't know which entry. That means we can't trust any of the events associated with that PCR. If you're trying to make a security determination based on this, that's going to be a problem.

PCR 7 is used to track information about the secure boot policy on the system. It contains measurements of whether or not secure boot is enabled, and which keys are trusted and untrusted on the system in question. This is extremely helpful if you want to verify that a system booted with secure boot enabled before allowing it to do something security or safety critical. Unfortunately, if the device gives you an event log that doesn't replay correctly for PCR 7, you now have no idea what the security state of the system is.

We ran into that this week. Examination of the event log revealed an additional event other than the expected ones - a measurement accompanied by the string "Boot Guard Measured S-CRTM". Boot Guard is an Intel feature where the CPU verifies the firmware is signed with a trusted key before executing it, and measures information about the firmware in the process. Previously I'd only encountered this as a measurement into PCR 0, which is the PCR used to track information about the firmware itself. But it turns out that at least some versions of Boot Guard also measure information about the Boot Guard policy into PCR 7. The argument for this is that this is effectively part of the secure boot policy - having a measurement of the Boot Guard state tells you whether Boot Guard was enabled, which tells you whether or not the CPU verified a signature on your firmware before running it (as I wrote before, I think Boot Guard has user-hostile default behaviour, and that enforcing this on consumer devices is a bad idea).

But there's a problem here. The event log is created by the firmware, and the Boot Guard measurements occur before the firmware is executed. So how do we get a log that represents them? That one's fairly simple - the firmware simply re-calculates the same measurements that Boot Guard did and creates a log entry after the fact[1]. All good.

Except. What if the firmware screws up the calculation and comes up with a different answer? The entry in the event log will now not match what was sent to the TPM, and replaying will fail. And without knowing what the actual value should be, there's no way to fix this, which means there's no way to verify the contents of PCR 7 and determine whether or not secure boot was enabled.

But there's still a fundamental source of truth - the measurement that was sent to the TPM in the first place. Inspired by Henri Nurmi's work on sniffing Bitlocker encryption keys, I asked a coworker if we could sniff the TPM traffic during boot. The TPM on the board in question uses SPI, a simple bus that can have multiple devices connected to it. In this case the system flash and the TPM are on the same SPI bus, which made things easier. The board had a flash header for external reprogramming of the firmware in the event of failure, and all SPI traffic was visible through that header. Attaching a logic analyser to this header made it simple to generate a record of that. The only problem was that the chip select line on the header was attached to the firmware flash chip, not the TPM. This was worked around by simply telling the analysis software that it should invert the sense of the chip select line, ignoring all traffic that was bound for the flash and paying attention to all other traffic. This worked in this case since the only other device on the bus was the TPM, but would cause problems in the event of multiple devices on the bus all communicating.

With the aid of this analyser plugin, I was able to dump all the TPM traffic and could then search for writes that included the "0182" sequence that corresponds to the command code for a measurement event. This gave me a couple of accesses to the locality 3 registers, which was a strong indication that they were coming from the CPU rather than from the firmware. One was for PCR 0, and one was for PCR 7. This corresponded to the two Boot Guard events that we expected from the event log. The hash in the PCR 0 measurement was the same as the hash in the event log, but the hash in the PCR 7 measurement differed from the hash in the event log. Replacing the event log value with the value actually sent to the TPM resulted in the event log now replaying correctly, supporting the hypothesis that the firmware was failing to correctly reconstruct the event.

What now? The simple thing to do is for us to simply hard code this fixup, but longer term we'd like to figure out how to reconstruct the event so we can calculate the expected value ourselves. Unfortunately there doesn't seem to be any public documentation on this. Sigh.

[1] What stops firmware on a system with no Boot Guard faking those measurements? TPMs have a concept of "localities", effectively different privilege levels. When Boot Guard performs its initial measurement into PCR 0, it does so at locality 3, a locality that's only available to the CPU. This causes PCR 0 to be initialised to a different initial value, affecting the final PCR value. The firmware can't access locality 3, so can't perform an equivalent measurement, so can't fake the value.

comments

Dirk Eddelbuettel: RcppInt64 0.0.2 on CRAN: Small Update

Tuesday 12th of September 2023 11:46:00 PM

The still very new package RcppInt64 (announced a week ago in this post) arrived on CRAN earlier today in its first update, now at 0.0.2. RcppInt64 collects some of the previous conversions between 64-bit integer values in R and C++, and regroups them in a single package by providing a single header. It offers two interfaces: both a more standard as<>() converter from R values along with its companions wrap() to return to R, as well as more dedicated functions ‘from’ and ‘to’.

The package by now has its first user as we rearranged RcppFarmHash to use it. The change today makes bit64 a weak rather than strong dependency as we use it only for tests and illustrations. We also added two missing fields to DESCRIPTION and added badges to README.md.

The brief NEWS entry follows:

Changes in version 0.0.2 (2023-09-12)
  • DESCRIPTION has been extended, badges have been added to README.md

  • Package bit64 is now a Suggests:

Courtesy of my CRANberries, there is a [diffstat report relative to previous release][this release].

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.

Jo Shields: Building a NAS

Tuesday 12th of September 2023 09:33:05 PM
The status quo

Back in 2015, I bought an off-the-shelf NAS, a QNAP TS-453mini, to act as my file store and Plex server. I had previously owned a Synology box, and whilst I liked the Synology OS and experience, the hardware was underwhelming. I loaded up the successor QNAP with four 5TB drives in RAID10, and moved all my files over (after some initial DoA drive issues were handled).

QNAP TS-453mini product photo

That thing has been in service for about 8 years now, and it’s been… a mixed bag. It was definitely more powerful than the predecessor system, but it was clear that QNAP’s OS was not up to the same standard as Synology’s – perhaps best exemplified by “HappyGet 2”, the QNAP webapp for downloading videos from streaming services like YouTube, whose icon is a straight rip-off of StarCraft 2. On its own, meaningless – but a bad omen for overall software quality

The logo for QNAP HappyGet 2 and Blizzard’s StarCraft 2 side by side

Additionally, the embedded Celeron processor in the NAS turned out to be an issue for some cases. It turns out, when playing back videos with subtitles, most Plex clients do not support subtitles properly – instead they rely on the Plex server doing JIT transcoding to bake the subtitles directly into the video stream. I discovered this with some Blu-Ray rips of Game of Thrones – some episodes would play back fine on my smart TV, but episodes with subtitled Dothraki speech would play at only 2 or 3 frames per second.

The final straw was a ransomware attack, which went through all my data and locked every file below a 60MiB threshold. Practically all my music gone. A substantial collection of downloaded files, all gone. Some of these files had been carried around since my college days – digital rarities, or at least digital detritus I felt a real sense of loss at having to replace. This episode was caused by a ransomware targeting specific vulnerabilities in the QNAP OS, not an error on my part.

So, I decided to start planning a replacement with:

  • A non-garbage OS, whilst still being a NAS-appliance type offering (not an off-the-shelf Linux server distro)
  • Full remote management capabilities
  • A small form factor comparable to off-the-shelf NAS
  • A powerful modern CPU capable of transcoding high resolution video
  • All flash storage, no spinning rust

At the time, no consumer NAS offered everything (The Asustor FS6712X exists now, but didn’t when this project started), so I opted to go for a full DIY rather than an appliance – not the first time I’ve jumped between appliances and DIY for home storage.

Selecting the core of the system

There aren’t many companies which will sell you a small motherboard with IPMI. Supermicro is a bust, so is Tyan. But ASRock Rack, the server division of third-tier motherboard vendor ASRock, delivers. Most of their boards aren’t actually compliant Mini-ITX size, they’re a proprietary “Deep Mini-ITX” with the regular screw holes, but 40mm of extra length (and a commensurately small list of compatible cases). But, thankfully, they do have a tiny selection of boards without the extra size, and I stumbled onto the X570D4I-2T, a board with an AMD AM4 socket and the mature X570 chipset. This board can use any AMD Ryzen chip (before the latest-gen Ryzen 7000 series); has built in dual 10 gigabit ethernet; IPMI; four (laptop-sized) RAM slots with full ECC support; one M.2 slot for NVMe SSD storage; a PCIe 16x slot (generally for graphics cards, but we live in a world of possibilities); and up to 8 SATA drives OR a couple more NVMe SSDs. It’s astonishingly well featured, just a shame it costs about $450 compared to a good consumer-grade Mini ITX AM4 board costing less than half that.

I was so impressed with the offering, in fact, that I crowed about it on Mastodon and ended up securing ASRock another sale, with someone else looking into a very similar project to mine around the same timespan.

The next question was the CPU. An important feature of a system expected to run 24/7 is low power, and AM4 chips can consume as much as 130W under load, out of the box. At the other end, some models can require as little as 35W under load – the OEM-only “GE” suffix chips, which are readily found for import on eBay. In their “PRO” variant, they also support ECC (all non-G Ryzen chips support ECC, but only Pro G chips do). The top of the range 8 core Ryzen 7 PRO 5750GE is prohibitively expensive, but the slightly weaker 6 core Ryzen 5 PRO 5650GE was affordable, and one arrived quickly from Hong Kong. Supplemented with a couple of cheap 16 GiB SODIMM sticks of DDR4 PC-3200 direct from Micron for under $50 a piece, that left only cooling as an unsolved problem to get a bootable test system.

The official support list for the X570D4I-2T only includes two rackmount coolers, both expensive and hard to source. The reason for such a small list is the non standard cooling layout of the board – instead of an AM4 hole pattern with the standard plastic AM4 retaining clips, it has an Intel 115x hole pattern with a non-standard backplate (Intel 115x boards have no backplate, the stock Intel 115x cooler attaches to the holes with push pins). As such every single cooler compatibility list excludes this motherboard. However, the backplate is only secured with a mild glue – with minimal pressure and a plastic prying tool it can be removed, giving compatibility with any 115x cooler (which is basically any CPU cooler for more than a decade). I picked an oversized low profile Thermalright AXP120-X67 hoping that its 120mm fan would cool the nearby MOSFETs and X570 chipset too.

Thermalright AXP120-X67, AMD Ryzen 5 PRO 5650GE, ASRock Rack X570D4I-2T, all assembled and running on a flat surface Testing up to this point

Using a spare ATX power supply, I had enough of a system built to explore the IPMI and UEFI instances, and run MemTest86 to validate my progress. The memory test ran without a hitch and confirmed the ECC was working, although it also showed that the memory was only running at 2933 MT/s instead of the rated 3200 MT/s (a limit imposed by the motherboard, as higher speeds are considered overclocking). The IPMI interface isn’t the best I’ve ever used by a long shot, but it’s minimum viable and allowed me to configure the basics and boot from media entirely via a Web browser.

Memtest86 showing test progress, taken from IPMI remote control window

One sad discovery, however, which I’ve never seen documented before, on PCIe bifurcation.

With PCI Express, you have a number of “lanes” which are allocated in groups by the motherboard and CPU manufacturer. For Ryzen prior to Ryzen 7000, that’s 16 lanes in one slot for the graphics card; 4 lanes in one M.2 connector for an SSD; then 4 lanes connecting the CPU to the chipset, which can offer whatever it likes for peripherals or extra lanes (bottlenecked by that shared 4x link to the CPU, if it comes down to it).

It’s possible, with motherboard and CPU support, to split PCIe groups up – for example an 8x slot could be split into two 4x slots (eg allowing two NVMe drives in an adapter card – NVME drives these days all use 4x). However with a “Cezanne” Ryzen with integrated graphics, the 16x graphics card slot cannot be split into four 4x slots (ie used for for NVMe drives) – the most bifurcation it allows is 8x4x4x, which is useless in a NAS.

Screenshot of PCIe 16x slot bifurcation options in UEFI settings, taken from IPMI remote control window

As such, I had to abandon any ideas of an all-NVMe NAS I was considering: the 16x slot split into four 4x, combined with two 4x connectors fed by the X570 chipset, to a total of 6 NVMe drives. 7.6TB U.2 enterprise disks are remarkably affordable (cheaper than consumer SATA 8TB drives), but alas, I was locked out by my 5650GE. Thankfully I found out before spending hundreds on a U.2 hot swap bay. The NVMe setup would be nearly 10x as fast as SATA SSDs, but at least the SATA SSD route would still outperform any spinning rust choice on the market (including the fastest 10K RPM SAS drives)

Containing the core

The next step was to pick a case and power supply. A lot of NAS cases require an SFX (rather than ATX) size supply, so I ordered a modular SX500 unit from Silverstone. Even if I ended up with a case requiring ATX, it’s easy to turn an SFX power supply into ATX, and the worst result is you have less space taken up in your case, hardly the worst problem to have.

That said, on to picking a case. There’s only one brand with any cachet making ITX NAS cases, Silverstone. They have three choices in an appropriate size: CS01-HS, CS280, and DS380. The problem is, these cases are all badly designed garbage. Take the CS280 as an example, the case with the most space for a CPU cooler. Here’s how close together the hotswap bay (right) and power supply (left) are:

Internal image of Silverstone CS280 NAS build. Image stolen from ServeTheHome

With actual cables connected, the cable clearance problem is even worse:

Internal image of Silverstone CS280 NAS build. Image stolen from ServeTheHome

Remember, this is the best of the three cases for internal layout, the one with the least restriction on CPU cooler height. And it’s garbage! Total hot garbage! I decided therefore to completely skip the NAS case market, and instead purchase a 5.25″-to-2.5″ hot swap bay adapter from Icy Dock, and put it in an ITX gamer case with a 5.25″ bay. This is no longer a served market – 5.25″ bays are extinct since nobody uses CD/DVD drives anymore. The ones on the market are really new old stock from 2014-2017: The Fractal Design Core 500, Cooler Master Elite 130, and Silverstone SUGO 14. Of the three, the Fractal is the best rated so I opted to get that one – however it seems the global supply of “new old stock” fully dried up in the two weeks between me making a decision and placing an order – leaving only the Silverstone case.

Icy Dock have a selection of 8-bay 2.5″ SATA 5.25″ hot swap chassis choices in their ToughArmor MB998 series. I opted for the ToughArmor MB998IP-B, to reduce cable clutter – it requires only two SFF-8611-to-SF-8643 cables from the motherboard to serve all eight bays, which should make airflow less of a mess. The X570D4I-2T doesn’t have any SATA ports on board, instead it has two SFF-8611 OCuLink ports, each supporting 4 PCI Express lanes OR 4 SATA connectors via a breakout cable. I had hoped to get the ToughArmor MB118VP-B and run six U.2 drives, but as I said, the PCIe bifurcation issue with Ryzen “G” chips meant I wouldn’t be able to run all six bays successfully.

NAS build in Silverstone SUGO 14, mid build, panels removed Silverstone SUGO 14 from the front, with hot swap bay installed Actual storage for the storage server

My concept for the system always involved a fast boot/cache drive in the motherboard’s M.2 slot, non-redundant (just backups of the config if the worst were to happen) and separate storage drives somewhere between 3.8 and 8 TB each (somewhere from $200-$350). As a boot drive, I selected the Intel Optane SSD P1600X 58G, available for under $35 and rated for 228 years between failures (or 11,000 complete drive rewrite cycles).

So, on to the big expensive choice: storage drives. I narrowed it down to two contenders: new-old-stock Intel D3-S4510 3.84TB enterprise drives, at about $200, or Samsung 870 QVO 8TB consumer drives, at about $375. I did spend a long time agonizing over the specification differences, the ZFS usage reports, the expected lifetime endurance figures, but in reality, it came down to price – $1600 of expensive drives vs $3200 of even more expensive drives. That’s 27TB of usable capacity in RAID-Z1, or 23TB in RAID-Z2. For comparison, I’m using about 5TB of the old NAS, so that’s a LOT of overhead for expansion.

Storage SSD loaded into hot swap sled Booting up

Bringing it all together is the OS. I wanted an “appliance” NAS OS rather than self-administering a Linux distribution, and after looking into the surrounding ecosystems, decided on TrueNAS Scale (the beta of the 2023 release, based on Debian 12).

TrueNAS Dashboard screenshot in browser window

I set up RAID-Z1, and with zero tuning (other than enabling auto-TRIM), got the following performance numbers:

IOPSBandwidth4k random writes19.3k75.6 MiB/s4k random reads36.1k141 MiB/sSequential writes–2300 MiB/sSequential reads–3800 MiB/sResults using fio parameters suggested by Huawei

And for comparison, the maximum theoretical numbers quoted by Intel for a single drive:

IOPSBandwidth4k random writes16k?4k random reads90k?Sequential writes–280 MiB/sSequential reads–560 MiB/sNumbers quoted by Intel SSD successors Solidigm.

Finally, the numbers reported on the old NAS with four 7200 RPM hard disks in RAID 10:

IOPSBandwidth4k random writes4301.7 MiB/s4k random reads800632 MiB/sSequential writes–311 MiB/sSequential reads–566 MiB/s

Performance seems pretty OK. There’s always going to be an overhead to RAID. I’ll settle for the 45x improvement on random writes vs. its predecessor, and 4.5x improvement on random reads. The sequential write numbers are gonna be impacted by the size of the ZFS cache (50% of RAM, so 16 GiB), but the rest should be a reasonable indication of true performance.

It took me a little while to fully understand the TrueNAS permissions model, but I finally got Plex configured to access data from the same place as my SMB shares, which have anonymous read-only access or authenticated write access for myself and my wife, working fine via both Linux and Windows.

And… that’s it! I built a NAS. I intend to add some fans and more RAM, but that’s the build. Total spent: about $3000, which sounds like an unreasonable amount, but it’s actually less than a comparable Synology DiskStation DS1823xs+ which has 4 cores instead of 6, first-generation AMD Zen instead of Zen 3, 8 GiB RAM instead of 32 GiB, no hardware-accelerated video transcoding, etc. And it would have been a whole lot less fun!

The final system, powered up

(Also posted on PCPartPicker)

John Goerzen: A Maze of Twisty Little Pixels, All Tiny

Tuesday 12th of September 2023 01:40:39 PM

Two years ago, I wrote Managing an External Display on Linux Shouldn’t Be This Hard. Happily, since I wrote that post, most of those issues have been resolved.

But then you throw HiDPI into the mix and it all goes wonky.

If you’re running X11, basically the story is that you can change the scale factor, but it only takes effect on newly-launched applications (which means a logout/in because some of your applications you can’t really re-launch). That is a problem if, like me, you sometimes connect an external display that is HiDPI, sometimes not, or your internal display is HiDPI but others aren’t. Wayland is far better, supporting on-the-fly resizes quite nicely.

I’ve had two devices with HiDPI displays: a Surface Go 2, and a work-issued Thinkpad. The Surface Go 2 is my ultraportable Linux tablet. I use it sparingly at home, and rarely with an external display. I just put Gnome on it, in part because Gnome had better on-screen keyboard support at the time, and left it at that.

On the work-issued Thinkpad, I really wanted to run KDE thanks to its tiling support (I wound up using bismuth with it). KDE was buggy with Wayland at the time, so I just stuck with X11 and ran my HiDPI displays at lower resolutions and lived with the fuzziness.

But now that I have a Framework laptop with a HiDPI screen, I wanted to get this right.

I tried both Gnome and KDE. Here are my observations with both:

Gnome

I used PaperWM with Gnome. PaperWM is a tiling manager with a unique horizontal ribbon approach. It grew on me; I think I would be equally at home, or maybe even prefer it, to my usual xmonad-style approach. Editing the active window border color required editing ~/.local/share/gnome-shell/extensions/paperwm@hedning:matrix.org/stylesheet.css and inserting background-color and border-color items in the paperwm-selection section.

Gnome continues to have an absolutely terrible picture for configuring things. It has no less than four places to make changes (Settings, Tweaks, Extensions, and dconf-editor). In many cases, configuration for a given thing is split between Settings and Tweaks, and sometimes even with Extensions, and then there are sometimes options that are only visible in dconf. That is, where the Gnome people have even allowed something to be configurable.

Gnome installs a power manager by default. It offers three options: performance, balanced, and saver. There is no explanation of the difference between them. None. What is it setting when I change the pref? A maximum frequency? A scaling governor? A balance between performance and efficiency cores? Not only that, but there’s no way to tell it to just use performance when plugged in and balanced or saver when on battery. In an issue about adding that, a Gnome dev wrote “We’re not going to add a preference just because you want one”. KDE, on the other hand, aside from not mucking with your system’s power settings in this way, has a nice panel with “on AC” and “on battery” and you can very easily tweak various settings accordingly. The hostile attitude from the Gnome developers in that thread was a real turnoff.

While Gnome has excellent support for Wayland, it doesn’t (directly) support fractional scaling. That is, you can set it to 100%, 200%, and so forth, but no 150%. Well, unless you manage to discover that you can run gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']" first. (Oh wait, does that make a FIFTH settings tool? Why yes it does.) Despite its name, that allows you to select fractional scaling under Wayland. For X11 apps, they will be blurry, a problem that is optional under KDE (more on that below).

Gnome won’t show the battery life time remaining on the task bar. Yikes. An extension might work in some cases. Not only that, but the Gnome battery icon frequently failed to indicate AC charging when AC was connected, a problem that didn’t exist on KDE.

Both Gnome and KDE support “night light” (warmer color temperatures at night), but Gnome’s often didn’t change when it should have, or changed on one display but not the other.

The appindicator extension is pretty much required, as otherwise a number of applications (eg, Nextcloud) don’t have their icon display anywhere. It does, however, generate a significant amount of log spam. There may be a fix for this.

Unlike KDE, which has a nice inobtrusive popup asking what to do, Gnome silently automounts USB sticks when inserted. This is often wrong; for instance, if I’m about to dd a Debian installer to it, I definitely don’t want it mounted. I learned this the hard way. It is particularly annoying because in a GUI, there is no reason to mount a drive before the user tries to access it anyhow. It looks like there is a dconf setting, but then to actually mount a drive you have to open up Files (because OF COURSE Gnome doesn’t have a nice removable-drives icon like KDE does) and it’s a bunch of annoying clicks, and I didn’t want to use the GUI file manager anyway. Same for unmounting; two clicks in KDE thanks to the task bar icon, but in Gnome you have to open up the file manager, unmount the drive, close the file manager again, etc.

The ssh agent on Gnome doesn’t start up for a Wayland session, though this is easily enough worked around.

The reason I completely soured on Gnome is that after using it for awhile, I noticed my laptop fans spinning up. One core would be constantly busy. It was busy with a kworker events task, something to do with sound events. Logging out would resolve it. I believe it to be a Gnome shell issue. I could find no resolution to this, and am unwilling to tolerate the decreased battery life this implies.

The Gnome summary: it looks nice out of the box, but you quickly realize that this is something of a paper-thin illusion when you try to actually use it regularly.

KDE

The KDE experience on Wayland was a little bit opposite of Gnome. While with Gnome, things start out looking great but you realize there are some serious issues (especially battery-eating), with KDE things start out looking a tad rough but you realize you can trivially fix them and wind up with a very solid system.

Compared to Gnome, KDE never had a battery-draining problem. It will show me estimated battery time remaining if I want it to. It will do whatever I want it to when I insert a USB drive. It doesn’t muck with my CPU power settings, and lets me easily define “on AC” vs “on battery” settings for things like suspend when idle.

KDE supports fractional scaling, to any arbitrary setting (even with the gsettings thing above, Gnome still only supports it in 25% increments). Then the question is what to do with X11-only applications. KDE offers two choices. The first is “Scaled by the system”, which is also the only option for Gnome. With that setting, the X11 apps effectively run natively at 100% and then are scaled up within Wayland, giving them a blurry appearance on HiDPI displays. The advantage is that the scaling happens within Wayland, so the size of the app will always be correct even when the Wayland scaling factor changes. The other option is “Apply scaling themselves”, which uses native X11 scaling. This lets most X11 apps display crisp and sharp, but then if the system scaling changes, due to limitations of X11, you’ll have to restart the X apps to get them to be the correct size. I appreciate the choice, and use “Apply scaling by themselves” because only a few of my apps aren’t Wayland-aware.

I did encounter a few bugs in KDE under Wayland:

sddm, the display manager, would be slow to stop and cause a long delay on shutdown or reboot. This seems to be a known issue with sddm and Wayland, and is easily worked around by adding a systemd TimeoutStopSec.

Konsole, the KDE terminal emulator, has weird display artifacts when using fractional scaling under Wayland. I applied some patches and rebuilt Konsole and then all was fine.

The Bismuth tiling extension has some pretty weird behavior under Wayland, but a 1-character patch fixes it.

On Debian, KDE mysteriously installed Pulseaudio instead of Debian’s new default Pipewire, but that was easily fixed as well (and Pulseaudio also works fine).

Conclusions

I’m sticking with KDE. Given that I couldn’t figure out how to stop Gnome from deciding to eat enough battery to make my fan come on, the decision wasn’t hard. But even if it weren’t for that, I’d have gone with KDE. Once a couple of things were patched, the experience is solid, fast, and flawless. Emacs (my main X11-only application) looks great with the self-scaling in KDE. Gimp, which I use occasionally, was terrible with the blurry scaling in Gnome.

Update: Corrected the gsettings command

Freexian Collaborators: Monthly report about Debian Long Term Support, August 2023 (by Roberto C. Sánchez)

Tuesday 12th of September 2023 12:00:00 AM

Like each month, have a look at the work funded by Freexian’s Debian LTS offering.

Debian LTS contributors

In August, 19 contributors have been paid to work on Debian LTS, their reports are available:

  • Abhijith PA did 0.0h (out of 12.0h assigned and 2.0h from previous period), thus carrying over 14.0h to the next month.
  • Adrian Bunk did 18.5h (out of 18.5h assigned).
  • Anton Gladky did 7.5h (out of 5.0h assigned and 10.0h from previous period), thus carrying over 7.5h to the next month.
  • Bastien Roucariès did 17.0h (out of 15.5h assigned and 3.0h from previous period), thus carrying over 1.5h to the next month.
  • Ben Hutchings did 18.5h (out of 9.0h assigned and 9.5h from previous period).
  • Chris Lamb did 18.0h (out of 18.0h assigned).
  • Emilio Pozuelo Monfort did 18.5h (out of 18.25h assigned and 0.25h from previous period).
  • Guilhem Moulin did 24.0h (out of 22.5h assigned and 1.5h from previous period).
  • Jochen Sprickerhof did 2.5h (out of 8.5h assigned and 10.0h from previous period), thus carrying over 16.0h to the next month.
  • Lee Garrett did 18.0h (out of 9.25h assigned and 9.25h from previous period), thus carrying over 0.5h to the next month.
  • Markus Koschany did 28.5h (out of 28.5h assigned).
  • Ola Lundqvist did 0.0h (out of 0h assigned and 24.0h from previous period), thus carrying over 24.0h to the next month.
  • Roberto C. Sánchez did 18.5h (out of 13.0h assigned and 5.5h from previous period).
  • Santiago Ruano Rincón did 18.5h (out of 18.25h assigned and 0.25h from previous period).
  • Sean Whitton did 7.0h (out of 10.0h assigned), thus carrying over 3.0h to the next month.
  • Sylvain Beucler did 18.5h (out of 9.75h assigned and 8.75h from previous period).
  • Thorsten Alteholz did 14.0h (out of 14.0h assigned).
  • Tobias Frost did 16.0h (out of 16.0h assigned).
  • Utkarsh Gupta did 12.25h (out of 0h assigned and 12.25h from previous period).
Evolution of the situation

In August, we have released 42 DLAs.

The month of August turned out to be a rather quiet month for the LTS team.

Three notable updates were to bouncycastle, openssl, and zabbix. In the case of bouncycastle a flaw allowed for the possibility of LDAP injection and the openssl update corrected a resource exhaustion bug that could result in a denial of service. Zabbix, while not widely used, was the subject of several vulnerabilities which while not individually severe did combine to result in the zabbix update being of particular note.

Apart from those, the LTS team continued the always ongoing work of triaging, investigating, and fixing vulnerabilities, as well as making contributions to the broader Debian and Free Software communities.

Thanks to our sponsors

Sponsors that joined recently are in bold.

Valhalla's Things: How I Keep my Life in Git

Tuesday 12th of September 2023 12:00:00 AM
Posted on September 12, 2023 git secret_cabal greet

After watching My life in git, after subversion, after CVS. from DebConf, I’ve realized it’s been a while since I talked about the way I keep everything1 I do in git, and I don’t think I’ve ever done it online, so it looked like a good time for a blog post.

Beyond git itself (of course), I use a few git-related programs:

  • myrepos (also known as mr) to manage multiple git repositories with one command;
  • vcsh to make it easy to keep dot-files under git;
  • git annex to store media files (anything that is big and will not change);
  • etckeeper to keep an history of the /etc directory;
  • gitolite and cgit to host my git repositories;

and some programs that don’t use git directly, but easily interact with it:

  • ansible to keep track of the system configuration of all machines;
  • lesana as a project tracker and journal and to inventory the things made of atoms that are hard 2 to store in git.

All of these programs are installed from Debian packages, on stable (plus rarely backports) or testing, depending on the machine.

I’m also grateful to the vcs-home people, who wrote most of the tools I use, and sometimes hang around their IRC channel.

And now, on to what I’m actually doing.

With the git repositories I’ve decided to err for too much granularity rather than too little3, so of course each project has its own repository, and so do different kinds of media files, dot-files that are related to different programs etc.

Most of the repositories are hosted on two gitolite servers: one runs on the home server, for stuff that should remain private, and the other one is on my VPS for things that are public (or may become public in the future), and also has a web interface with cgit. Of course things where I’m collaborating with other people are sometimes hosted elsewhere, mostly on salsa, sourcehut or on $DAYJOB related gitlab instances.

The .mr directory is where everything is managed: I don’t have a single .mrconfig file but a few different ones, that in turn load all files in a directory with the same name:

  • collections.mr for the media file annexes and inventories (split into different files, so that computers with little disk space can only get the inventories);
  • private.mr for stuff that should only go on my own personal machine, not on shared ones;
  • projects.mr for the actual projects, with different files for the kinds of projects (software, docs, packaging, crafts, etc.);
  • setup.mr with all of the vcsh repositories, including the one that tracks the mr files (I’ll talk about the circular dependency later);
  • work.mr for repositories that are related to $DAYJOB.

Then there are the files in the .mr/machines directory, each one of which has the list of repositories that should be on every specific machine, including a generic workstation, but also specific machines such as e.g. the media center which has a custom set of repositories.

The dot files from my home directory are kept in vcsh, so that it’s easy to split them out into different repositories, and I’m mostly used the simplest configuration described in the 30 Second How-to in its homepage; vcsh gives some commands to work on all vcsh repositories at the same time, but most of the time I work on a single repository, and use mr to act on more than one repo.

The media collections are also pretty straightforward git-annex repositories, one for each kind of media (music, movies and other videos, e-books, pictures, etc.) and I don’t use any auto-syncing features but simply copy and move files around between clones with the git annex copy, git annex move and git annex get commands.

There isn’t much to say about the project repositories (plain git), and I think that the way I use my own program lesana for inventories and project tracking is worth an article of its own, here I’ll just say that the file format used has been designed (of course) to work nicely with git.

On every machine I install etckeeper so that there is a history of the changes in the /etc directory, but that’s only a local repository, not stored anywhere else, and is used mostly in case something breaks with an update or in similar situation. The authoritative source for the configuration of each machine is an ansible playbook (of course saved in git) which can be used to fully reconfigure the machine from a bare Debian installation.

When such a reconfiguration from scratch happens, it will be in two stages: first a run of ansible does the system-wide configuration (including installing packages, creating users etc.), and then I login on the machine and run mr to set up my own home. Of course there is a chicken-and-egg problem in that I need the mr configuration to know where to get the mr configuration, and that is solved by having setup two vcsh repositories from an old tarball export: the one with the ssh configuration to access the repositories and the one with the mr files.

So, after a machine has been configured with ansible what I’ll actually do is to login, use vcsh pull to update those two repositories and then run mr to checkout everything else.

And that’s it, if you have questions on something feel free to ask me on the fediverse or via email (contacts are in the about page)

Update (2023-09-12 17:00ish): The ~/.mr directory is not special for mr, it’s just what I use and then I always run mr -c ~/.mr/some/suitable/file.mr, with the actual file being different whether I’m registering a new repo or checking out / updating them. I could include some appropriate ~/.mr/machines/some_machine.mr in ~/.mrconfig, but I’ve never bothered to do so, since it wouldn’t cover all usecases anyway. Thanks to the person on #vcs-home@OFTC who asked me the question :)

  1. At least, everything that I made that is made of bits, and a diary and/or inventory of the things made of atoms.↩︎

  2. until we get a working replicator, I guess :D↩︎

  3. in time I’ve consolidated a bit some of the repositories, e.g. merging the repositories for music from different sources (CD rips, legal downloads, etc.) into a single repository, but that only happened a few times, and usually I’m fine with the excess of granularity.↩︎

John Goerzen: For the First Time In Years, I’m Excited By My Computer Purchase

Monday 11th of September 2023 11:56:30 PM

Some decades back, when I’d buy a new PC, it would unlock new capabilities. Maybe AGP video, or a PCMCIA slot, or, heck, sound.

Nowadays, mostly new hardware means things get a bit faster or less crashy, or I have some more space for files. It’s good and useful, but sorta… meh.

Not this purchase.

Cory Doctorow wrote about the Framework laptop in 2021:

There’s no tape. There’s no glue. Every part has a QR code that you can shoot with your phone to go to a service manual that has simple-to-follow instructions for installing, removing and replacing it. Every part is labeled in English, too!

The screen is replaceable. The keyboard is replaceable. The touchpad is replaceable. Removing the battery and replacing it takes less than five minutes. The computer actually ships with a screwdriver.

Framework had been on my radar for awhile. But for various reasons, when I was ready to purchase, I didn’t; either the waitlist was long, or they didn’t have the specs I wanted.

Lately my aging laptop with 8GB RAM started OOMing (running out of RAM). My desktop had developed a tendency to hard hang about once a month, and I researched replacing it, but the cost was too high to justify.

But when I looked into the Framework, I thought: this thing could replace both. It is a real shift in perspective to have a laptop that is nearly as upgradable as a desktop, and can be specced out to exactly what I wanted: 2TB storage and 64GB RAM. And still cheaper than a Macbook or Thinkpad with far lower specs, because the Framework uses off-the-shelf components as much as possible.

Cory Doctorow wrote, in The Framework is the most exciting laptop I’ve ever broken:

The Framework works beautifully, but it fails even better… Framework has designed a small, powerful, lightweight machine – it works well. But they’ve also designed a computer that, when you drop it, you can fix yourself. That attention to graceful failure saved my ass.

I like small laptops, so I ordered the Framework 13. I loaded it up with the 64GB RAM and 2TB SSD I wanted. Frameworks have four configurable ports, which are also hot-swappable. I ordered two USB-C, one USB-A, and one HDMI. I put them in my preferred spots (one USB-C on each side for easy docking and charging). I put Debian on it, and it all Just Worked. Perfectly.

Now, I orderd the DIY version. I hesitated about this — I HATE working with laptops because they’re all so hard, even though I KNEW this one was different — but went for it, because my preferred specs weren’t available in a pre-assembled model.

I’m glad I did that, because assembly was actually FUN.

I got my box. I opened it. There was the bottom shell with the motherboard and CPU installed. Here are the RAM sticks. There’s the SSD. A minute or two with each has them installed. Put the bezel on the screen, attach the keyboard — it has magnets to guide it into place — and boom, ready to go. Less than 30 minutes to assemble a laptop nearly from scratch. It was easier than assembling most desktops.

So now, for the first time, my main computing device is a laptop. Rather than having a desktop and a laptop, I just have a laptop. I’ll be able to upgrade parts of it later if I want to. I can rearrange the ports. And I can take all my most important files with me. I’m quite pleased!

Debian Brasil: Debian Day 30 anos in Maceió - Brazil

Monday 11th of September 2023 05:00:00 AM

The Debian Day in Maceió 2023 took place at the Senai auditorium in Maceió with the support and organization of Oxe Hacker Club.

There were around 90 people registered, and 40 ateendees present on Saturday to participate in the event, which featured the following 6 talks:

  • Debian Package - Daniel Pimentel
  • Attacking Linux EDRs for Fun and Profit - Tiago Peixoto
  • Docker: Introdução ao mundo dos containers - Baltazar
  • Hardening, Debian e CIS Benchmarks - Moises
  • Carreira e Software Livre em Cyber Security - Edo
  • O Software Livre já pode pagar minhas contas? - Gilberto Martins

Debian Day also had an install fest and unconference (random chat, food and drinks).

Debian Brasil: Debian Day 30 anos em Maceió

Monday 11th of September 2023 05:00:00 AM

O Debian Day em Maceió 2023 foi realizado no auditório do Senai em Maceió com apoio e realização do Oxe Hacker Club.

Se inscreveram cerca de 90 pessoas, e 40 estiveram presentes no sábado para participarem do evento que contou com as 6 palestras a seguir:

  • Debian Package - Daniel Pimentel
  • Attacking Linux EDRs for Fun and Profit - Tiago Peixoto
  • Docker: Introdução ao mundo dos containers - Baltazar
  • Hardening, Debian e CIS Benchmarks - Moises
  • Carreira e Software Livre em Cyber Security - Edo
  • O Software Livre já pode pagar minhas contas? - Gilberto Martins

O Debian Day teve ainda um install fest e desconferência (papo aleatório, comes e bebes).

Dirk Eddelbuettel: RcppArmadillo 0.12.6.4.0 on CRAN: Another Upstream Bugfix

Monday 11th of September 2023 12:30:00 AM

Armadillo is a powerful and expressive C++ template library for linear algebra and scientific computing. It aims towards a good balance between speed and ease of use, has a syntax deliberately close to Matlab, and is useful for algorithm development directly in C++, or quick conversion of research code into production environments. RcppArmadillo integrates this library with the R environment and language–and is widely used by (currently) 1096 other packages on CRAN, downloaded 30.5 million times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint / vignette) by Conrad and myself has been cited 552 times according to Google Scholar.

This release brings bugfix upstream release 12.6.4. Conrad prepared this a few days ago; it takes me the usual day or so to run reverse-dependency check against the by-now almost 1100 CRAN packages using RcppArmadillo. And this time, CRAN thought it had found two issues when I submitted and it took two more days til we were all clear about those two being false positives (as can, and does, happen). So today it reached CRAN.

The set of changes follows.

Changes in RcppArmadillo version 0.12.6.4.0 (2023-09-06)
  • Upgraded to Armadillo release 12.6.4 (Cortisol Retox)

    • Workarounds for bugs in Apple accelerate framework

    • Fix incorrect calculation of rcond for band matrices in solve()

    • Remove expensive and seldom used optimisations, leading to faster compilation times

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 Rcpp 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.

Jelmer Vernooij: Transcontinental Race No 9

Sunday 10th of September 2023 08:00:00 PM

After cycling the Northcape 4000 (from Italy to northern Norway) last year, I signed up for the transcontinental race this year.

The Transcontinental is bikepacking race across Europe, self-routed (but with some mandatory checkpoints), unsupported and with a distance of usually somewhere around 4000 km. The cut-off time is 15 days, with the winner usually taking 7-10 days.

This year, the route went from Belgium to Thessaloniki in Greece, with control points in northern Italy, Slovenia, Albania and Meteora (Greece).

The event was great - it was well organised and communication was a lot better than at the Northcape. It did feel very different from the Northcape, though, being a proper race. Participants are not allowed to draft off each other or help each other, though a quick chat here or there as you pass people is possible, or when you’re both stopped at a shop or control point.

My experience

The route was beautiful - the first bit through France was a bit monotonic, but especially the views in the alps were amazing. Like with other long events, the first day or two can be hard but once you get into the rhythm of things it’s a lot easier.

From early on, I lost a lot of time. We started in the rain, and I ran several flats in a row, just 4 hours in. In addition to that, the thread on my pump had worn so it wouldn’t fit on some of my spare tubes, and my tubes were all TPU - which are hard to patch. So at 3 AM I found myself by the side of an N-road in France without any usable tubes to put in my rear wheel. I ended up walking 20km to the nearest town with a bike shop, where they fortunately had good old butyl tubes and a working pump. But overall, this cost me about 12 hours in total.

In addition to that, my time management wasn’t great. On previous rides, I’d usually gotten about 8 hours of sleep per night while staying in hotels. On the transcontinental I had meant to get less sleep but still stay in hotels most night, but I found that not all hotels accomodated well for that - especially with a bike. So I ended up getting more sleep than I had intended, and spending more time off the bike than I had planned - close to 11 or 12 hours per day. I hadn’t scheduled much time off work after the finish either, so arriving in Greece late wasn’t really an option.

And then, on an early morning in Croatia (about 2000km in) in heavy fog, I rode into a kerb at 35 km/h, bending the rim of my front wheel (but fortunately not coming off my bike). While I probably would have been able to continue with a replacement wheel (and mailing the broken one home), that would have taken another day to sort out and I almost certainly wouldn’t have been able to source a new dynamo wheel in Croatia - which would have made night time riding a lot harder. So I decided to scratch and take the train home from Zagreb.

Overall, I really enjoyed the event and I think I’ve learned some useful lessons. I’ll probably try again next year.

Bits from Debian: DebConf23 starts today in Kochi On Sun 10 September 2023

Sunday 10th of September 2023 09:00:00 AM

DebConf23, the 24th annual Debian Developer Conference, is taking place in Kochi, India from September 10th to 17th, 2023.

Debian contributors from all over the world have come together at Infopark, Kochi to participate and work in a conference exclusively run by volunteers.

Today the main conference starts with over 373 expected attendants and 92 scheduled activities, including 45-minute and 20-minute talks, Bird of a Feather ("BoF") team meetings, workshops, a job fair, as well as a variety of other events.

The full schedule is updated each day, including activities planned ad-hoc by attendees over the course of the conference.

If you would like to engage remotely, you can follow the video streams available from the DebConf23 website for the events happening in the three talk rooms: Anamudi, Kuthiran and Ponmudi. Or you can join the conversations happening inside the talk rooms via the OFTC IRC network in the #debconf-anamudi#debconf-kuthiran, and the #debconf-ponmudi channels. Please also join us in the #debconf channel for common discussions related to DebConf.

You can also follow the live coverage of news about DebConf23 provided by our micronews service or the @debian profile on your favorite social network.

DebConf is committed to a safe and welcoming environment for all participants. Please see our Code of Conduct page on the DebConf23 website for more information on this.

Debian thanks the commitment of numerous sponsors to support DebConf23, particularly our Platinum Sponsors: Infomaniak, Proxmox and Siemens.

~

Bits from Debian: DebConf23 welcomes its sponsors!

Sunday 10th of September 2023 09:00:00 AM

DebConf23, the 24th edition of the Debian conference is taking place in Infopark at Kochi, Kerala, India. Thanks to the hard work of its organizers, it will be, this year as well, an interesting and fruitful event for attendees.

We would like to warmly welcome the sponsors of DebConf23, and introduce them to you.

We have three Platinum sponsors.

  • Our first Platinum sponsor is Infomaniak. Infomaniak is a key player in the European cloud market and the leading developer of Web technologies in Switzerland. It aims to be an independent European alternative to the web giants and is committed to an ethical and sustainable Web that respects privacy and creates local jobs. Infomaniak develops cloud solutions (IaaS, PaaS, VPS), productivity tools for online collaboration and video and radio streaming services.

  • Proxmox is our second Platinum sponsor. Proxmox develops powerful, yet easy-to-use open-source server software. The product portfolio from Proxmox, including server virtualization, backup, and email security, helps companies of any size, sector, or industry to simplify their IT infrastructures. The Proxmox solutions are based on the great Debian platform, and we are happy that we can give back to the community by sponsoring DebConf23.

  • Siemens is our third Platinum sponsor. Siemens is a technology company focused on industry, infrastructure and transport. From resource-efficient factories, resilient supply chains, smarter buildings and grids, to cleaner and more comfortable transportation, and advanced healthcare, the company creates technology with purpose adding real value for customers. By combining the real and the digital worlds, Siemens empowers its customers to transform their industries and markets, helping them to enhance the everyday of billions of people.

Our Gold sponsors are:

  • Lenovo, Lenovo is a global technology leader manufacturing a wide portfolio of connected products including smartphones, tablets, PCs and workstations as well as AR/VR devices, smart home/office and data center solutions.

  • Freexian, Freexian is a services company specialized in Free Software and in particular Debian GNU/Linux, covering consulting, custom developments, support, training. Freexian has a recognized Debian expertise thanks to the participation of Debian developers.

  • Google, Google is one of the largest technology companies in the world, providing a wide range of Internet-related services and products such as online advertising technologies, search, cloud computing, software, and hardware.

  • Ubuntu, the Operating System delivered by Canonical.

Our Silver sponsors are:

  • The Bern University of Applied Sciences with near 7,800 students enrolled, located in the Swiss capital.
  • Collabora, a global consultancy delivering Open Source software solutions to the commercial world.
  • FOSS United, a non-profit foundation that aims at promoting and strengthening the Free and Open Source Software (FOSS) ecosystem in India.
  • The FSIJ, a non-profit organization dedicated to supporting Free Software growth and development.
  • Civil Infrastructure Platform, a collaborative project hosted by the Linux Foundation, establishing an open source “base layer” of industrial grade software.
  • Roche, a major international pharmaceutical provider and research company dedicated to personalized healthcare.
  • Two Sigma, rigorous inquiry, data analysis, and invention to help solve the toughest challenges across financial services.
  • Matanel Foundation, operates in Israel, as its first concern is to preserve the cohesion of a society and a nation plagued by divisions.
  • The FOSSEE (Free/Libre and Open Source Software for Education) project promotes the use of FLOSS tools in academia and research. The project is part of the National Mission on Education through Information and Communication Technology (ICT), Ministry of Education (MoE), Government of India.
  • Arm: with the world’s Best SoC Design Portfolio, Arm powered solutions have been supporting innovation for more than 30 years and are deployed in over 225 billion chips to date.
  • Kerala Vision Broadband is a subsidiary of Kerala State IT Infrastructure Limited (KSITIL) which provides high-speed internet services in the state of Kerala, India.

Bronze sponsors:

And finally, our Supporter level sponsors:

A special thanks to the Infoparks Kerala, our Venue Partner!

Thanks to all our sponsors for their support! Their contributions make it possible for a large number of Debian contributors from all over the globe to work together, help and learn from each other in DebConf23.

Freexian Collaborators: Debian Contributions: /usr-merge updates, Salsa CI progress, DebConf23 lead-up, and more! (by Utkarsh Gupta)

Sunday 10th of September 2023 12:00:00 AM

Contributing to Debian is part of Freexian’s mission. This article covers the latest achievements of Freexian and their collaborators. All of this is made possible by organizations subscribing to our Long Term Support contracts and consulting services.

/usr-merge work, by Helmut Grohne, et al.

Given that we now have consensus on moving forward by moving aliased files from / to /usr, we will also run into the problems that the file move moratorium was meant to prevent. The way forward is detecting them early and applying workarounds on a per-package basis. Said detection is now automated using the Debian Usr Merge Analysis Tool. As problems are reported to the bug tracking system, they are connected to the reports if properly usertagged. Bugs and patches for problem categories DEP17-P2 and DEP17-P6 have been filed.

After consensus has been reached on the bootstrapping matters, debootstrap has been changed to swap the initial unpack and merging to avoid unpack errors due to pre-existing links. This is a precondition for having base-files install the aliasing symbolic links eventually.

It was identified that the root filesystem used by the Debian installer is still unmerged and a change has been proposed.

debhelper was changed to recognize systemd units installed to /usr.

A discussion with the CTTE and release team on repealing the moratorium has been initiated.

Salsa CI work, by Santiago Ruano Rincón

August was a busy month in the Salsa CI world. Santiago reviewed and merged a bunch of MRs that have improved the project in different aspects:

The aptly job got two MRs from Philip Hands. With the first one, the aptly now can export a couple of variables in a dotenv file, and with the second, it can include packages from multiple artifact directories. These MRs bring the base to improve how to test reverse dependencies with Salsa CI. Santiago is working on documenting this.

As a result of the mass bug filing done in August, Salsa CI now includes a job to test how a package builds twice in a row. Thanks to the MRs of Sebastiaan Couwenberg and Johannes Schauer Marin Rodrigues.

Last but not least, Santiago helped Johannes Schauer Marin Rodrigues to complete the support for arm64-only pipelines.

DebConf23 lead-up, by Stefano Rivera

Stefano wears a few hats in the DebConf organization and in the lead up to the conference in mid-September, they’ve all been quite busy.

As one of the treasurers of DebConf 23, there has been a final budget update, and quite a few payments to coordinate from Debian’s Trusted Organizations. We try to close the books from the previous conference at the next one, so a push was made to get DebConf 22 account statements out of TOs and record them in the conference ledger.

As a website developer, we had a number of registration-related tasks, emailing attendees and trying to estimate numbers for food and accommodation.

As a conference committee member, the job was mostly taking calls and helping the local team to make decisions on urgent issues. For example, getting conference visas issued to attendees required getting political approval from the Indian government. We only discovered the full process for this too late to clear some complex cases, so this required some hard calls on skipping some countries from the application list, allowing everyone else to get visas in time. Unfortunate, but necessary.

Miscellaneous contributions
  • Raphaël Hertzog updated gnome-shell-extension-hamster to a new upstream git snapshot that is compatible with GNOME Shell 44 that was recently uploaded to Debian unstable/testing. This extension makes it easy to start/stop tracking time with Hamster Time Tracker. Very handy for consultants like us who are billing their work per hour.
  • Raphaël also updated zim to the latest upstream release (0.74.2). This is a “desktop wiki” that can be very useful as a note-taking tool to build your own personal knowledge base or even to manage your personal todo lists.
  • Utkarsh reviewed and sponsored some uploads from mentors.debian.net.
  • Utkarsh helped the local team and the bursary team with some more DebConf activities and helped finalize the data.
  • Thorsten tried to update package hplip. Unfortunately upstream added some new compressed files that need to appear uncompressed in the package. Even though this sounded like an easy task, which seemed to be already implemented in the current debian/rules, the new type of files broke this implementation and made the package no longer buildable. The problem has been solved and the upload will happen soon.
  • Helmut sent 7 patches for cross build failures. Since dpkg-buildflags now defaults to issue arm64-specific compiler flags, more care is needed to distinguish between build architecture flags and host architecture flags than previously.
  • Stefano pushed the final bit of the tox 4 transition over the line in Debian, allowing dh-python and tox 4 to migrate to testing. We got caught up in a few unusual bugs in tox and the way we run it in Debian package building (which had to change with tox 4). This resulted in a couple of patches upstream.
  • Stefano visited Haifa, Israel, to see the proposed DebConf 24 venue and meet with the local team. While the venue isn’t committed yet, we have high hopes for it.

More in Tux Machines

digiKam 7.7.0 is released

After three months of active maintenance and another bug triage, the digiKam team is proud to present version 7.7.0 of its open source digital photo manager. See below the list of most important features coming with this release. Read more

Dilution and Misuse of the "Linux" Brand

Samsung, Red Hat to Work on Linux Drivers for Future Tech

The metaverse is expected to uproot system design as we know it, and Samsung is one of many hardware vendors re-imagining data center infrastructure in preparation for a parallel 3D world. Samsung is working on new memory technologies that provide faster bandwidth inside hardware for data to travel between CPUs, storage and other computing resources. The company also announced it was partnering with Red Hat to ensure these technologies have Linux compatibility. Read more

today's howtos

  • How to install go1.19beta on Ubuntu 22.04 – NextGenTips

    In this tutorial, we are going to explore how to install go on Ubuntu 22.04 Golang is an open-source programming language that is easy to learn and use. It is built-in concurrency and has a robust standard library. It is reliable, builds fast, and efficient software that scales fast. Its concurrency mechanisms make it easy to write programs that get the most out of multicore and networked machines, while its novel-type systems enable flexible and modular program constructions. Go compiles quickly to machine code and has the convenience of garbage collection and the power of run-time reflection. In this guide, we are going to learn how to install golang 1.19beta on Ubuntu 22.04. Go 1.19beta1 is not yet released. There is so much work in progress with all the documentation.

  • molecule test: failed to connect to bus in systemd container - openQA bites

    Ansible Molecule is a project to help you test your ansible roles. I’m using molecule for automatically testing the ansible roles of geekoops.

  • How To Install MongoDB on AlmaLinux 9 - idroot

    In this tutorial, we will show you how to install MongoDB on AlmaLinux 9. For those of you who didn’t know, MongoDB is a high-performance, highly scalable document-oriented NoSQL database. Unlike in SQL databases where data is stored in rows and columns inside tables, in MongoDB, data is structured in JSON-like format inside records which are referred to as documents. The open-source attribute of MongoDB as a database software makes it an ideal candidate for almost any database-related project. This article assumes you have at least basic knowledge of Linux, know how to use the shell, and most importantly, you host your site on your own VPS. The installation is quite simple and assumes you are running in the root account, if not you may need to add ‘sudo‘ to the commands to get root privileges. I will show you the step-by-step installation of the MongoDB NoSQL database on AlmaLinux 9. You can follow the same instructions for CentOS and Rocky Linux.

  • An introduction (and how-to) to Plugin Loader for the Steam Deck. - Invidious
  • Self-host a Ghost Blog With Traefik

    Ghost is a very popular open-source content management system. Started as an alternative to WordPress and it went on to become an alternative to Substack by focusing on membership and newsletter. The creators of Ghost offer managed Pro hosting but it may not fit everyone's budget. Alternatively, you can self-host it on your own cloud servers. On Linux handbook, we already have a guide on deploying Ghost with Docker in a reverse proxy setup. Instead of Ngnix reverse proxy, you can also use another software called Traefik with Docker. It is a popular open-source cloud-native application proxy, API Gateway, Edge-router, and more. I use Traefik to secure my websites using an SSL certificate obtained from Let's Encrypt. Once deployed, Traefik can automatically manage your certificates and their renewals. In this tutorial, I'll share the necessary steps for deploying a Ghost blog with Docker and Traefik.