gnome-info-collect is a new tool that collects anonymous data about how GNOME systems are configured. It sends that information back to GNOME servers where it can be analyzed. The goal of this tool is to help improve GNOME, by providing data that can inform design decisions, influence where resources are invested, and generally help GNOME understand its users better.

The more people who provide data, the better! So, if you would like to help us improve GNOME, please consider installing and running gnome-info-collect on your system. It only takes a second.

As of last week, gnome-info-collect is ready to be used, and we are asking all GNOME users to install and run it!

How to run the tool

Simply install the package from Fedora Copr repository by running the following commands:

$ dnf copr enable vstanek/gnome-info-collect
$ dnf install gnome-info-collect

The Copr repository also contains instructions on how to install on systems without dnf (useful for Silverblue users).

After installing, simply run

$ gnome-info-collect

from the Terminal. The tool will show you what information will be shared and won’t upload anything until you give your consent.

There are packages for other distributions as well. See the project’s README for more information.

How it works

gnome-info-collect is a simple client-server application. The client can be run on any GNOME system. There, it collects various system data including:

• Hardware information, including the manufacturer and model
• Various system settings, including workspace configuration, and which sharing features are enabled
• Application information, such as which apps are installed, and which ones are favourited
• Which GNOME shell extensions are installed and enabled

You can find the full list of collected information in the gnome-info-collect README. The tool shows the data that will be collected prior to uploading and, if the user consents to the upload, is then securely sent to GNOME’s servers for processing.

Data privacy

The collected data is completely anonymous and will be used only for the purpose of enhancing usability and user experience of GNOME. No personal information, like usernames or email addresses, is recorded. Any potentially identifying information, such as the IP address of the sender and the precise time of receiving the data, is discarded on the server side. To prevent the same client from sending data multiple times, a salted hash of the machine ID and username is used.

All of this ensures that the collected data is confidential and untraceable.

Spread the word!

The best way to help is to take part by running gnome-info-collect and uploading your anonymous data.

You can also help by sharing this article with other GNOME users, and by encouraging others to run the collection tool themselves. The more users running gnome-info-collect, the better conclusions we can make from the collected data. This will result in an improved GNOME system that is more comfortable for its users.

So, do not hesitate to help improve GNOME. Simply install gnome-info-collect, run it and go tell all your GNOME friends about it! Thank you!

This article walks you through the manual setup for hibernation in Fedora Linux 36 Workstation using BTRFS and is based on a gist by eloylp on github.

Goal and Rationale

Hibernation stores the current runtime state of your machine – effectively the contents of your RAM, onto disk and does a clean shutdown. Upon next boot this state is restored from disk to memory such that everything, including open programs, is how you left it.

Fedora Workstation uses ZRAM. This is a sophisticated approach to swap using compression inside a portion of your RAM to avoid the slower on-disk swap files. Unfortunately this means you don’t have persistent space to move your RAM upon hibernation when powering off your machine.

How it works

The technique configures systemd and dracut to store and restore the contents of your RAM in a temporary swap file on disk. The swap file is created just before and removed right after hibernation to avoid trouble with ZRAM. A persistent swap file is not recommended in conjunction with ZRAM, as it creates some confusing problems compromising your systems stability.

A word on compatibility and expectations

Hibernation following this guide might not work flawless on your particular machine(s). Due to possible shortcomings of certain drivers you might experience glitches like non-working wifi or display after resuming from hibernation. In that case feel free to reach out to the comment section of the gist on github, or try the tips from the troubleshooting section at the bottom of this article.

The changes introduced in this article are linked to the systemd hibernation.service and hibernation.target units and hence won’t execute on their own nor interfere with your system if you don’t initiate a hibernation. That being said, if it does not work it still adds some small bloat which you might want to remove.

Hibernation in Fedora Workstation

The first step is to create a btrfs sub volume to contain the swap file.

$ btrfs subvolume create /swap

In order to calculate the size of your swap file use swapon to get the size of your zram device.

$ swapon
NAME TYPE SIZE USED PRIO
/dev/zram0 partition 8G 0B 100

