Language Selection

English French German Italian Portuguese Spanish

A better Qt because of Open Source and KDE

Filed under
Development
KDE

The development framework Qt is available both as Open Source and under paid license terms. Two decades ago, when Qt 2.0 was first released as Open Source, this was exceptional. Today, most popular developing frameworks are Free/Open Source Software1. Without the dual licensing approach, Qt would not exist today as a popular high-quality framework.

There is another aspect of Qt licensing which is still very exceptional today, and which is not as well-known as it ought to be. The Open Source availability of Qt is legally protected through the by-laws and contracts of a foundation.

The KDE Free Qt Foundation was created in 1998 and guarantees the continued availability of Qt as Free/Open Source Software2. When it was set up, Qt was developed by Trolltech, its original company. The foundation supported Qt through the transitions first to Nokia and then to Digia and to The Qt Company.

In case The Qt Company would ever attempt to close down Open Source Qt, the foundation is entitled to publish Qt under the BSD license. This notable legal guarantee strengthens Qt. It creates trust among developers, contributors and customers.

The KDE Free Qt Foundation is a cooperation between The Qt Company on the one hand and KDE on the other hand. KDE is one of the largest Free Software communities for general purpose end-user software, founded in 1996. In case of ties, KDE has an extra vote, ensuring that The Qt Company does not have a veto on decisions.

My in-depth presentation below provides an overview of the history of the Foundation and describes its importance for Qt today. It explains in detail why the existence of the Foundation has a positive influence on the long-term market success of Qt.

Read more

More in Tux Machines

CERN adopts Mattermost, an open source messaging app

The European Organization for Nuclear Research (CERN) has decided to discontinue the use of the Facebook collaboration app Workplace, instead opting to replace it with Mattermost, an open source messaging app. CERN switched to open source software after changes to Facebook’s solution subscription prices and possible changes in the data security settings. Read more

Programming/Development: PHP 8.0, WASMtime 0.12, Perl, Python, and java

  • Looking At The PHP 8.0 Performance So Far In Early 2020

    With it being a while now since the PHP 7.4 release and the PHP developers continuing to be busy at work on PHP 8.0 as the next major installment of the popular web programming language, here is a fresh look at the performance of PHP 8.0 in its current state -- including when its JIT compiler is enabled -- compared to releases going back to PHP 5.6. Most exciting with PHP 8.0 is the JIT compiler that has the ability to provide better performance on top of all the gains already scored during PHP 7.x releases. PHP 8.0 is also bringing support for static return types, weak maps, union types, improved errors and warnings, and more is surely to come -- stay tuned to the PHP RFC page. The latest indications are PHP 8.0 isn't expected for release until the very end of 2020 or early 2021.

  • WASMtime 0.12 Released For The JIT-Style WebAssembly Runtime

    Announced last November was the Bytecode Alliance with a goal of running WebAssembly everywhere. This effort by Intel, Red Hat, Mozilla, and others has resulted in a new release today of wasmtime, their JIT-style runtime for WebAssembly on the desktop. The Bytecode Alliance developers from the different organizations continue working heavily on their Wasmtime JIT runtime, Cranelift low-level code generator, the WAMR micro-runtime, and Lucet sandboxing WebAssembly compiler. Wasmtime v0.12 is the new release out today for their optimizing run-time offering for WebAssembly and WASI (WebAssembly System Interface) on desktops and other non-browser use-cases.

  • The Weekly Challenge #049

    This is my second blog for The Weekly Challenge. I am only able to participate, thanks to Ryan Thompson for helping me with the Perl and Raku reviews. I am going for Perl solutions first then will try to translate it into Raku next. I believe in coding to learn the language. With so many Raku experts around, I am not shy throwing questions up. I am now going to share my experience doing “The Weekly Challenge - 049”.

  • EuroPython 2020: Call for Proposals opens on March 9th

    We’re looking for proposals on every aspect of Python: all levels of programming from novice to advanced, applications, frameworks, data science, Python projects, internals or topics which you’re excited about, your experiences with Python and its ecosystem, creative or artistic things you’ve done with Python, to name a few. EuroPython is a community conference and we are eager to hear about your use of Python. Since feedback shows that our audience is very interested in advanced topics, we’d appreciate more entries in this category for EuroPython 2020. Please help spread word about Call for Proposals to anyone who might be interested. Thanks.

  • Using Anaconda Environments with Wing Python IDE

    Wing version 7.2 has been released, and we've been looking at the new features in this version. So far we've covered reformatting with Black and YAPF, Wing 7.2's expanded support for virtualenv, and using python -m with Wing. This time we'll take a look at what Wing 7.2 provides for people that are using Anaconda environments created with conda create as an alternative to virtualenv.

  • Easy Provisioning Of Cloud Instances On Oracle Cloud Infrastructure With The OCI CLI

    The OCI CLI requires python version 3.5 or later, running on Mac, Windows, or Linux. Installation instructions are provided on the OCI CLI Quickstart page.

  • Python Range

    The Python range type generates a sequence of integers by defining a start and the end point of the range. It is generally used with the for loop to iterate over a sequence of numbers. range() works differently in Python 2 and 3. In Python 2, there are two functions that allow you to generate a sequence of integers, range and xrange. These functions are very similar, with the main difference being that range returns a list, and xrange returns an xrange object.

  • Code Borrowing and Licence Violations [Ed: This study may be deeply flawed because they bothered assessing no projects other than those that Microsoft controls (what about projects that don't use Git and Microsoft's proprietary trap?)]

    The researchers used the Public Git Archive (PGA), a large dataset that was composed in the early 2018. It consists of all GitHub projects with 50 or more stars which can be filtered by language. They extract all projects with at least one line written in Java which resulted in 24,810 projects overall and a final dataset of 23,378 Java repositories.

  • Painless Java with BlueJ

    Whenever you're learning a new programming language, it's easy to criticize all the boilerplate text you need to memorize. Before you can get comfortable starting a project, you have to remember the preambles that, in theory, ought to be easy to remember since they're usually relatively short and repetitive. In practice, though, boilerplate text is too obscure in meaning to become an easy habit, but it's essential for a program to run.

