Let’s go for my web review for the week 2022-46. With all the turmoil in the social media space, this looks a bit like a special edition on this topic (more links to articles related to that than usual).

Microsoft “irreparably damaging” EU’s cloud ecosystem, industry group claims | Ars Technica

Tags: tech, microsoft, cloud, vendor-lockin

More anti-trust pressure coming toward Microsoft. Let’s see how it goes.

https://arstechnica.com/tech-policy/2022/11/microsoft-irreparably-damaging-eus-cloud-ecosystem-industry-group-claims/

Infosys leaked FullAdminAccess AWS keys on PyPi for over a year | Tom Forbes

Tags: tech, security

Shady practices clearly… don’t commit secrets in repositories. There are even tools to check this doesn’t happen.

https://tomforb.es/infosys-leaked-fulladminaccess-aws-keys-on-pypi-for-over-a-year/

“When We All Have Pocket Telephones”: A 1920s Comic Accurately Predicts Our Cellphone-Dominated Lives | Open Culture

Tags: tech, smartphone, history, culture

Interesting look at the perception of cellphones before they even existed.

https://www.openculture.com/2022/08/when-we-all-have-pocket-telephones.html

The Age of Social Media Is Ending - The Atlantic

Tags: tech, social-media

Interesting point of view, also lays out nicely how social networks degenerated into social media. I appreciate this kind of perspective.

https://www.theatlantic.com/technology/archive/2022/11/twitter-facebook-social-media-decline/672074/

Fediverse

Tags: tech, fediverse, social-media, ecology

Good thinking about the recent Mastodon users increase. Highlights fairly well why it’s desirable, why it’s a better social media platform but also the challenges ahead… including resources consumption.

https://bastianallgeier.com/notes/fediverse

Home invasion - Mastodon’s Eternal September begins

Tags: tech, fediverse, social-media

Success is a two sided coin. Clearly this mass exodus of Twitter users will overwhelm existing Mastodon users and a few instance administrators. It’s understandable that is can be perceived as some kind of assault from people not used to the customs. How will the preexisting culture hold? The Pandora box is now opened we shall see.

https://www.hughrundle.net/home-invasion/

Is the fediverse about to get Fryed? (Or, “Why every toot is also a potential denial of service attack”) – Aral Balkan

Tags: tech, architecture, fediverse, performance, social-media

There are indeed a few architectural problems with the Fediverse as it is. Can this be solved? Hopefully yes.

https://ar.al/2022/11/09/is-the-fediverse-about-to-get-fryed-or-why-every-toot-is-also-a-potential-denial-of-service-attack/

How fast is ASP.NET Core?

Tags: tech, benchmarking, web, framework, microsoft, dotnet

Don’t believe too good to be true marketing claims by vendors. Clearly something went wrong there and the benchmark has been gamed.

https://dusted.codes/how-fast-is-really-aspnet-core

Refactoring with =delete

Tags: tech, programming, refactoring, c++

This is a clever and important use of =delete which I sometimes miss in other languages.

https://quuxplusone.github.io/blog/2022/11/11/refactoring-with-delete/

Immutable Collections should be Your Default

Tags: tech, programming, multithreading, java

Illustrated with Java, still this highlight fairly well the caveats of mutable collections in multithreaded code.

https://alexn.org/blog/2022/10/27/immutable-collections-your-default/

Performance Optimizations Can Have Unexpectedly Large Effects When Combined With Caches

Tags: tech, performance, optimization

Interesting take about how performance optimizations can sometimes leverage even more performance gains than you would expect.

https://justinblank.com/notebooks/performanceoptimizationscanhaveunexpectedlylargeeffectswhencombinedwithcaches.html

The hidden cost of complexity

Tags: tech, software, complexity

A simplified mental model of complexity in software projects. It’s not completely accurate but is valuable in the way it is easy to reason about it and probably use it for decision making.

https://medium.com/@dolevp/the-hidden-cost-of-complexity-d9d8eb91594c

Split Your Overwhelmed Teams - ACM Queue

Tags: tech, management, team, burnout

Interesting take of the cognitive overload in bigger teams which end up with more responsibilities. Indeed splitting the teams and the responsibilities can then be a way out.

https://queue.acm.org/detail.cfm?id=3570920

Why do we call it “boilerplate code?” • Buttondown

Tags: tech, programming, history, etymology

I love this kind of explorations. Where does the term boilerplate code come? Let’s find out.

https://buttondown.email/hillelwayne/archive/why-do-we-call-it-boilerplate-code/

