When dealing with go modules, sometimes it’s handy to test some changes from a local repository instead of using the upstream one.

Now, go programs are typically relying only on the upstream packages. Take the module file of openqa-mon as example:

One of the most popular destinations in syslog-ng is Elasticsearch. Due to the license change of the Elastic stack, some people changed quickly to Grafana/Loki and other technologies. However, most syslog-ng users decided to wait and see. Version 1.0.0 of OpenSearch, a fork of the Elastic code base from before the license change is now available. Elastic also published a new release last week.

For this blog, I tested the latest and greatest from both product lines and I’m sharing my experiences. For the impatient: both work perfectly well.

For details read my blog at https://www.syslog-ng.com/community/b/blog/posts/elasticsearch-7-14-and-opensearch-1-0-are-available-and-work-fine-with-syslog-ng

Yes, it’s a syslog-ng blog from me, and it’s not on https://syslog-ng.com/ :-) The reason is simple: this is not a technical blog. This is my story about how I found the Turris Omnia Linux router and how this lead to working together with the Turris guys.

The beginnings

When I ordered my Turris Omnia, I did not know that it ran syslog-ng. All I knew that it was an ARM device and that it ran Linux. It has a reasonable amount of RAM, storage can be extended, and I can also run containers on it, including my favorite OS: openSUSE. Crowdsourcing was very popular at that time. I ordered my box through Indiegogo.

Working together

Once my Turris Omnia was up and running, I realized that TurrisOS uses syslog-ng for logging. Even if it was an ancient version (3.0), I was very happy about it. I featured the Turris Omnia in some of my blogs as a log source. Finally, a device that could provide me with some interesting real-life log messages!

It turned out that the Turris team has a member whom I already knew from the openSUSE project. We met at conferences, exchanged some e-mails. Soon, syslog-ng was updated to 3.9 in TurrisOS, jumping almost a decade in code and adding many interesting features along the way.

Every now and then, I helped in version updates, suggested new features and changes to the configuration, which helped to greatly extend the feature set of syslog-ng in TurrisOS without adding too many extra dependencies. Using syslog-ng on the Turris Omnia (and most likely on all the other Turris devices), you can now parse many types of incoming log messages and send log messages to Elasticsearch and various cloud services.

Mutual benefits

To me, working with Turris is completely a hobby project. Still, there are mutual benefits both for Turris and Balabit (now One Identity Hungary). I help Turris with syslog-ng and include Turris Omnia in my blogs. It’s a fantastic log source. For example, if you click the YouTube icon in the upper right corner, you will see some timelapse videos built from Turris logs. The blogs describing how to make those heat maps and videos were quite popular for a while: https://www.syslog-ng.com/community/b/blog/posts/creating-heat-maps-using-new-syslog-ng-geoip2-parser

For Turris, it means that even more people learn about their products. For Balabit, it strengthens the syslog-ng everywhere image: running everywhere from embedded devices, like the Kindle e-book reader and Turris Omnia router up to some of the largest HPC clusters of the world.

It was a pleasure working with the Turris team at cz.nic as it allowed me to intersect my work interests with my hobby. Getting swag from them did not hurt either. I am a t-shirt maniac, and the USB converter with four different plugs and a Turris logo is not just nice, but also quite practical :-)

On the photo below you can see me in my latest t-shirt and mask:

Adding about $200 worth of hardware to the HP EliteBook 840 G7, running openSUSE Tumbleweed makes a good machine into an excellent machine.

Dear Tumbleweed users and hackers,

How often did you update your machine during the last week? If you were to follow every single snapshot, you had to do it seven times. That’s how many snapshots passed openQA and had been pushed out to the mirrors.

What were the main changes in the snapshots 0729…0804?

• Mozilla Firefox 90.0.2
• KDE Plasma 5.22.4
• Pipewire 0.3.32
• Postfix 3.6.2
• Parted 3.4: supports F2FS
• Mesa 21.1.6
• Bash 5.1.8
• Linux kernel 5.13.6
• Systemd 248.6
• Zypper 1.14.48: experimental support for singletrans rpm commits
• Network Manager 1.32.6
• Freetype 2.11.0