GNU: GDB (Debugger), Project's History, and GCC (Compiler)

  • GDB Debugger Adds Support For Debuginfod Web Server

    Debuginfod is the Red Hat led debug information HTTP web server distributed as part of elfutils and able to supply on-demand source code and ELF/DWARF debug files to debuggers / IDEs / other compiler tooling. The GDB debugger can now tap debuginfod for on-demand source files and debug information that isn't present on the local system. The motivation with debuginfod is to carry less developer "baggage" on local systems when it comes to debug files and potentially even source files. Particularly for organizations or cases like Linux distributions, a centralized debuginfod server could in turn supply the needed files to clients based upon the requested build ID. Red Hat has been working to expand the debuginfod support both for the GNU toolchain and also LLVM, among other possible users.

  • When is GOTS not in the national interest?

    The modern open-source software (OSS) movement can be traced back to the early 1980s with the birth of Richard Stallman’s GNU Project and the Free Software Foundation. [...] However, cost is a red herring for the real challenge presented by GOTS software solutions. On the surface, GOTS seems very similar to OSS which implies that it has the larger structural advantages of OSS. If handled cautiously, it can have those advantages, but care needs to be taken about what sort of existing software is being commoditized. The U.S. has a national interest in maintaining a strong software development capability. We are fortunate to be the dominant software-building country in the world. According to the Forbes 2000 list, the total market capitalization of U.S. internet, software, and computer services companies is close to $4.7 trillion — more than twice the rest of the world combined. Software tech is an enormous comparative advantage for the U.S. As a result, it is clearly in the national interest to have the government avoid directly competing against and potentially weakening the U.S. private sector.

  • New compiler added to popular studio for ARM and Cortex-M IDE

    The studio for ARM/Cortex-M is now supplied with three different compilers: GCC, Clang and the company's own compiler. The new compiler outperforms GCC and regular Clang on most benchmarks, decreasing both size of generated code as well as its execution speed.

