Neil McGovern recently published an article entitled GNOME relationship with GNU and the FSF where he described parts of an e-mail exchange from Dr. Richard Stallman as “reprehensible” and called for him stepping down from his position at the Free Software Foundation. This eventually happened.
Mr. McGovern decided to close comments on his blog entry. I respect this decision, especially because the topic is bound to attract troll commenters and an attempt to moderate the discussion might just take too much effort. I might end up doing the same. However, I disagree with Mr. McGovern’s assessment and believe it shouldn’t remain without a response. I figured out that an open letter might be the right way to respond.
I’d like to stress that I’m, unlike Mr. McGovern, not speaking for GNOME, my colleagues, fellow hackers, my employer or anyone else but myself. Don’t cancel your GNOME Foundation membership because you think either of us is wrong. Engage in civilized discussion!
On your blog you wrote:
This came after the president of the FSF made some pretty reprehensible remarks saying that the “most plausible scenario is that [one of Epstein’s underage victims] presented themselves as entirely willing” while being trafficked.
I credit you for not twisting Dr. Stallman’s words and quoting them verbatim. I very much wish this was the case for the tabloid media that covered the same issue.
Another three months have passed since NetworkManager’s 1.18, and 1.20 is now available. What follows is a quick overview of what’s new.
We’re dropping some old cruft
Yes, the line diff compared to the previous major release, NetworkManager 1.18, is negative!
The libnm-glib library, deprecated in favor of libnm since NetworkManager 1.0 release almost five years ago, was dropped. At this point it’s almost certain to have no users.
If you’re developing a program that has anything to do with network configuration, libnm is the way to go. You can also use it from other languages than C via GObject instrospection — just check out our examples.
NetworkManager needs no introduction. In fifteen years since its initial release, it has reached the status of the standard Linux network configuration daemon of choice of all major Linux distributions. What, on the other hand, may need some introduction, are the features of its 28th major release.
Ladies and gentlemen, please welcome: NetworkManager-1.16.
Guarding the Wire
Unless you’ve been living under a rock for the last year, there’s a good chance you’ve heard of WireGuard. It is a brand new secure protocol for creating IPv4 and IPv6 Virtual Private Networks. It aims to be much simpler than IPsec, a traditional protocol for the job, hoping to accelerate the adoption and maintainability of the code base.
Unlike other VPN solutions NetworkManager supports, WireGuard tunnelling will be entirely handled by the Linux kernel. This has an advantages in terms of performance, and also removes the needs of a VPN plugin. We’ve started work on supporting WireGuard tunnels as first-class citizens and once the kernel bits settle, we’ll be ready.
A brand new version of NetworkManager, a standard Linux network management daemon, is likely to reach your favourite Linux distribution soon. As usual, the new version is 100% compatible with the older releases and most users can update their systems without spending much time caring about technicalities.
Nevertheless, we’ve spent significant effort improving things under the hood, addressed many bug reports and added new features. We are especially proud of the increased community contributions to NetworkManager.
Read on to learn what awaits you in the version 1.12!
Three and a half months (and some 700+ commits) after NetworkManager 1.6, we’re pleased to announce NetworkManager 1.8 is ready. This release is generally focused on fixing bugs and addressing usability annoyances, yet it delivers some new features as well. Let’s have a look!
Reliable daemon restarts
In general, NetworkManager is not something that is restarted too frequently. But when it is, chances are it will end up looking slightly confused. In particular, a different connection profile may appear to be active on a device than before the restart.
NetworkManager 1.6 was delivered in early 2017, and is doing pretty well. It has found its way to many Linux distributions, including the upcoming Debian 9 “Stretch” release. There are good chances you’re already running it. Nevertheless, we still owe you an overview of what’s new.
My favorite parts are: MACsec, much improved libnm performance, systemd-resolved support, PacRunner integration and IPv6 connection sharing. Let’s delve into them!
When accompanied with a recent-enough wpa_supplicant (that for now means a post 2.6 git snapshot) and kernel (4.6 or newer), NetworkManager is able to create and maintain IEEE 802.1AE (better known as MACsec) links.
For those those who don’t know: MACsec is an encryption protocol that operates in the data link layer (Layer 2 in OSI model), beneath IP. MACsec comes useful when you don’t trust your physical link — such as with cloud hostings. IPsec, on the contrary, would operate on Level 3 and thus is not practical for protecting the ARP, DHCP or Neighbor Discovery traffic.
After we released version 1.0 of NetworkManager, it took us sixteen months to reach the 1.2 milestone. This means that it took over a year for some newly added features to reach the user base. Now we are releasing the next major release after just four months.
This improved release cadence was made possible by the excellent work of Red Hat’s Quality Engineering team during the development cycle. Their thorough testing gave us confidence in the new code and dramatically lowered the number of bugs late in the release cycle.
Despite a somewhat shorter release cycle the new version of NetworkManager, while still API and ABI compatible with previous versions, is by no means short on improvements. Let’s take a detailed look!
The central component of good modem support on Linux is ModemManager. The components, such as NetworkManager, that make use of modems in Linux would typically use the convenient D-Bus interface ModemManager provides.
Nevertheless, there’s more to good modem support than just ModemManager. There’s little standardization in the protocols that modems use and multiple components need to coordinate to support a wide range of hardware with all of its idiosyncrasies.
There’s more to good modem support than just ModemManager.
This article will provide a short overview of the modern Linux modem support stack and some recent changes to it. If you own a modem, we may need your help to ensure it’s well supported. Read on to find out how can you help!
The NetworkManager team just released NetworkManager 1.2, and it is the biggest update in over a year. With almost 3500 commits since the previous major release (1.0), this release delivers many new key features:
It’s quite some time since we’ve done an update to the 1.0.x version. As it matures, we’re busy getting the 1.2.x tree ready for release. Nevertheless, fixes waiting to be delivered have accumulated over the time, so we’re releasing them now.
The new version fixes a number of issues, such as
a crash in Wi-Fi management that has been bothering users according to the volume of ABRT bug reports,
ordering of the NetworkManager.service in systemd-managed distributions
a low severity race condition that could cause a leak of connection secrets (Wi-Fi password) to a local authenticated user
bad behavior when another tool created a Wi-Fi monitor mode interface
If your distributor ships NetworkManager 1.0.x, you can probably expect an update soon. Fedora 23 users can grab the new release from the updates-testing repository, Fedora 24 testers already run a 1.2.x snapshot.
PS: Thanks for responses to the user survey. It’s very valuable to us. We’re reading every single of the 1500 responses, so it may take time till we respond to yours. Thanks for the patience.