Digital Books wear out faster than Physical Books - Internet Archive Blogs

Tags: book, low-tech

The limits of digital books, this won’t get me off the paper books addiction I got.

http://blog.archive.org/2022/11/15/digital-books-wear-out-faster-than-physical-books/

Bye for now!

Ever since work on NeoChat has started in 2020, the most requested feature has been support for end-to-end (E2EE) encrypted rooms. Unfortunately, while libQuotient, the library NeoChat uses for dealing with the Matrix protocol, had some pre-existing support for E2EE, it was not in a functional state at that time and was thus not enabled by default.

History

Early in 2021, Carl and I were made aware of NLnet, a dutch foundation that sponsors many open source projects, and decided to apply for some funding there to expedite the development process. Fortunately, the application process at NLnet is very light-weight, so there isn't a lot of risk involved in applying for funding. A while after sending our application, NLnet got back to us with the good news that they would indeed be funding E2EE work for NeoChat and libQuotient.

The actual development work started with creating Qt-Style bindings for libOlm, the library that provides implementations of the cryptographic functions required for implementing end-to-end encryption in matrix. Most of this work was done by Carl and is now merged into libQuotient.

Building on this foundation, we implemented support for reading and sending encrypted messages into libQuotient. This includes support for all of the different types like texts, images, files, audio and others. By integrating this into libQuotient, this is almost completely transparent to the actual application, meaning that for the most part, app developers building on top of libQuotient do not need to do extra work for supporting E2EE. There are some parts, like loading images and notifications, that will need slight adaptions from how they were implemented before supporting E2EE. If you, as an app developer, have questions about those, come talk to us in #quotient:matrix.org.

The last part of end-to-end encryption that has been implemented so far is device verification. Device verification allows users to verify that their devices are actually who they claim they are and are not subject to, for example, a man-in-the-middle attack.

What works right now

For this to work, you need to use a dev-branch build of libQuotient with the correct build flags and a build of NeoChat from the master branch. (You will not find the correct versions of libQuotient or NeoChat in your package manager yet; if you do, please tell the packagers not to ship them yet 😃).

NeoChat can show new messages in all of your encrypted rooms and send useful notifications for them. It can also send all types of messages in those rooms, including through the Quick-Reply feature KNotifications offers on some platforms.

You can also verify your other devices by comparing emojis. This can be started either from a different client or from NeoChat's device settings page.

There is one known bug that sometimes causes the first message sent from a megolm session (this typically means the first message sent from a specific device) to not be decryptable. This is purely a UI bug and restarting NeoChat should fix it. This is actually a bug in Qt that will hopefully be fixed upstream soon.

Coming soon

The immediate next step is releasing version 0.7 of libQuotient, which will contain all of the previously mentioned features. We're currently in a phase of several beta releases for this, which means that the final release will be coming very soon. At that point, distros will be able to start shipping E2EE-enabled versions of libQuotient and NeoChat. (At this point i should probably mention that this is still not the most mature work and will thus not be enabled by default 😃)

Next steps

The next features we will implement are:

• Cross-signing, which allows users to verify the identity of other users in a simple way.
• Recovery from undecryptable messages, building on the previous device verification work
• Secure Secret Storage and Sharing (SSSS), which is a method of securely storing encryption keys server-side, which allows us to load existing messages on a new device.
• By this time, the matrix community will have probably come up with more amazing things to implement 😃

Special Thanks

• NLnet, for funding this work (Sorry for taking so long!)
• Alexey Rusakov, maintainer of libQuotient, for spending a lot of his time reviewing my merge requests and a lot of the rest of his time working on libQuotient in general
• Carl Schwan, for reviewing all of my merge requests and working on NeoChat in general
• James & Jan, for reporting a lot of bugs, fixing a lot of bugs and adding many new features & improvements
• Everybody else who uses & tests NeoChat, reports bugs, fixes bugs, implements features, ...

Lessons learned

• Implementing end-to-end encryption is hard
• It is also a lot of fun :)
• Applying for an NLnet grant is easy, you should do it

Getting involved

There's always more things to do in NeoChat. Come talk to us in #neochat:kde.org and have a look at community.kde.org/Get_Involved.

Welcome to my new blog.

This is the successor of my previous blog on https://dragotin.wordpress.com.

After paying wordpress quite some money to get an advertise free blog I decided to get rid of that and have my own hosted blog where I do not have to pay for not having battle ships or girls underneath my articles. Yes, that is true: Readers sent me screenshots with this kind of images.

