After a lot of work, we moved our website to a new Hugo based platform! A lot of time and energy went into making this new version. There were a number of reasons and issues that we moved the site.
Translations - The previous website had a very messy translation process. There was so much manual work creating logins for translators, and uploading files to the web server every time new languages were added. With the new system, translation is built through our KDE translation pipeline. This is the same pipeline that is used for translating the application. This greatly simplifies the experience for both our web master and translation team.
Site maintenance - While many updates could previously be done via the CMS, there were a lot of portions that needed special access to the web server files. This made doing updates like releases a coordination between a lot of people to make sure all the pieces in place.
Simplify site building and publishing - The new site is only using static files in the end. In the previous CMS, pages were dynamically generated from a database. There were many complicated layers of caching that were needed to make the site responsive and load fast. This created a number of instances where the entire krita.org went down because of some caching snafu.
Qt for MCUs 2.6.1 has been released and is available for download.As a patch release, Qt for MCUs 2.6.1 provides bug fixes and other improvements, and maintains source compatibility with Qt for MCUs 2.6.x. It does not add any new functionality.
Last weekend I attended FOSDEM as part of KDE’s presence there, gave a talk about
semantic data extraction of travel-related emails,
met old long-time friends, had many interesting discussions and the occasional waffle.
One topic however got slightly out of hand and ended up consuming most of my time.
Open Public Transport Routing
For road-based routing a few FOSS and Open Data services exist, OSM has some integrated on their
website for example. We don’t have something like this for public transport though.
There we are stuck with proprietary services, run mostly by transport operators themselves
or by companies like Google. Those have a number of issues:
Borders. Transport operators tend to only cover the area they are serving, be it a municipality, a region or a country.
Competition. Transport operators have no interested in showing services offered by their competitors.
Access. Most of those services are meant for the corresponding websites or apps of the operators, access
for 3rd parties (and even more so non-paying FOSS 3rd parties) is often restricted one way or the other.
Privacy and data protection. Google is involved.
While much of this is understandable from an operator perspective, it’s not really satisfying from a user perspective.
Therefore demand for an independently-run fully open public transport routing service has been building up since quite some time.
Roughly this would need three non-trivial ingredients:
A FOSS routing engine.
Freely available schedule data as well as realtime position/delay/disruption data.
Someone to run that as a service.
So for context and dramatic effect here’s how things developed in chronological order.
With GTFS, NeTEx,
standards for exchanging schedule and realtime data exist.
Regulation mandating operators to publish such data also exists in several regions of the world (including the EU),
compliance with that still has room for improvement though (especially in the EU).
Deployments for those also exist. OTP is used nation-wide in Finland and Norway,
by a few municipalities in Germany (stadtnavi, bbnavi)
and by community-run projects in the cities of Münster and Ulm. Being run not by transport operators, those show what becomes possible
when your goal isn’t to sell your services but to help people to find the best way to get from A to B.
The Navitia team also runs an instance covering many areas all over the world. Routing between different coverage areas isn’t
supported, but it’s often the only way to get any coverage at all, in particular outside of Europe. Many of the FOSS
transport apps rely on this.
None of the FOSS engines scales well enough yet to be able to route across all of Europe though.
Navitia drops many coverage areas from their free service and SNCB discontinues their Hafas API,
leaving the FOSS transport apps with several large gaps in the regions they can serve.
MOTIS is meanwhile said to have achieved acceptable performance for routing on an European-scale dataset
on realistic hardware.
The year ends with various discussions on that topic at 37C3
showing a growing demand for a proper alternative, while at the same time technical blockers crumble.
February 3rd 14:00
It’s the first morning at FOSDEM.
Mikolai Gütschow from Transportr presents in the Railway and Open Transport devroom, and towards the end of his talk suggests to create an open public transport routing service
among the various parties in the growing FLOSS public transport ecosystem.
February 3rd 15:30
Following Mikolai’s talk a few interested people meet in the hallway discussing this subject.
There is a sense of actually starting to look into possibly working towards implementing this eventually,
gathering people that had shown interest in this, determining what would be needed in terms of infrastructure
and approaching organizations that might potentially able and interested in hosting this.
And then things escalated a bit.
February 3rd 17:00
Approaching the end of day 1 of FOSDEM, a powerful server had been found. Retired from previously doing simulations
in an university physics lab it comes with plenty of memory (which is important for this), and is hosted and
available for free.
Moreover, Jonah had already been looking into setting up MOTIS on it and was getting the
February 4th 11:00
The people interested in this (more by now) meet again in the hallway, to catch up on what had changed meanwhile
and to discuss how to continue. Two topics are in focus in particular:
Project setup, infrastructure and communication channels to work together.
Designing a setup that allows for easy crowd-sourcing of the GTFS feed maintenance.
The last point is probably where most of the work has to be spend overall. FOSS routing engines exist,
but they depend on correct input data, and that data is spread out into hundreds if not thousands of separate
feeds of varying quality.
Keeping on top of each single one of those will likely involve manual work to some extend, and that is best
done by someone local, understanding the local language and able to judge the correctness and completeness of
the data. In some cases it might also involve working with the local public transport operator to resolve issues
and/or to remind them of regulation requiring the publication of this data.
Luckily there is also quite some prior work around GTFS quality assurance and processing tools available
which this can be built on top of.
While walking across FOSDEM to another unrelated meeting we get offered more servers to host this on.
Just normal FOSDEM things.
February 4th 22:00
From on board of trains home the first code lands and the first merge requests are opened.
February 5th 07:30
People not having been at FOSDEM have gotten word of this and want to join.
February 5th and onwards
There is a continuous stream of work going on, including discussing GTFS feed metadata formats,
identifying and fixing API issues in MOTIS, server setup and implementing MOTIS client support
Initial experiments also show that further work in clients is needed to deal with the much larger
variety of operators in the results, some of which might not be usable with an already existing
ticket for example.
This is and remains an enormous task and there’s no guarantee of success. But if only a fraction of the momentum from the past weekend remains
over the next weeks and months this might actually work out.
If you are interested in collaborating on this, join the #opentransport Matrix channel
and the Transitous Github project!
The KDE 6 mega-release is due in a little under three weeks! And folks have remained in diligent bugfixing-and-polishing mode, because we want this release to be as smooth and drama-free as possible! If you haven’t already tried it out, this is a good time to. Find all the bugs that are bugging you so we can hopefully fix them before the final release!
KDE 6 Mega-Release
(Includes all software to be released on the February 28th mega-release: Plasma 6, Frameworks 6, and apps from Gear 24.02)
KWin’s “Active screen follows mouse” setting is now gone; now the active screen is always the one with the cursor on it, or the last one that was tapped with a touchscreen. This turns out to be much simpler and it’s what we think most people wanted anyway, hopefully alleviating complaints about OSDs and new windows opening on unexpected screens (Vlad Zahorodnii, link)
You can now set the data range manually for “horizontal bars” charts in System Monitor and its widgets (Arjen Hiemstra, link)
When you use the System Tray’s “Always show all entries” option, now it actually does always show all entries, instead of sneakily keeping some of them hidden anyway according to some internal logic which was not obvious (Jin Liu, link)
Searching through clipboard entries is now case-insensitive (Yifan Zhu, link)
Important note: I don’t mention fixes for bugs that were never released to users; it’s just too much for me (it would probably be too much for you to read as well), and most people never encountered them in the first place. Because we’re in the middle of a big Plasma dev cycle, there are a lot of these bugs! So big thanks to everyone who’s made it a priority to fix them!
Fixed an issue affecting the Plasma X11 session that could cause the screen to end up black with only a movable cursor when you wake your system from sleep while using an NVIDIA GPU with its proprietary drivers (David Redondo, link)
CPU temperature sensors now work for a variety of Intel and AMD motherboards where they didn’t previously work (Arjen Hiemstra, link 1 and link 2)
When System Monitor’s window opens in maximized state, de-maximizing it now returns it to its pre-maximized geometry as expected (Arjen Hiemstra, link)
In various Kirigami-based apps, double-clicking on a page to open it multiple times is no longer interpreted that way–because opening the same page multiple times makes no sense–which avoids accidentally breaking the app (Arjen Hiemstra, link)
KScreen is now smarter about choosing better-matching screen settings when told to make one screen mirror another (Yifan Zhu, link)
Buttons and scrollbars in the Sticky Notes widget are now always distinguishable no matter what color you choose for the background of the note and no matter what your system color scheme is (me: Nate Graham, link)
A couple of Plasma UI elements with text on them that weren’t previously translatable now are (Emil Sari, link)
When your Task Manager is set up to only show tasks from the current screen, now this still keeps working when you switch around your screen arrangement without restarting Plasma (Someone awesome, link)
Header text in System Tray applets now elides instead of overflowing with a small window size and very long applet text (me: Nate Graham, link)
When you hit the Alt+Tab shortcut with no windows open, you’ll now see a nice “No open windows” message instead of a broken-looking task switcher or even nothing (Vlad Zahorodnii, Plasma 6.1. Link)
The ancient feature to add a spacer in your window titlebars returns! (Vlad Zahorodnii, Plasma 6.1, link)
Automation & Systematization
Added an autotest to make sure that loading Digital Clock plugins still works (Fushan Wen, link)
…And Everything Else
This blog only covers the tip of the iceberg! If you’re hungry for more, check out https://planet.kde.org, where you can find more news from other KDE contributors.
How You Can Help
Thanks to you, our Plasma 6 fundraiser has been a crazy success! I originally thought the goal of 500 new KDE e.V. supporting members was over-optimistic, but you’ve all proven me happily wrong. We’re now up to an amazing 800 members, blown past our stretch goals, and 1000 members by launch time seems like it might even be feasible. Thank you everyone for the confidence you’ve shown in us; we’ll try not to screw it up! For those who haven’t donated to become members yet, spreading the wealth via this fundraiser is a great way to share the love.
If you’re a developer, work on Qt6/KF6/Plasma 6 issues! Which issues? These issues. Plasma 6 is very close to a release and in a good state, but could still benefit from some final bug-fixing and polishing. And as I mentioned before, if you haven’t tried it out yet, please do!
Otherwise, visit https://community.kde.org/Get_Involved to discover other ways to be part of a project that really matters. Each contributor makes a huge difference in KDE; you are not a number or a cog in a machine! You don’t have to already be a programmer, either. I wasn’t when I got started. Try it, you’ll like it! We don’t bite!
KDE today announces the release of KDE Frameworks 5.115.0.
KDE Frameworks are 83 addon libraries to Qt which provide a wide variety of commonly needed functionality in mature, peer reviewed and well tested libraries with friendly licensing terms. For an introduction see the KDE Frameworks release announcement.
This release is part of a series of planned monthly releases making improvements available to developers in a quick and predictable manner.
New in this version
Update Google icon (bug 462165)
Extra CMake Modules
ECMUninstallTarget: port generated code away from deprecated exec_program
src/incidence.cpp - fix infinite looping
Add isProcExists func to check if /proc exists
Determine UNIX process if "/proc" does not exist
Show GridDelegate labels as plaintext (bug 480106)
holiday_ie_en-gb - Add St Brigid's Day (bug 479832)
CI: Don't require Windows test to pass
KDirModel: Consider invalid roots are local fs (bug 477039)
slavebase: abort mimetype emission when the worker was terminated (bug 474909)
KDirModel: Allow expanding network directories in file picker again (bug 479531)
KCoreDirLister: updateDirectory: update parent folder if it is listed (bug 440712)
copyjob: Fix implicitly skipping files when copying (bug 479082)
Add parent widget for diff dialogs
Emit the walletCreated signal in the KWalletD::pamOpen function if a new wallet is created during its call
Enable exceptions for videoscannerworker.cpp
The released code has been GPG-signed using the following key:
pub rsa2048/58D0EE648A48B3BB 2016-09-05 David Faure firstname.lastname@example.org
Primary key fingerprint: 53E6 B47B 45CE A3E0 D5B7 4577 58D0 EE64 8A48 B3BB
Netflix: Piracy is Difficult to Compete Against and Growing Rapidly * TorrentFreak
Tags: tech, streaming, video, business
Unsurprising trend… this was a market where there was no chance to have a single dominant platform due to the existing studio behemoths. So now we’re in the streaming wars, people can’t afford to pay for every silos… and they turn to piracy again. Could have been all avoided if we went the “global license” route instead of dumping money on platforms.
Rust Won’t Save Us: An Analysis of 2023’s Known Exploited Vulnerabilities – Horizon3.ai
Tags: tech, security, memory, rust
Indeed, not all security issues are due to memory related problems. It’s 20% of the security issues. This is of course massive, but there’s still 80% of the security issues coming from wrong authentication, appliances and so on.
A tad over two years ago, I revealed the 15-Minute Bug Initiative–an attempt to improve the out-of-the box user experience for Plasma by focusing on fixing obvious papercut issues. The idea was to crush the meme of “KDE is buggy” the same way we systematically addressed similar complaints like “KDE is ugly” and “KDE is bloated” in years past.
Well, it’s been two years, so how did it go? Let’s talk about it! First some numbers, because we like numbers:
Total number of bugs fixed (because more were added over time): 231
Percent of all total 15-minute bugs that have been fixed: 87.8%
(note if you’re from the future: if you visit those links, some numbers may be different–hopefully lower for the second one and higher for the third one!)
Wow! That’s quite a few. So this initiative looks like it’s been a real success so far! Nevertheless, 32 bug reports remain open, so we can’t declare victory yet. These are some of the stubbornest, hardest-to-fix bugs that require major re-architecting, working upstream, or similarly challenging efforts. Hopefully the pace of improvement seen over these years has managed to convince you that they’ll eventually be resolved as well.
“Wait a minute, Plasma is still buggy AF you n00b”
Keep in mind these aren’t all the bug reports in the world we can fix (there are over 5000 of them for Plasma and Plasma-aligned software alone), just the ones I and some others have deemed to be most obvious to the average user! If you’re not an average user because you have three monitors arranged in a weird shape, each plugged into a different GPU from a different vendor and its own different DPI, scale factors, and custom Plasma panels, plus 4 activities and 9 virtual desktops and 6 internal disks, only half of which automount, and 12 apps set to autostart, and each of them is installed onto different disks, 15 window rules, and finally a custom theming setup including Kvantum themes and Aurorae window decorations… then yeah, you’re probably going to experience some more bugs compared to a more typical user who doesn’t have such a complex setup!
That’s okay. We care about you too, and we do work on those kinds of more esoteric bugs because many of us also have complex setups! But progress here will be necessarily slower, because the complex setups are more varied, more unusual, and harder to debug. And let’s be honest here: those of us with setups like these are experts capable of working around most bugs we find, who really should be helping to investigate and fix them. Admit it, you know it’s true!
But in a way, this is good: it represents Plasma moving from “It’s generally buggy” to “it’s specifically buggy–buggy with only certain less common combinations of settings, rather than buggy in a way that anyone can find within 15 minutes of using a system with its default settings. Improving on that was the point of this initiative.
Up until now we’ve been ignoring Wayland-only bugs here, because the Wayland session was not the default one. Well, with Plasma 6 that changes, so all of those Wayland-only issues that meet the loose criteria to be a 15-minute bug will be promoted. Similarly, current 15-minute bugs that are X11-only will be demoted. So sometime in the next few weeks, expect the list to shift around a bit.
Once the number gets down to 0, it will of course go up again periodically as new bugs are found or introduced. But this is great! It means we can whack them as they appear, rather than letting them pile up over time. In this way the list becomes a “rapid response needed” task list rather than a backlog we’re always behind on.
What happens with those development resources once the 15-minute Plasma bugs are under control? I have a plan, first articulated in the original announcement 2 years ago: extend the program to Frameworks bugs! There are quite a few candidates there too. And because frameworks bugs can affect Plasma and our vast app library, quality will go up overall.
Speaking of those apps, once the 15-minute Frameworks bugs are also down to zero or close to it, we can include app bugs. This will finally give us complete coverage! I have a dream that one day, we’ll have a stable and mostly bug-free UI layer and our limited development resources can be focused more on performance work, sustainably-crafted new features, usability, more standardized styling, etc. I think it’s doubtful we can get there while we’re still battling routine bugs all the time.
How you can help
As always, help work on the existing 15-minute bugs if you can! If not, it’s always useful to work on bug triaging, so that more of those issues that will eventually become 15-minute bugs can get discovered. Another impactful way is to donate to KDE e.V., the nonprofit that support KDE on a ridiculously small budget. We’re still running the Plasma 6 fundraiser which represents a great way to donate!