Language Selection

English French German Italian Portuguese Spanish

The Road Towards KF6 & SPDX License Identifiers

Filed under

With KF6, I want to see SPDX license identifiers being introduced into KDE frameworks in order to ease the framework re-use in other projects. This follows the same approach e.g. the Linux Kernel took over the last years.

The problem that the SPDX markers address is the following: When publishing source code under an open source license, each source code file shall explicitly state the license it is released with. The usual way this is done is that a developer copies a license header text from the KDE licensing policies wiki, from another source file, or from somewhere else from the internet and puts it at the top of their newly created source code file. Thus the result is that today we have many slightly different license headers all over our frameworks source files (even if they only differ in formatting). Yet, these small differences make it very hard to introduce automatic checks for the source code licenses in terms of static analysis. This problem becomes even more urgent when one wants to check that a library, which consists of several source files with different licenses, does only contain compatible licenses.

The SPDX headers solve this problem by introducing a standardized language that annotates every source code file with license information in the SPDX syntax. This syntax is rich enough to express all of our existing license information and it can also cover more complicated cases like e.g. dual-licensed source files.

Read more

More in Tux Machines

Screencasts/Audiocasts: Zorin OS 15.1 Run Through, Linux Action News and Open Source Security Podcast

XFS - 2019 Development Retrospective

We frequently hear two complaints lodged against XFS -- memory reclamation runs very slowly because XFS inode reclamation sometimes has to flush dirty inodes to disk; and deletions are slow because we charge all costs of freeing all the file's resources to the process deleting files. Dave Chinner and I have been collaborating this year and last on making those problems go away. Dave has been working on replacing the current inode memory reclaim code with a simpler LRU list and reorganizing the dirty inode flushing code so that inodes aren't handed to memory reclaim until the metadata log has finished flushing the inodes to disk. This should eliminate the complaints that slow IO gets in the way of reclaiming memory in other parts of the system. Meanwhile, I have been working on the deletion side of the equation by adding new states to the inode lifecycle. When a file is deleted, we can tag it as needing to have its resources freed, and move on. A background thread can free all those resources in bulk. Even better, on systems with a lot of IOPs available, these bulk frees can be done on a per-AG basis with multiple threads. Read more Also: Oracle Talks Up Recent Features For XFS + Some File-System Improvements On The Horizon

Review: OpenIndiana 2019.10 Hipster

For me, the conclusion after battling with OpenIndiana for a few weeks is quite simple: the operating system's aim is to "ensure the continued availability of an openly developed distribution based on OpenSolaris" and it clearly achieves that goal. However, it does very little beyond that modest aim, and the lack of documentation makes it difficult to use OpenIndiana for people unfamiliar with OpenSolaris and/or Solaris. My advice for Linux users like me is to take plenty of time to get familiar with the operating system. At times I found using OpenIndiana hugely frustrating but that was largely because things weren't working as I expected. I am fairly confident that I would have solved most of the issues I encountered if I had spent more time with OpenIndiana. Some issues may be show-stoppers, including OpenIndiana's struggle with connecting to wireless networks and the limited amount of applications that are available. Many of these issues can be solved though. One of the main struggles I faced was finding documentation. The best place to look for information appears to be Oracle's Solaris documentation. Unfortunately, OpenIndiana's Hipster Handbook is not much use. It is mostly populated with content placeholders and the section on web servers counts exactly two words: "Apache" and "nginx". Even new features, such as the "native and metadata encryption" for ZFS and an option to disable hyper-treading are not mentioned in the handbook. At times OpenIndiana felt like an operating system that belongs in a museum. The set-up is quite old-school, the theme looks very dated and everything felt sluggish; the system is slow to boot and launching applications always took just a little too long for my liking. OpenIndiana's stand-out features are also nothing new - they are what made OpenSolaris a powerful operating system a decade years ago. Yet, in the Linux world there aren't many distros - if any - that have something like the Time Slider. openSUSE comes close but, in my humble opinion, OpenIndiana's Time Slider is more advanced and easier to use than OpenSUSE's Snapper. I am hoping Linux will catch up when it comes to OpenIndiana's ZFS goodness. Ubuntu is working on integrating ZFS, and I for one hope that in time there will be a Time Slider in file managers such as GNOME Files and Dolphin. Read more

OpenWiFi Open-Source Linux-compatible WiFi Stack Runs on FPGA Hardware

WiFi is omnipresent on most connected hardware, and when it works it’s great, but when there are issues oftentimes they can not be solved because the firmware is a closed-source binary. Read more