In this example the machine has 16G of RAM and a 8G zram device. ZRAM stores roughly double the amount of system RAM compressed in a portion of your RAM. Let that sink in for a moment. This means that in total the memory of this machine can hold 8G * 2 + 8G of RAM which equals 24G uncompressed data. Create and configure the swapfile using the following commands.

$ touch /swap/swapfile
# Disable Copy On Write on the file
$ chattr +C /swap/swapfile
$ fallocate --length 24G /swap/swapfile
$ chmod 600 /swap/swapfile $ mkswap /swap/swapfile

Modify the dracut configuration and rebuild your initramfs to include the

module, so it can later restore the state at boot.

$ cat <<-EOF | sudo tee /etc/dracut.conf.d/resume.conf
add_dracutmodules+=" resume "
EOF
$ dracut -f

In order to configure grub to tell the kernel to resume from hibernation using the swapfile, you need the UUID and the physical offset.

Use the following command to determine the UUID of the swap file and take note of it.

$ findmnt -no UUID -T /swap/swapfile
dbb0f71f-8fe9-491e-bce7-4e0e3125ecb8

Calculate the correct offset. In order to do this you’ll unfortunately need gcc and the source of the btrfs_map_physical tool, which computes the physical offset of the swapfile on disk. Invoke gcc in the directory you placed the source in and run the tool.

$ gcc -O2 -o btrfs_map_physical btrfs_map_physical.c
$ ./btrfs_map_physical /path/to/swapfile FILE OFFSET EXTENT TYPE LOGICAL SIZE LOGICAL OFFSET PHYSICAL SIZE DEVID PHYSICAL OFFSET
0 regular 4096 2927632384 268435456 1 <4009762816>
4096 prealloc 268431360 2927636480 268431360 1 4009766912
268435456 prealloc 268435456 3251634176 268435456 1 4333764608
536870912 prealloc 268435456 3520069632 268435456 1 4602200064
805306368 prealloc 268435456 3788505088 268435456 1 4870635520
1073741824 prealloc 268435456 4056940544 268435456 1 5139070976
1342177280 prealloc 268435456 4325376000 268435456 1 5407506432
1610612736 prealloc 268435456 4593811456 268435456 1 5675941888

The first value in the PHYSICAL OFFSET column is the relevant one. In the above example it is 4009762816.

Take note of the pagesize you get from getconf PAGESIZE.

Calculate the kernel resume_offset through division of physical offset by the pagesize. In this example that is 4009762816 / 4096 = 978946.

Update your grub configuration file and add the resume and resume_offset kernel cmdline parameters.

grubby --args="resume=UUID=dbb0f71f-8fe9-491e-bce7-4e0e3125ecb8 resume_offset=2459934" --update-kernel=ALL

The created swapfile is only used in the hibernation stage of system shutdown and boot hence not configured in fstab. Systemd units control this behavior, so create the two units hibernate-preparation.service and hibernate-resume.service.

$ cat <<-EOF | sudo tee /etc/systemd/system/hibernate-preparation.service
[Unit]
Description=Enable swap file and disable zram before hibernate
Before=systemd-hibernate.service [Service]
User=root
Type=oneshot
ExecStart=/bin/bash -c "/usr/sbin/swapon /swap/swapfile && /usr/sbin/swapoff /dev/zram0" [Install]
WantedBy=systemd-hibernate.service
EOF
$ systemctl enable hibernate-preparation.service
$ cat <<-EOF | sudo tee /etc/systemd/system/hibernate-resume.service
[Unit]
Description=Disable swap after resuming from hibernation
After=hibernate.target [Service]
User=root
Type=oneshot
ExecStart=/usr/sbin/swapoff /swap/swapfile [Install]
WantedBy=hibernate.target
EOF
$ systemctl enable hibernate-resume.service

Systemd does memory checks on login and hibernation. In order to avoid issues when moving the memory back and forth between swapfile and zram disable some of them.

$ mkdir -p /etc/systemd/system/systemd-logind.service.d/
$ cat <<-EOF | sudo tee /etc/systemd/system/systemd-logind.service.d/override.conf
[Service]
Environment=SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1
EOF
$ mkdir -p /etc/systemd/system/systemd-hibernate.service.d/
$ cat <<-EOF | sudo tee /etc/systemd/system/systemd-hibernate.service.d/override.conf
[Service]
Environment=SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1
EOF