So I am starting this journey here with Hugo. Let’s see how that turns out :-)

I’m happy to announce that the support for WebVTT format and all the nice features that it brings is finished.

Along with reading and writing of WebVTT subtitles, Subtitle Composer can now fully understand CSS - Cascading Style Sheets, subtitle positions and alignment.

A new panel has been added that allows syntax-higlighted CSS editing and subtitle position/alignment adjustment. Of course all edits are visible everywhere in app in realtime.

Some user interface elements are still being worked on and should be available in following days, in particular:

• Buttons for assigning class/voice tags to selected text
• Intuitive video overlay with handles to easily drag/size individual subtitle areas
• Ability to show/hide style/class/voice tags/elements

Release 0.8.0 is planned once above list is done and potential bugs that come up are resolved. Depending on community interest - ASS/SSA format improvements could be done to benefit from things that WebVTT support brought.

As usual you can try out precompiled binaries or AppImage of git development version (the subtitlecomposer-git package) from download page or build it yourself from invent.kde.org.

— Mladen

I’ve just made a new 5.3.1 release of Grantlee. The 5.3.0 release had some build issues with Qt 6 which should now be resolved with version 5.3.1.

Unlike previous releases, this release will not appear on http://www.grantlee.org/downloads/. I’ll be turning off grantlee.org soon. All previous releases have already been uploaded to https://github.com/steveire/grantlee/releases.

The continuation of Grantlee for Qt 6 is happening as KTextTemplate so as not to be constrained by my lack of availability. I’ll only make new Grantlee patch releases as needed to fix any issues that come up in the meantime.

Many thanks to the KDE community for taking up stewardship and ownership of this library!

Let’s go for my web review for the week 2022-45.

Do Users Write More Insecure Code with AI Assistants?

Tags: tech, programming, ai, machine-learning

Very early days for research on this topic and the sample is rather small still. That said the results are interesting, there seems to have a few biases inherent to the use of such an assistant, there’s also clearly a link between the AI agency and the quality of what gets produced. We’ll see if those result holds to larger studies.

https://arxiv.org/pdf/2211.03622.pdf

Microsoft is phoning home the content of your PowerPoint slides. | Roger Mexico’s Oscillator

Tags: tech, microsoft, surveillance

Indeed in the context of the feature it kind of make sense… still, where was the consent or the warning to the user?

https://rogermexico.bearblog.dev/microsoft-is-phoning-home-the-content-of-your-powerpoint-slides/

Mobilizon v3: Find events and groups throughout the fediverse! – Framablog

Tags: tech, framasoft

An important project in my opinion, glad to see it’s moving forward at a nice pace.

https://framablog.org/2022/11/08/mobilizon-v3-find-events-and-groups-throughout-the-fediverse/

hishtory: Your shell history: synced, queryable, and in context

Tags: tech, tools, command-line

OK, that looks like shell history on steroids. Definitely something I will try out.

https://github.com/ddworken/hishtory

Containers are chroot with a Marketing Budget - Earthly Blog

Tags: tech, docker, chroot

A good reminder of what’s truly at the root of the container idea.

https://earthly.dev/blog/chroot/

Stop requiring only one assertion per unit test: Multiple assertions are fine - Stack Overflow Blog

Tags: tech, tests, tdd, design

Indeed, I encounter that same idea in some people. I’m unsure where it comes from, it feels like reading and extrapolating from something more reasonable (it’s like the “one test per line” I sometimes hear about). Bad idea indeed, it’s fine to have several assertions, it’s probably often required to avoid complexity explosion in your tests. This of course doesn’t mean your test should become unfocused.

https://stackoverflow.blog/2022/11/03/multiple-assertions-per-test-are-fine/

What is a developer experience team?

Tags: tech, developer-experience

Very important topic. Nice to see more such teams appearing and thinking now focusing on how to structure them.

https://leaddev.com/productivity-eng-velocity/what-developer-experience-team

FizzBuzz Enterprise Edition

Tags: tech, architecture, funny, java

OK, this is funny. Clear over-engineering non sense for the sake of it.

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

How to lead strategically every day — Lena Reinhard

Tags: business, management, leadership, strategy

Interesting framework for sustaining a strategic train of thoughts for the long term. This can’t be a fix thing, it needs to live and breather which this approach seems to foster.

https://www.lenareinhard.com/articles/how-to-lead-strategically-every-day

How to Present a Strategy in 6 Slides | by Shea Cole | Medium

Tags: business, strategy