Kernel: LWN and Phoronix Articles About Latest Discussions and Linux Developments

  • Filesystem UID mapping for user namespaces: yet another shiftfs

    The idea of an ID-shifting virtual filesystem that would remap user and group IDs before passing requests through to an underlying real filesystem has been around for a few years but has never made it into the mainline. Implementations have taken the form of shiftfs and shifting bind mounts. Now there is yet another approach to the problem under consideration; this one involves a theoretically simpler approach that makes almost no changes to the kernel's filesystem layer at all. ID-shifting filesystems are meant to be used with user namespaces, which have a number of interesting characteristics; one of those is that there is a mapping between user IDs within the namespace and those outside of it. Normally this mapping is set up so that processes can run as root within the namespace without giving them root access on the system as a whole. A user namespace could be configured so that ID zero inside maps to ID 10000 outside, for example; ranges of IDs can be set up in this way, so that ID 20 inside would be 10020 outside. User namespaces thus perform a type of ID shifting now. In systems where user namespaces are in use, it is common to set them up to use non-overlapping ranges of IDs as a way of providing isolation between containers. But often complete isolation is not desired. James Bottomley's motivation for creating shiftfs was to allow processes within a user namespace to have root access to a specific filesystem. With the current patch set, instead, author Christian Brauner describes a use case where multiple containers have access to a shared filesystem and need to be able to access that filesystem with the same user and group IDs. Either way, the point is to be able to set up a mapping for user and group IDs that differs from the mapping established in the namespace itself.

  • Keeping secrets in memfd areas

    Back in November 2019, Mike Rapoport made the case that there is too much address-space sharing in Linux systems. This sharing can be convenient and good for performance, but in an era of advanced attacks and hardware vulnerabilities it also facilitates security problems. At that time, he proposed a number of possible changes in general terms; he has now come back with a patch implementing a couple of address-space isolation options for the memfd mechanism. This work demonstrates the sort of features we may be seeing, but some of the hard work has been left for the future. Sharing of address spaces comes about in a number of ways. Linux has traditionally mapped the kernel's address space into every user-space process; doing so improves performance in a number of ways. This sharing was thought to be secure for years, since the mapping doesn't allow user space to actually access that memory. The Meltdown and Spectre hardware bugs, though, rendered this sharing insecure; thus kernel page-table isolation was merged to break that sharing. Another form of sharing takes place in the processor's memory caches; once again, hardware vulnerabilities can expose data cached in this shared area. Then there is the matter of the kernel's direct map: a large mapping (in kernel space) that contains all of physical memory. This mapping makes life easy for the kernel, but it also means that all user-space memory is shared with the kernel. In other words, an attacker with even a limited ability to run code in the kernel context may have easy access to all memory in the system. Once again, in an era of speculative-execution bugs, that is not necessarily a good thing.

  • Revisiting stable-kernel regressions

    Stable-kernel updates are, unsurprisingly, supposed to be stable; that is why the first of the rules for stable-kernel patches requires them to be "obviously correct and tested". Even so, for nearly as long as the kernel community has been producing stable update releases, said community has also been complaining about regressions that make their way into those releases. Back in 2016, LWN did some analysis that showed the presence of regressions in stable releases, though at a rate that many saw as being low enough. Since then, the volume of patches showing up in stable releases has grown considerably, so perhaps the time has come to see what the situation with regressions is with current stable kernels. As an example of the number of patches going into the stable kernel updates, consider that, as of 4.9.213, 15,648 patches have been added to the original 4.9 release — that is an entire development cycle worth of patches added to a "stable" kernel. Reviewing all of those to see whether each contains a regression is not practical, even for the maintainers of the stable updates. But there is an automated way to get a sense for how many of those stable-update patches bring regressions with them. The convention in the kernel community is to add a Fixes tag to any patch fixing a bug introduced by another patch; that tag includes the commit ID for the original, buggy patch. Since stable kernel releases are supposed to be limited to fixes, one would expect that almost every patch would carry such a tag. In the real world, about 40-60% of the commits to a stable series carry Fixes tags; the proportion appears to be increasing over time as the discipline of adding those tags improves.

  • Finer-grained kernel address-space layout randomization

    The idea behind kernel address-space layout randomization (KASLR) is to make it harder for attackers to find code and data of interest to use in their attacks by loading the kernel at a random location. But a single random offset is used for the placement of the kernel text, which presents a weakness: if the offset can be determined for anything within the kernel, the addresses of other parts of the kernel are readily calculable. A new "finer-grained" KASLR patch set seeks to remedy that weakness for the text section of the kernel by randomly reordering the functions within the kernel code at boot time.

  • Debian discusses how to handle 2038

    At this point, most of the kernel work to avoid the year-2038 apocalypse has been completed. Said apocalypse could occur when time counted in seconds since 1970 overflows a 32-bit signed value (i.e. time_t). Work in the GNU C Library (glibc) and other C libraries is well underway as well. But the "fun" is just beginning for distributions, especially those that support 32-bit architectures, as a recent Debian discussion reveals. One of the questions is: how much effort should be made to support 32-bit architectures as they fade from use and 2038 draws nearer? Steve McIntyre started the conversation with a post to the debian-devel mailing list. In it, he noted that Arnd Bergmann, who was copied on the email, had been doing a lot of the work on the kernel side of the problem, but that it is mostly a solved problem for the kernel at this point. McIntyre and Bergmann (not to mention Debian as a whole) are now interested in what is needed to update a complete Linux system, such as Debian, to work with a 64-bit time_t. McIntyre said that glibc has been working on an approach that splits the problem up based on the architecture targeted. Those that already have a 64-bit time_t will simply have a glibc that works with that ABI. Others that are transitioning from a 32-bit time_t to the new ABI will continue to use the 32-bit version by default in glibc. Applications on the latter architectures can request the 64-bit time_t support from glibc, but then they (and any other libraries they use) will only get the 64-bit versions of the ABI. One thing that glibc will not be doing is bumping its SONAME (major version, essentially); doing so would make it easier to distinguish versions with and without the 64-bit support for 32-bit architectures. The glibc developers do not consider the change to be an ABI break, because applications have to opt into the change. It would be difficult and messy for Debian to change the SONAME for glibc on its own.

  • UEFI Boot Support Published For RISC-V On Linux

    As we've been expecting to happen with the Linux EFI code being cleaned up before the introduction of a new architecture, the RISC-V patches have been posted for bringing up UEFI boot support. Western Digital's Atish Patra sent out the patch series on Tuesday for adding UEFI support for the RISC-V architecture. This initial UEFI Linux bring-up is for supporting boot time services while the UEFI runtime service support is still being worked on. This RISC-V UEFI support can work in conjunction with the U-Boot bootloader and depends upon other recent Linux kernel work around RISC-V's Supervisor Binary Interface (SBI).

  • Linux Kernel Seeing Patches For NVIDIA's Proprietary Tegra Partition Table

    As an obstacle for upstreaming some particularly older NVIDIA Tegra devices (namely those running Android) is that they have GPT entry at the wrong location or lacking at all for boot support. That missing or botched GPT support is because those older devices make use of a NVIDIA proprietary/closed-source table format. As such, support for this proprietary NVIDIA Tegra Partition Table is being worked on for the Linux kernel to provide better upstream kernel support on these consumer devices. NVIDIA Tegra devices primarily rely on a special partition table format for their internal storage while some also support traditional GPT partitions. Those devices with non-flakey GPT support can boot fine but TegraPT support is being worked on for handling the upstream Linux kernel with the other devices lacking GPT support or where it's at the wrong sector. This issue primarily plagues Tegra 2 and Tegra 3 era hardware like some Google Nexus products (e.g. Nexus 7) while fortunately newer Tegra devices properly support GPT.

  • Intel Continues Bring-Up Of New Gateway SoC Architecture On Linux, ComboPHY Driver

    Besides all the usual hardware enablement activities with the usual names by Intel's massive open-source team working on the Linux kernel, one of the more peculiar bring-ups recently has been around the "Intel Gateway SoC" with more work abound for Linux 5.7. The Intel Gateway SoC is a seemingly yet-to-be-released product for high-speed network packet processing. The Gateway SoC supports the Intel Gateway Datapath Architecture (GWDPA) and is designed for very fast and efficient network processing. Outside of Linux kernel patches we haven't seen many Intel "Gateway" references to date. Gateway appears to be (or based on) the Intel "Lightning Mountain" SoC we were first to notice and bring attention to last summer when patches began appearing for that previously unknown codename.