Reboot your machine for the changes to take effect. The following SELinux configuration won’t work if you don’t reboot first.

SELinux won’t like hibernation attempts just yet. Change that with a new policy. An easy although “brute” approach is to initiate hibernation and use the audit log of this failed attempt via audit2allow. The following command will fail, returning you to a login prompt.

systemctl hibernate

After you’ve logged in again check the audit log, compile a policy and install it. The -b option filters for audit log entries from last boot. The -M option compiles all filtered rules into a module, which is then installed using semodule -i.

$ audit2allow -b
#============= systemd_sleep_t ==============
allow systemd_sleep_t unlabeled_t:dir search;
$ cd /tmp
$ audit2allow -b -M systemd_sleep
$ semodule -i systemd_sleep.pp

Check that hibernation is working via systemctl hibernate again. After resume check that ZRAM is indeed the only active swap device.

$ swapon
NAME TYPE SIZE USED PRIO
/dev/zram0 partition 8G 0B 100

You now have hibernation configured.

GNOME Shell hibernation integration

You might want to add a hibernation button to the GNOME Shell “Power Off / Logout” section. Check out the extension Hibernate Status Button to do so.

Troubleshooting

A first place to troubleshoot any problems is through journalctl -b. Have a look around the end of the log, after trying to hibernate, to pin-point log entries that tell you what might be wrong.

Another source of information on errors is the Problem Reporting tool. Especially problems, that are not common but more specific to your hardware configuration. Have a look at it before and after attempting hibernation and see if something comes up. Follow up on any issues via BugZilla and see if others experience similar problems.

Revert the changes

To reverse the changes made above, follow this check-list:

• remove the swapfile
• remove the swap subvolume
• remove the dracut configuration and rebuild dracut
• remove kernel cmdline args via grubby –remove-args=
• disable and remove hibernation preparation and resume services
• remove systemd overrides for systemd-logind.service and systemd-hibernation.service
• remove SELinux module via semodule -r systemd_sleep

Credits and Additional Resources

This article is a community effort based primarily on the work of eloylp. As author of this article I’d like to make transparent that I’ve participated in the discussion to advance the gist behind this but many more minds contributed to make this work. Make certain to check out the discussion on github.

There are already some ansible playbooks and shell scripts to automate the process depicted in this guide. For example check out the shell scripts by krokwen and pietryszak or the ansible playbook by jorp

See the arch wiki for the full guide on how to calculate the swapfile offset.

This article aims to introduce community containers, where users can pull them from, and use them. The three groups of containers available for use by community users are discussed. These are: Fedora, CentOS, and CentOS Stream.

What are the differences between the containers?

Fedora containers are based on the latest stable Fedora content, and CentOS-7 containers are based on components from the CentOS-7 and related SCLo SIG components. And finally, CentOS Stream containers are based on either CentOS Stream 8 or CentOS Stream 9.

Each container, e.g. s2i-php-container or s2i-perl-container, contain the same packages which are available for a given operating system. It means, that from a functionality point of view these example containers provides the PHP interpreter or Perl interpreter,respectively. 

Differences can be only in versions, which are available for each distribution. For example:

Fedora PHP containers are available in these versions:

• PHP-80 for Fedora 35

CentOS-7 PHP containers are available in these versions:

• PHP-73

CentOS Stream 9 PHP containers are available in these versions:

• PHP-74

CentOS Stream 8 is not mentioned here for the PHP use case since users can pull it directly from the Red Hat Container Catalog registry as a UBI image. Containers that are not UBI based have CentOS Stream 8 repositories in the quay.io/sclorg namespace with repository suffix “-c8s”.

Fedora container images moved recently

The Fedora container images have recently moved to the quay.io/fedora registry organization. All of them use Fedora:35, and later Fedora:36 ,as a base image. The CentOS-7 containers are stored in the quay.io/centos7 registry organization. All of them use CentOS-7 as a base image.

CentOS Stream container images

The CentOS Stream containers are stored in the quay.io/sclorg registry organization.

The base image used for our CentOS Stream 8 containers is CentOS Stream 8 with the tag “stream8”.