Nice succinct form to present a strategy.

https://medium.com/@sheacole08/how-to-present-a-strategy-in-6-slides-1c4df52ca23

“It would be career limiting…”

Tags: tech, project-management, failure

Interesting story on how power plays can sometimes completely hide the fate of a project until it’s too late. Definitely a cautionary tale.

https://doomedprojects.com/post/it-would-be-career-limiting

Too much efficiency makes everything worse: overfitting and the strong version of Goodhart’s law | Jascha’s blog

Tags: tech, ai, machine-learning, optimization, science, politics, economics

Interesting food for thought. Not necessarily easy to see it used in as many fields as the article claims. Maybe a bit too much on the techno solutionist side at times. Still, that sounds like an interesting guideline and path to explore.

https://sohl-dickstein.github.io/2022/11/06/strong-Goodhart.html

It’s not you.. A mental model for addressing burnout

Tags: management, business, work, burnout

Interesting take on burnout as an organizational phenomenon and the consequences. This is not simply about the amount of work.

https://writing.pupius.co.uk/burned-out-its-not-you-869ecce65270

Just Don’t · ongoing by Tim Bray

Tags: psychology, linguistics, problem-solving

Indeed, be careful when using “just”. It’s often doing more harm than anything.

https://www.tbray.org/ongoing/When/202x/2022/11/07/Just-Dont

Introduction to Genomics for Engineers | Introduction to Genomics for Engineers

Tags: genomics, biology, science

Oh that looks really cool… will need quite some time to go through this though.

https://learngenomics.dev/

Bye for now!

Monthly update on KDE/Plasma on Debian: Updates to Frameworks and KDE Gears

Short summary of recent changes and updates:

• Frameworks updated to 5.99.0
• Plasma 5.24 LTS (repo plasma524) has been updated to the latest patch level 5.24.7
• Plasma 5.25 updated to the latest patch level 5.25.5
• KDE Gears 22.08 updated to latest patch level 22.08.3
• Krita updated to 5.1.3
• (hopefully) everything recompiled against new Qt from Debian

If you see some strange behavior, please report.

Concerning Plasma 5.26

Debian unstable and testing already have (albeit outdated) packages for Plasma 5.26, and I have tried to package and build it for all the releases including Debian/stable. Unfortunately, Plasma 5.26 has a hard dependency onto a version of libDRM that is not available in Debian/stable, and thus compilation on Debian/stable does not succeed.

This makes my work regarding Plasma 5.26 far less useful, and thus I am currently not working on 5.26.

Usual reminder

I repeat (and update) instructions for all here, updated to use deb822 format (thanks to various comments on the blog here):

• Get the key via

  curl -fsSL https://www.preining.info/obs-npreining.asc | sudo tee /usr/local/share/keyrings/obs-npreining.asc
  

• Add the sources definition in /etc/apt/sources.lists.d/obs-npreining-kde.sources, replacing the DISTRIBUTION part with one of Debian_11 (for Bullseye), Debian_Testing, or Debian_Unstable:

  # deb822 source:
  # https://www.preining.info/blog/tag/kde/
  Types: deb
  URIs: 
   https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/other-deps/DISTRIBUTION
   https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/frameworks/DISTRIBUTION
   https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/plasma525/DISTRIBUTION
   https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/apps2208/DISTRIBUTION
   https://download.opensuse.org/repositories/home:/npreining:/debian-kde:/other/DISTRIBUTION
  Suites: /
  Signed-By: /usr/local/share/keyrings/obs-npreining.asc
  Enabled: yes
  

You can use also plasma524 instead of plasma525 if you prefer the LTS version of Plasma.

Enjoy!

tl;dr : There is nothing wrong with any of the mechanisms in the subject, you just have to be careful when combining them all.

Long title, but the combination is important. Recently, I had an embedded device on my desk, which drove me to claiming quite strongly that “this is not possible what is happening in front of me!!!” If you are familiar with setups of all the points above, this article might be interesting to you.

Starting from the very strange effects I had. The device itself in question has a read-only root file system, as it is common for embedded devices. On this device a QtQuick application is running and, because I have not the most efficient processor, QML cache is enabled. Instead of going the build-time cache generation route, I have a persistent writable partition on the device, on which the QML cache is generated and stored at first start of the QtQuick application after first boot. Note that the cache needs to be persistently stored since otherwise the whole performance improvement on startup is moot.

