After a series of horrible fuckups (and I’m not using this word lightly here) by Lenovo, they’ve finally replaced my laptop with a 2nd gen X1 Yoga. I’ve finished building Plasma from git (which I need for development work) and thought to give powertop a whirl to check how we’re doing in terms of battery life. I’m very pleased with the results: An idle Plasma Desktop doesn’t wake up the CPU, which is something we worked on avoiding for years. Furthermore, idling, I get a battery drain rate of less than 4 watt, which is pretty exceptional. Bottom line: Our work hasn’t been in vain and shows that Plasma is pretty well optimized to get the most out of your battery. This is especially interesting for Plasma Mobile of course, but benefits laptop users as well. It’s a nice example how our work on convergence benefits all users. And polar bears.
As a means to give our work direction and a clearer purpose, KDE is currently in the process of soul-searching. Here’s my proposal of what we should concentrate and focus on in the coming years. I’d welcome any feedback from the community to make this proposal better, and rally up more support from the community, and others interested.
So here’s the Big, hairy, audacious goal that — in my opinion — KDE should focus on, and should adapt its strategy for:
“In 5 years, KDE software enables and promotes privacy”
Privacy is the new challenge for Free Software. KDE is in a unique position to offer users a complete software environment that helps them to protect their privacy. KDE, being community-driven and user-focused, has the opportunity to put privacy on top of the agenda, arguably, being in this position, KDE has the obligation to do this, in the interest of the users.
The effect is expected to be two-fold:
- Offer users the tools to protect privacy and to lead a private and safe digital life without compromising their identity, exposing their habits and communications
- Setting a high standard and example for others to follow, define the state of the art of privacy protection in the age of big data and force others to follow suit, thereby increasing pressure on the whole industry and eco-system to protect users’ privacy better
Leaking user data, allowing users to be tracked, collecting their most private information in databases across the world means that users lose control of their identity and what parts they want others to know, and what they want to keep for themselves. Worse, collecting data in so many places, often commercially, but also by governments means that the user has little way of knowing what is known about him or her, let alone being able to determine who should be able to control what. Data being persistently collected means that not only today's security measures and policies are relevant, but also the future's. This poses multiple great risks.
KDE adds a 5th Freedom to the 5 principal software Freedoms:
“The freedom to decide which data is sent to which service”.
Personal Risks for Users
Risks that individual users run are, among others:
- The more data that is collected, the bigger the risk of Identity Theft becomes
- More collected data means that decisions will be made for the user based on skewed or incomplete information (imagine insurance policies)
- Collected data may end up in the hands of oppressive regimes, posing risks to the user when travelling, or even at home
- User's most private secrets may end up in the wrong hands
Socio-economic effects that effect how society, national and international communities work, are:
- Free speech is compromised
- Journalists need tools to communicate secretly, lacking that, freedom and independence of press cannot be guaranteed
- Trade-secrets cannot be kept, free markets cannot function without tools protecting privacy
- Sovereignty of nations cannot be guaranteed
- Cyber-attacks may lead to shift in power
What it will take?
- Privacy-respecting defaults
- Offering the right tools in the first place
We can only guarantee privacy if we also value security.
- Functioning code-review
- Quick turn-around times for software updates, especially security fixes
- Prefer to use encrypted communication where possible, prefer HTTPS over HTTP where possible, avoid unencrypted connections
- Storing sensitive information only in an encrypted way
- Moving away from inherently insecure technologies, i.e. default to Wayland instead of X11
- Avoiding single points of failure and centralized control
KDE software supporting this goal should:
- Only collect and send data when necessary and clear and sensible from within the context. No hidden telemetry sending user stats, not HTTP connections downloading content, no search queries to online services without the users explicit consent (or where it's entirely clear from the context, e.g. web browsers, software updater, etc.).
- Use anonymity where it is possible, for example by using Tor connections for things like weather updates that don't require user identification
- No collection of privacy-relevant data without clear purpose.
- Conservative defaults: a user should not have to make changes to the software configuration to avoid leaking data. Secure and private by default. (Software may be configured to be more leaky if that benefits the user, but the risk to that should be clear, either from context or explicitely stated.)
- Use clear and consistent UI and design language around network-related options
Offering the Right Tools
KDE needs to make an effort to provide a comprehensive set of tools for most users' needs, for example:
- An email client allowing encrypted communication
- Chat and instant messenging with state-of-the art protocol security
- A webbrowser (self-provided) that has private default settings
- File storage and groupware solutions
- Other tools that allow offline operation and independence from popular cloud services
- Support for online services that can be operated as private instance, not depending on a 3rd party provider
- State-of-the-art support and integration for services like Tor, Matrix, Zeronet, etc.
- KDE e.V. allows anonymous donations via bitcoin (or other crypto currencies)
- Adaption of blockchain where useful
How we know we succeeded
Static and runtime analysis tools:
KDE software can be audited for compliance with common, security related standards, such as:
- NIST Cybersecurity Framework (NIST CSF)
- ISO 15408
- Cyber Essentials (UK Government Standard)
- … etc.
"Soft" criteria include:
- Press and 3rd party refer to KDE as carrying the gold-standard for such software
- Journalists prefer KDE software for their work
- The NSA hates KDE
- The CCC loves KDE ♥
The full proposal has a little more details and pointers (and may still be updated, it’s not final yet), but I’d like to keep it at this for my weblog, and also add a note here: Coincidentally, shortly after starting the work on this proposal, KDE’s Plasma team was contacted by Purism who are building a privacy-focused phone. I was immediately excited since I think privacy is more or less an extension of the core values of Free software and the librem5 could provide a really valuable target for KDE’s privacy efforts, I see a fantastic degree of synergy there.
Convergence, or the ability the serve different form factors from the same code base, is an often discussed concept. Convergence is at the heart of Plasma‘s design philosophy, but what does this actually mean to how apps are developed? What’s in it for the user? Let’s have a look!
First, let’s have a look at different angles of “Convergence”. It can actually mean different things, and there is overlap between these. Depending on who you ask, convergence could mean any of the following:
- Being able to plug a monitor, keyboard and mouse into smartphone and use it as a full-fledged desktop replacement
- Develop an application that works on a phone as well as on a desktop
- Create different device user interfaces from the same code base
Convergence, in the broadest sense, has been one of the design goals of Plasma when we started creating it. When we work on Plasma, we ultimately expect components to run on a wide variety of target devices, we refer to that concept as the device spectrum.
Alex, one of Plasma’s designers has created a visual concept for a convergent user interface, that gives an impression how a fully convergent Plasma could look like to the user:
Input Methods and Screen Characteristics
Technically, there are a few aspects of convergence, the most important being: input methods, for example mouse, keyboard, touchscreens or combinations of those, and screen size (both physical dimensions, portrait vs. landscape layout and pixel density).
Touchscreen support is one aspect when it comes to run KDE software on a mobile device or within Plasma Mobile. Touchscreens are not specific to phones any more however, so making an app, or a Plasma component ready for touchscreen usage also benefits people who run Plasma on their convertible laptops, for example. Another big factor is that the app needs to work well on the screen of a smartphone, this means support for high dpi screens as well as a layout that presents the necessary controls in a way that is functional, attractive and user-friendly. With the Kirigami toolkit, which builds on top of QtQuick, we develop apps that work well on both target devices. From a more general point of view, KDE has always developed apps in a cross- platform way, so portability to other platforms is very much at the heart of our codebase.
The Kirigami toolkit, which offers a set of high-level application flow-controls for QtQuick applications achieves exactly that: it allows to built responsive apps that adapt to screen characteristics and input method.
(As an aside, there’s the case for Kirigami also supporting Android. Developing an app specifically for usage in Plasma may be easier, but it is also limiting its reach. Imagine an app running fine on your laptop, but also on your smartphone, be it Android or drive by Plasma Mobile (in the future). That would totally rock, and it would mean a target audience in the billions, not millions. Conversely, providing the technology to create such apps decreases the relative investment compared to the target audience, making technologies such as QtQuick and Kirigami an excellent choice for developers that want to maximize their target audience.)
Plasma Mobile vs. Plasma Desktop
Plasma Mobile is being developed in tandem with the popular Plasma desktop, in fact it shares more then 90% of the code with it. This means that work done on either of the two, mobile and desktop often benefits the other, and that there’s a large degree of compatibility between the two. The result is a system that feels the same across different devices, but makes use of the special capabilities of a given device, and supports different ways of using the software. On the development side, this means huge gains in terms of productivity and quality: A wider set of usage scenarios and having the code running on more machines means that it gets more real-world testing and bugs get shaken out quicker.
Who cares, anyway?
Whether or not convergence is something that users want, I think so. It takes a learning curve for users, and I think advancements in technology to bring this to the market, you need rather powerful hardware, the right connectors, and the right hardware components, so it’s not an easy end-goal. The path to convergence already bears huge benefits, as it means more efficient development, more consistency across different form factors and higher quality code.
Whether or not users care is only relevant to a certain point. Arguably, the biggest benefit of convergence lies in the efficiency of the development process, especially when multiple devices are involved. It doesn’t actually matter all that much if users are going to plug their mouse and keyboard into a phone and use it as a desktop device. Already today, users expect touchscreen to just work, even on laptops, users already expect the convertible being usable when the keyboard is flipped away or unplugged, users already expect to plug a 4K into their 1024×768 resolution laptop and the UI neither becoming unreadable or comically large.
In short: There really is no way around a large degree of convergence in Plasma (and similar products).
Back around 2006, when the Plasma project was started by Aaron Seigo and a group of brave hackers (among which, yours truly) we wanted to create a user interface that is future-proof. We didn’t want to create something that would only run on desktop devices (or laptops), but a code-base that grows with us into whatever the future would bring. Mobile devices were already getting more powerful, but would usually run entirely different software than desktop devices. We wondered why. The Linux kernel served as a wonderful example. Linux runs on a wide range of devices, from super computers to embedded systems, you would set it up for the target system and it would run largely without code changes. Linux architecture is in fact convergent. Could we do something similar at the user interface level?
In 2007, Asus introduced the Eee PC, a small, inexpensive laptop. Netbooks proved to be all the rage at that point, so around 2009, we created Plasma Netbook, proving for the first time that we could actually serve different device user interfaces from the same code-base. There was a decent amount of code-sharing, but Plasma Netbook also helped us identifying areas in which we wanted to do better.
Plasma Mobile (I)
Well, Nokia-as-we-knew-it is dead now, and Plasma never materialized on Nokia devices.
Plasma Active was built as a successor to the early prototypes, and our first attempt at creating something for end-users. Conceived in 2011, the idea was not just to produce a simple Plasma user interface for a tablet device, but also deliver on a range of novel ideas for interaction with the device, closely related to the semantic desktop. Interlinked documents, contacts, sharing built right into the core, not just a “dumb” platform to run apps on, but a holistic system that allows users to manage their digital life on the fly. While Plasma Active had great promise and a lot of innovative potential, it never materialized for end-users in part due to lack of interest from both, the KDE community itself, but also from people on the outside. This doesn’t mean that the work put into it was lost, but thanks to a convergent code-base, many improvements made primarily with Plasma Active in mind have improved Plasma for all its users and continue to do so today. In many ways, Active proved valuable as a playground, as a clean slate where we want to take the technology, and how we can improve our developemnt process. It’s not a surprise that Plasma 5 today is developed in a process very similar to how we approached Plasma Active back then.
Plasma Mobile (II)
Learning from the Plasma Active project, in 2015 we regrouped and started to build a rather simple smartphone user interface, along with a reference software stack that would allow us not only to develop Plasma Mobile further, but to allow us to run on a growing number of devices. Plasma Mobile (II)’s goal wasn’t to get the most innovative of interfaces out, but to create a bread-and-butter platform, a base to develop applications on. From a technology point of view, Plasma is actually very small. It shares approximately 95% of the code with its desktop companion, widgets, and increasingly applications are interchangeable between the two.
Plasma Mobile (in any shape or form) has never been this close to actually making it into the hands and pockets of end users. A collaboration project with Purism, a company bringing privacy and software freedom to end-users, we may create the first Plasma phone for end users and have it on the market as soon as januari 2019. If you want to support this project, the crowdfunding campaign has just passed the 40% mark, and you can be part of it — either by joining the development crew, or by pre-ordering a device and thereby funding the development.
Today, we went out onto the North Sea for a day of maritime training, a course how to rescue, survive and help in the case of being lost at sea, or going overboard from a ship at high sea. The course was extremely valuable towards my long-term goal of being able to do clean-ups of North Sea shipwrecks from ghost nets, abandoned fishing nets which harm marine life.
We went out this morning for two hours of class-room training and then boarded a ship and went out to sea, where we learned how to use flares, smoking pots, floats and various means to rescue men over board and victims of drowning.
This training was organized by Get Wet. I can highly recommend it.
The news is out! KDE and Purism are working together on a Free software smartphone featuring Plasma Mobile. Purism is running a crowdfunding campaign right now, and if that succeeds, with the help of KDE, the plan is to deliver a smartphone based on Plasma Mobile in January 2019.
Why do I care?
Data collection and evesdropping has become a very common problem. Not only governments (friendly and less-friendly) are spying on us, collecting information about our private lives, also companies are doing so. There is a lot of data about the average user stored in databases around the world that not only allows them to impersonate you, but also to steal from you, to kidnap your data, and to make your life a living hell. There is hardly any effective control how this data is secured, and the more data is out there, the more interesting a target it is to criminals. Do you trust random individuals with your most private information? You probably don’t, and this is why you should care.
Protect your data
The only way to re-gain control before bad things happen is to make sure as little data as possible gets collected. Yet, most electronic products out there do the exact opposite. Worse, the market for smartphones is a duopoly of two companies, neither of which has as a goal the protection of its users. It’s just different flavors of bad.
There’s a hidden price to the cheap services of the Googles and Facebooks of this world, and that is collection of data, which is then sold to third parties. Hardly any user is aware of the problems surrounding that.
KDE has set out to provide users an alternative. Plasma Mobile was created to give users a choice to regain control. We’re building an operating system, transparently, based on the values of Free software and we build it for users to take back control.
Purism and KDE
In the past week, we’ve worked with Purism, a Social Purpose Corporation devoted to bringing security, privacy, software freedom, and digital independence to everyone’s personal computing experience, to create a mobile phone that allows users to regain control.
Purism has started a crowdfunding campaign to collect the funds to make the dream of a security and privacy focused phone.
Invest in your future
By supporting this campaign, you can invest not only into your own future, become an early adopter of the first wave of privacy-protecting personal communication devices, but also to proof that there is a market for products that act in the best interest of the users.
Support the crowdfunding campaign, and help us protect you.
A few days ago, Hostingadvice.com’s lovely Alexandra Leslie interviewed me about my work in KDE. This interview has just been published on their site. The resulting article gives an excellent overview over what and why KDE is and does, along with some insights and personal stories from my own history in the Free software world.
At the time, Sebastian was only a student and was shocked that his work could have such a huge impact on so many people. That’s when he became dedicated to helping further KDE’s mission to foster a community of experts committed to experimentation and the development of software applications that optimize the way we work, communicate, and interact in the digital space.
“With enough determination, you can really make a difference in the world,” Sebastian said. “The more I realized this, the more I knew KDE was the right place to do it.”
I published an article about the recent Akademy conference on KDE’s news site, dot.kde.org. This article discusses the presentation Marco and I gave (Plasma: State of the Union), Wayland, Kirigami, Plasma Mobile and our award-winning colleague Kai. Enjoy the read!
Over the past weeks, we (KDE’s Plasma team) have distilled the reasons why we do what we do, and what we want to achieve into a vision statement. In this article, I’d like to present Plasma’s vision and explain a bit what is behind it. Let’s start with the statement itself, though:
Plasma is a cross-device work environment by the KDE Community where trust is put on the user’s capacity to best define her own workflow and preferences.
Plasma is simple by default, a clean work area for real-world usage which intends to stay out of your way.
Plasma is powerful when needed, enabling the user to create the workflow that makes her more effective to complete her tasks.
Plasma never dictates the user’s needs, it only strives to solve them. Plasma never defines what the user is allowed to do, it only ensures that she can.
Our motivation is to enable actual work to happen, across devices, across different platforms, using any application needed.
We build to be durable, we create to be usable, we design to be elegant.
I’ve marked a few bits which are especially important in a bold font, let’s get into a bit more detail:
Cross-device — Plasma is a work environment for different classes of devices, it adapts to the form-factor and offers a user interface which is suitable for the device’s characteristics (input methods such as touchscreen, mouse, keyboard) and constraints (screen size, memory and CPU capabilties, etc.).
Define the workflow — Plasma is a flexible tool that can be set up as the user wishes and needs to make her more effective, to get the job done. Plasma is not a purpose in itself, it rather enables and gets out of the way. This isn’t to say that we’ll introduce every single option one can think of, but we strive to serve many users’ use cases.
Simple by default means that Plasma is self-explanatory to new users, and that it offers a clean and sober interface in its default state. We don’t want to overwhelm the user, but present a serene and friendly environment.
Powerful when needed on the other hand means that under the hood, Plasma offers tremendous power that allow to get almost any job done efficiently and without flailing.
We build to be durable, we create to be usable, we design to be elegant. — The end result is a stable workspace that the user can trust, that is friendly and easy to use, and that is beautiful and elegant in how it works.
In this article, I am outlining an idea for an improved process of deploying software to Linux systems. It combined advantages of traditional, package mangement based systems with containerized software through systems such as Flatpak, Snap, or AppImage. An improved process allows us to make software deployment more efficient across the whole Free software community, have better supported software on users systems and allow for better quality at the same time.
In today’s Linux and Free software ecosystems, users usually receive all their software from one source. It usually means that software is well integrated with the system, can be tested in combination with each other and support comes from a single vendor. Compared to systems, in which single software packages are downloaded from their individual vendors and then installed manually, this has huge advantages, as it makes it easy to get updates for everything installed on your system with a single command. The base system and the software comes from the same hands and can be tested as a whole. This ease of upgrading is almost mind-boggling to people who are used to a Windows world, where you’d download 20 .exe installer files post-OS-install and have to update them individually, a hugely time-consuming process and at time outright dangerous as software easily gets out of date.
There are also downsides to how we handle software deployment and installation currently, most of them revolve around update cycles. There is always a middle man who decides when and what to upgrade. This results in applications getting out of date, which is bad in reality and leads to a number of problems, as security and bug fixes are not making it to users in a timely fashion,
- It’s not unusual that software installed on a “supported” Linux system is outdated and not at all supported upstream anymore on the day it reaches the user. Worse, policies employed by distributions (or more generally, operating system vendors) will prevent some software packages from ever getting an update other than the most critical security fix within the whole support cycle.
- Software out in the wild with its problems isn’t supported upstream, bug reports reaching the upstream developers are often invalid and have been fixed in newer versions, or users are asked to test the latest version, which most of the time isn’t available for their OS — this makes it harder to address problems with the software and it’s frustrating for both, users and developers.
- Even if bugs are fixed in a timely fashion, the likelihood of users of traditional distributions actually receiving these updates without manually installing them is small, especially if users are not aware of it.
- Packaging software for a variety of different distributions is a huge waste of time. While this can be automated to some extent, it’s still less than ideal as work is duplicated, packaging bugs do happen simply because distribution packagers do not fully understand how a specific piece of software is built and best deployed (there’s a wide variety of software after all) and software stacks aren’t often well-aligned. (More on that later!)
- Support cycles differ, leading to two problems:
- Distros need to guarantee support for software they didn’t produce
- Developers are not sure how much value there is in shipping a release and subsequent bugfix releases, since it takes usually at least months until many users upgrade their OS and receive the new version.
- Related to that, it can take a long time until a user confirms a bug fix.
- There is only a small number of distributions who can package every single piece of useful software available. This essentially limits the user’s choice because his niche distro of choice may simply not have all needed software available.
The value of downstreams
One argument that has been made is that downstreams do important work, too. An example for that legal or licensing problems are often found during reviews at SUSE, one of KDE’s downstream partners. These are often fed back to KDE’s developers where the problems can be fixed and be made part of upstream. This doesn’t have to change at all, in fact, with a quicker deployment process, we’re actually able to ship these fixes quicker to users. Likewise, QA that currently happens downstream should actually shift more to upstream so fixes get integrated and deployed quicker.
One big problem that we are currently facing is the variety of software stacks our downstreams use. An example that often bites us is that Linux distributions are combining applications with different versions of Qt. This is not only problematic on desktop form-factors, but has been a significant problem on mobile as well. Running an application against the same version of Qt that developers developed or tested it against means fewer bugs due to a smaller matrix of software stacks, resulting in less user-visible bugs.
In short: We’d be better off if work happening downstream happens more upstream, anyway.
Upstream as software distributor
So, what’s the idea? Let me explain what I have in mind. This is a bit of a radical idea, but given my above train of thoughts, it may well solve a whole range of problems that I’ve explained.
Linux distributors supply a base system, but most of the UI layers, so the user-visible parts come from downstream KDE (or other vendors, but let’s assume KDE for now). The user gets to run a stable base that boots a system that supports all his hardware and gets updated according to the user’s flavor, but the apps and relevant libraries come from upstream KDE, are maintained, tested and deployed from there. For many of the applications, the middle-man is cut out.
This leads to
- vastly reduced packaging efforts of distros as apps are only packaged once, not once per distro.
- much, much shorter delays until a bug fix reaches the user
- stacks that are carefully put together by those that know the apps’ requirements best
Granted, for a large part of the user’s system that stays relatively static, the current way of using packaged software works just fine. What I’m talking about are the bits and pieces that the users relies on for her productivity, the apps that are fast moving, where fixes are more critical to the user’s productivity, or simply where the user wants to stay more up to date.
Containerization allows systemic improvements
In practice, this can be done by making containerized applications more easily available to the users. Discover, Plasma’s software center, can allow the user to install software directly supplied by KDE and allow to keep it up to date. Users can pick where to get software from, but distros can make smart choices for users as well. Leaner distros could even entirely rely on KDE (or other upstreams) shipping applications and fully concentrate on the base system and advancing that part.
Luckily, containerization technologies now allow us to rethink how we supply users with our software and provide opportunities to let native apps on Linux systems catch up with much shorter deployment cycles and less variety in the stack, resulting in higher quality software on our users’ systems.