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!
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.
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.
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.
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.
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:
With the Muskquake leading to a tsunami of users flooding Mastodon, and even mainstream praising the platform as "interesting", should you too migrate away from Twitter? (TL;DR: Yes. You can carry on with your day now).
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:
Check for the right magic key: Ie. here is a basic sanity check that tells if the cache was generated by the right tooling.
Check for the cache file having been created by using the same Qt version as is used to executed the application.
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.
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.
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:
As ordinary files, which most probably are placed somewhere in /usr/lib/qml/…
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:
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.
Among my contributions towards KDE I am probably best known for becoming a dolphin maintainer recently. “Maintainers” are the people most responsible for something, and I share this responsibility with Méven Car these days.
The plan was to have a dolphin meeting at Barcelona, so I set off.
I think the most important topic for a self-organising and -acting international group like us, that swims in all seven seas, is that we meet from time to time at a coast to talk about common goals. Otherwise, everyone surfs and browses wherever the streams pulls them. Everyone has an idea about what is currently the most important thing to get to and then simply swims there as directly as they can. However sometimes it makes sense to discuss what really is the most important area to focus on. And that is exactly the topic I have chosen for our dolphin meeting.
It was new to me to act in a leading organisational role within KDE. Not only concerning Dolphin but also more generally within the ecosystem of penguin fans.
Okay, I think I have to drop the Doublespeak here because technical terms become necessary. To avoid any further confusion, I'll clarify now: Dolphin is an application. To be more precise: It is the default file manager of KDE. Méven Car and I share the responsibility of maintaining it. The text above wasn't really about animals at all!
We did meet in Barcelona and tried to figure out where the biggest areas of improvement for Dolphin might be.
Time Travel for Files and Folders?
Neal Grompa, who brings KDE's software to Fedora and other distributions, had the idea that Dolphin should have a feature that allows users to restore older states of files and folders. The practical application of this would for example be that a user — after ruining a report or article — could simply bring back an older version of that file. Or that someone — after accidentally deleting a file — could restore an older version of the folder containing that file and therefore restore the file itself.
Does that sound like magic to you? Is it even possible? Wouldn't it be necessary to have some sort of backup for this to work?
The answer to all these questions is “Yes”. You might not yet be aware that some modern file systems, which you might already be using while you are reading this, are already keeping old data around. They do this so that you can bring your computer back into a working condition if your system ever becomes dysfunctional. Popular file systems which have this as an integrated feature are BTRFS and ZFS.
While exploring the sights of Barcelona with Luca Weiss and Arjen Hiemstra, we discussed how such a time travel feature could be implemented in Dolphin, and I also researched the topic a bit on my own later: The problem I am currently seeing is that it is difficult to pinpoint where in the file system the older versions of files and folders are located. It turns out that at least for BTRFS there is no mandatory folder structure. While it is normally reasonably easy for users to find the old versions (e.g. in openSuse in “/.snapshot/SNAPSHOTNUMBER/snapshot”) the names could be anything, the age of the backup is not necessarily stored in an easily accessible manner either, and figuring out which files belong together isn't trivial either. What do we do if the file that should be restored has been moved to a different folder in the meantime?
Maybe I am missing something, but I am having difficulty inventing a reliable approach even if I ignore all the technical details for the moment. That doesn't mean that the project is impossible to implement. Not at all! Worst case one could simply search the full disk. However, I have to admit that this is too big of a project to programme on the side. If you are interested or capable to implement this nicely you would be the hero of some users who would otherwise not know how to recover the data. I am certain of that.
One would probably implement it as a KAbstractFileItemActionPlugin which opens a window in which the user could choose the version of the file or folder they want to restore.
Dolphin could be better at dealing with slow storage
In a way the most important thing for a file manager is that it quickly displays the data on storage media. We don't want the name Dolphin to only be for show: A dolphin is fast (fastest mammal in water at 64 km/h). Nothing blocks it in the oceans.
Disks, on the other hand, can be blocking which can be a problem for the other Dolphin. It might take a while for them to retrieve data especially when they are accessed over the internet or another “slow” network. But the access being slow isn't really a good excuse for Dolphin to stutter as well. Loading of data can obviously take some time but Dolphin should stay responsive and quick regardless of that.
Copying files and folders is wrongfully reported as completed
With some regularity users complain about data loss because they removed a storage device after the data transfer has been reported as completed.
In KDE we report a file transfer as complete when the Linux-kernel reports to us that the transfer is complete. Unfortunately, that isn't the full truth because the Linux kernel is a bit hasty in that regard. It considers a transfer as complete as soon as the data is “accessible from the new location.” However, that is a while before the data has actually been physically transferred.
I see three solutions to this: 1. Linux gains a new option so the reported transfer progress is based on physical data transfer progress. 2. We make sure ourselves that the transfer is complete before we report that it is. 3. (In the words of Kai Uwe Broulik:) “We show a very very angry message to the user when they unplug a device that is still mounted, so they will learn not to do that!”
Dolphin should allow users to manage root-owned files and folders
As you might know, the Linux security model can deal with multiple user accounts that act on the same data. Depending on the specific file or folder, different users can have different permissions when it comes to accessing, changing or executing the data.
The account that has full access to all data on the computer is typically called “root”. It is the administrator account on pretty much every computer.
If a user tries to run Dolphin with all the permissions of an administrator by using the programme “sudo”, which would allow them to edit any data on the file system, Dolphin denies this. The reason for this is that this action could potentially allow a hacker to seize full control over the computer. This blockade was put in place before I was part of KDE but users are still annoyed by it because it makes certain tasks more difficult for them. How can we improve this situation without introducing new security hazards for companies and users alike?
I also recently discussed a different more immediate solution with Nate Graham: We know that in the past years various methods have emerged to bypass the blockade. These methods, that reduce security, are quite popular. The blockade in Dolphin doesn't really stop users who want to do an insecure thing. So instead of trying to hinder users more effectively, we should take the chance and inform them about the dangers of what they are trying to do. If they still want to continue after that, we can't and shouldn't stop them. It could be a good idea to transform the block into more of a lock with an easy way to open it legitimately.
So much for what was discussed at the Dolphin Meeting. The rest of this article is about other topics that are relevant to me.
Dolphin for Phones?
In Barcelona I talked a lot with the young developers who strive to make an adapted version of KDE Plasma a success on mobile phones. I hope this software will soon become a viable alternative to Google's Android for the average user. There is some interest to have the file manager that people know and love from their computer also available on their phone.
They didn't know — and neither do you probably — that Dolphin is already so flexible and touch-friendly that not too much work should be necessary to bring Dolphin in a state that is nice to use on phones:
We would probably need a separate configuration for phones, so users can easily install Dolphin in such a fitted state. Are you interested in making Dolphin shine in the mobile space? Contributions are always welcome!
Dolphin and the “Blue Angel”
I talked with Joseph P. De Veaugh-Geiss, who supports the eco-friendly “Blauer Engel For FOSS” project, about the possibility of also certifying Dolphin with the “Blauer Engel”. Question is: What are the direct benefits we expect from such a move? Eventually, it could push governmental institutions towards using Dolphin but Joseph explained that they probably wouldn't switch to Linux for this alone. To his surprise — and maybe yours too — Dolphin already works on Microsoft Windows and to my knowledge even on macOS. It has some rough edges on Windows and nobody really takes care of those at the moment. Would that be worthwhile? If we were to popularise the Windows version, would that lead to a lot more free and eco-friendly computing? I am not sure if we shouldn't rather use our limited resources on other things.
You might notice by now that there is way more meaningful work to do in Dolphin alone than we can realistically undertake with our small group of volunteer developers. It would be great if even more friendly contributors would join the project all of a sudden. :)
Documentation in the Application
Another topic that is dear to my heart is that our software should also be usable by computer-illiterate users. We accomplish this with guides and help texts among other things. Some of my efforts to have more help available were successful. One example are the little help buttons which have made their way to various parts of KDE by now after I introduced them on the “Fonts” settings page only two years ago (https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/51). In a similar vein I added a feature to many applications that allows users to invoke exhaustive help directly from an application's user interface. You might have noticed the little “Press Shift for more.”-notes which for example show up when you hover your mouse cursor over a button in Dolphin. In my opinion every KDE application should provide more help this way.
I was in the meeting about writing guides and documentation for the web page https://userbase.kde.org/Welcome_to_KDE_UserBase and tried to promote the idea there that it might make more sense in many cases to have help available directly where it is needed: in the application. Unfortunately, I didn't get the impression that I was able to convince the attendees of that. So instead, I'll repeat here that every step we put between the user and the available help leads to less users actually using that help. When a user wants to know what a button does, the help should be available right there either next to the button or invokable directly from the button.
On a positive note I noticed that some KDE contributors have already figured out the benefits of this feature. Kai is a fan for example. I hope it is only a matter of time until this new way of providing help is used as naturally as the two-year-old little help buttons are by now in system settings.
So much about my endeavours. If you read with interest until now, you might also be interested in my videos about KDE development: https://tube.tchncs.de/c/felix_ernst/videos
Thanks to KDE e.V. and Its Donors
Meeting the unique group that traveled to Akademy 2022 in Barcelona this year held many benefits for our future collaborations and therefore ultimately for our software. The text above is already way too long even though I nearly exclusively talked about Dolphin. So many other topics would be worth mentioning. Above all else how great it was for me to meet all these friendly KDE contributors in person for the first time.
I would like to thank KDE e.V. and the many donors to that organisation for paying the majority of my travel expenses. After personally meeting the people who manage the donation money, I can say with full confidence that donation to the KDE e.V. are in good hands and spent with diligence and strategy to ensure the long-term existence and growth of the wider KDE community. If you would like to donate to this non-profit entity, visit https://kde.org/community/donations/.
The SAFe Delusion – Information for decision-makers considering the SAFe framework
Tags: tech, agile, criticism, safe
Finally out of Google Docs it seems. Better version for sharing around. Still an interesting list of case studies and opinions around SAFe. I learned a few things, I didn’t realize it’s creation was so disconnected from the pre-existing agile community. It all seems to confirm my opinion that it’s better to stay away from it though. The few organizations I know of which use it are clearly very much in a command and control mode. This is going backwards.
Definitely this! It’s important to model properly your domain and leverage smart value types everywhere it makes sense. This can prevent quite a few different types of bugs.
Good reminder that “premature” doesn’t mean “early”. Poor Knuth is so often badly quoted in the context of optimization that it’s really sad. The number of times I see “early pessimisation” on the pretense of avoiding “premature optimization”. Such a waste…
Good old-fashioned code optimization never goes out of style
Tags: tech, programming, optimization
What the title said, there’s nothing fancy about optimizations. It’s mostly well known knowledge, doesn’t change much over time or on different stacks… still it’s very satisfying.
If you like remote work, then you need to make sure your written communication is good. There’s a handful of proper guidelines in this paper. Good reminders.
Once again, I got the honor of the Halloween special for the News from KDE PIM post.
Let’s see what happened during the last two months.
Akademy 2022
Akademy 2022 happened in early October. Since it was in Barcelona it was almost next door
for me and I could easily attend by train. Of course, a PIM BoF occurred there. Here are
a few notes of what was discussed there:
we might move to a less aggressive dependency bumping strategy, supporting one or two
KDE Frameworks past versions would help people working from distro packages to
contribute
the idea of merging the kontact and kalendar chat channels is floating around
plans are being made for a PIM sprint (involving Plasma Mobile PIM and Desktop PIM)
aiming at holding it in Toulouse somewhen during Spring 2023
Kalendar will hopefully be splitted into reusable modules for other apps consumption
(like Raven)
the docker container for PIM development might be decommissioned as it’s apparently
unused
there’s growing interest into switching Akonadi to SQLite again, would help with the
robustness, clearly will be quite some work though
branching for Qt 6 will occur around the same time as Plasma
The crypto support in the message composer has also been improved which has been
covered in more details in another blog post with images and
videos, some more
improvements are on the way.
It is also now possible to resend an email you opened via KMail (courtesy of Christian
Schoenebeck), definitely useful to send emails generated by another program without
access to SMTP
Language support has also been improved
More translators are available (Google Translate, Libre Translate, Yandex, Bing,
Lingva you name it)
We can directly use LibreOffice auto-correction list now
Lots of bug have been fixed in the grammar plugin support
KOrganizer
KOrganizer handling of recurring to-dos has been improved. Since version 22.08.3 the
“Toggle To-do Completed” action properly acts on past or future occurrence as you would
expect. Indeed, when toggling an instance if it gets marked as done then all previous
occurrences are considered done as well, if it gets marked as not done then all future
occurrences are considered not done as well.
KDE Itinerary
KDE Itinerary gained support for boat and ferry tickets, ICAO VDS health certificates and
many improvements to the travel data extractor which also benefit the KMail itinerary
plugin. More details can be found in this blog
post.
Kalendar
Views now have a new “basic” mode useful for low performance or battery powered
devices. In this mode the views are not swipe based and more static but significantly
faster and less resource intensive.
A refactoring occurred in the data models used in the backend. This led to overall
performance improvements especially when editing events and tasks.
The sidebar is now responsive and will adapt to still be useful when the window gets
narrower. It will collapse in a strip or expand depending on the available width.
Lots of bug fixes ranging from UI glitches to major crashes. Make sure to update to the
latest version!
Kleopatra
For OpenPGP smart cards supporting ECC Kleopatra now allows generating keys for the
curves supported by the cards. Moreover, the keys stored on an OpenPGP smart card can
now be (re-)generated separately. (T4429)
The notepad now has a dedicated Import button. Previously, the Sign/Encrypt button
changed to Import when certificate data was detected in the notepad. This behavior
made encrypting certificate data impossible and wasn’t good for usability and
accessibility. (T6188)
Secret key backup of S/MIME certificates was
fixed. (T6189)
The Certificate Dump window now opens in the foreground when clicking “More Details” in
the Certificate Details window for an S/MIME certificate opened from the Group Edit
dialog. (T6180)
Canceling an encrypt operation triggered from the notepad doesn’t show an error message
anymore. (T6196)
If one enters a bad passphrase when importing an S/MIME certificate in PKCS#12 format,
then a proper error message is shown. (T5713)
Fixed potential invalidation of keys referenced by commands which could cause those
commands to fail unexpectedly. (T6157)
Unusable actions are now disabled when the details of a remote key (i.e. the result of
a lookup) are displayed. (T6201)
The Certify dialog no longer offers expired user IDs for certification.
(T6155)
The keyboard focus indicator for labels is only drawn if the label received focus by a
keyboard command. (T6111)
Errors during Web Key Directory (WKD) lookups (which happen in the background when
doing a key lookup) are now ignored. (T6202)
The Qt binding of GpgME (used by Kleopatra, KMail, and other KDE applications) can now
be built for Qt 6.
Misc
Now dialog box size in PIM applications are correct on HiDpi displays.
Community Analytics, What Else?
Of course, I couldn’t conclude such a post without taking a look at the community data
analytics during the period. Let’s see how it looks for the past two months.
A big shout out to all those who participated in KDE PIM work the past couple of
months. Thanks a lot! It’s an important job you’re all doing. You know who you are. Still,
here is the activity graph of the past two months, so now everyone know who you are
(offer them drinks if you get the chance!):
In the past two months, we had 30 different developers on KDE PIM (that seems rather
stable compared to my last post two years ago). And of course, since my data is coming
solely from git, this unfortunately misses people who helped with bug reports, docs,
design etc. Whatever your contribution you can be all proud!
Now, how does the code contributor network looks like?
The three most influential ones are Laurent, Heiko and Volker. You can also see three
extra persons pretty central to the network: Carl Schwan, Claudio Cambra and Sandro Knauß.
Clearly all the work on Kalendar and crypto support is showing up.
How You Can Help
Next time, your name could show up in visualizations like the ones above!
Check out the KDE PIM Development wiki
and find out how to take part into something that matters. If you want your share of this
or need help to get started, feel free to contact us via the #kontact and #akonadi IRC
channels on Libera Chat or via #kontact:kde.org and #akonadi:kde.org on Matrix.
Time is running and already a couple of weeks passed since I have been at this year’s Akademy in Barcelona. It was great to (finally again!!!) meet people in person and talk about free software projects, while eating tapas our having nice beer.
One of the topics on my agenda was the next iteration of our Yocto layers. At the moment we have two layers provided by KDE for downstream usage, “meta-kf5” and “meta-kde“. The first provides a simple integration of KDE Frameworks into Yocto projects and the second one is a set of KDE Plasma (Desktop, Mobile & Bigscreen) and KDE Gears applications, which is mostly focused on providing nice show cases of KDE software.
Using the opportunity to have most people in Barcelona for a live meeting and the missing ones at least via remote, we had a quite intense BoF session. For the details just have a look at the notes. For me, the main points and results are these:
We finally have a wiki landing page for Yocto in KDE: https://community.kde.org/Yocto. This page is supposed to document the main workflows for our Yocto layers, give a first starting point for on-boarding and also explain to downstream users what we want to achieve. Most points are not there yet in all the details they are supposed to, but work is ongoing.
Our next important goal is to finally get the Yocto layers running in the KDE CI. As an important preparation step, we now introduce Repo manifests that help us to organize the different meta-layers and their revisions we depend on. This is actually what most projects in the Yocto ecosystem are doing, so it’s also part of our housekeeping. As already some time passed since Akademy, the first manifest files are in place and are ready to use, just follow the README. As an important side-note, they not only help with CI but very much speed up bootstrapping your system in case you want to test our layers.
And finally, I took over the Yocto layer maintainer role from Volker. To celebrating this, I directly ordered yet another 2 TB SSD, which now is already 41% full with Yocto artifacts
If you want to have a look at the KDE Yocto layers, best first have a short glance at the wiki page and then just try it out by using the default.xml manifest.
The All-American High School Film Festival (hereafter, A-AHSFF) is a week-long event hosted in New York City. Students can submit their short films in advance, and at the event are exhibitions and rewards for the best-judged films. There is also a tech fair, this year on the 22nd of October. KDE community member Nataniel Farzan is one of this year’s selected entrants, and negotiated a booth for KDE at the tech fair!
There aren’t very many members in the KDE community in the US, but a few of us live in the area. Philip Cohn-Cort and I heeded the call (with the invaluable remote support of Paul Brown and Aniqa Khokhar).
Paul and Aniqa did most of the heavy lifting of preparing the event for success. They requested the budget, and ordered the stickers, tablecloth, and banner. Big thank you to both of you! All Philip and I did was prepare the computers and, of course, show up.
Arrival
For me, the trip is about an hour and a half by train. Since the event started early on Saturday and we needed to set up, my best option was to leave Friday and spent the night. Philip similarly has a bit of a journey into the city. Since the banner was running late, he stayed later at his place in the hope it might arrive.
I got to the hotel first and checked in. A cute and efficient way to spend a night! The wifi was useless so it’s a good thing everything was already downloaded.
Festival
Booth Setup
Philip and I arrived in plenty of time, an hour before the festival started. This turned out to be good, because the venue had an extreme shortage of power outlets and none close to our booth! There was only one outlet on the whole area. I had a long extension cord, but not long enough to run all the way across the room. Happily, we didn’t need much power to run three laptops, so the people setting up the booth in front of the outlet let us plug into their power strip.
With that out of the way, we plugged my power strip into the extension cord, covered the extension cord with mats also kindly offered by the Fotocare booth to prevent a tripping hazard, and got everything set up.
In order from left to right, Philip’s older Surface Book running KDE Neon, Appimage kdenlive, and Krita. My new laptop running Windows with kdenlive. And my old touchscreen laptop running Fedora, krita, and kdenlive.
Krita turned out to be a great addition to the demo. Students loved doodling with the pen touchscreens, and several attendees were interested in it for the ability to do animation.
A group of students who came for kdenlive but stayed for Krita
Power strip might be an American English word? For those not familiar, here is a picture.
Going into the festival, one key note from Paul kept ringing in my head:
At places like FOSDEM or Scale, KDE is relatively well-known… This is not the case for A-AHSFF. At A-AHSFF, booth staff will have to be pro-active and engage attendees as they pass.
This turned out to be completely true. I spoke with exactly one person (a student) who knew what kdenlive was. So I needed a pro-active strategy.
Across from our booth, the huge lights of the Fotocare booth could not be missed. So I used this to our advantage. As groups or individual students came to admire the lights, I would intercept them and ask simply, “Can I give you a sticker?”
After all, who doesn’t want a sticker? I gave away a lot of stickers this way.
Most visitors would say “Yes”, after which point I had their attention and could present my quick pitch. “This is for kdenlive, free video editing software written by volunteers.”
During showings, the booth was very quietBut in between showings, the booth was booming!
Student Reception
To be honest, I am surprised at how well my short pitch worked. Some (say, 15%) students were just not interested, and responded with some form of “Ok, thanks for the sticker” and wander off.
But most were at least intrigued, at which point I would launch into my second phase: “It’s totally free, it runs on Mac, Windows, and Linux, and it supports Adobe file formats. It’s running on these laptops, please feel free to have a seat and try it out.”
(The second phrase evolved a lot over the course of the day, trying to head off the questions I had already received, like “What do you mean, free? Is there a subscription?” and “Are you a startup?”)
Nearly every attendee who heard this part of my pitch would look at the laptops and examine them for a few seconds, maybe prod the computer, and most (say, 80%) would leave with some form of “Cool! I’ll check it out.” I imagine by the time their long day is over, most students will have forgotten. But hopefully a few will find their stickers tomorrow, and remember to install it.
Finally, there was the rarer group of students who would actually sit down, and were really interested. This only happened 5 or 10 times through the event, but those students were really engaged. I’m pretty confident they’ll look for their sticker tomorrow and install kdenlive.
Educator Engagement
At the same time as we were trying to engage students, I was trying to pick out and engage adults who were not just parents wandering around after their darting children, but educators interested in putting kdenlive in their classroom. Before the event got fully under way, I started an online form to collect data from interested educators. This form also evolved over the course of the event, but I intentionally kept it short and simple. Just an email entry, a few checkboxes, and a field for “anything else” (largely for our usage, so we could keep notes about them!)
We chatted with quite a few educators and everyone I chatted with put their information into my form. The overwhelming response was “Wow, this is so cool, I can send this home with my students so they can work when their school laptop (and thus, Adobe subscription) isn’t available.” I remember one educator who primarily worked for a large, wealthy university, but in the summers taught at a poorer school where he was excited to bring kdenlive. Another educator said his school district paid for Adobe subscriptions, but that would end as soon as his students graduated, and he was excited to be able to offer them kdenlive as a replacement.
Postmortem
Overall, I am very happy with how the festival turned out. We reached lots of excited students, I suspect many of them will try kdenlive in the near future. Moreover, we reached many excited educators, who thought kdenlive would fit in their classroom in one way or another.
At the start of the event, I commented that I wished the stickers had a QR code. Since our banner hadn’t arrived, we only had the smaller QR codes on pieces of paper on the table, and I doubt my shouts of “kdenlive.org” have stuck in any memories. I usually scan QR codes of things I am interested in during a busy event. That way, the browser tabs act as automatic reminders, long after I’ve forgotten the sticker in the bottom of my bag. However, I think our stickers did an appropriate job of allowing me to start conversations, as well as let students who were really excited remember what it was they were excited about. We had intended to pair it with a big banner with a QR code, which would have filled that hole. Several of the most excited students scanned the printed QR codes we had on the table.
With the relative sudden appearance of the event, the banner was unfortunately not able to arrive in time. I am mostly cross because that means that we now have a banner that we will not be using! However, with the laptops, tablecloth, and stickers, I think our booth was snazzy, and we were able to get plenty of attention.
steveire
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.
@felixernst:kde.org
