According to information I have picked up somewhere (but can't properly confirm via web searches ATM) there was a compiler in the 90s (the IBM VisualAge compiler maybe?) which had a special caching daemon mode. The basic idea was that you would send your code to that process and then it could return cached compile results without needing to reparse and reprocess same bits of code over and over. A sort of an in-compiler CCache, if you will. These compilers no longer seem to exist, probably because you can't just send snippets of code to be compiled, you have to send the entire set of code up to the point you want to compile. If it is different, for example because some headers are included in a different order, the results can not be reused. You have to send everything over and at that point it becomes distcc.

I was thinking about this some time ago (do not ask why, I don't know) and while this approach does not work in the general case, maybe it could be made to work for a common special case. However I am not a compiler developer so I have no idea if the following idea could work or not. But maybe someone skilled in the art might want to try this or maybe some university professor could make their students test the approach for course credit.

The basic idea is quite simple. Rather than trying to cache compiler internal state to disk somehow, persist it in a process without even attempting to be general.

The steps to take

Create a C++ project with a dozen source files or so. Each of those sources include some random set of std headers and have a single method that does something simple like returns the sum of its arguments. What they do is irrelevant, they just have to be slow to compile.

Create a PCH file that has all the std headers used in the source files. Compile that to a file.

Start compiling the actual sources one by one. Do not use parallelism to emphasize the time difference.

When the first compilation starts, read the PCH file contents into memory in the usual way. Then fork the process. One of the processes carries on compiling as usual. The second process opens a port and waits for connections, this process is the zygote server process.

When subsequent compilations are done, they connect to the port opened by the zygote process, send the compilation flags over the socket and wait for the server process to finish.

The zygote process reads the command line arguments over the socket and then forks itself. One process starts waiting on the socket again whereas the other compiles code according to the command line arguments it was given.

The performance boost comes from the fact that the zygote process already has stdlib headers in memory in compiler native data structures. In the optimal case loading the PCH file takes effectively zero time. What makes this work (in this test at least) is that the PCH file is the same for all compilations and it is the first thing the compiler starts processing. Thus it is always the same for all compilations. Conceptually at least, the actual compiler might do something else. There may be a dozen other reasons it might not work.

If someone tries this out, do let us know whether it actually worked.

04 Dec 2024 11:46pm GMT

The upcoming systemd v257 release will have support for a feature originating from ConEmu (a terminal emulator for Windows) which was eventually adopted by Windows Terminal.

Specifically, it is an OSC (Operating System Command) escape sequence which defines progress state.

Various systemd tools will natively support this. Terminal emulators which do not support it simply ignore the OSC sequence but those that do support it may provide additional UI to the application.

Lennart discussed this briefly in their ongoing systemd v257 features series on Mastodon and so I took up a quick attempt to implement the sequence parsing for VTE-based terminals.

That has since been iterated upon and landed in VTE. Additionally, Ptyxis now has corresponding code to support it as well.

Once GNOME CI is back up and running smoothly this will be available in the Ptyxis nightly build.

03 Dec 2024 8:30pm GMT

• Mail chew, 1:1's with Miklos & Lily, lunch. Set off to Paris via the Eurostar.

02 Dec 2024 2:14pm GMT

• All Saints, family service + Baptism in the morning, caught up with wider church family; home for Pizza lunch with E.
• Put up Christmas decorations left & right. Slugged variously, watched Night Action some Fallout - gratuitous gore, but interesting effects & characters.

01 Dec 2024 9:00pm GMT

Update on what happened across the GNOME project in the week from November 22 to November 29.

GNOME Core Apps and Libraries

GJS

Use the GNOME platform libraries in your JavaScript programs. GJS powers GNOME Shell, Polari, GNOME Documents, and many other apps.

ptomato reports

This week, Gary added a feature to the GJS command-line interpreter: command history is now saved between runs. Look for this in GNOME 48.

Third Party Projects

xjuan says

Cambalache version 0.94.0 is out!Release notes:

• Gtk 4 and Gtk 3 accessibility support
• Support property subclass override defaults
• AdwDialog placeholder support
• Improved object description in hierarchy
• Lots of bug fixes and minor UI improvements

Read more about it at https://blogs.gnome.org/xjuan/2024/11/26/cambalache-0-94-released/

nokyan announces

Resources 1.7 has been released with support for Neural Processing Units (NPUs), the ability to select multiple processes and swap usage columns for the Apps and Processes views.

Additionally, temperatures are now also displayed as graphs and there are a couple of improvements for AMD GPUs regarding media engine and compute utilization.

The update is of course available on Flathub. Enjoy!

Jan-Michael Brummer says

TwoFun 0.5.1 has been released. It's a two player game for touch devices featuring smaller game to kill some time. This time user interface gained some smaller improvements and bugfixes. Enjoy!

GNOME Foundation

Rosanna announces

Some sad news to report this week: the GNOME shop is currently closed to new orders. If you have an outstanding order that has not yet arrived and have not already contacted me, please let me know by forwarding the order to info@gnome.org. If you have any experience with running an online shop like the one we have and have the time and patience to help me troubleshoot and explain it to me, please reach out as well! I would be most grateful.

Hope everyone in the US celebrating this week has had a wonderful Thanksgiving!

That's all for this week!

See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!

29 Nov 2024 12:00am GMT

During my Outreachy internship with GNOME, Tamnjong Larry Tabeh and I conducted user research exercises under the inspiring mentorship of Allan Day and Aryan Kaushik.

In this blog post, I'll discuss the usability test we conducted for GNOME's Files, also known as Nautilus.

This blog post will introduce the study, outline our methodology, and present our key findings from the usability test. I've also attached a downloadable report at the end of this blogpost that discusses (in detail) our observations and recommendation(s) for each task performed in the usability test.

Without further ado, let's jump right in!

1. Introduction

Files is the default file manager of the GNOME desktop. It provides a simple and integrated way of managing files when running a Linux-based OS by supporting all the basic functions of a file manager and more.

With recent GNOME releases introducing significant changes to the Files user experience, and more improvements planned for subsequent releases, the design team wanted to assess the effectiveness of these updates and learn more about other aspects of the user experience.

To support these efforts, we executed a user research project to identify areas for improvement, and gather actionable insights from observed user behaviours that can inform design decisions when addressing identified issues.

1.1. Research Goals

Our research goals were to:

1. • Assess the effectiveness of the new menu structure and the discoverability of the following menu items:
   1. Icon Size editors
   2. Properties
   3. Select All
   4. Undo/Redo
   5. Sort
   6. Open Item Location
   7. Show Hidden Files
   8. Add To Bookmark

1. • Evaluate the ease of use of Files's Search feature, and the intuitiveness of its Search Filters.

1. • Investigate the extent to which any difficulty experienced when right-clicking an empty space in List View impacts the user experience when accessing a folder context-menu.

1.2. Research Questions

Upon completion of the study, we wanted to be able to answer the following questions:

• • Menu Structure

1. 1. 1. Is the current organization of the menus effective?
      2. Can people find the buttons they need for basic tasks when they need them?

• • Search Experience

1. 1. 1. Do people understand how to search in Files?
      2. Do people understand the search filters and how to use them?
      3. Are the search filters effective for their context of use?

• • List View Layout

1. 1. 1. Is it challenging for people to access the folder context menu in list view when they have a lot of files?
      2. Does the current design meet user expectations when accessing folder context menu in list view?

2. Study Design

2.1. Approach

To answer our research questions, we opted for a moderated task-based usability test. This approach meant that we could simulate typical usage conditions and observe participants interact with Files. This made it easy for us to identify pain-points and gaps in the specific aspects of the Files user experience that we were interested in, and allowed us to engage participants in discussions that deepened our understanding of the challenges they experienced with Files.

To plan the study, we started by defining the ideal participant for our research goals. Next, we established an optimal sequence for the tasks we wanted participants to perform, then crafted a scenario for each, after which we designed the testing environment. Then concluded preparations with a pilot test to identify weaknesses in the study plan and implement revisions where necessary before testing with recruited participants.

2.2. Recruitment Criteria

To generate the data we needed, we had to observe individuals who were unfamiliar with the Files menu structure. This requirement was crucial, as previous use of Files could influence a participant's interactions, which would have made it difficult for us to discern valid usability issues from their interactions.

We also needed participants to be able to perform basic computing tasks independently: tasks like navigating software and managing files on their computer. This proficiency was important to ensuring that any challenges observed during the study were specifically related to the Files user experience, rather than stemming from a lack of general computer skills.

Therefore, we defined our recruitment criteria as follows:

1. 1. Has never used GNOME prior to their usability test session.
   2. Is able to use a computer moderately well.

2.3. Testing Environment

During testing, participants interacted with development versions of Files, specifically, versions 47.rc-7925df1ba and 47.rc-3faeec25e. Both versions were the latest available at the time of testing and had identical implementations of the features we were targeting.

To elicit natural interactions from the participants, we enhanced the testing environment with a selection of files and folders that were strategically organized, named, and hidden, to create states in Files that encouraged and facilitated the tasks we planned to observe.

3. Participant Overview

We recruited and tested with six first-time GNOME users, aged twenty-one to forty-seven, from diverse backgrounds, with varying levels of computer expertise. This diversity in the sample helped us keep our findings inclusive by ensuring that we considered a broad range of experiences in the usability test.

Although the majority of the participants reported current use of Windows 11 as shown below, a few also reported previous use of macOS and earlier versions of Windows OS.

4. Methodology

For this usability test:

• • We conducted in-person usability tests with six computer users who met our selection criteria.

• • The moderating researcher followed a test script and concluded each session with a brief, semi-structured interview.

• • Participants attempted eleven tasks in the following order:

1. 1. 1. Change the icon size
      2. Find the size of a folder with Properties
      3. Select all files in a folder with "Select All"
      4. Undo an action with the "Undo" button
      5. Change the sort order
      6. Change Files display from grid view to list view
      7. Create a new folder while in list view
      8. Find a file using the search feature, with filters
      9. Go to a file's location from search results with "Open Item Location"
      10. Reveal hidden items in a folder with "Show Hidden Files"
      11. Add a folder to the sidebar with "Add to Bookmarks"

• • Participants were encouraged to continuously think aloud while the performing tasks and each session lasted at least 40 minutes.

• • All sessions were recorded with participant consent and were later transcribed for analysis.

• • To analyze the collected data, we summarized the participants' experiences for each task using Jim Hall's Heat Map technique and synthesized findings from our session notes through Thematic Analysis.

5. Usability Test Result

Applying Jim Hall's Heat Map technique we summarized the observed experience for all tasks performed in the usability test. The heatmap below shows the completion rate for each task and the level of difficulty experienced by participants when performing them.

The tasks are in rows and participants are represented in columns. The cell where a row (Task) intersects with a column (Participant) captures the task outcome and relative difficulty experienced by a participant during their attempt.

A cell is green if the participant completed the task without any difficulty, yellow if the participant completed the task with very little difficulty, orange if the participant completed the task with moderate difficulty, red if the participant completed the task with severe difficulty, black if the participant was unable to complete the task, and gray if the participant's approach was outside the scope of the study.

6. Key Insights

1. Menu structure

• • The menu structure was generally easy for participants to navigate. Despite using GNOME and Files for the first time during their testing sessions, they adapted quickly and were able to locate most of the buttons and menu items required to complete the tasks.

• • The best performing tasks were "Change the sort order" and "Reveal hidden items in a folder", and the worst performing tasks were "Change the icon size" and "Add a folder to Bookmark".

• • Overall, the participants easily found the following menu items when needed:

1. 1. 1. Sort
      2. Show Hidden Files
      3. Properties
      4. Open Item Location

1. 1. But struggled to find these menu items when needed

1. 1. 1. Icon size editors
      2. Select All
      3. Undo/Redo
      4. Add To Bookmark

• • In situations where participants were familiar with a shortcut or gesture for performing a task, they almost never considered checking the designated menus for a button.

• • We observed this behavior in every participant, particularly when they performed the following tasks:
  • 
    Nonetheless, Files excelled in this area with its remarkable support for widely used shortcuts and cross-platform conventions.

• • We also observed that when these actions worked as expected it had the following effects on the user's experience:

1. 1. 1. It reduced feelings of apprehension in participants and encouraged them to engage more confidently with the software.
      2. It made it possible for the participants to discover Files's menu structure without sacrificing their efficiency.

2. Search

The "Search Current Folder" task flow was very intuitive for all participants. The search filters were also very easy to use and they effectively supported participants during the file search.

However, we found that the clarity of some filter labels could be reasonably improved by tailoring them to the context of a file search.

3. List View Layout

The current List View layout did not effectively support typical user behavior when accessing the folder context menu.

4. General Observation

When the participants engaged in active discovery of Files, we observed behaviour patterns that are linked to the following aspects of the design:

• • Familiarity:

• • We observed that when participants attempted familiar tasks, they looked for familiar cues in the UI. We noticed that when a UI component looked familiar to participants, they interacted without hesitation and with the expectation that this interaction would lead to the same outcomes that they're accustomed to from their prior experience with similar software. Whereas, when a UI component was unfamiliar, participants were more restrained and cautious when they interacted with it.

• • For example, we noticed participants interact differently with the "Search Current Folder" button compared to the "List/Grid View" and "View Options" buttons.

• • With the "Search Current Folder" button, participants took longer to identify the icon, and half of the sample checked the tooltip for confirmation before clicking the button, because the icon was unfamiliar.

• • In contrast, participants reacted a lot quicker during the first task, as they instinctively clicked on the "List/Grid View" or "View Options" icons without checking the tool tip. Some even did so while assuming the two buttons were part of a single control and interacted with them as if they were combined, because they were familiar with the icons and the design pattern.

• • Tool tips

• • With a lot of icon buttons in the Files UI, we observed participants relying heavily on tooltips to discover the UI. Mostly as a way to validate their assumptions about the functionality of an icon button as highlighted above.

• • Clear and effective labels:

• • We observed that, the more abstract or vague a label was, the more participants struggled to interpret it correctly.

• • In the "Open Item Location" tasks, we guided the participants who were unable to find the menu item to the file's context menu, then asked them if they thought there was a button that could have helped them complete the task. Both participants who gave up on this task instantly chose the correct option.

• • Whereas, in the "Add To Bookmarks" tasks, almost everyone independently found the menu item but the majority of them were hesitant to click on it because of the word "Bookmarks" in the label.

• • Layout of Files

• • By the end of most of the sessions, participants had concluded that controls in the white (child) section of the layout affected elements within that section, while controls in the sidebar were relevant to just the elements in the sidebar, even though this wasn't always the case with how the Files menu structure is actually organized.

• • Therefore, when participants needed to perform an action they believed would affect elements in the child section of the layout, most of them instinctively checked the same section for an appropriate control.

7. Conclusion, Reflections and Next Steps

If you'd like to learn about our findings and the identified usability issues for each task, here is a detailed report that discusses our how the participants interacted alongside our recommendations: Detailed Report for Files Usability Test

Overall, the usability test effectively supported our research goals and provided qualitative insights that directly addressed our research questions.

Beyond these insights, we also noted that users have preferences for performing certain tasks. Future research efforts can build on this insight by exploring the usage patterns of Files users to inform decisions around the most effective ways to support them.

Reflecting on the study's limitations, a key aspect that may have influenced our result was the participant sample. We tested with a sample that was predominantly composed of Windows 11 users, although unintended. Ideally, a more diverse group that included current users of different operating systems could have further enriched our findings by providing a broader range of experiences to consider. However, we mitigated this limitation by recognizing that the participants who had previous experience with more operating systems brought their knowledge from those interactions into their use of Files, which likely influenced their behaviors and expectations during the test.

8. Acknowledgements

I gained a lot of valuable skills from my internship with GNOME; I significantly improved my communications skills, learned practical skills for designing and executing user research projects using different qualitative and quantitative user research methods, and developed a sense for the more nuanced but critical considerations necessary for ensuring reliability and validity of research findings through the various phases of a study and how to mitigate them in research planning and execution.

So, I'd like to conclude by expressing my profound gratitude to everyone who made this experience so impactful.

I'd like to appreciate my mentors (Allan day and Aryan Kaushik) for their guidance, insightful feedback, and encouragement, throughout and beyond the internship; the GNOME community, for the warm welcome and support; and Outreachy, for making it possible for me to even have this experience.

I greatly enjoyed working on this project and I expect to make more user research contributions to GNOME.

Thank you!

27 Nov 2024 11:55am GMT

Hello, I am pleased to announce a new Cambalache stable release.

Version 0.94.0 - Accessibility Release!

• Gtk 4 and Gtk 3 accessibility support
• Support property subclass override defaults
• AdwDialog placeholder support
• Improved object description in hierarchy
• Lots of bug fixes and minor UI improvements

How it started?

A couple of months ago I decided to make a poll on Mastodon about which feature people would like to see next.

To my surprise GtkExpression did not come up first and GResources where not the last one.

Data Model

First things firsts, how to store a11y data in the project"

So what are we trying to sotre? from Gtk documentation:

GtkWidget allows defining accessibility information, such as properties, relations, and states, using the custom <accessibility> element:

These looks a lot like regular properties so my first idea was to store them as properties in the data model.

So I decided to create one custom/fake interface class for each type of a11y data CmbAccessibleProperty, CmbAccessibleRelation and CmbAccessibleState.

These are hardcoded in cmb-catalog-gen tool and look like this

# Property name: (type, default value, since version)
self.__a11y_add_ifaces_from_enum([
  (
    "Property",
    "GtkAccessibleProperty",
    {
      "autocomplete": ["GtkAccessibleAutocomplete", "none", None],
      "description": ["gchararray", None, None],
      ...
    }
  ),
  (
    "Relation",
    "GtkAccessibleRelation",
    {
      "active-descendant": ["GtkAccessible", None, None],
      "controls": ["CmbAccessibleList", None, None],  # Reference List
      "described-by": ["CmbAccessibleList", None, None],  # Reference List
      ...
    }
  ),
  (
    "State",
    "GtkAccessibleState",
    {
      "busy": ["gboolean", "False", None],
      "checked": ["CmbAccessibleTristateUndefined", "undefined", None],
      "disabled": ["gboolean", "False", None],
      "expanded": ["CmbBooleanUndefined", "undefined", None],
      ...
    }
  )
])

This function will create the custom interface with all the properties and make sure all values in the GtkEnumeration are covered.

One fundamental difference with properties is that some a11y relations can be used more than once to specify multiple values.

To cover this I created a new value type called CmbAccessibleList which is simply a coma separated list of values.

This way the import and export code can handle loading and exporting a11y data into Cambalache data model.

Editing a11y data in the UI

Now since these interfaces are not real, no actual widget implements them, they wont show up automatically in the UI.

This can be easily solved by adding a new tab "a11y" to the object editor which only shows a11y interface properties.Now at this point it is possible to create and edit accessibility metadata for any UI but as Emmanuelle pointed out not every a11y property and relation is valid for every role.

To know what is valid or not you need to read WAI-ARIA specs or write a script that pulls all the metadata from it.

With this metadata handy is it easy to filter properties and relations depending on the a11y role.BTW keep in mind that accessible-role property should not be changed under normal circumstances.

Where to get it?

From Flathub

flatpak remote-add --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo

flatpak install flathub ar.xjuan.Cambalache

or directly from gitlab

git clone https://gitlab.gnome.org/jpu/cambalache.git

Matrix channel

Have any question? come chat with us at #cambalache:gnome.org

Mastodon

Follow me in Mastodon @xjuan to get news related to Cambalache development.

Happy coding!

27 Nov 2024 12:29am GMT

It's the time for a new Hack Week. The Hack Week 24 was from November 18th to November 22th, and I've decided to join the New openSUSE-welcome project this time.

The idea of this project is to revisit the existing openSUSE welcome app, and I've been trying to help here, specifically for the GNOME desktop installation.

openSUSE-welcome

Right now after installing any openSUSE distribution with a graphical desktop, the user is welcomed on first login with a custom welcome app.

This custom application is a Qt/QML with some basic information and useful links.

The same generic application is used for all desktops, and for popular desktops right now exists upstream applications for this purpose, so we were talking on Monday morning about it and decided to use specific apps for desktops.

So for GNOME, we can use the GNOME Tour application.

gnome-tour

GNOME Tour is a simple rust/gtk4 application with some fancy images in a slideshow.

This application is generic and just shows information about GNOME desktop, so I created a fork for openSUSE to do some openSUSE specific customization and use this application as openSUSE welcome in GNOME desktop for Tumbleweed and Leap.

Desktop patterns, the welcome workflow

After some testing and investigation about the current workflow for the welcome app:

1. x11_enhanced pattern recommends opensuse-welcome app.
2. We can add a Recommends: gnome-tour to the gnome pattern
3. The application run using xdg autostart, so gnome-tour package should put the file in /etc/xdg/autostart and set to hidden on close.
4. In the case of having a system with multiple desktops, we can choose the specific welcome app using the OnlyShowIn/NotShowIn config in desktop file

So I've created a draft PR to do not show the openSUSE-welcome app in GNOME, and I've also the gnome-tour fork in my home OBS project.

I've been testing this configuration in Tumbleweed with GNOME, KDE and XFCE installed and it works as expected. The openSUSE-welcome is shown in KDE and XFCE and the gnome-tour app is only shown in GNOME.

Next steps

The next steps to have the GNOME Tour app as default welcome for openSUSE GNOME installation are:

1. Send forked gnome-tour package to GNOME:Next project in OBS.
2. Add the Recommends: gnome-tour to patterns-gnome to GNOME:Next project in OBS.
3. Make sure that any other welcome application is not shown in GNOME.
4. Review openQA tests that expect opensuse-welcome and adapt for the new application.

22 Nov 2024 11:00am GMT

Update on what happened across the GNOME project in the week from November 15 to November 22.

GNOME Core Apps and Libraries

GJS

Use the GNOME platform libraries in your JavaScript programs. GJS powers GNOME Shell, Polari, GNOME Documents, and many other apps.

ptomato says

Gary Li added support for source maps to GJS. If you use build tools such as TypeScript for source code transformation, you can ship source map files alongside your built JS files and make sure your build tool adds the magic source map comment. You will then get the original source locations printed in stack traces and in the debugger.

Third Party Projects

Konstantin Tutsch announces

Lock v1.1.0 is here!

The user experience of encrypting data has drastically improved with the manual entering of a key's UID being obsolete. You can now simply choose the key you want to encrypt for from a list of all available keys with just a single click!

Fingerprint access of keys has also improved. You can now copy a key's fingerprint by clicking on its row during keyring management.

Available on Flathub.

Mateus R. Costa reports

Today I have released version 1.1.1 of bign-handheld-thumbnailer. This new version is a patch release with some small tweaks and I believe there won't be much to add to the program for a while.

bign-handheld-thumbnailer, for those who haven't heard about, is a thumbnailer for Nintendo DS and 3DS roms. It was created as a replacement for gnome-nds-thumbnailer (which only created thumbnails for NDS roms and has been recently archived), but also gained the ability to generate thumbnails for 3DS roms.

The new 1.1.1 version is available in a copr for Fedora 40, 41 and Rawhide (Fedora 39 is left out as it will be EoL in a few days).

For the next steps, and since gnome-nds-thumbnailer has been archived, it should be a good moment to try to get the project added into official distro repos. I will be attempting to going through the Fedora process, if you are on a different distro and this thumbnailer is useful for you, consider asking for an official package.

(Another possibility is shipping the thumbnailer as a Flatpak in the near future, if that functionality is ever added…)

Turtle

Manage git repositories in Nautilus.

Philipp says

Turtle 0.11 has been released.

Clean and reset dialog

A clean and reset dialog has been added to clean a repository from untracked files or reset the current branch to a specific reference.

Diff and log updates

It is now possible to compare the working directory to a reference in the diff dialog.

Renamed files are now shown as one entry in the commit table instead of a removed and added entry. Additionally the context menu in the log dialog has been extended by a push action to push the selected branch.

Minor updates

There are more minor updates, for the full list see the changelog

Parabolic

Download web video and audio.

Nick announces

Parabolic V2024.11.1 is here!

This update contains fixes for various bugs users were experiencing.

Here's the full changelog:

• Fixed an issue where file names that included a period were truncated
• Fixed an issue where long file names caused the application to crash
• Fixed an issue where external subtitle files were created although embedding was supported
• Fixed an issue where generic downloads were unable to be opened upon completion
• Updated yt-dlp to 2024.11.18

That's all for this week!

See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!

22 Nov 2024 12:00am GMT

A month of low energy here. My work day is spent on a corporate project which I can't talk about due to NDAs, although I can say it's largely grunt work at the moment.

I'm not much of a gamer but sometimes you need a dose of solid fun. I finally started playing through Age of Empires II: The Conquerers, which has aged 24 years at this point, like a fine whisky. I played the original AoE when it came out, and I loved the graphics and the scenarios but got burned out by how dumb the units would be. All that was greatly improved in the second edition; although your guys will still sometimes wander off to chip away single-handedly at an enemy castle with their tiny sword, the new keyboard shortcuts make it less frustrating to micro-manage an army. I guess this is old news for everyone except me but, what a game.

I'm preparing some QA related talk submissions for FOSDEM 2025. I haven't had time or energy to work on QA testing in GNOME, but I still have a clear idea of how we can move forwards, and I'll keep talking about it a little longer to see if we can really go somewhere. There is still a small community joining our monthly call which gives a certain momentum to the project.

In terms of search, unfortunately I don't feel much momentum around this at the moment. Besides the heroic contributions from Carlos, we did get a new IDE from Demigod's and Rachel's summer of code project. Somehow that hasn't even made its way into Fedora 41, despite being part of the latest GNOME 47 release, so it's still tricky to use it in demos. I looked at submitting some desktop search related talk to FOSDEM but there's not a single dev room I can see where a proposal would even fit. There we are.

One final thought. This was a pretty engaging 20 minute talk by Cabel Sasser on the topic of a bizarre mural he saw at a McDonalds burger restaurant in Washington, USA. I recommend watching it if you haven't, but you can also jump straight to the website about the mural's artist, Wes Cook.

Something jumped out at me in the middle of the talk when he said "We all want to be seen." Most folk want some recognition of the work we do and some understanding. In the software industry it's very difficult because what we do is so specialised. But we're now at a point where graphical desktops have been mainstream for nearly 30 years. Everyone uses one in their job. Smartphones are 15 years old and the tech isn't hugely evolving.

A lot of this stuff is based on open source projects with 15+ year histories, and the people who can tell the stories of how they were made and how they work are all still around and still active.

It could be worth spending some effort recognising what we have, and talking about it, and the people who make it happen.

(If only we could have a desktop room at FOSDEM again…)

21 Nov 2024 12:44pm GMT

Le weekend du 16 et 17 novembre 2024, j'ai eu le plaisir d'aller au Capitole du Libre (CdL), une chouette conférence tenue tous les ans à Toulouse, et j'ai envie de revenir dessus. Le CdL rassemble la communauté libriste française, avec une représentation notable du milieu associatif. On y trouve un village associatif rassemblant un large pan du milieu libriste français au delà du logiciel, des présentations techniques accessibles à tous les niveaux de connaissance, et des présentations plus politiques qui proposent de réfléchir et faire évoluer le mouvement libriste. Ça en fait une conférence très joviale et conviviale où l'on peut venir en famille.

J'ai déjà participé au CdL par le passé, y tenant des stands pour parler de GNOME sur smartphones en 2018, 2019 et 2022. De plus en 2019 j'y ai donné une présentation sur mes travaux pour porter GNOME sur smartphones, et en 2022 j'ai eu le plaisir d'interviewer David Revoy dans les couloirs de la conférence. C'est une conférence que j'apprécie et à laquelle j'aime participer, et 2024 est la première édition où j'y suis allé en visiteur.

Des présentations marquantes

Une fois n'est pas coutume, je suis venu au CdL pour assister à des présentations, et quelques unes m'ont agréablement marqué. Voici un bref récapitulatif par ordre chronologique de celles qui ont constitué les points hauts de ma visite.

Le samedi à 15:00, Valentin Deniaud a donné une présentation piquante et très drôle sur la lutte de l'éditeur de logiciels libres Entr'ouvert contre Orange, narrant comment le géant des télécoms a été condamné après des décennies de lutte pour non respect d'une licence libre. La présentation pleine d'anecdotes et d'humour dresse un parcours laborieux dans divers types de droits et dans la justice française.

Le même après-midi à 16:30, Armony Altinier et Jean-Philippe Mengual nous ont fait une démonstration des limitation de l'accessibilité de la plate-forme d'apprentissage Moodle aux personnes non-voyantes. La présentation explique surtout comment les personnes utilisant cette plate-forme pour proposer du matériel éducatif peuvent adapter le contenu pédagogique et les méthodes d'évaluation pour une plus grande inclusivité.

Le dimanche à 10:30, un intervenant représentant l'association Skeptikón a dressé les liens entre logiciels libres, scepticisme et politique. La présentation nous invite à faire face aux temps sombres que profile la montée globale du fascisme, présentant divers moyens d'y faire face comme le scepticisme, le librisme et le syndicalisme, le point d'orgue étant mis sur la nécessité de combattre le sentiment d'inanité et le fatalisme en créant du nous.

Elle a été suivie à 11:30 par une présentation d'Isabella Vanni décrivant le fonctionnement de l'April et son cheminement pour mieux inclure la diversité de genres. Partant des origines de l'informatique dévalorisée et féminisée pour aller jusqu'à sa valorisation et sa réappropriation par les hommes dans les années 1980, elle présente les mécanismes qui freinent la ré-inclusion des femmes dans le secteur et des moyens de lutter contre.

La conférence reprend à 14:00 par une présentation de Khrys, nous offrant une plongée dans les origines féminines de l'informatique, tissant des liens avec l'intelligence artificielle et le luddisme. Par le prisme du mythe de Prométhée et de ses diverses réinterprétations en science-fiction, elle confronte les visions patriarcales et féminines des innovations techniques, nous invitant à être technocritiques envers les intelligences artificielles via une approche féministe.

Des intentions d'inclusion sans application

Le CdL est doté d'un code de conduite que chaque participant·e se doit de respecter, qu'ils et elles soient visiteurs·euses, invités·es ou organisateurs·ices. Le code de conduite déclare que les organisateurs·ices souhaitent éviter tout type de discrimination, que le non respect de ces règles de bienséance pourra entraîner l'exclusion de l'évènement et nous invite à signaler toute discrimination dont on est victime ou témoin.

Tout cela est louable mais sa mise en application me pose quelques problèmes. Comment faire un retour quand c'est l'organisation de l'évènement dans sa globalité qui est discriminante, empêchant des pans entiers de la population d'y accéder ? Comment faire un retour quand les discriminations sont causées sur la scène principale par des intervenants·es pendant des présentations ou la table-ronde, sous les yeux de l'organisation qui laisse faire sans répondre ? Car de la discrimination au CdL il y en a, il y en a beaucoup même, mais elle n'est pas forcément où l'organisation s'y attend.

Si ce n'est pas ma première participation au CdL, c'est ma première en tant que visiteur et confronter ces deux expérience me faire prendre conscience des œillères qu'on peut avoir vis-à-vis du déroulement de l'évènement quand on est affairé·e à son animation, qu'elles soient par volonté de ne pas faire de vagues ou parce qu'on a la tête dans le guidon. Je suis donc convaincu de l'honnêteté des intentions de l'organisation du CdL, tout autant que je suis convaincu que les problèmes sont de fond, et sont communs aux milieux du libre et à de trop larges pans des milieux socialistes. Allez dans n'importe quelle conférence et vous trouverez une partie de ces problèmes, et probablement d'autres encore.

Pour ces raisons, j'ai décidé de faire un retour sur les problèmes dont j'ai été témoin non pas à l'organisation du CdL directement, mais par cet article pour appeler la communauté libriste toute entière à se remettre en question. Dans la suite de cet article, je vais tenter d'expliquer ce qui constitue à mes yeux des problèmes de l'évènement et d'offrir des pistes pour y remédier.

Invisibilisation des luttes des travailleurs·euses du libre

Le samedi s'est clôturé par une table-ronde sur les modèles de gouvernance des projets libres. Si les échanges étaient intéressants, on a pu entendre plusieurs fois qu'il n'y a pas de licenciements dans les logiciels libres. Je ne comprends pas d'où peut venir une telle affirmation, sinon peut-être d'une vision très limitée de ce qu'il se passe dans nos milieux.

Je connais beaucoup trop de personnes licenciées qui travaillaient pour des multinationales du libre, mais également des organisations à but non-lucratif, des coopératives ou encore de petites associations. Les vagues de licenciements chez Red Hat et Mozilla de ces dernières années devraient suffire de vous convaincre, pour ne citer que les exemples les plus médiatisés. Et au delà des licenciements, les travailleurs·euses du libre sont aussi victimes de harcèlements et des mises au placard.

Et ça c'est sans parler de la précarité du milieu, supérieure à celles des autres milieux de l'informatique. Contrats précaires, salariat déguisé, freelance, exploitation du travail passion, travail bénévole, alternance entre embauche et non-emploi, le tout sans nécessairement de chômage entre temps. Tout ça est très fréquent. Je me suis énormément retrouvé dans ma lecture de Te plains pas, c'est pas l'usine, quand bien même je n'ai jamais travaillé dans le milieu associatif, il y a une exploitation très similaire dans les milieux libristes, exploitation fondée sur un sentiment de devoir pour le bien commun et des injonctions à l'abnégation et au don de soi. Alors qu'il s'agît certes de luttes, mais avant tout de relations de travail dans une économie capitaliste.

On parle tout le temps des licences libres, mais trop peu des licenciés·es du libre, et ce genre de discours déconnectés de la réalité dans nos milieux participent à l'invisibilisation de leurs luttes. Par solidarité on devrait s'y intéresser. Peut-être que cet écueil ne serait pas arrivé si la table était réellement ronde et incluait l'auditoire au lieu d'être une discussion descendante entre quatre grands noms du milieu.

Incommodation de personnes handicapées

Pour plein de raisons que ce soit, on n'a pas toustes assez d'énergie pour tenir une journée entière, d'autant plus une journée de conférence. Les rares lieux de repos sont la cour intérieure et des bancs de béton dans le bruyant, passant et illuminé hall principal. Les conférences peuvent être épuisantes pour moi, et lorsque j'ai dû à certains moments trouver un endroit calme où me reposer à l'abris du froid, le mieux que j'ai trouvé était par terre dans un couloir passant, ce qui vous vous en doutez n'est pas idéal.

Il y a plein de choses à faire pour améliorer ça qui ne coûtent pas grand chose. Une salle de repos un peu isolée, avec des chaises, calme, dans la pénombre et clairement indiquée serait plus que bienvenue. En complément ou à minima, avoir quelques chaises disposées çà et là permettrait un repos de meilleure qualité et plus fréquent. En complément, avoir plus de tables de bar près de la buvette permettrait aux personnes de manger leur crêpe et de boire leur café sans occuper une des rares places assises simplement pour répondre à leur besoin de libérer leurs mains.

Je dois louer l'organisation du CdL pour fournir un son clair et audible, ce qu'en tant que personne malentendante j'apprécie. Cela dit le son était parfois beaucoup trop fort, notamment lors de projections de vidéos promotionnelles auxquelles le son n'apportait rien de pertinent. Étant également hypersensible auditif, je dois avouer que ces rares moments étaient particulièrement pénibles et venaient contribuer à ma fatigue. Je n'ai pas eu le temps de me ruer sur mes bouchons d'oreille, le son était tellement fort et incommodant que je n'ai eu d'autre choix que de me boucher les oreilles avec les doigts en attendant que ça passe. Faire plus attention au niveau sonore serait bienvenu.

Stigmatisation des personnes psychiatrisées

Lors d'une présentation, une slide déclare que « le progrès technique est comme une hache qu'on aurait mise dans les mains d'un psychopathe », soulignée d'une image d'Elon Musk éclatant une porte avec une hache, faisant référence au film Shining. La personne présentant affirmant que c'est une citation d'Albert Einstein, comme pour appuyer la spiritualité du propos. Un peu plus tard dans la présentation, et à moins que ma mémoire ne me fasse défaut, le terme est réutilisé pour qualifier les personnes qui emploient des termes misogynes.

Psychopathe est une insulte saniste qui stigmatise les personnes psychiatrisées. Il disqualifie une personne en lui associant une tare psychologique infamante, méritant au mieux le mépris et le rejet, au pire l'enfermement ou la mort. Le simple fait d'utiliser ce terme participe à légitimer le système saniste dont souffrent les personnes psychiatrisées.

Ce terme médicalise les comportements perçus comme déviants, l'appliquer à Elon Musk pour qualifier ses actes revient à expliquer son fascisme par une tare mentale. Ses comportements s'expliquent pourtant très bien par son status social, et chercher à l'en extraire pour les expliquer par d'autres moyens dépolitise la situation. Elon Musk a de tels comportements parce que c'est un milliardaire fasciste, un influenceur libertarien, un colon blanc, un transphobe. Il en va de même pour les misogynes, je pense que n'importe quelle féministe sera d'accord pour dire que le patriarcat n'est pas une question de pathologie, et je suis convaincu que les féministes psychiatrisées n'apprécient pas d'être associées à des misogynes. Cette psychiatrisation du politique prend également forme dans l'injonction à voir un·e psy.

Pourtant en entretenant le sanisme, on entretien un système qui vise en grande partie à enfermer les personnes en lutte pour leur émancipation. Les esclaves luttant pour leur libération étaient psychiatrisés·es, les femmes luttant contre le patriarcat étaient psychiatrisées, les personnes homosexuelles étaient psychiatrisées, les opposants politiques étaient ou sont toujours psychiatrisés·es, les personnes trans sont toujours très activement psychiatrisées. Pour maintenir les hiérarchies on médicalise, psychiatrise, enferme, médicamente, camisole et ôte de toute agentivité les personnes en révolte contre les dominations qu'elles subissent. Voilà ce qui se cache derrière le terme psychopathe. Jamais un fasciste n'a été enfermé pour ses idées, jamais un homme pour sa misogynie.

Quand après sa présentation, je suis allé brièvement demander à la personne de ne plus utiliser ce terme, elle a justifié que c'est une citation d'Einstein. La comparaison des personnes psychiatrisée à des fascistes et des misogynes, ça n'est pas d'Einstein, pas plus que c'est Einstein qui a inclus ce terme dans la présentation. Einstein a dit plein de choses, pourquoi d'entre toutes retenir celle là ? Et si le but est d'avoir une citation à propos, pourquoi en choisir une saniste datant de 1917, ignorant plus d'un siècle de luttes ?

Il aurait été possible de choisir n'importe quelle autre citation, voire de se passer de citation, mais c'est celle là qui a été retenue. Il aurait même été possible d'utiliser la citation mais en la commentant, soulignant qu'elle est problématique et pourquoi, mais à ce compte autant ne pas l'utiliser puisque c'est hors-propos de la présentation. Mais surtout, ll aurait été possible de ne pas réemployer ce terme plus tard, hors de toute citation servant d'excuse à son utilisation. Les personnes psychiatrisées ne sont pas des punchlines.

Lors d'une autre présentation on apprend que lors du procès de Nuremberg, le nazi Hermann Göring a été jugé contre toute attente parfaitement sain par les psychologues. La personne présentant tentait de démontrer que les idées politiques ne sont pas une question de santé mentale, mais l'a fait sans démonter l'idée même de santé mentale, laissant penser que le fait que ces personnes aient été jugées saines serait une anomalie. Il me semble donc important de compléter en démontant l'idée même de santé mentale, qui comme j'ai tenté de l'expliquer plus haut est avant tout un outil d'oppression. Pour aller plus loin, je vous recommande de lire l'article L'abolition carcérale doit inclure la psychiatrie. Je précise que lutter contre la psychiatrie ne revient pas à nier les difficultés neurologiques ou psychologiques que peuvent rencontrer des personnes, ni le fait que le système psychiatrique peut parfois les aider. Mais si le système psychiatrique peut les aider, c'est parce que c'est l'unique moyen alors à notre disposition pour faire du soin mental et ce principalement pour des raisons de légalité, ce qui ne doit pas servir à nier que le système psychiatrique est avant tout un système de contrôle des corps et des esprits et une extension du système carcéral. Le soin doit se faire malgré la psychiatrie, pas grâce à elle. Le fait que les nazis aient été trouvés sains par les psychologues du procès de Nuremberg complète et illustre ce que je disais plus haut sur le rôle de la psychiatrie comme outil de domination.

On apprend dans le même temps que les psychologues ont donné à Hermann Göring un quotient intellectuel de 138, soulignant avec surprise que les nazis ne sont pas nécessairement idiots. Au delà du fait que la notion d'intelligence est en elle même très discutable, le QI est intrinsèquement un outil de hiérarchisation conçu par des bourgeois blancs pour se dresser au dessus des autres, réduisant les personnes à un unique nombre masquant sa méthode de calcul et les biais qui la constitue, mais offrant une illusion de scientificité. Le QI a principalement été utilisé en soutien au racisme, hiérarchisant l'intelligence des races pour justifier le colonialisme, et il suffit de regarder une carte mondial des QIs pour s'en convaincre. Rien d'étonnant donc qu'un bourgeois blanc ai un haut QI, l'outil fonctionne comme prévu. Et au delà du QI, ramener le fascisme à une notion d'intelligence dépolitise là encore le sujet et stigmatise les personnes qui en sont en réalité victimes.

Je tiens à présenter mes excuses à la première personne citée dans cette section et à qui je suis allé brièvement parler en aparté après un présentation autrement louable, j'espère ne pas avoir contribué au stress de l'évènement, mais par antivalidisme je ne pouvais pas laisser passer l'utilisation d'un tel terme. De même, je tiens à présenter mes excuses à la seconde personne et à son audience pour avoir monopolisé la parole pendant le court temps alloué aux questions, après là encore une excellente présentation.

Stigmatisation des personnes racisées

Lors de la table-ronde du samedi soir, une personne évoque la récente faille de sécurité injectée au logiciel xz suite à une longue infiltration. Elle semble avant tout avoir retenu une chose de cet épisode, à savoir la nationalité chinoise de la personne infiltrée puisqu'elle a cru pertinent de commenter en feignant une gêne que, puisqu'on n'est qu'entre nous cette personne peut l'avouer, elle a peur quand elle voit des contributions aux logiciels libres qu'elle maintient venant de personnes de l'est, de Russie, d'Asie du sud. Cette personne savait pertinemment que la table-ronde était filmée et allait être publiée, et elle a pu dire ça sans la moindre réaction ni des autres personnes sur scène, ni de l'organisation de l'évènement. Le public quant-à lui n'a jamais eu la parole de toute la table-ronde, empêchant toute réponse tierce dans le cadre de la conférence.

Erratum du 24 novembre 2024 : il y a bel et bien eu un tour de questions que j'avais fini par oublier, et ce malgré une intervention que j'avais trouvée salutaire répondant à une vision très libérale de l'inclusion partagée sur scène.

Virtuellement tous les pays, tous les états pratiquent l'infiltration, l'injection de backdoors, les attaques virales, y compris les états occidentaux, y compris la France. Je serais tenté de dire que c'est probablement avant tout les états occidentaux qui en sont la source, il n'y a qu'à voir l'étendue du virus étasunien Stuxnet pour s'en convaincre. Pourtant ce n'est pas des logiciels développés par la CIA ou encore l'armée française que cette personne a remis en question, comme si l'informatique devait rester avant tout une préoccupation d'occidentaux. Le problème, c'est les sud asiatiques. Disons-le clairement, ce à quoi on assisté durant cette table-ronde n'est rien de plus que de la xénophobie éhontée, du racisme.

Le pire étant que ces immondices racistes ont été dites en réponse au fait qu'une autre personne de la table-ronde ai loué les contributions des personnes venant de régions en guerre au Moyen-Orient. Des tas de nos camarades libristes viennent de Russie ou de Chine, d'autres y vivent et subissent au quotidien le fascisme de ces états. Et que dire des camarades libristes des pays réprimés par les états occidentaux et les USA plus particulièrement ? Des mainteneurs du noyau Linux ont très récemment été virés du projet car russes, mais il n'y a pas de licenciements dans le libre nous a-t-on annoncé dans cette même table-ronde. Ni de racisme, manifestement, puisque l'organisation du CdL n'a pas réagi.

Plus tard, cette même personne nous annonce fièrement tutorer pour le Google Summer of Code. J'ai été tuteur pour cet évènement à deux reprises, et je sais qu'il y a une représentation notable des personnes d'Asie du sud parmi les candidats·es stagiaires. Ça m'inquiète pour la sélection des candidats·es que cette personne peut opérer, de même que pour la qualité de l'encadrement et le traitement des stagiaires.

Exclusion des personnes sourdes

Au delà d'être très intéressante, la présentation d'Armony Altinier et Jean-Philippe Mengual était lunaire et ce pour une raison toute simple : des personnes sourdes étaient venues assister à l'unique présentation de toute la conférence sur l'accessibilité et absolument rien n'a été mis en place par le CdL pour les inclure. Armony et Jean-Philippe se sont retrouvés·es à pallier le manque en ouvrant un éditeur de texte et en s'échangeant le clavier à tour de rôle pour retranscrire tant bien que mal ce que l'autre disait. Même si elle a trouvé ses limites lors des démonstrations où l'éditeur de texte a dû être masqué et où le clavier était sollicité, leur démarche et adaptivité a été plus que louable pour pallier les manquements de l'organisation de la conférence.

Imaginez la scène, deux personnes avec différents handicaps qui se retrouvent à devoir bricoler pour compenser l'accessibilité de la conférence à des personne ayant encore une autre catégorie de handicap ! Et tout ça, de nouveau, pendant l'unique présentation de toute la conférence ayant rapport avec le handicap et plus exactement avec le manque d'accessibilité. Pourtant des solutions existent. Idéalement, avoir des interprètes en langue des signes française pour inclure les personnes sourdes et avoir des personnes pour faire la transcription en sous-titres pour inclure les personnes mal-entendantes.

Ces solutions peuvent certes coûter cher en main d'œuvre, mais même sans moyens il est possible de bricoler des choses. Des logiciels libres de transcription existent comme Live Captions, et même si ces logiciels sont imparfaits, les avoir sur un écran dédié déporté ou sur la machine des présentateurs·ices permettrait de limiter l'exclusion. Et si on considère que ces logiciels libres ne sont pas suffisants, il ne faut pas hésiter à passer par des logiciels propriétaires, l'inclusion doit passer avant le purisme.

De plus, écrire les sous-titres en direct et sur place permettrait de compenser des soucis de captation audio et permettrait de plus rapidement publier les captations vidéo avec leurs sous-titres, pour toujours mieux inclure les personnes sourdes et mal entendantes. Enfin ce ne sont pas les seules personnes handicapées à bénéficier de sous-titres et de nombreuses personnes souffrant de troubles de l'attention arrivent mieux à suivre quand il y a à la fois de l'audio et des sous-titres, avoir des sous-titres en direct faciliterait leur participation et limiterait leur fatigue.

Addendum du 24 novembre 2024 : on m'a fait remarquer que des sous-titres français permettent de mieux inclure les personnes dont le français n'est pas la première langue que l'audio français seul. Je suis pourtant bien placé pour le savoir, ayant réussi début octobre à suivre un documentaire grâce à ses sous-titres en italien alors que je ne connais pas la langue. De la même manière, on m'a fait remarquer que l'interprétation en langue des signes française permet de mieux inclure les personnes dont le français n'est pas la première langue que des sous-titres français.

Exclusion des personnes craignant pour leur santé et propagation des épidémies

Hé, regardez sous le tapis, c'est le covid, il n'est jamais parti, on l'y a glissé et on fait comme s'il n'existait plus. Pourtant c'est toujours une cause de mortalité majeure, et le covid long continue d'handicaper un grand nombre de personnes. J'ai des amis·es et camarades libristes qui ont acquis des handicaps parfois très sévère suite à de « petites grippes » ou du covid, et ce n'étaient pas des personnes dites « à risque ». Je parle de perte d'odorat définitif, de grande fatigue chronique ou de grande réduction de la mobilité. Et c'est sans mentionner les autres maladies comme la coqueluche, ni sans parler des morts. On continue de faire comme si de rien n'était, on n'a rien appris du début de la pandémie du covid et on redevient eugénistes pour un confort fantasmé.

Je peux porter un FFP2 tant que je veux pendant la conférence, il ne fait que vous protéger des virus que je pourrais diffuser, il ne me protège pas de ceux que vous diffusez. Pourtant éviter la propagation de maladies aéroportées, les gênes qu'elles occasionnent, les handicaps et les morts ne demande pas grand chose. Aérer les endroits clos tant que possible et se masquer dans les endroits de passage et confinés tels que les transports en commun, les supermarchés ou les conférences suffiraient à grandement réduire le nombre d'infections. Mais pour que ça fonctionne, encore faut-il qu'on se protège les uns·es les autres. Refuser de se masquer est eugéniste, c'est considérer que la maladie c'est pour les autres, qu'on est fort·e et que les handicaps et les morts sont acceptables. Il ne faut surtout pas attendre d'avoir des symptômes pour se masquer, on peut être porteur·se asymptomatique et participer à la diffusion de maladies, qu'on finisse par les développer ou non. De plus lorsqu'on développe une maladie telle que le covid ou la grippe, on a déjà participé à sa propagation pendant plusieurs jours. Porter un masque quand on le peut et quand c'est pertinent est devenu un acte radical de soin communautaire, c'est déprimant.

L'organisation du CdL contribue à cette situation, je n'ai vu aucune recommandation à se masquer, aucun système de filtration, aucune aération, pas même des fenêtres ouvertes qui ne coûtent pourtant littéralement rien. Ce n'est pourtant pas faute de sensibilisation, de documentation et d'actions de la part de l'Association pour la Réduction des Risques Aéroportés. Cabrioles ou Autodéfense Sanitaire fournissent également des ressources à ce sujet. L'autodéfense ne peut pas être individuelle, et sans actes collectifs tout le monde est vulnérable, sans prise en compte sérieuse des risques sanitaires par l'organisation de l'évènement personne n'est protégé.

Au delà de ça, en rassemblant un nombre conséquent de participants·es de tout le pays dans des salles bondées sans la moindre mesure de prévention, le CdL participe activement à la propagation des épidémies.

Erratum du 24 novembre 2024 : les masques FFP2 protègent bel et bien leur porteurs·ses, mais ils ne sont réellement efficaces une journée que si tout le monde joue le jeu.

Addendum du 24 novembre 2024 : toutes les personnes qui souhaiteraient se masquer ne peuvent pas le faire, c'est pourquoi il faut que toutes les personnes qui le peuvent se masquent pour les protéger. Le but n'est pas de faire les choses parfaitement mais de les faire au mieux de nos moyens, et à l'heure actuelle nous sommes collectivement lamentables. L'organisation de l'évènement a le pouvoir de participer à reverser la donne, de conscientiser nos milieux, de protéger et inclure nos camarades.

Une conférence de mecs blancs

Les conférences que j'ai citées comme marquantes pourraient faire croire à une parité de genre des intervenants·es, mais il n'en est rien. Les militant·es antipatriarcales doivent malheureusement faire un énorme travail pour leur inclusion et l'organisation du CdL s'est déjà faite remonter les bretelles il y a quelques années pour avoir refusé des présentations de femmes quand dans le même temps elle en accordait plusieurs à des hommes.

Lors de sa keynote, le présentateur nous expliquait que la mode est aux IAs, que c'est là que sont les financements en ce moment et que par conséquent et pour leur propre bien, les projets logiciels libres se doivent de suivre l'exemple de VLC et inclure des fonctionnalités en IA. La démonstration m'a laissé peu convaincu. Le lendemain, dans la même salle et au même créneau horaire, Khrys donnait une présentation nous invitant à être technocritiques des IAs via une angle féministe, soulignant la nécessité du libre. La présentation de Khrys était pertinente, percutante, intéressante, stimulante et salvatrice en nous invitant à aller contre le capitalisme et le patriarcat, et non pas à s'en accommoder comme la keynote de la veille. Sujet similaire, angle différent, la seconde présentation était à mon sens bien meilleure, mais c'est à une homme plutôt qu'à une femme que l'organisation a choisi de donner le créneau de keynote, créneau sans autres présentations pour lui faire concurrence. Khrys qui quant-à-elle a dû partager l'audience avec les nombreuses autres présentations du créneau a malgré tout réussi à faire salle comble.

De la même manière, si la présentation d'Isabella Vanni sur l'inclusion des femmes et des minorités de genre à l'April s'est vue allouée l'amphithéâtre, elle a été mise en concurrence avec une présentation sur la censure d'internet en France qui a fait salle comble, face à un amphi presque désert pour Isabella. Si la présentation sur la censure d'internet a été annulée au dernier moment, ce manquement de programmation a été relevé et critiqué.

La conférence se clôt sur une slide nous annonçant 1 200 participants à cette édition. On ne saura pas combien de participantes. Probablement que les personnes ayant réalisé ces slides n'ont pas assisté à la présentation d'Isabella Vanni qui nous expliquait pourtant bien combien le masculin neutre participe activement à l'absence des femmes dans les milieux de l'informatique et du libre.

Un autre point tristement notable est la blanchité des intervenants·es. La conférence est un véritable entre-soi blanc, pas étonnant que des propos racistes puissent être proférés pendant la table ronde sans soulever la moindre réaction, et il y a fort à parier que ça participe du fait que les personnes racisées n'y participent pas plus.

J'ai cru comprendre que certaines conférences vont activement rechercher des personnes pour présenter, mettant réellement la diversité du milieu en avant et aidant de ce fait à la rétablir en normalisant la présence, la visibilité et les paroles des personnes minorisées. J'ai entendu du bien de MiXiT et de Paris Web du point de vue de l'inclusivité, peut-être y-aurait-il à creuser dans la façon dont elles s'organisent ? Je ne dis pas que l'organisation du CdL ne se soucie pas de la diversité des intervenants·es, mais je suis convaincu que d'autres parviennent beaucoup mieux à la réaliser et que ces conférences devraient servir de points de référence.

Le CdL a beaucoup de tracks en parallèle mais je me demande si cette quantité ne se fait pas au détriment de la qualité de la conférence, et ce malgré la diversité des sujets abordés. Peut-être vaudrait-il mieux avoir moins des tracks mais des salles plus pleines, notamment l'amphithéâtre qui héberge la track principale ? Je peux entendre que réduire le nombre de tracks augmenterait l'occupation des salles de cours déjà bondées, ce qui serait effectivement un problème, mais peut-être y'a-t-il d'autres amphis à utiliser ? J'imagine que si l'organisation du CdL pouvait en avoir d'autres, elle ne les aurait pas boudés, et que donc elle ne peut en avoir qu'un seul.

Vous noterez que si les présentations qui m'ont marquées sont pour moitié présentées par des présentatrices et ce malgré une très vaste majorité de présentateurs, cela veut dire que j'ai trouvé en moyennes les présentations données par des femmes de meilleure qualité. Je serais taquin, je suggèrerais que réduire le nombre de présentations en donnant la priorité aux non-mecs et non-blancs augmenterait la qualité de la conférence. Allez, soyons taquins, je le suggère. Mais qu'on s'entende, je ne dis pas que la parité et l'inclusivité doivent être atteintes pour avoir une meilleure conférence, je note juste qu'une meilleure conférence serait un effet de bord bénéfique de leur atteinte.

Conclusion

J'ai volontairement omis de détailler les personnes qui ont commis ces impairs parce que je ne souhaite pas m'en prendre à elles mais aux problèmes. On vit dans des sociétés patriarcales, racistes, sanistes, validistes, et le milieu du libre n'y échappe pas. Je ne souhaite pas lutter contre des personnes mais contre des systèmes et les discours qui les soutiennent. J'espère que les personnes qui se reconnaîtraient dans cet article ne prendront pas mes remarques comme des attaques mais comme un appel à faire plus attention. Il y a certainement des tas d'autres problèmes que je n'ai pas vus, soit parce que je n'en ai pas eu conscience, soit parce que je n'en ai pas été témoin, soit parce que je n'ai pas le recul ou le vécu nécessaire. Je n'ai par exemple aucune idée de combien la conférence est accessible en fauteuil roulant. Mon but n'est de toute façon pas de faire une liste exhaustive mais de faire un retour sur mon vécu de la conférence, pointant du doigt des choses que je trouve graves et qui je pense devraient être sérieusement prises en compte. De plus, je tiens à présenter mes excuses de ne pas avoir plus sourcé et référencé mes propos, cet article a été écrit dans l'urgence et sa rédaction m'a fatigué, je n'ai plus l'énergie pour plus de recherches.

Je crois sincèrement aux volontés d'inclusion du CdL, tout autant que je sais qu'on vit dans des sociétés où les oppressions sont tellement banalisées qu'elles sont invisibles à la majorité. J'appelle néanmoins l'organisation du CdL à se remettre en question, les intentions d'inclusivité ne doivent pas rester des mots sur une page web et doivent être activement mises en pratique. Je ne souhaite pas spécifiquement jeter la pierre à son organisation, le CdL est une conférence que j'aime sincèrement et ce genre de problèmes sont malheureusement extrêmement répandus, non seulement dans la société mais également dans les milieux du libres. En disant ça, je souhaite pointer du doigt l'entièreté des mouvements des logiciels libres comme de la culture libre.

Conférence majeure du libre, le FOSDEM accueille des milliers de personnes et probablement plus de 10 000 dans un espace incroyablement sous-dimensionné. Évènement hautement international, les participants·es viennent de partout autour du monde. Le FOSDEM est un véritable lieu d'échange international d'épidémies où l'on blague à demi-mots que l'on tu n'as pas pleinement vécu la conférence si l'on re rentre pas avec une grippe du FOSDEM. L'organisation du FOSDEM ferme volontairement les yeux sur le problème et n'a absolument aucune politique sanitaire, la rendant activement complice de la propagation des épidémies et pandémies. À cette complicité doit s'ajouter celles des entreprises du libre qui incitent sinon forcent leurs employés·es à participer à la conférence bruxelloise.

Bien qu'étant intimiste avec sa cinquantaine de participants·es, j'ai de nouveau attrapé le covid pendant le Berlin Mini GUADEC 2024. Les mesures de protection mises en place étaient là encore insuffisantes, et nous étions de mémoire seulement 4 à se masquer, tout en devant passer des journées entières dans le même espace mal aéré. Encore une fois, je participais à la protection de personnes qui refusaient de m'accorder la même en ne se masquant pas, et l'organisation est responsable de l'insuffisance des mesures mises en place.

Je ne demande pas à ce que les conférences soient parfaites, aucune ne le sera jamais, et je ne prétends surtout pas pouvoir faire aussi bien sinon mieux. Je tiens à saluer l'organisation du CdL pour faire avoir fait un évènement assez chouette pour qu'on ait envie de le voir aller de l'avant, quitte à devoir le secouer un peu pour qu'il devienne réellement inclusif. J'espère que l'équipe du CdL ne prendra pas les problèmes que je remonte comme des attaques, tout autant que j'espère que les autres conférences du libre sauront s'assurer de ne pas faire les mêmes erreurs. J'espère également que les pistes d'amélioration que j'ai données aideront, je ne prétends pas qu'elles sont toutes faciles à mettre en place mais je veux bien, à mon échelle et avec l'énergie que j'ai, me tenir disponible pour aider l'organisation du CdL ou d'une autre conférence à trouver comment arranger la situation.

20 Nov 2024 11:00pm GMT

A while ago I was looking at Rust-based parsing of HID reports but, surprisingly, outside of C wrappers and the usual cratesquatting I couldn't find anything ready to use. So I figured, why not write my own, NIH style. Yay! Gave me a good excuse to learn API design for Rust and whatnot. Anyway, the result of this effort is the hidutils collection of repositories which includes commandline tools like hid-recorder and hid-replay but, more importantly, the hidreport (documentation) and hut (documentation) crates. Let's have a look at the latter two.

Both crates were intentionally written with minimal dependencies, they currently only depend on thiserror and arguably even that dependency can be removed.

HID Usage Tables (HUT)

As you know, HID Fields have a so-called "Usage" which is divided into a Usage Page (like a chapter) and a Usage ID. The HID Usage tells us what a sequence of bits in a HID Report represents, e.g. "this is the X axis" or "this is button number 5". These usages are specified in the HID Usage Tables (HUT) (currently at version 1.5 (PDF)). The hut crate is generated from the official HUT json file and contains all current HID Usages together with the various conversions you will need to get from a numeric value in a report descriptor to the named usage and vice versa. Which means you can do things like this:

  let gd_x = GenericDesktop::X;
  let usage_page = gd_x.usage_page();
  assert!(matches!(usage_page, UsagePage::GenericDesktop));
  

Or the more likely need: convert from a numeric page/id tuple to a named usage.

  let usage = Usage::new_from_page_and_id(0x1, 0x30); // GenericDesktop / X
  println!("Usage is {}", usage.name());
  

90% of this crate are the various conversions from a named usage to the numeric value and vice versa. It's a huge crate in that there are lots of enum values but the actual functionality is relatively simple.

hidreport - Report Descriptor parsing

The hidreport crate is the one that can take a set of HID Report Descriptor bytes obtained from a device and parse the contents. Or extract the value of a HID Field from a HID Report, given the HID Report Descriptor. So let's assume we have a bunch of bytes that are HID report descriptor read from the device (or sysfs) we can do this:

  let rdesc: ReportDescriptor = ReportDescriptor::try_from(bytes).unwrap();
  

I'm not going to copy/paste the code to run through this report descriptor but suffice to day it will give us access to the input, output and feature reports on the device together with every field inside those reports. Now let's read from the device and parse the data for whatever the first field is in the report (this is obviously device-specific, could be a button, a coordinate, anything):

   let input_report_bytes = read_from_device();
   let report = rdesc.find_input_report(&input_report_bytes).unwrap();
   let field = report.fields().first().unwrap();
   match field {
       Field::Variable(var) => {
          let val: u32 = var.extract(&input_report_bytes).unwrap().into();
          println!("Field {:?} is of value {}", field, val);
       },
       _ => {}
   }
  

The full documentation is of course on docs.rs and I'd be happy to take suggestions on how to improve the API and/or add features not currently present.

hid-recorder

The hidreport and hut crates are still quite new but we have an existing test bed that we use regularly. The venerable hid-recorder tool has been rewritten twice already. Benjamin Tissoires' first version was in C, then a Python version of it became part of hid-tools and now we have the third version written in Rust. Which has a few nice features over the Python version and we're using it heavily for e.g. udev-hid-bpf debugging and development. An examle output of that is below and it shows that you can get all the information out of the device via the hidreport and hut crates.

$ sudo hid-recorder /dev/hidraw1
# Microsoft Microsoft® 2.4GHz Transceiver v9.0
# Report descriptor length: 223 bytes
# 0x05, 0x01,                    // Usage Page (Generic Desktop)              0
# 0x09, 0x02,                    // Usage (Mouse)                             2
# 0xa1, 0x01,                    // Collection (Application)                  4
# 0x05, 0x01,                    //   Usage Page (Generic Desktop)            6
# 0x09, 0x02,                    //   Usage (Mouse)                           8
# 0xa1, 0x02,                    //   Collection (Logical)                    10
# 0x85, 0x1a,                    //     Report ID (26)                        12
# 0x09, 0x01,                    //     Usage (Pointer)                       14
# 0xa1, 0x00,                    //     Collection (Physical)                 16
# 0x05, 0x09,                    //       Usage Page (Button)                 18
# 0x19, 0x01,                    //       UsageMinimum (1)                    20
# 0x29, 0x05,                    //       UsageMaximum (5)                    22
# 0x95, 0x05,                    //       Report Count (5)                    24
# 0x75, 0x01,                    //       Report Size (1)                     26
... omitted for brevity
# 0x75, 0x01,                    //     Report Size (1)                       213
# 0xb1, 0x02,                    //     Feature (Data,Var,Abs)                215
# 0x75, 0x03,                    //     Report Size (3)                       217
# 0xb1, 0x01,                    //     Feature (Cnst,Arr,Abs)                219
# 0xc0,                          //   End Collection                          221
# 0xc0,                          // End Collection                            222
R: 223 05 01 09 02 a1 01 05 01 09 02 a1 02 85 1a 09 ... omitted for previty
N: Microsoft Microsoft® 2.4GHz Transceiver v9.0
I: 3 45e 7a5
# Report descriptor:
# ------- Input Report -------
# Report ID: 26
#    Report size: 80 bits
#  |   Bit:    8       | Usage: 0009/0001: Button / Button 1                          | Logical Range:     0..=1     |
#  |   Bit:    9       | Usage: 0009/0002: Button / Button 2                          | Logical Range:     0..=1     |
#  |   Bit:   10       | Usage: 0009/0003: Button / Button 3                          | Logical Range:     0..=1     |
#  |   Bit:   11       | Usage: 0009/0004: Button / Button 4                          | Logical Range:     0..=1     |
#  |   Bit:   12       | Usage: 0009/0005: Button / Button 5                          | Logical Range:     0..=1     |
#  |   Bits:  13..=15  | ######### Padding                                            |
#  |   Bits:  16..=31  | Usage: 0001/0030: Generic Desktop / X                        | Logical Range: -32767..=32767 |
#  |   Bits:  32..=47  | Usage: 0001/0031: Generic Desktop / Y                        | Logical Range: -32767..=32767 |
#  |   Bits:  48..=63  | Usage: 0001/0038: Generic Desktop / Wheel                    | Logical Range: -32767..=32767 | Physical Range:     0..=0     |
#  |   Bits:  64..=79  | Usage: 000c/0238: Consumer / AC Pan                          | Logical Range: -32767..=32767 | Physical Range:     0..=0     |
# ------- Input Report -------
# Report ID: 31
#    Report size: 24 bits
#  |   Bits:   8..=23  | Usage: 000c/0238: Consumer / AC Pan                          | Logical Range: -32767..=32767 | Physical Range:     0..=0     |
# ------- Feature Report -------
# Report ID: 18
#    Report size: 16 bits
#  |   Bits:   8..=9   | Usage: 0001/0048: Generic Desktop / Resolution Multiplier    | Logical Range:     0..=1     | Physical Range:     1..=12    |
#  |   Bits:  10..=11  | Usage: 0001/0048: Generic Desktop / Resolution Multiplier    | Logical Range:     0..=1     | Physical Range:     1..=12    |
#  |   Bits:  12..=15  | ######### Padding                                            |
# ------- Feature Report -------
# Report ID: 23
#    Report size: 16 bits
#  |   Bits:   8..=9   | Usage: ff00/ff06: Vendor Defined Page 0xFF00 / Vendor Usage 0xff06 | Logical Range:     0..=1     | Physical Range:     1..=12    |
#  |   Bits:  10..=11  | Usage: ff00/ff0f: Vendor Defined Page 0xFF00 / Vendor Usage 0xff0f | Logical Range:     0..=1     | Physical Range:     1..=12    |
#  |   Bit:   12       | Usage: ff00/ff04: Vendor Defined Page 0xFF00 / Vendor Usage 0xff04 | Logical Range:     0..=1     | Physical Range:     0..=0     |
#  |   Bits:  13..=15  | ######### Padding                                            |
##############################################################################
# Recorded events below in format:
# E: .  [bytes ...]
#
# Current time: 11:31:20
# Report ID: 26 /
#                Button 1:     0 | Button 2:     0 | Button 3:     0 | Button 4:     0 | Button 5:     0 | X:     5 | Y:     0 |
#                Wheel:     0 |
#                AC Pan:     0 |
E: 000000.000124 10 1a 00 05 00 00 00 00 00 00 00
  

19 Nov 2024 1:54am GMT

You might be surprised to hear that closed source firmware typically contains open source dependencies. In the case of EDK II (probably the BIOS of your x64 machine you're using now) it's about 20 different projects, and in the case of coreboot (hopefully the firmware of the machine you'll own in the future) it's about another 10 - some overlapping with EDK II. Examples here would be things like libjpeg (for the OEM splash image) or libssl (for crypto, but only the good kind).

It makes no sense for each person building firmware to write the same SBOM for the OSS code. Moving the SBOM upstream means it can be kept up to date by the same team writing the open source code. It's very similar to what we encouraged desktop application developers to do with AppStream metadata a decade or so ago. That was wildly successful, so maybe we can do the same trick again here.

My proposal would to submit a sbom.cdx.json to each upstream project in CycloneDX format, stored in a location amenable to the project - e.g. in ./contrib, ./data/sbom or even in the root project folder. The location isn't important, only the file suffix needs to be predictable.

Notice the CycloneDX word there not SPDX - the latter is great for open source license compliance, but I was only able to encode 43% of our "example firmware SBOM" into SPDX format, even with a lot of ugly hacks. I spent a long time trying to jam a round peg in a square hole and came to the conclusion it's not going to work very well. SPDX works great as an export format to ensure license compliance (and the uswid CLI can already do that now…) but SPDX doesn't work very well as a data source. CycloneDX is just a better designed format for a SBOM, sorry ISO.

Let's assume we check in a new file to ~30 projects. With my upstream-maintainer hat on, nobody likes to manually edit yet-another-file when tagging releases, so I'm encouraging projects shipping a CycloneDX sbom.cdx.json to use some of the auto-substituted tokens, e.g.

• @VCS_TAG@ → git describe --tags --abbrev=0 e.g. 1.2.3
• @VCS_VERSION@ → git describe --tags e.g. 1.2.3-250-gfa2371946
• @VCS_BRANCH@ → git rev-parse --abbrev-ref HEAD e.g. staging
• @VCS_COMMIT@ → git rev-parse HEAD e.g. 3090e61ee3452c0478860747de057c0269bfb7b6
• @VCS_SBOM_AUTHORS@ → git shortlog -n -s -- sbom.cdx.json e.g. Example User, Another User
• @VCS_SBOM_AUTHOR@ → @VCS_SBOM_AUTHORS@[0] e.g. Example User
• @VCS_AUTHORS@ → git shortlog -n -s e.g. Example User, Another User
• @VCS_AUTHOR@ → @VCS_AUTHORS@[0] e.g. Example User

Using git in this way during the built process allows us to also "fixup" SBOM files with either missing details, or when the downstream ODM patches the project to do something upstream wouldn't be happy with shipping upstream.

For fwupd (which I'm using as a cute example, it's not built into firmware…) the sbom.cdx.json file would be something like this:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "version": 1,
  "metadata": {
    "authors": [
      {
        "name": "@VCS_SBOM_AUTHORS@"
      }
    ]
  },
  "components": [
    {
      "type": "library",
      "bom-ref": "pkg:github/fwupd/fwupd@@VCS_TAG@",
      "cpe": "cpe:2.3:a:fwupd:fwupd:@VCS_TAG@:*:*:*:*:*:*:*",
      "name": "fwupd",
      "version": "@VCS_VERSION@",
      "description": "Firmware update daemon",
      "supplier": {
        "name": "fwupd developers",
        "url": [
          "https://github.com/fwupd/fwupd/blob/main/MAINTAINERS"
        ]
      },
      "licenses": [
        {
          "license": {
            "id": "LGPL-2.1-or-later"
          }
        }
      ],
      "externalReferences": [
        {
          "type": "website",
          "url": "https://fwupd.org/"
        },
        {
          "type": "vcs",
          "url": "https://github.com/fwupd/fwupd"
        }
      ]
    }
  ]
}

Putting it all together means we can do some pretty clever things assuming we have a recursive git checkout using either git modules, sub-modules or sub-projects:

$ uswid --find ~/Code/fwupd --fixup --save sbom.cdx.json --verbose
Found:
 - ~/Code/fwupd/contrib/sbom.cdx.json
 - ~/Code/fwupd/venv/build/contrib/sbom.cdx.json
 - ~/Code/fwupd/subprojects/libjcat/contrib/spdx.json
Substitution required in ~/Code/fwupd/contrib/sbom.cdx.json:
 - @VCS_TAG@ → 2.0.1
 - @VCS_VERSION@ → 2.0.1-253-gd27804fbb
Fixup required in ~/Code/fwupd/subprojects/libjcat/spdx.json:
 - Add VCS commit → db8822a01af89aa65a8d29c7110cc86d78a5d2b3
Additional dependencies added:
 - pkg:github/hughsie/libjcat@0.2.1 → pkg:github/hughsie/libxmlb@0.2.1
 - pkg:github/fwupd/fwupd@2.0.1 → pkg:github/hughsie/libjcat@0.2.1
~/Code/fwupd/venv/build/contrib/sbom.cdx.json was merged into existing component pkg:github/fwupd/fwupd@2.0.1

And then we have a sbom.cdx.json that we can use as an input file used for building the firmware blob. If we can convince EDK2 to merge the additional sbom.cdx.json for each built module then it all works like magic, and we can build the 100% accurate external SBOM into the firmware binary itself with no additional work. Comments most welcome.

14 Nov 2024 3:58pm GMT

Note: the PDF/A specification is not freely available so everything here is based on reverse engineering. It might be complete bunk.

There are many different "subspecies" of PDF. The most common are PDF/X and PDF/A. CapyPDF can already do PDF/X, so I figured it's time to look into PDF/A. Like, how much worse could it possibly be?

Specifying that a PDF file is PDF/X is straightforward. Each PDF has a Catalog dictionary that defines properties of the document. All you need to do is to add an OutputIntent dictionary and link it to the Catalog. The dictionary has a key that specifies the subtype. Setting that to /GTS_PDFX does the trick. There are many different versions of PDF/X so you need to define that as well. A simple solution would be to have a second key in that dictionary for specifying the subtype. Half of that expectation is correct. There is indeed a key you can set, but it is in a completely different part of the object tree called the Information dictionary. It's a bit weird but you implement it once and then forget it.

PDF/A has four different versions, namely 1, 2, 3, 4 and each of these have several conformance levels that are specified with a single letter. Thus the way you specify that the file is a PDF/A document is that you write the value /GTS_PDFA1 to the intent dictionary. Yes. regardless of which version of PDF/A you want, this dictionary will say it is PDFA1.

What would be the mechanism, then, to specify the sub version:

1. In the Information dictionary, just like with PDF/X?
2. In some other PDF object dictionary?
3. In a standalone PDF object that is in fact an embedded XML document?
4. Something even worse?

Depending on your interpretation, the correct answer is either 3 or 4. Here is the XML file in question as generated by LibreOffice. The payload parts are marked with red arrows.

The other bits are just document metadata replicated. PDF version 2.0 has gone even further and deprecated storing PDF metadata in PDF's own data structures. The sructures that have been designed specifically for PDF documents, which all PDF processing software already know how to handle and which tens of billions (?) of documents already use and which can thus never be removed? Those ones. As Sun Tzu famously said:

A man with one metadata block in his file format always knows what his document is called.

A man with two can never be sure.

Thus far we have only been at level 3. So what more could possibly be added to this to make it even worse?

Spaces.

Yes, indeed. The screen shot does not show it, but the recommend way to use this specific XML format is to add a whole lot of whitespace below the XML snippet so it can be edited in place later if needed. This is highly suspicious for PDF/A for two main reasons. First of all PDF/A is meant for archiving usage. Documents in it should not be edited afterwards. That is the entire point. Secondly, the PDF file format already has a way of replacing objects with newer versions.

The practical outcome of all this is that every single PDF/A document has approximately 5 kilobytes of fluff to represent two bytes of actual information. Said object can not even be compressed because the RDF document must be stored uncompressed to be editable. Even though in PDF/A documents it will never be edited.

08 Nov 2024 3:01pm GMT

Today at Red Hat is day of learning again! I used the occasion to brush up my knowledge about web components and taking a look at PatternFly Elements. I've leered at that for a long time already - using "regular" PatternFly requires React, and thus all the npm, bundler, build system etc. baggage around it. In Cockpit we support writing your own plugins with a simple static .html and .

08 Nov 2024 12:00am GMT

I've just been to two traditional Czech open source conferences - LinuxDays and OpenAlt - and I've noticed one interesting shift: the communication on social media during the conferences has disappeared.

After 2010, we suddenly all had a device in our pocket that we could easily use to share experiences and observations from anywhere. And at least at IT events, people started doing this a lot. Under the hashtag of the given conference, there was a stream of messages from participants about which talks they liked, where they could find a good place to eat in the area, what caught their attention among the booths. The event organizers used this to inform visitors, and the booth staff to attract people to their booth. I remember writing about what we had interesting at our booth, and people actually came to have a look based on that.

At the peak of this trend, the popular so-called Twitter walls were in use. These were typically web applications that displayed the latest messages under a given hashtag, and they ran on screens in the corridors or were projected directly in the lecture rooms, so that even those who weren't following it on their mobile phones could keep track.

And today, all of this has practically disappeared. When I counted it after LinuxDays, there were a total of 14 messages with the #linuxdays hashtag on Mastodon during the conference, and only 8 on Twitter. During OpenAlt, there were 20 messages with the #openalt hashtag on Mastodon and 8 on Twitter. I also checked if it was running on Bluesky. There were a few messages with the hashtags of both conferences there, but except for one, they were all bridged from Mastodon.

In any case, these are absolutely negligible numbers compared to what we used to see ten years ago. Where did it all go? I thought about it and came up with four reasons:

1. Microblogging is much more fragmented today than it was ten years ago. Back then, we were all on Twitter. That is now in decline. The open-source community has largely moved to Mastodon, but not entirely. Some are still on LinkedIn, some on Bluesky, etc. When there is no single place where everyone is, the effect of a universal communication channel disappears.
2. Conference communication has partly shifted to instant messaging. This trend started 8-9 years ago. A group (typically on Telegram) was created for conference attendees, and it served for conference communication. Compared to a microblogging platform, this has the advantage that it is not entirely open communication. What happens at the conference, stays at the conference. It doesn't take the form of publicly searchable messages. For some, this is a safer space than a social network. It's also faster, with features like location sharing, etc. However, this mode of communication has also declined a lot. During OpenAlt, there were only 20 messages in its Telegram group.
3. People are much more passive on social media today. Rather than sharing their own posts from the conference, they'd rather leave it to some influencer who will make a cool video from there, which everyone will then watch and like. All the major social networks have shifted towards a small group creating content for a passive majority. New platforms like TikTok have been functioning this way from the start.
4. After Covid, people simply don't have the same need to share their conference experiences online. They are somewhat saturated with it after the Covid years, and when they go somewhere, they don't want to tap messages into their phone about how they're doing there.

Overall, I don't see it as a bad thing. Yes, it had its charm, and it was easier during the conference to draw attention to your booth or talk, but in today's digital age, any shift towards offline is welcome. After all, conferences are there for people to meet in person. Otherwise, we could just watch the streams from home and write about them on social media. We've been there before, and it wasn't quite right.

How do you see it? Do you also notice that you share less online from conferences?

07 Nov 2024 5:00pm GMT