This is 2021: what’s coming in free/libre software (Libre Arts)

[Development] Posted Jan 21, 2021 21:16 UTC (Thu) by corbet

Libre Arts (formerly Libre Graphics World) has posted a comprehensive survey of what 2021 might hold for a wide range of free content-creation software.

The topic of fullscreen color management implementation in Wayland is back, and it’s a kinda frustrating story. In a nutshell:

  • people who are now working on this (Collabora developers) seem to have little experience with color management but they appear to be motivated to hack on the code;
  • all the while people who have a crapload of experience with color management have had bad experience discussing this before, do not like the approach by the new team, and don’t seem excited to contribute to this new effort (Graeme’s spec proposal is still available).

So we might end up with an implementation that is not suitable for professional work.

Comments (none posted)

Corellium: How we ported Linux to the M1

[Kernel] Posted Jan 21, 2021 18:37 UTC (Thu) by corbet

The Corellium blog is carrying a description of how the Linux port to the Apple M1 processor was done. “Many components of the M1 are shared with Apple mobile SoCs, which gave us a good running start. But when writing Linux drivers, it became very apparent how non-standard Apple SoCs really are. Our virtual environment is extremely flexible in terms of models it can accommodate; but on the Linux side, the 64-bit ARM world has largely settled on a well-defined set of building blocks and firmware interfaces – nearly none of which were used on the M1.

Comments (none posted)

[$] Installing Debian on modern hardware

It is an unfortunate fact of life that non-free firmware blobs are required
to use some hardware, such as network devices (WiFi in particular), audio
peripherals, and video cards. Beyond that, those blobs may even be
required in order to install a Linux distribution, so an installation over
the network may need to get non-free firmware directly from the installation
media. That, as might be guessed, is a bit of a problem for distributions
that are not willing to officially ship said firmware because of its
non-free status, as a recent discussion in the Debian community shows.

The Debian tech committee allows Kubernetes vendoring

[Distributions] Posted Jan 20, 2021 21:24 UTC (Wed) by corbet

Back in October, LWN looked at a conversation within the Debian project regarding whether it was permissible to ship Kubernetes bundled with some 200 dependencies. The Debian technical committee has finally come to a conclusion on this matter: this bundling is acceptable and the maintainer will not be required to make changes:

Our consensus is that Kubernetes ought to be considered special in the same way that Firefox is considered special — we treat the package differently from most other source packages because (i) it is very large and complex, and (ii) upstream has significantly more resources to keep all those moving parts up-to-date than Debian does.

In the end, allowing this vendoring seemed like the only feasible way to package Kubernetes for Debian.

Comments (none posted)

Banon: License changes to Elasticsearch and Kibana

[Development] Posted Jan 20, 2021 19:27 UTC (Wed) by ris

Shay Banon first announced that Elastic would move its Apache 2.0-licensed source code in Elasticsearch and Kibana to be dual licensed under Server Side Public License (SSPL) and the Elastic License. “To be clear, our distributions starting with 7.11 will be provided only under the Elastic License, which does not have any copyleft aspects. If you are building Elasticsearch and/or Kibana from source, you may choose between SSPL and the Elastic License to govern your use of the source code.

In another post Banon added some clarification. “SSPL, a copyleft license based on GPL, aims to provide many of the freedoms of open source, though it is not an OSI approved license and is not considered open source.

There is also this article on why the change was made. “So why the change? AWS and Amazon Elasticsearch Service. They have been doing things that we think are just NOT OK since 2015 and it has only gotten worse. If we don’t stand up to them now, as a successful company and leader in the market, who will?

The FAQ has additional information. “While we have chosen to avoid confusion by not using the term open source to refer to these products, we will continue to use the word “Open” and “Free and Open.” These are simple ways to describe the fact that the product is free to use, the source code is available, and also applies to our open and collaborative engagement model in GitHub. We remain committed to the principles of open source – transparency, collaboration, and community.

Comments (none posted)

Red Hat expands no-cost RHEL options

[Distributions] Posted Jan 20, 2021 15:28 UTC (Wed) by corbet

Red Hat has announced a new set of options meant to attract current CentOS users who are unhappy with the shift to CentOS Stream. “While CentOS Linux provided a no-cost Linux distribution, no-cost RHEL also exists today through the Red Hat Developer program. The program’s terms formerly limited its use to single-machine developers. We recognized this was a challenging limitation. We’re addressing this by expanding the terms of the Red Hat Developer program so that the Individual Developer subscription for RHEL can be used in production for up to 16 systems. That’s exactly what it sounds like: for small production use cases, this is no-cost, self-supported RHEL.

Comments (none posted)