The base image used for our CentOS Stream 9 containers is CentOS Stream 9 with the tag “stream9”.

In this registry organization, each container contains a “suffix”, either “c8s”  for CentOS Stream 8 or “c9s” for CentOS Stream 9, respectively.

See container PHP-74 for CentOS Stream 9.

Frequency of container image updates and testing

The community-based containers are updated in two ways.

First, when a pull request in the container sources that live under github.com/sclorg organization is merged, the corresponding versions in the GitHub repository are built and pushed into the proper repository.

Second, an update process is also implemented by GitHub Actions set up in each of our GitHub repositories. The base images, like “s2i-core” and “s2i-base”, are built each Tuesday at 1:00 pm. The rest of the containers are built each Wednesday at 1:00 pm.

This means every package update or change is updated in the container image within a few days, not later than after a week.

Each container that is not beyond its end of life is tested by our nightly builds. If we discover or detect an error on some of our containers, we attempt to fix it, but there are no guarantees provided.

What container shall I use?

In the end, what containers are we providing? That’s a great question. All containers live in the GitHub organization https://github.com/sclorg

The list of containers with their upstreams is summarized here:

• PostgreSQL server – https://github.com/sclorg/postgresql-container
• Nginx web server – https://github.com/sclorg/nginx-container
• Redis server – https://github.com/sclorg/redis-container
• Varnish cache – https://github.com/sclorg/varnish-container
• MySQL server – https://github.com/sclorg/mysql-container
• MariaDB server – https://github.com/sclorg/mariadb-container
• Apache HTTPD server – https://github.com/sclorg/httpd-container
• PHP application container image – https://github.com/sclorg/s2i-php-container
• Perl application container image – https://github.com/sclorg/s2i-perl-container
• Ruby application container image – https://github.com/sclorg/s2i-ruby-container
• Node.js application container image – https://github.com/sclorg/s2i-nodejs-container
• Python application container image – https://github.com/sclorg/s2i-python-container

How to use the container image I picked?

All container images are tuned up to be fully functional in the OpenShift (or OKD and even Kubernetes itself) without any trouble. Some containers support the source-to-image build strategy while some are expected to be used as daemons (like databases, for instance). For specific steps, please, navigate to the GitHub page for the respective container image by following one of the links above.

Finally, Some Real examples

Let’s show how to use PHP container images across all platforms that we support.

First of all, clone the container GitHub repository using this command:

$ git clone https://github.com/sclorg/s2i-php-container

Switch to the following directory created by the cloning step:

$ cd s2i-php-container/examples/from-dockerfile

Fedora example

Start by pulling the Fedora PHP-80 image with this command:

$ podman pull quay.io/fedora/php-80

Modify “Dockerfile” so it refers to Fedora php-80 image. “Dockerfile” then looks like:

FROM quay.io/fedora/php-80 USER 0
# Add application sources
ADD app-src .
RUN chown -R 1001:0 .
USER 1001 # Install the dependencies
RUN TEMPFILE=$(mktemp) && \ curl -o "$TEMPFILE" "https://getcomposer.org/installer" && \ php <"$TEMPFILE" && \ ./composer.phar install --no-interaction --no-ansi --optimize-autoloader # Run script uses standard ways to configure the PHP application
# and execs httpd -D FOREGROUND at the end
# See more in <version>/s2i/bin/run in this repository.
# Shortly what the run script does: The httpd daemon and php need to be
# configured, so this script prepares the configuration based on the container
# parameters (e.g. available memory) and puts the configuration files into
# the appropriate places.
# This can obviously be done differently, and in that case, the final CMD
# should be set to "CMD httpd -D FOREGROUND" instead.
CMD /usr/libexec/s2i/run

Check if the application works properly

Build it by using this command:

$ podman build -f Dockerfile -t cakephp-app-80

Now run the application using this command:

$ podman run -ti --rm -p 8080:8080 cakephp-app-80

To check the PHP version use these commands:

$ podman run -it –rm cakephp-app-80 bash
$ php –version

To check if everything works properly use this command:

$ curl -s -w ‘%{http_code}’ localhost:8080

This should return HTTP code 200. If you would like to see a web page enter “localhost:8080” in your browser.

