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

This year the syslog-ng project will participate in the Google Summer of Code (GSoC) as a mentor organization again. If you are a university student or otherwise eligible to participate in the GSoC program, you can choose to develop a new feature for syslog-ng.

Read my blog to learn why to choose syslog-ng and how to get started: https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-in-gsoc-2022

Running a x86_64 image in qemu machine can be as easy as:

qemu-system-x86_64 openSUSE-Leap-15.3-JeOS.x86_64-kvm-and-xen.qcow2

# A more extended example
qemu-system-x86_64 -m 1G -cpu host -enable-kvm -smp cores=2,threads=1,sockets=1 -drive file=openSUSE-Leap-15.3-JeOS.x86_64-kvm-and-xen.qcow2,if=virtio

Doing the same for aarch64 is a bit more tricky. In this tutorial we’re gonna learn how to run a aarch64 vm using qemu. This approach works on native aarch64 hardware and as emulated VM on any other architectures as well.