During the next two weeks, Richard will be taking care of openSUSE Tumbleweed. Naturally, I tried to leave him only a small pile of things in the stagings. Currently, there are:

• Linux kernel 5.13.8
• systemd 249
• rpmlint 2.0
• openssl 3
• glibc 2.34

Most of them requiring a good bunch of build fixes to make them acceptable. So, I can only ask you all to support Richard during the next few days and offer him as many build fixes as you possibly can.

Here is the 31st one-lump sized podcast episode This is published late due to things. I hope you find something worth while. PipeWire Audio Server on openSUSE Tumbleweed Valve’s SteamDeck Release BDLL Follow Up openSUSE Corner News GNOME, Wireshark update in Tumbleweed Leap Gains Maintenance Update Improvements Tumbleweed Roundup 6 snapshots during this week (0715, […]

In a versatile tool like Inkscape, there are always features that aren't for you. There are some that really get in your way though, like the recently added canvas rotation.

If you're like me and constantly keep triggering it by accident (Blender zooming being Inkscape's panning having to do with it), you'll be happy to learn it can be completely disabled. Sip on your favorite beverage and dive into the thick preferences dialog again (Edit>Preferences), this time you're searching for Lock canvas rotation by default in the Interface section. One more thing that might throw you off is that you need to restart Inkscape for the change to have any effect.

If you don't wish to go nuclear on the function, do note it can be reset from the status bar bottom right.

In a versatile tool like Inkscape, there are always features that aren’t for you. There are some that really get in your way though, like the recently added canvas rotation.

If you’re like me and constantly keep triggering it by accident (Blender zooming being Inkscape’s panning having to do with it), you’ll be happy to learn it can be completely disabled. Sip on your favorite beverage and dive into the thick preferences dialog again (Edit>Preferences), this time you’re searching for Lock canvas rotation by default in the Interface section. One more thing that might throw you off is that you need to restart Inkscape for the change to have any effect.

If you don’t wish to go nuclear on the function, do note it can be reset from the status bar bottom right.

One of the great attributes of SVG is that its text nature lends itself to be easily version controlled. Inkscape uses SVG as its native format (and extends it using its private namespace).

Unfortunately it uses the documents themselves to store things like canvas position and zoom state. This instantly erases one of the benefits for easy version control as every change instantly turns into unsolvable conflict.

Luckily you can at least give up the ability to store the canvas position for the greater good of not having merge conflicts, if you manage to convince your peers to change its defaults. Which is what this blog post is about :)

To change these defaults, you have to dive into the thick forrest that is Inkscape's preferences (Edit > Preferences). You'll find then in the Interface > Windows section. The default being the unfortunate Save and restore window geometry for each document needs to be changed either to Don't save window geometry or Remember to use last window's geometry.

From now on, rebasing icon-development-kit won't cause any more grey hair for you!

Update: Turns out, despite me testing before posting, only Don't save window geometry is safe. Even window geometry appears to be saved into the document.

One of the great attributes of SVG is that its text nature lends itself to be easily version controlled. Inkscape uses SVG as its native format (and extends it using its private namespace).

Unfortunately it uses the documents themselves to store things like canvas position and zoom state. This instantly erases one of the benefits for easy version control as every change instantly turns into unsolvable conflict.

Luckily you can at least give up the ability to store the canvas position for the greater good of not having merge conflicts, if you manage to convince your peers to change its defaults. Which is what this blog post is about :)

To change these defaults, you have to dive into the thick forrest that is Inkscape’s preferences (Edit > Preferences). You’ll find then in the Interface > Windows section. The default being the unfortunate Save and restore window geometry for each document needs to be changed either to Don't save window geometry or Remember to use last window's geometry.

From now on, rebasing icon-development-kit won’t cause any more grey hair for you!

Update: Turns out, despite me testing before posting, only Don't save window geometry is safe. Even window geometry appears to be saved into the document.