CentOS 7 example

Start by pulling the CentOS-7 PHP-73 image using this command:

$ podman pull quay.io/centos7/php-73-centos7

Modify “Dockerfile” so it refers to CentOS php-73 image.

“Dockerfile” then looks like this:

FROM quay.io/centos7/php-73-centos7 USER 0
# Add application sources
ADD app-src .
RUN chown -R 1001:0 .
USER 1001 # Install the dependencies
RUN TEMPFILE=$(mktemp) && \ curl -o "$TEMPFILE" "https://getcomposer.org/installer" && \ php <"$TEMPFILE" && \ ./composer.phar install --no-interaction --no-ansi --optimize-autoloader # Run script uses standard ways to configure the PHP application
# and execs httpd -D FOREGROUND at the end
# See more in <version>/s2i/bin/run in this repository.
# Shortly what the run script does: The httpd daemon and php needs to be
# configured, so this script prepares the configuration based on the container
# parameters (e.g. available memory) and puts the configuration files into
# the appropriate places.
# This can obviously be done differently, and in that case, the final CMD
# should be set to "CMD httpd -D FOREGROUND" instead.
CMD /usr/libexec/s2i/run

Check if the application works properly

Build it using this command:

$ podman build -f Dockerfile -t cakephp-app-73

Now run the application using this command:

$ podman run -ti --rm -p 8080:8080 cakephp-app-73

To check the PHP version us these commands:

$ podman run -it –rm cakephp-app-73 bash
$ php –version

To check if everything works properly use this command:

curl -s -w ‘%{http_code}’ localhost:8080

RHEL 9 UBI 9 real example

Start by pulling the RHEL9 UBI-based PHP-80 image using the command:

$ podman pull registry.access.redhat.com/ubi9/php-80

Modify “Dockerfile” so it refers to the RHEL9 ubi9 php-80 image.

“Dockerfile” then looks like:

FROM registry.access.redhat.com/ubi9/php-80 USER 0
# Add application sources
ADD app-src .
RUN chown -R 1001:0 .
USER 1001 # Install the dependencies
RUN TEMPFILE=$(mktemp) && \ curl -o "$TEMPFILE" "https://getcomposer.org/installer" && \ php <"$TEMPFILE" && \ ./composer.phar install --no-interaction --no-ansi --optimize-autoloader # Run script uses standard ways to configure the PHP application
# and execs httpd -D FOREGROUND at the end
# See more in <version>/s2i/bin/run in this repository.
# Shortly what the run script does: The httpd daemon and php needs to be
# configured, so this script prepares the configuration based on the container
# parameters (e.g. available memory) and puts the configuration files into
# the appropriate places.
# This can obviously be done differently, and in that case, the final CMD
# should be set to "CMD httpd -D FOREGROUND" instead.
CMD /usr/libexec/s2i/run

Check if the application works properly

Build it using this command:

$ podman build -f Dockerfile -t cakephp-app-80-ubi9

Now run the application using this command:

$ podman run -ti --rm -p 8080:8080 cakephp-app-80-ubi9

To check the PHP version use these commands:

$ podman run -it –rm cakephp-app-80-ubi9 bash
$ php –version

To check if everything works properly use this command:

curl -s -w ‘%{http_code}’ localhost:8080

which should return HTTP code 200. If you would like to see a web page enter localhost:8080 in your browser.

What to do in the case of a bug or enhancement

Just file a bug (known as an “issue” in GitHub) or even a pull request with a fix, to one of the GitHub repositories mentioned in the previous section.

Introduction

Embroidered shirts are great custom gifts and can also be a great way to show your love for open source. This tutorial will demonstrate how to design your own custom embroidered polo shirt using Inkscape and Ink/Stitch. Polo shirts are often used for embroidery because they do not tear as easily as t-shirts when pierced by embroidery needles, though with care t-shirts can also be embroidered. This tutorial is a follow on article to Make More with Inkscape and Ink/Stitch and provides complete steps to create your design.

Logo on Front of Shirt

Pictures with only a few colors work well for embroidery. Let us use a public domain black and white SVG image of Tux created by Ryan Lerch and Garret LeSage.

