Google Ordered To Identify Who Watched Certain YouTube Videos
Tags: tech, google, law, surveillance
This is a worrying trend we see in law enforcement a bit everywhere. It’s a bit too convenient to make such requests even though it is unconstitutional.
Interesting, with the price hikes and bundles to come, we might indeed see a resurgence in physical media. It will stay niche for sure, but looks like demand is about to grow.
How People Create and Destroy Value with Generative AI | BCG
Tags: tech, ai, gpt, creativity, quality
Interesting study on the impact generative AI can have on people performances in business settings. There are a few nuggets in there. In particular anything related to problem solving people do worse with generative AI tools than without. And even worse than that when they’ve been trained (probably due to overconfidence). The place where it seems to help is for more creativity related tasks… at the individual level, but at the collective level creativity decreases due to homogenization. Definitely things to keep in mind.
Tags: tech, ai, gpt, criticism, communication, copyright, law
Very interesting piece. The chances that it is another bubble are high. It’s currently surviving on a lot of wishful thinking and hypothetical. This really feels like borrowed time… I wonder what useful will remain once it all collapses. Coding assistants are very likely to survive. Clearly there could be interesting uses in a more sober approach.
Wondering where some of the biases of AI models generating images come from? This is an excellent deep dive into one of the most successful data sets used to train said models. And they’ve been curated by… statistical models, not humans. This unsurprisingly amplifies biases all the way to the final models.
This is an excellent piece, I highly recommend reading it.
Why choose async/await over threads? – notgull – The world’s number one source of notgull
Tags: tech, rust, multithreading, coroutine
In which case you want one or the other? This is illustrated in the Rust case which has its own struggles, but the question applies more largely in my opinion.
This is about a Rust library but equally applies to any ecosystem which allows to easily pull a dependency. As soon as you pull them, you need to monitor their health for the sake of your own project.
This is a piece I also wrote for the enioka blog, so there is a French version available.
At enioka Haute Couture we started offering trainings a little while ago.
True to our DNA this is focusing on software engineering practice rather than
a given tool, framework or API. This is why we have courses on topics like software
architecture, refactoring, dealing with legacy code, test driven development (TDD),
code review and so on.
Also, not every team has the same needs. Some prefer a few intensive days during a
given week, others prefer smaller sessions over an extended period. That’s why our
courses are designed to be flexible. They can be tailored to build a multi-day
session, or all the way down to many one hour knowledge building sessions.
Hopefully, this all sound great to you (for sure it does sound great to me). So why
talk about this now? Is it some kind of advertisement stunt? Well… not really.
You see, while working on our training offers something happened. Almost three years
ago GitHub announced GitHub Copilot. It was just a technical preview at the time.
Since then, there has been an arms race in the large language model (LLM) domain.
Like it or not, generative AI is here to stay and code assistants based on such
models are used more and more.
I’m not one of those doom sayers claiming such models and assistants are going
to take over our jobs. Likewise, I don’t think they’re going to double the
daily productvity of developers. Still, they will necessarily impact how we work
and the code which is produced. So keeping an eye on development practices, I’m less
concerned about disappearing developer jobs and more concerned about a drop in
the quality of the code produced.
Indeed, early studies indicate that code assistants when introduced in an
unchecked manner tend to push the code quality down and tend to increase
the amount of security issues introduced. Interestingly the main factors
highlighted are behaviorial. Which means that before waiting for a magical new
assistant which would code perfectly (spoiler: it won’t happen), we should rather
improve the way we introduce and use those tools.
Which gets me back to the [enioka Haute Couture trainings]. In this new era,
we have to acknowledge coding assistants during our trainings. This perfuses all the
topics I mentioned previously. There is now a nagging question for all our software
development practices: when is a coding assistant the right tool for the job?
If you’re practicing TDD or trying to improve your use of it, is it a good
idea to have the coding assistant write the tests for you? Maybe not… since it is
where you make important design decisions, you likely want to stay at the helm.
Might come in handy to generate the code which must pass the tests though.
If you’re dealing with a legacy code base which needs to be modernized, for which
part of the process the coding assistant will make you faster? Updating the code
to a newer version of the language or dependencies? Extracting clearer modules
and functions? Writing approval tests to secure all of that?
There are many more such questions… and you can explore the answers with us
during one of our training sessions. We’ll keep talking TDD, legacy code…
with a twist!
And of course, just like any other tools, what we’re proposing is not specific to
a given solution. You use GitHub Copilot? Codeium? A specific in-house fine-tuned
model? This is fine. We’ll take this into account during the training to adapt
it as much as possible to the involved developers and their context.
For a while Qt has been offering qmlls, a Language Server Protocol implementation for QML. This allows popular text editors like Kate (and some lesser known ones like Visual Studio Code) to work with QML code without having to write dedicated support for it.
Naturally many people are eager to use it to hack on KDE code. When trying to do that you probably have encountered some frustration with things not working as expected. So what’s going on there, and how can we make it work?
First and foremost one must mention that qmlls is still under heavy development. There’s a number of things missing that you’d expect from a fully featured LSP implementation. If you encounter something that looks like it should work but doesn’t, don’t hesitate to file a bugreport.
So how does one use qmlls? In Kate it should be activated out-of-the-box when opening a QML file. If that doesn’t work you might need to tweak the LSP-Client settings. For other editor please consult their documentation on how to enable LSP support.
One problem you are likely to encounter when using qmlls on KDE code is that it fails to find KDE-provided QML modules like Kirigami. This happens when the modules are installed into e.g. ~/kde/usr, which isn’t searched by Qt. One way to get around this is to build and install your own Qt into ~/kde/usr too, since that way the modules will be installed into the same prefix as Qt and Qt will find them. While building your own Qt is a worthwile thing to do in general it’s not a very satisfying solution. I hope we can find a better solution for this soon. See here for a related bugreport.
If your installation is set up in a way that qmlls can find the KDE-provided modules you might still encounter it warning on unknown modules or types. In order for qmlls to show information for a module the module needs a qmltypes file. These files provide machine-readable information about the types that the module exposes. The easiest way to make these available is porting the module to ecm_add_qml_module and declarative type registration. This was done for many KDE modules already, but there’s still a number of them missing. Help on that is very welcome! Something that isn’t obvious is that in order for the tooling to work correctly module dependencies need to be marked explicity via the DEPENDENCIES parameter in ecm_add_qml_module.
If all the modules and types are found correctly you will still encounter some warnings, but most of these should correspond to actual issues and non-optimal practices like using unqualified property lookups and context properties. qmlls is a great tool to guide you towards resolving those and thus modernizing and optimizing the code. There are however some classes of warnings for which we don’t have proper solutions yet:
Our translation functions, i18n and friends, are considered unqualified lookups by qmllint/qmlls. This is because they are magically injected into the engine at runtime. It’s not clear how a solution for this could look like.
When writing KCMs we expose the module’s C++ class via the kcm context property, which is opaque to the tools. A different approach is needed.
Despite the current limitations qmlls is already a very useful tool for working on QML code, assuming the project is set up properly.
Happy QML hacking!
If you are reading this from the future there’s an update available.
Definitely this. It might ultimately impact the abstraction levels accessible to us for coding… but the skills will still be needed. Natural language is too ambiguous for the task.
Indeed this. It’s not only about payload size, it’s also about CPU consumption. Our profession is still assuming too much that users will get faster CPU on a regular basis.
Interesting paper showing the main reasons why people ultimately change their phones. I find interesting that the opacity of storage management on mobile devices is such a factor.
Indeed, don’t mindlessly add tests. I find interesting that the doubts raised in this piece are once again concluded using an old quote of Kent Beck. What he was proposing was fine and then over time people became clearly unreasonable.
Very interesting piece. The DORA metrics are a good thing but I always felt they’re kind of dry and missing something. On the other hand surveys which are more qualitative give also interesting results but come with their own biases. The idea pushed here for better qualitative surveys and to combine them with quantitative metrics like the DORA one is definitely a tempting way forward.
A global theme on the kde third party store had an issue where it executed a script that removed user's data. It wasn't intended as malicious, but a mistake in some shell parsing. It was promptly identified and removed, but not before doing some damage to that user.
This has started a lot of discourse around the concept of the store, secuirty and upstream KDE. With the main question how can a theme have access to do this?
To developers it's not a surprise that third party plugins can do this sort of thing. It's as intended. A global theme can ship custom lockscreens, custom applets, custom settings and all of these can run arbitrary bundled code. You can't constrain this without limiting functionality.
To that end there's an explicit warning when downloading plugins.
Expectations
Our primary issue boils down to expectation management and communication.
There are plenty of other ways where users can download and run any other unfettered code from the internet; the Arch user repository (AUR), adding ubuntu PPAs and alike. This isn't a bad thing - it's useful and people do amazing things with this to benefit users.
Nothing on the KDE store happens without explicit user interaction either.
A problem is there's an expectation that because it's programs that it's inherently unsafe and a user needs to trust the source. Our issue is phrases like "global themes" or "Plasma applets" don't always carry this message.
The tech world has changed a lot over the past decade and whilst our code hasn't changed, users expectations have. More and more places provide well kept walled gardens where most actions accessible via the UI are safe-by-default - or at least claim to be!
I've also seen confusion that because a lot of our UI is written in a higher-level language (QML) that's enriched with javascript all browser sandboxing automatically applies. Even though that's not what we claim.
But ultimately if there is a gap in expectations, that's on us to fix.
What can we do better?
In the short term we need to communicate clearly what security expectations Plasma users should have for extensions they download into their desktops. Applets, scripts and services, being programs, are easily recognised as potential risks. It's harder to recognise that Plasma themes, wallpaper plugins and kwin scripts are not just passive artwork and data, but may potentially also include scripts that can have unintended or malicious consequences.
We need to improve the balance of accessing third party content that allows creators to share and have users to get this content easily, with enough speed-bumps and checks that everyone knows what risks are involved.
(UI from Flathub for potentially unsafe content)
Longer term we need to progress on two avenues. We need to make sure we separate the "safe" content, where it is just metadata and content, from the "unsafe" content with scriptable content.
Then we can look at providing curation and auditing as part of the store process in combination with slowly improving sandbox support.
Do I need to do anything as a user?
If you install content from the store, I would advise checking it locally or looking for reviews from trusted sources.
If you're a sys-admin you might want to consider adding the following to block users installing addons with the following kiosk snippet.
For the next digiKam releases, the digiKam team needs photographs for digiKam and Showfoto splash-screens.
Proposing photo samples as splash-screens is a simple way for users to contribute to digiKam project. The pictures must be correctly exposed/composed, and the subject must be chosen from a real photographer’s inspiration. Note that we will add a horizontal frame to the bottom of the image as in the current splashes.
Since the dawn of the times, the only way to implement any effect that has fancy user interface used to be in C++. It would be rather an understatement to say that the C++ API is difficult to use or get it right so there are no glitches. On the other hand, it would be really nice to be able to implement dashboard-like effects while not compromise on code simplicity and maintainability, especially given the rise of popularity of overview effects a few years ago, which indicated that there is demand for such effects.
In order solve that problem, we started looking for some options and the most obvious one was QtQuick. It’s a quite powerful framework and it’s already used extensively in Plasma. So, in Plasma 5.24, we introduced basic support for implementing kwin effects written in QML and even added a new overview effect. Unfortunately, if you wanted to implement a QtQuick-based effect yourself, you would still have to write a bit of C++ glue yourself. This is not great because effects that use C++ are a distribution nightmare. They can’t be just uploaded to the KDE Store and then installed by clicking “Get New Effects…”. Furthermore, libkwin is a fast moving target with lots of ABI and API incompatible changes in every release. That’s not good if you’re an effect developer because it means you will need to invest a bit of time after every plasma release to port the effects to the new APIs or at least rebuild the effects to resolve ABI incompatibilities.
This has been changed in Plasma 6.0.
In Plasma 6, we’ve had the opportunity to address that pesky problem of requiring some C++ code and also improve the declarative effect API after learning some lessons while working on the overview and other effects. So, enough of history and let’s jump to the good stuff, shall we?
Project Structure
Declarative effects require some particular project structure that we need to learn first before writing any code
The package directory is a toplevel directory, it should contain two things: a metadata.json file and a contents directory. The metadata.json file contains information about the name of the effect, what API it uses, the author, etc.
The contents directory contains the rest of QML code, config files, assets, etc. Keep in mind that ui/main.qml is a “magical” file, it acts as an entry point, every effect must have it.
In order to install the effect and make it visible in Desktop Effects settings, you will need to run the following command
This is quite a lot to memorize. That’s why kwin provides an example qtquick effect that you can grab, tweak some metadata and you’re good to go. You can find the example project at https://invent.kde.org/plasma/kwin/-/tree/master/examples/quick-effect?ref_type=heads. Note that the example project also contains a CMakeLists.txt file, which provides an alternative way to install the effect by the means of cmake, i.e. make install or cmake --install builddir.
Hello World
Let’s start with an effect that simply shows a hello world message on the screen:
import QtQuick is needed to use basic QtQuick components such as Rectangle. import org.kde.kwin imports kwin specific components.
The SceneEffect is a special type that every declarative effect must use. Its delegate property specifies the content for every screen. In this case, it’s a blue rectangle with a “Hello World!” label in the center.
The ShortcutHandler is a helper that’s used to register global shortcuts. ShortcutHandler.name is the key of the global shortcut, it’s going to be used to store the shortcut in the config and other similar purposes. ShortcutHandler.text is a human readable description of the global shortcut, it’s going to be visible in the Shortcuts settings.
The ScreenEdgeHandler allows to reserve a screen edge. When the pointer hits that screen edge, some code can be executed by listening to the activated signal.
The PinchGestureHandler and SwipeGestureHandler allow to execute some code when the user makes a pinch or a swipe gesture, respectively.
effect.visible = !effect.visible toggles the visibility of the effect. When effect.visible is true, the effect is active and visible on the screen; otherwise it’s hidden. You need to set effect.visible to true in order to show the effect.
If you press Meta+H or make a pinch gesture or move the pointer to the top screen edge, you’re going to see something like this
Note that there are no windows visible anymore, it is the responsibility of the effect to decide what should be displayed on the screen now.
Displaying Windows
Being able to display text is great, but it’s not useful. Usually, effects need to display some windows, so let’s display the active window
The change is quite simple. Instead of displaying a Text component, there’s a WindowThumbnail component now. The WindowThumbnail type is provided by the org.kde.kwin module. WindowThumbnail.client indicates what window the thumbnail item should display.
Input
Input processing contains no kwin specific APIs. TapHandler, MouseArea, Keys and other stuff available in QtQuick should just work. For example, let’s implement an effect that arranges windows in a grid and if somebody middle clicks a window, it will be closed
The code looks pretty straightforward except maybe the model of the GridView. WindowModel is a helper provided by org.kde.kwin module that lists all the windows. It can be passed to various views, Repeater, and so on.
The result can be seen here
Delegates are Per Screen
One thing to keep in mind is that the delegates are instantiated per screen. For example,
delegate: Rectangle { color: "yellow"
Text { anchors.centerIn: parent color: "black" text: SceneView.screen.name } }
When you activate the effect on a setup with several outputs, each output will be filled with yellow color and the output name in the center
Usually, the output is irrelevant, but if you need to know what output particular delegate is displayed on, you could use the SceneView.screen attached property.
Configuration
As your effect grows, you will probably face the need to provide an option or two. Let’s say that we want the background color in our hello world effect to be configurable. How do we achieve that? The first step, is to add a main.xml file in package/contents/config directory, i.e.
In our case, only one option is needed: BackgroundColor, which has Color type and #ff00ff default value. You can refer to the KConfigXT documentation to learn more what other entry types are supported.
The next step is to actually use the BackgroundColor option
effect.configuration is a map object that contains all the options listed in the main.xml.
Now, if you toggle the hello world effect, you’re going to see
There are a few more thing left to do though. If you navigate to Desktop Effects settings, you’re not going a configure button next to the hello world effect
Besides providing a main.xml file, the effect also needs to provide a config.ui file containing a configuration ui
The config.ui file is a regular Qt Designer UI file. The only special thing about it is that the controls that represent options should have special name format: kcfg_ + OptionName. For example, kcfg_BackgroundColor
The last final piece in order to expose the configuration ui is to add the following line in the metadata.json file
"X-KDE-ConfigModule": "kcm_kwin4_genericscripted"
With all of that, the effect is finally displayed as configurable in the system settings and the background color can be changed
Sharing Your Effect With Other People
The preferred method to distribute third party extensions is via the KDE Store. Both JS and QML effects can be uploaded to the same “KWin Effects” category.
Documentation and Other Useful Resources
Documentation is still something that needs a lot of work (and writing it is no fun ). KWin scripting API documentation can be found here https://develop.kde.org/docs/plasma/kwin/api/.
If you need to pack or arrange windows like how the overview effect does, you could use the WindowHeap component from org.kde.kwin.private.effects module. BUT you need to keep in mind that that helper is private and has no stable API yet, so use it on your own risk (or copy paste the relevant code in kwin). Eventually, the WindowHeap will be stabilized once we are confident about its API.
I hope that some people find this quick introduction to QML-based effects in KWin useful. Despite being a couple years old, declarative effects can be still considered being in the infancy stage and there’s a lot of untapped potential in them yet. The QML effect API is not perfect, and that’s why we are interested in feedback from third party extension developers. If you have some questions or feedback, feel free to reach out us at https://webchat.kde.org/#/room/#kwin:kde.org. Happy hacking!
Since a brief tryst with Ubuntu Budgie Edition, I’ve dearly missed its Raven side-panel, a special panel on the side of the screen that can be opened and closed with a click. As someone who needs a clean, minimal desktop, the workflow is just too perfect — when you have two or three widgets that you use frequently, but not frequently enough that they warrant permanent homes on a main panel, just stuff them into a disappearing side-panel that can be called with a quick key-combination or by clicking on an icon; It’s a great way to keep things out of the way, but within reach, without having a permanently cluttered system tray that you might want to keep clear for things like email notifications.
My side panel, and the widget that launches it.
There are some drawbacks; this workflow isn’t well supported on KDE Plasma, so it’s a bit of a faff to set up, and only a few widgets will display nicely on a wide side-panel. For instance, it would be a dream to have the KDE weather widget automatically take advantage of the horizontal space and display the information that would usually be in its dropdown, but what you get instead is a giant icon, for now at least. I use my side-panel for my clipboard history and the media player widget, both of which play nicely with a side-panel. Another niggle I have with it is that, as far as I know, there’s no way to disable activation of the panel when your mouse pointer makes contact with the screen edge. This is a mild to moderate inconvenience when you’re working with applications that have toolbars on the sides of the window, like design applications often do.
For me, personally, the drawbacks aren’t so severe as to put me off of the workflow.
First, you’ll need to create a panel. To do this, right click on an empty section of your desktop, and select “Add Panel > Empty Panel.” When the panel appears, right click it and select “Enter Edit Mode.” Set up your panel however you like, but you will need to set “Visibility” to “Auto Hide” and may want to give it a width of at least 400px or so.
Now, if you wanted to show and hide your panel with a keyboard shortcut, you can set up a focus shortcut in the panel settings window and stop here. If, like me, you want to toggle your panel by clicking on an icon somewhere, we’re going to have to use a wee script, but don’t worry, it’s not as hard as it sounds and I’ll take you through it step by step.
Before we can put our script together, we’re going to need to know what the ID of our panel is. Open up KRunner with Alt+F2 or Alt+Space and run plasma-interactiveconsole. This will launch KDE’s Desktop Shell Scripting Console. In the console, type print(panelIds); and click “Execute.” Assuming you entered that in correctly, what you should see now in the output console beneath the text editor is a series of numbers — the ID numbers of our panels. Keep a note of these numbers.
Look at those IDs.
Clear the text editor and enter the following:
let panel =panelById(401);
panel.hiding ==="autohide"? panel.hiding ="windowsgobelow": panel.hiding ="autohide";
This will check if our panel is set to auto-hide; if it is, the script will set the panel to “windows go below” mode, otherwise it will set the panel to auto-hide.
Now to make use of those panel ID numbers. Which number corresponds to your new side-panel? While I can’t be sure, chances are it’s the last number on the list as we’ve just made the new panel a moment ago. So in the script above, where I have entered 401, enter the last number in your ID list and click “Execute.” At this point, if the ID number is correct, your panel should appear; click “Execute” once more to hide it.
Alright, we’ve got our script ready, so we just need one more thing in place: a button or icon that we can click on to show and hide the panel. Fortunately, we can use a widget called “Scriptinator” to provide just this. Right click on an empty area of your desktop or a panel, click “Add Widgets,” and “Get New Widgets.”
Let’s get that widget.
From here, find and install Scriptinator. Once installed, simply drag it where you’d like it to live, either on your desktop, or on a panel. Once you’ve done that, right click on the widget and choose “Configure Scriptinator.” Here, enter the path of the icon you’d like to use in “Custom icon full path;” I used /usr/share/icons/breeze-dark/actions/22/sidebar-expand-right-symbolic.svg. In “OnClick Script,” enter the following:
If you’ve done everything correctly, you should see your side-panel appear when you click the widget and disappear when you click a second time. You may need to restart to see your icon applied to the widget; if you don’t want to wait, you can drop the file path into “OnClick icon full path” in your Scriptinator configuration.
ervin
). KWin scripting API documentation can be found here 
@nathanu:matrix.org
