There have been three openSUSE Tumbleweed snapshots released since last Thursday.

If the 20220420 snapshot passes openQA, it might be released before this article publishes and push the number of snapshots released to four.

A little less than 10 packages were updated in the 20220419 snapshot. The most updates in the snapshot came in the 5.17.3 Linux Kernel update. A few KVM fixes were made for x86; there was also one for arm64 that makes sure an event filter isn’t changed. There were also about 30 Direct Rendering Manager changes in the kernel update. Wine applications using the JACK backend should no longer crash with the pipewire 0.3.50 update. The audio and video package update also had a change that ensures Advanced Linux Sound Architecture will now only allocate a buffer size big enough to hold four times the quantum limit instead of as large as possible. The update of the libnl3 3.6.0 package added Generic Routing Encapsulation and Virtual Tunnel Interface support for IPv6 and both yast2-trans and libstorage-ng 4.5.4 updated slavic translations.

Snapshot 20220415 updated ImageMagick to version 7.1.0.29. A few reversions were made in the update, according to the changelog, and a fix was made to account for gray images imported as RGBA. The first minor release for Mozilla Firefox 99 was made with the 99.0.1 update. The browser update fixed a selection issue in the Download panel with the drag and drop. There was also a fix for an issue preventing the Zoom gallery mode to work. An update of git 2.35.3 fixed a Common Vulnerabilities and Exposures; CVE-2022-24765 could have allowed git to execute commands defined by other users from unexpected worktrees, according to the changelog. Other packages to update in the snapshot were vim 8.2.4745, Ruby 3.1.2, Xen 4.16.1, whois 5.5.13 and more.

With the 20220414 snapshot from last Thursday, the procps package was reverted from version 4.0.0 to 3.3.17. This major version reversion picked up several patches and took care of some CVEs. A major version update of LLVM 14.0.0 arrived in the snapshot. This version brought in a bunch of new tools, dropped some patches and opted to split up Clang libraries, which was inspired by GNU Compiler Collection packaging. A major update of libunistring 1.0 was made in the snapshot, which provided Unicode 14.0.0 support and a license change. There was a git version update of kdump 1.0.2, which gave a filesystem remount for fadump regarding read and write. Also updated in the snapshot was a newer version of ncurses and dracut. There were several other packages updated in the snapshot.

How can you make Windows easy? Install the Windows Subsystem for Linux, or WSL in short. Well, probably this is not true for everyone. However, as a Linux user, I definitely love WSL. When not using a browser or text editor, I spend my time on the command line. With WSL, you can have the familiar Linux command line environment from openSUSE also under Windows.

Why Windows?

Die hard Linux users might ask: why do I use Windows? There is an Open Source alternative for almost all Windows software. Well, it’s mostly true. However there are multiple problems. I love state-of-the-art hardware. Nothing could open the RAW files from my brand new camera for years under Linux, so I had to use Windows to process those files. My other hobby is playing on the synthesizer. Not that I ever learned music, but I still enjoy most of the noise I make (strictly only using headphones…). Linux Audio was problematic even before PulseAudio was introduced, but now it’s even more difficult and its sound quality is even worse. And while there are some software synthesizers available under Linux, there are a lot more available under Windows. Without spending days and weeks to get them to work.

As a bonus, using Windows also helps to separate my work and private life. Linux is my work OS, Windows is my play OS for photography and music. And I do not have access to anything work-related from my Windows box.

Why WSL?

I recall that one of my managers told me when he saw how I work: you do not need a GUI, you do everything in a terminal window. Well, it’s not completely true, but I even start LibreOffice from a terminal and not from the menu. On Windows, it’s slightly different: I start all applications from the search window. For working with files, I use the terminal. PowerShell is powerful, just as its name implies. However, I already have shell scripts to manage photo archives and got used to BASH anyway. Using WSL, I do not have to learn PowerShell, but I can keep using my familiar tools. Use joe for text editing, Midnight Commander for file management, including sftp access to remote Linux hosts. There might be native alternatives available on Windows. But that would require research, testing software, integrating a new environment.

When installing openSUSE Leap in WSL I can keep the exact same scripts and workflows on my Windows box as I already have on Linux. I can spend my time on photos and music instead of building up and maintaining a new environment on Windows.