Download this public domain image, tux-bw.svg, to your computer, and import it into your document as an editable SVG image using File>Import...

Use a Transparent Background

It is helpful to have a checkerboard background to distinguish background and foreground colors. Click File>Document Properties… and then check the box to enable a checkerboard background.

Then close the document properties dialog box. You can now distinguish between colors used on Tux and the background color.

Use a Single Color For Tux

Type s to use the Select and Transform objects tool, and click on the image of Tux to select it. Then click on Object>Fill and Stroke, in the menu. Type n to use the Edit paths by Nodes tool and click on a white portion of Tux. Within the Fill and Stroke pane change the fill to No paint to make this portion of Tux transparent.

Thi leaves the black area to be embroidered.

Enable Embroidering of Tux

Now convert the image for embroidery. Type s to use the Select and Transform objects tool and click on the image of Tux to select it again. Choose Extensions>Ink/Stitch>Fill Tools>Break Apart Fill Objects … In the resulting pop up, choose Complex, click Apply, and wait for the operation to complete.

For further explanation of this operation, see the Ink/Stitch documentation.

Resize Document

Now resize the area to be embroidered. A good size is about 2.75 inches by 2.75 inches. Press s to use the Select and Transform objects tool, and select Tux, hold down the shift key, and also select any text area. Then choose Object>Transform …, click on Scale in the dialogue box, change the measurements to inches, check the Scale proportionally box and choose a width of 2.75 inches, and click Apply.

Before saving the design, reduce the document area to just fit the image. Press s to use the Select and Transform objects tool, then select Tux.

Choose File>Document Properties… then choose Resize to content: or press Ctrl+Shift+R

The document is resized.

Save Your Design

You now need to convert your file to an embroidery file. A very portable format is the DST (Tajima Embroidery Format) format, which unfortunately does not have color information, so you will need to indicate color information for the embroidery separately. First save your design as an Inkscape SVG file so that you retain a format that you can easily edit again. Choose File>Save As, then select the Inkscape SVG format and enter a name for your file, for example AnotherAwesomeFedoraLinuxUserFront.svg and save your design. Then choose File>Save As and select the DST file format and save your design. Generating this file requires calculation of stitch locations, this may take a few seconds. You can preview the DST file in Inkscape, but another very useful tool is vpype-embroidery

Install vpype-embroidery on the command line using a Python virtual environment via the following commands:

virtualenv test-vpype
source test-vpype/bin/activate
pip install matplotlib
pip install vpype-embroidery
pip install vpype[all]

Preview your DST file (in this case named AnotherAwesomeFedoraLinuxUserFront.dst which should be replaced by the filename you choose if it is different), using this command:

vpype eread AnotherAwesomeFedoraLinuxUserFront.dst show

Check the dimensions of your design, if you need to resize it, you should resize the SVG design file before exporting it as a DST file. Resizing the DST file is not recommended since it contains stitch placement information, regenerate this placement information from the resized SVG file to obtain a high quality embroidered result.

Text on the Back of the Shirt

Now create a message to put on the back of your polo shirt. Create a new Inkscape document using File>New. Then choose Extensions>Ink/Stitch>Lettering.

Choose a font, for example Geneva Simple Sans created by Daniel K. Schneider in Geneva. If you want to resize your text, do so at this point using the scale section of the dialog box since resizing it once it is in Inkscape will distort the resulting embroidered pattern. Add your text,

Another Awesome Fedora Linux User

A preview will appear, click on Quit

Then click on Apply and Quit in the lettering creation dialog box. Your text should appear in your Inkscape document.

Create a checkered background and resize the document to content by opening up the document properties dialog box File>Document Properties…

Your document should now be a little larger than your text.

Clean Up Stitches

Many commercial embroidery machines support jump instructions which can save human time in finishing the embroidered garment. Examine the text preview image. A single continuous thread sews all the letters. Stitches joining the letters are typically removed. These stitches can either be cut by hand after the embroidery is done, or they can be cut by the embroidery machine if it supports jump instructions. Ink/Stitch can add these jump instructions.