So far so good, everything works well… until we are starting to update the software or more precisely the root file system. For this example, and this will be important later, the update of the root file system just updates my QtQuick application and its QML file but not the Qt version. What I then see after the update and the following boot is a system where the QML application still looks like before the update. Looking deeper at the file system, everything seems fine, files are updated, even QML files are updated, but the application just ignores them. But even worse, the application now randomly crashes because the executable and the shared libraries apparently do not match to the QML code being executed. — I will shorten this up, because with the intro the problem is quite obvious: the QML cache is not being invalidated even if it should and old versions of the QML files are used to run the applications. But how can this be?!

How a File in QML Cache is Invalided

All the magic that decides if the cache file is up to date or not essentially is located in qv4executablecompilationunit.cpp. Reading that code, we find the following checks:

1. Check for the right magic key: Ie. here is a basic sanity check that tells if the cache was generated by the right tooling.
2. Check for the cache file having been created by using the same Qt version as is used to executed the application.
3. Check if the cache file was being created with the exact same QML_COMPILE_HASH: This value essentially is the git revision of the QtDeclarative module and thus forces a cache invalidation whenever the QtDeclarative module changes (see here for the generation process with Qt 6, in Qt5 it is similar but just with QMake). As I see this, this check is mostly a Qt developer use case with often changing QtDeclarative versions.
4. Check if the cache file fits to the QML source file: Since all the previous checks are about the Qt versions, there is a final check that checks if the last modified date of the QML file under question is the same or a different one as the one for which the data is in the cache.
5. Note that there is no further check for e.g. the file’s hash value, which is obviously a performance optimization topic because we are doing the whole QML cache process essentially to speed up startup.

I do not think that much further explanations are required that tell why this can break fundamentally when we are building a root file system image in some environment like Yocto that fixes all timestamps in order to make builds reproducible (Many thanks to the NixOS folks for their initial analysis! Apparently we independently hit this issue at nearly the same time.)

The Origin of the Modified Timestamp

Ok, we now know that the modified timestamp of the QML file (this is what eg. “stat -c%Y MyFile.qml” gives you as result) is the key ingredient for making the cache working correctly in our setting. For this, we have to differentiate between two ways how QML files might land on our root file system:

1. As ordinary files, which most probably are placed somewhere in /usr/lib/qml/…
2. As baked-in resource files inside the deployed binaries via the Qt Resource System.

The first case is fairly simple. Here, we have to look into the process on how the root file system image is created (in case of package based distros this is different and you have to check how the packaging system is handling this!). In my case, the root file system is generated by Yocto and there is a global BitBake value called REPRODUCIBLE_TIMESTAMP_ROOTFS, which forces all files inside the root file system to have the same modified time stamp during image creation.

The second case is more interesting though. Here the SOURCE_DATE_EPOCH environment variable is used to set the modified date of the source files to a certain value. Note that one needs such a mechanism in order to make the build really reproducible because one cannot rely on the file date extracted or checkout out sources, which also may further change due to patches being applied during the build process. Rather, we want to use the timestamp of the last commit or a timestamp that is baked into a release tarball.
Yocto, as most modern meta build systems, does exactly this and sets this value for the build from the source data (for details look into Poky). Further, rcc (Qt’s resource compiler) picks this value up and sets the modified timestamps of the QML files correctly while baking the files into the binaries.

Solving the Issue (for Yocto Builds)

Since Yocto already handles SOURCE_DATA_EPOCH correctly, just use a fixed REPRODUCIBLE_TIMESTAMP_ROOTFS and be happy And here, I urge you to not try workarounds like setting REPRODUCIBLE_TIMESTAMP_ROOTFS=””, because this triggers fallbacks at different places of the code. Eg. you will find /etc/timestamp being the actual time of the build but then you will note later that the modified time stamp of the files in the root file system is now the date of the latest Poky revision. Funny, heh ;D So, never rely of fallbacks, because the tend to be inconsistent.

A much better way is to couple the rootfs timestamp in your project to something that is regularly updated, at least once for every release. I am in the lucky position to usually have a meta-layer/submodule with release notes where I know for sure that there is a commit before every release. Thus, I can simply add the following line in my conf/local.conf:

REPRODUCIBLE_TIMESTAMP_ROOTFS:="${@os.popen('git -C "$BBPATH/../sources/my-layer" log -1 --pretty=%ct 2>/dev/null').read().rstrip()}"

It is not that important what exactly to use to initialize the timestamp, as long as it changes often enough, as long as it still makes your build reproducible.

And again, you only have to really worry about all of the above if you have a QML cache on a persistent partition while updating the root files system.