You can find some of my photos on-line at GuruShots: https://gurushots.com/pczanik/photos

There are no recordings of my music, not even in private :-)

Many of you are taking advantage of the SCM/CI integration in OBS. Sometimes the integration fails and it’s hard to find out why. In the last weeks, we have focused on improving the error handling and adding more meaningful error messages to make things easier for you. Haven’t you tried the SCM/CI integration yet? Please join the beta program and read our previous blog posts to learn about the topic. We started off the continuous...

The first one is splitting text into script runs (separating runs of e.g. latin text from RTL text). About 61% of time is spent in vcl::text::TextLayoutCache. Which is rather strange for something called 'cache'. But this is one of the cases of poor naming, as the class is actually not a cache, it is the result of the script run splitting. It is called TextLayoutCache probably because callers are supposed to cache it and pass the same item to several OutputDevice calls ... which mostly does not happen. So whenever a text is to be drawn, this gets recreated. To make things even worse, it is done for the entire string, even if only a part of it is drawn, so this supposed cache actually makes things slower.

This can be fairly easily fixed by turning the class into an actual cache. Each TextLayoutCache instance depends only on the string, so it's easy to keep a reasonable number of them in one global cache.

The second problem is breaking text into multiple lines at suitable places. In this case the problem was in the ICU library we use. The common scenario when breaking text is finding the first break and then continuing with the same text to find the following break, and so on. ICU code tries to cache this if the position in the text is close enough to the previous one, and if it's not close enough but after the last position, it tries to only walk back a bit instead of repeating the entire work from the beginning of the string. But for whatever strange reason this walking back didn't work, and it walked back until the very beginning. And the test handling the result of the walking back didn't check what the result was and reset the position to whatever the result was. So in practice the breaking almost always started from the beginning, even if the last position was a way more reasonable place to start breaking from. So 26% of time is spent breaking the same text over and over (and it's only 26% because script run splitting is even more expensive).

I've reported this to ICU together with a suggested fix to not reset position to beginning if the last position is better, they've confirmed the problem, but apparently want to look at why the walking back doesn't work in the first place, and there has not been an actual fix from them yet. So I've at least pushed my patch for now.

The resulting perf profile now looks much better:

As can be seen from the number of cycles at the bottom, this is now almost 10x faster (well, ok, 8x to be more precise). The script run splitting can't be seen anymore (it's ~0.1% now), text breaking is still there, but way smaller (6%, and that's 6% of a total that's 8x smaller, so it would be 0.75% compared to the original 26%). Not bad. The PDF generation still takes a couple of seconds (it's 400 pages after all), but it's way faster.

Other problem I noticed while working on this was the related bugreport #144515 (and a couple more that I've closed as its duplicates):

The primary cost here is OutputDevice::ImplLayout(), which lays out text into glyphs and their positions. It is possible to cache this using the SalLayoutGlyphs class, and e.g. Writer has already started caching that for repeated calls, but in this case it's Calc using the EditEngine class, which does no caching.

So as a fix I've moved the caching code to VCL and turned it into a generic SalLayoutGlyphsCache class, and then made this place use that cache ... which didn't really help that much. After investigation it turned out that EditEngine tries to fit the given text into the given paper size (Calc's cell in this case), and so it repeatedly asks to lay out the entire long string in the cell, then breaks the line at the needed width, and then it repeats the same with the rest of the string for the next line, and so on. Which again results in horrible O(N^2) performance that mostly repeats the same over and over again.

But that should be possible to avoid, right? If it's repeatedly the same text, just a subset with increasing starting index, then presumably the glyphs are the same, and their positions are also the same, just at an offset. Well, it's not that simple actually, as in some cases it's not possible to cut glyphs for text at a random place and hope it'll be exactly the same as text layout would give, since text layout may try e.g. to position several adjacent spaces more nicely. But after a couple of attempts Noel pointed out to me that Harfbuzz actually provides information about places where it's not safe to break. Finally, I noticed that the problem with a number of those bugreports is people having small Calc cells with long text, where most of the text is not seen. So for the default case it can be made to show only the start of the text that fits, and so I made it possible for EditEngine to stop breaking lines when the given size is filled in instead of trying to pointlessly process lines that won't be needed.

Again, the resulting profile looks much better:

The operation is now almost 100x times faster (*cough*, ok, 62x) and is just a relatively small part in the total picture. Let's call that good enough.

In other somewhat related news, the fontconfig library has a new stable release that finally includes some performance improvemens when looking up fonts (not updated on its webpage, but available for download in release list).

BTW, since this was a TDF tender work, these improvements have been funded by TDF donations.

Last Friday, my wife and I packed up our car and drove 9.5 hours south from Prague, Czech Republic through Austria and Slovenia to a small coastal town in Croatian on the Adriatic sea. We used the Waze app on my Android phone for guidance all the way there. We stayed in an Airbnb that I found online. On the way to Croatia, we stopped outside Saltzburg, Austria for lunch. Just outside of Ljubliana, Slovenia, we topped up on diesel and had a drink and a short break.

On Saturday, we drove 90 minutes to Trieste, Italy. Except for a small problem where I put the wrong address into the Waze app, we drove to the Miramare castle parking lot through the narrow Italian streets in my big (by Italian standards) SUV. Afterward, we looked for a shopping center in Trieste where we could buy some wine and gifts for family and friends back in Prague. I found one on Google and we were there 15 minutes later.

On Sunday, we went to the Roman coliseum in Pula, Croatia. Pula is about 90 minutes away in the opposite direction from Trieste. It seemed to be a popular tourist location even on a major holiday. Parking was a bit rough but not unbearable. In truth, understanding how to use the parking meter was the only time where we had much of a problem concerning language on the entire trip.

I am blessed and privileged to fluently speak the language that is the lingua franca of much of the world today. Yet for all of my adventures on this short vacation, I can say if I didn’t speak English, but still had a relatively good understanding of technology, the difficulty level of this trip would not have been substantially greater. This is a great wonder of modern life. In previous decades or centuries, journeys like this would be rare and would require much more bravery. This was true even 50 years ago with a car.

This freedom to travel far and wide is made possible by technological innovation. I used an app on my smartphone to provide reliable verbal directions to a small village that I had never heard of before. I used a website on my computer to find an apartment for rent which I paid for online. I used a search engine on my phone to get a conversion rate on my money. I used ATMs from banks I never heard of to get Euros and Croatian Kuna that were programmed in 4 to 5 different languages. These are all things that have never been possible in the past.

We live in amazing times. If we ever lost all of this, it would be a tragedy and because of that, I don’t want to take it for granted. We can’t assume that this progress will still be here tomorrow or next year. It can be taken away. We can regress.

SUSE-IT plans a replacement of some network equipment in the Nuremberg Datacenter next Thursday (2022-04-21), between 4PM to 5PM CEST. Actual downtime is planned to be up to 15 minutes.

Affected services:

• OBS
• Wikis
• Jitsi
• Forums
• Matrix
• Mailing Lists
• Etherpad
• Moodle
• and some more

Please have a look at our status page for more details.

As usual, the openSUSE heroes can be reached via IRC (irc.opensuse.org/#opensuse-admin) or (with delayl Email (admin@opensuse.org).

Hace tiempo en el grupo de Developers Ve en el mundo, preguntaba si alguien había utilizado Obsidian. Considerándome un power user de Evernote, sé lo que necesito, y en los años que llevo buscando una alternativa que funcione en linux, tenia el problema de que muy pocas realmente funcionan bien o siquiera tienen soporte para linux.

Decidí irme por Obsidian, luego de considerar Notion y otras herramientas principalmente por los plugins, que tiene Zettelkasten como feature, esta pensado con las siguientes otras razones:

• Es perfecto para Zettelkasten y para construir un segundo cerebro (Building a Second Brain), y tiene un sistema de tags simple, pero poderoso.
• Soporte para Markdown by default.
• Los archivos están en mis dispositivos, no en la nube by design.
• Puedo elegir alternativas de respaldo, control de versiones y redundancia.
• Soporte para Kanban Boards.
• Soporte para Day Planners.
• Soporte para Natural Language Dates para cosas like: @today, @tomorrow.
• La interfaz es exactamente lo que me encanta de Sublime que es lo que había estado utilizando para tomar notas, junto a la aplicación de notas del teléfono y notas via el correo.
• Tiene un VIM mode :D.
• El roadmap promete.

Revisando varias cosas, y realmente investigando un poco, llegue al siguiente workflow:

• Logre construir el workflow que hace lo que necesito:
  • Vault en git en mi VPS, en una instancia propia de gitea, la data es mia.
  • En Linux:
    • El manejo de las distintas Vaults (Bóvedas) seria por git directamente.
      • Nextcloud como mecanismo de backup redundante en el NAS en casa via scsi en un rpi.
      • A mediano, o largo plazo:
        • La solución de NAS podría ser FreeNAS, TrueNAS o Synology
        • VPS como gateway, utilizando vpn con wireguard para mantener todo en una red privada.
  • En OSX:
    • Seria igual que en linux, por git pero con la diferencia de que las bóvedas estarían alojadas en una carpeta en iCloud.
    • La llave ssh con permiso de escritura en el repo seria importada al keystore (ssh-add -K), para que no de problemas a la hora de pedir contraseñas.
    • Queda pendiente revisar como hacer con las firmas de los commits con GPG, o maybe usando ssh para firmar commits
  • En IOS, los vaults se estarían abriendo via iCloud, dejando por fuera el manejo con git, mientras se agrega el soporte en para ios/mobile en obsidian-git.

En un tiempo revisare este post, y actualizare seguramente a mi nuevo workflow… o hare una vista en retrospectiva de que pudo salir mejor, etc, sin embargo creo que la primera tarea que hare, sera escribir un plugin para poderlo integrar con la creación de posts de este blog, y utilizar el grafo de tags, que por ahora… se ve así:

I recently ran into an issue where some Steam games wouldn’t launch and reported the error that the game would not run without DirectX 11. I was befuddled and could not find a solution. I chatted with people, search through forums and didn’t find a solution. I was left with the belief that the hardware […]

After 30 years of using the Internet and trying many communication formats, e-mail is still my favorite. However, e-mail has many problems. Spam is just annoying, but phishing and especially, spear phishing attacks can also be dangerous. A recent security training, and a Twitter thread I started about it, changed my mind completely about how I treat these harmful e-mails.

The old way

While most spam and some phishing can easily be filtered, spear phishing messages are unique by their nature. The way they try to trick users into clicking URLs, giving out sensitive data is improving each year. Of course, using e-mails as my primary communication form also means that most of the time it takes me less than a second to realize that an e-mail is problematic. For most of the past three decades, my immediate reaction was deleting these e-mails.

Ticketing

A couple years ago, my employer recommended opening a ticket if I run into a phishing e-mail. However, the problem with this is that tickets add a big overhead both to the reporter and to the department handling them. Which meant that I reported only a few tricky cases each year, when it took me more than a couple of seconds to decide that an e-mail is problematic. For the rest, I kept deleting them, as it allowed me to avoid the overhead of ticketing.

Everything? Everything!

Recently, I participated in a security training course where I was asked to report any kind of phishing e-mail to IT security. I was really surprised. Reporting everything has a huge overhead. Is it really necessary? I asked my Twitter followers, many of them working in infosec, and I also asked our IT department. The short answer from both of them was yes, because of two reasons.

First of all, as someone who spent almost three decades in infosec, I have no problem identifying problematic e-mails. But there are a lot more people without this experience. Reporting even trivial phishing e-mails can help saving these people from opening or responding to problematic e-mails.

The good news is that while previously, we needed to use a ticketing system to report problematic e-mails, now it’s just a simple click in the e-mail client. Most of the overhead is gone, so I just need to make sure that instead of deleting the e-mail right away, I report it instead.

Secondly, reporting all phishing e-mails also helps security to estimate the size of the attack and how much it is targeted. Reporting also means that instead of just defending myself, I can help to defend the rest of the users as well. As the security team can see the problematic e-mails on a centralized dashboard, they can identify phishing campaigns early, and so they can delete problematic e-mails from most users’ mail box, even before they could open them.

This is an idea that I’m playing around with. Here are some categories for any reviews. They could later depending on what I learn while doing the reviews.

1. Availability
2. Installation
3. Setup
4. Posting Articles
5. Filtering and Killfiles
6. Miscellaneous Features
7. Final Comments