Add jump instructions by selecting View>Zoom>Zoom Page to enlarge the view of the drawing. Press s to choose the Select and transform objects tool. Choose Extensions>Ink/Stitch>Commands>Attach Commands to Selected Objects. A dialog box should appear, check just the Trim thread after sewing this object option.

Then click in the drawing area and select the first letter of the text

Then click Apply, and some cut symbols should appear above the letter.

Repeat this process for all letters.

Now save your design, as before, in both SVG and DST formats. Check the likely quality of the embroidered text by previewing your DST file (in this case named AnotherAwesomeFedoraLinuxUserBack.dst – replaced this by the filename you chose), using

vpype eread AnotherAwesomeFedoraLinuxUserBack.dst show

Check the dimensions of your design, if you need to resize it, you should resize the SVG design file before exporting it as a DST file.

Create a Mockup

To show the approximate placement of your design on the polo shirt create a mockup. You can then send this to an embroidery company with your DST file. The Fedora Design Team has a wiki page with examples of mockups. An example mockup made using Kolourpaint is below.

You can also use an appropriately licensed drawing of a polo shirt, for example from Wikimedia Commons.

Example Shirt

Pictures of a finished embroidered polo shirt are below

Further Information

A three color image of Tux is also available, but single colors are easiest to achieve good embroidered results with. Adaptation of this shaded multiple color image is required to use it for embroidery. Additional tutorial information is available on the Ink/Stitch website.

Some companies that can do embroidery given a DST file include:

• Pappagallo Clothing Industry based in Cyprus
• Target Solutions based in Ghana
• Marvel Ark based in Kenya
• Core Digital based in South Africa
• Embroidery Your Way based in the USA

Search the internet for machine embroidery services close to you or a hackerspace with an embroidery machine you can use.

This article has benefited from many helpful suggestions from Michael Njuguna of Marvel Ark and Brian Lee of Embroidery Your Way.

The first concerted effort to support accessibility under Linux was undertaken by Sun Microsystems when they decided to use GNOME for Solaris. Sun put together a team focused on building the pieces to make GNOME 2 fully accessible and worked with hardware makers to make sure things like Braille devices worked well. I even heard claims that GNOME and Linux had the best accessibility of any operating system for a while due to this effort. As Sun started struggling and got acquired by Oracle this accessibility effort eventually trailed off with the community trying to pick up the slack afterwards. Especially engineers from Igalia were quite active for a while trying to keep the accessibility support working well.

But over the years we definitely lost a bit of focus on this and we know that various parts of GNOME 3 for instance aren’t great in terms of accessibility. So at Red Hat we have had a lot of focus over the last few years trying to ensure we are mindful about diversity and inclusion when hiring, trying to ensure that we don’t accidentally pre-select against underrepresented groups based on for instance gender or ethnicity. But one area we realized we hadn’t given so much focus recently was around technologies that allowed people with various disabilities to make use of our software. Thus I am very happy to announce that Red Hat has just hired Lukas Tyrychtr, who is a blind software engineer, to lead our effort in making sure Red Hat Enterprise Linux and Fedora Workstation has excellent accessibility support!

Anyone who has ever worked for a large company knows that getting funding for new initiatives is often hard and can take a lot of time, but I want to highlight how I was extremely positively surprised at how quick and easy it was to get support for hiring Lukas to work on accessibility. When Jiri Eischmann and I sent the request to my manager, Stef Walter, he agreed to champion the same day, and when we then sent it up to Mike McGrath who is the Vice President of Linux Engineering he immediately responded that he would bring this to Tim Cramer who is our Senior Vice President of Software Engineering. Within a few days we had the go ahead to hire Lukas. The fact that everyone just instantly agreed that accessibility is important and something we as a company should do made me incredibly proud to be a Red Hatter.

What we hope to get from this is not only a better experience for our users, but also to allow even more talented engineers like Lukas to work on Linux and open source software at Red Hat. I thought it would be a good idea here to do a quick interview with Lukas Tyrychtr about the state of accessibility under Linux and what his focus will be.

Christian: Hi Lukas, first of all welcome as a full time engineer to the team! Can you tell us a little about yourself?

Lukas: Hi, Christian. For sure. I am a completely blind person who can see some light, but that’s basically it. I started to be interested in computers around 2009 or so, around my 15th or 16th birthday. First, because of circumstances, I started tinkering with Windows, but Linux came shortly after, mainly because of some pretty good friends. Then, after four years the university came and the Linux knowledge paid off, because going through all the theoretical and practical Linux courses there was pretty straightforward (yes, there was no GUI involved, so it was pretty okay, including some custom kernel configuration tinkering). During that time, I was contacted by Red Hat associates whether I’d be willing to help with some accessibility related presentation at our faculty, and that’s how the collaboration began. And, yes, the hire is its current end, but that’s actually, I hope, only the beginning of a long and productive journey.

Christian: So as a blind person you have first hand experience with the state of accessibility support under Linux. What can you tell us about what works and what doesn’t work?

Lukas: Generally, things are in pretty good shape. Braille support on text-only consoles basically just always works (except for some SELinux related issues which cropped up). Having speech there is somewhat more challenging, the needed kernel module (Speakup for the curious among the readers) is not included by all distributions, unfortunately it is not included by Fedora, for example, but Arch Linux has it. When we look at the desktop state of affairs, there is basically only a single screen reader (an application which reads the screen content), called Orca, which might not be the best position in terms of competition, but on the other hand, stealing Orca developers would not be good either. Generally, the desktop is usable, at least with GTK, Qt and major web browsers and all recent Electron based applications. Yes, accessibility support receives much less testing than I would like, so for example, a segmentation fault with a running screen reader can still unfortunately slip through a GTK release. But, generally, the foundation works well enough. Having more and naturally sounding voices for speech synthesis might help attract more blind users, but convincing all the players is no easy work. And then there’s the issue of developer awareness. Yes, everything is in some guidelines like the GNOME ones, however I saw much more often than I’d like to for example a button without any accessibility labels, so I’d like to help all the developers to fix their apps so accessibility regressions don’t get to the users, but this will have to improve slowly, I guess.

Christian: So you mention Orca, are there other applications being widely used providing accessibility?

Lukas: Honestly, only a few. There’s Speakup – a kernel module which can read text consoles using speech synthesis, e.g. a screen reader for these, however without something like Espeakup (an Espeak to Speakup bridge) the thing is basically useless, as it by default supports hardware synthesizers, however this piece of hardware is basically a think of the past, e.g. I have never seen one myself. Then, there’s BRLTTY. This piece of software provides braille output for screen consoles and an API for applications which want to output braille, so the drivers can be implemented only once. And that’s basically it, except for some efforts to create an Orca alternative in Rust, but that’s a really long way off. Of course, utilities for other accessibility needs exist as well, but I don’t know much about these.

Christian: What is your current focus for things you want to work on both yourself and with the larger team to address?

Lukas: For now, my focus is to go through the applications which were ported to GTK 4 as a part of the GNOME development cycle and ensure that they work well. It includes adding a lot of missing labels, but in some cases, it will involve bigger changes, for example, GNOME Calendar seems to need much more work. During all that, educating developers should not be forgotten either. With these things out of the way, making sure that no regressions slip to the applications should be addressed by extending the quality assurance and automated continuous integration checks, but that’s a more distant goal.

Christian: Thank you so much for talking with us Lukas, if there are other people interested in helping out with accessibility in Fedora Workstation what is the best place to reach you?

Actually for now the easiest way to reach me is by email at ltyrycht@redhat.com. Be happy to talk to anyone wanting to help with making Workstation great for accessibility.

The kernel team is working on final integration for Linux kernel 5.18. This version was just recently released, and will arrive soon in Fedora. As a result, the Fedora kernel and QA teams have organized a test week now through Sunday, June 12, 2022. Refer to the wiki page for links to the test images you’ll need to participate. Read below for details.

How does a test week work?

A test week is an event where anyone can help make sure changes in Fedora work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed before, this is a perfect way to get started.

To contribute, you only need to be able to do the following things:

• Download test materials, which include some large files
• Read and follow directions step by step

The wiki page for the kernel test day has a lot of good information on what and how to test. After you’ve done some testing, you can log your results in the test day web application. If you’re available on or around the day of the event, please do some testing and report your results. We have a document which provides all the steps written.

Happy testing, and we hope to see you on test day.