Planet GNU

Aggregation of development blogs from the GNU Project

April 18, 2021

poke @ Savannah

GNU poke 1.2 released

I am happy to announce a new release of GNU poke, version 1.2.

This is a bug fix release in the poke 1.x series, and is the
result of all the user feedback we have received since we did
the last release.  Our big thanks to everyone who provided
feedback :)

See the file NEWS in the released tarball for a detailed list
of changes in this release.

The tarball poke-1.2.tar.gz is now available at
https://ftp.gnu.org/gnu/poke/poke-1.2.tar.gz.

  GNU poke (http://www.jemarch.net/poke) is an interactive,
  extensible editor for binary data.  Not limited to editing basic
  entities such as bits and bytes, it provides a full-fledged
  procedural, interactive programming language designed to describe
  data structures and to operate on them.

This release is the product of a month of work resulting in 37
commits, made by 5 contributors.

Thanks to the people who contributed with code and/or
documentation to this release.  In certain but no significant
order they are:

   Mohammad-Reza Nabipoor
   David Faust
   Egeyar Bagcioglu
   Konstantinos Chasialis

Thank you all!  It is a real pleasure to hack with you.

And this is all for now.
Happy poking!

--
Jose E. Marchesi
Frankfurt am Main
18 April 2021

18 April, 2021 05:21PM by Jose E. Marchesi

April 15, 2021

remotecontrol @ Savannah

How Amazon Strong-Arms Partners Using Its Power Across Multiple Businesses

https://www.wsj.com/articles/amazon-strong-arms-partners-across-multiple-businesses-11618410439

"Amazon.com Inc. last year told smart-thermostat maker Ecobee it had to give the tech giant data from its voice-enabled devices even when customers weren’t using them."

"Amazon responded that if Ecobee didn’t serve up its data, the refusal could affect Ecobee’s ability to sell on Amazon’s retail platform..."

15 April, 2021 12:17PM by Stephen H. Dawson DSL

April 12, 2021

FSF News

RMS addresses the free software community

12 April, 2021 01:55PM

GNU Guix

New Supported Platform: powerpc64le-linux

It is a pleasure to announce that support for powerpc64le-linux (PowerISA v.2.07 and later) has now been merged to the master branch of GNU Guix!

This means that GNU Guix can be used immediately on this platform from a Git checkout. Starting with the next release (Guix v1.2.1), you will also be able to download a copy of Guix pre-built for powerpc64le-linux. Regardless of how you get it, you can run the new powerpc64le-linux port of GNU Guix on top of any existing powerpc64le GNU/Linux distribution.

This new platform is available as a "technology preview". This means that although it is supported, substitutes are not yet available from the build farm, and some packages may fail to build. Although powerpc64le-linux support is nascent, the Guix community is actively working on improving it, and this is a great time to get involved!

Why Is This Important?

This is important because it means that GNU Guix now works on the Talos II, Talos II Lite, and Blackbird mainboards sold by Raptor Computing Systems. This modern, performant hardware uses IBM POWER9 processors, and it is designed to respect your freedom. The Talos II and Talos II Lite have recently received Respects Your Freedom (RYF) certification from the FSF, and Raptor Computing Systems is currently pursuing RYF certification for the more affordable Blackbird, too. All of this hardware can run without any non-free code, even the bootloader and firmware. In other words, this is a freedom-friendly hardware platform that aligns well with GNU Guix's commitment to software freedom.

How is this any different from existing RYF hardware, you might ask? One reason is performance. The existing RYF laptops, mainboards, and workstations can only really be used with Intel Core Duo or AMD Opteron processors. Those processors were released over 15 years ago. Since then, processor performance has increased drastically. People should not have to choose between performance and freedom, but for many years that is exactly what we were forced to do. However, the POWER9 machines sold by Raptor Computing Systems have changed this: the free software community now has an RYF-certified option that can compete with the performance of modern Intel and AMD systems.

Although the performance of POWER9 processors is competitive with modern Intel and AMD processors, the real advantage of the Talos II, Talos II Lite, and Blackbird is that they were designed from the start to respect your freedom. Modern processors from both Intel and AMD include back doors over which you are given no control. Even though the back doors can be removed with significant effort on older hardware in some cases, this is an obstacle that nobody should have to overcome just to control their own computer. Many of the existing RYF-certified options (e.g., the venerable Lenovo x200) use hardware that can only be considered RYF-certified after someone has gone through the extra effort of removing those back doors. No such obstacles exist when using the Talos II, Talos II Lite, or Blackbird. In fact, although Intel and AMD both go out of their way to keep you from understanding what is going on in your own computer, Raptor Computing Systems releases all of the software and firmware used in their boards as free software. They even include circuit diagrams when they ship you the machine!

Compared to the existing options, the Talos II, Talos II Lite, and Blackbird are a breath of fresh air that the free software community really deserves. Raptor Computing Systems' commitment to software freedom and owner control is an inspiring reminder that it is possible to ship a great product while still respecting the freedom of your customers. And going forward, the future looks bright for the open, royalty-free Power ISA stewarded by the OpenPOWER Foundation, which is now a Linux Foundation project (see also: the same announcement from the OpenPOWER Foundation.

In the rest of this blog post, we will discuss the steps we took to port Guix to powerpc64le-linux, the issues we encountered, and the steps we can take going forward to further solidify support for this exciting new platform.

Bootstrapping powerpc64le-linux: A Journey

To build software, you need software. How can one port Guix to a platform before support for that platform exists? This is a bootstrapping problem.

In Guix, all software for a given platform (e.g., powerpc64le-linux) is built starting from a small set of "bootstrap binaries". These are binaries of Guile, GCC, Binutils, libc, and a few other packages, pre-built for the relevant platform. It is intended that the bootstrap binaries are the only pieces of software in the entire package collection that Guix cannot build from source. In practice, additional bootstrap roots are possible, but introducing them in Guix is highly discouraged, and our community actively works to reduce our overall bootstrap footprint. There is one set of bootstrap binaries for each platform that Guix supports.

This means that to port Guix to a new platform, you must first build the bootstrap binaries for that platform. In theory, you can do this in many ways. For example, you might try to manually compile them on an existing system. However, Guix has package definitions that you can use to build them - using Guix, of course!

Commonly, the first step in porting Guix to a new platform is to use Guix to cross-compile the bootstrap binaries for that new platform from a platform on which Guix is already supported. This can be done by running a command like the following on a system where Guix is already installed:

guix build --target=powerpc64le-linux-gnu bootstrap-tarballs

This is the route that we took when building the powerpc64le-linux bootstrap binaries, as described in commit 8a1118a. You might wonder why the target above is "powerpc64le-linux-gnu" even though the new Guix platform is called "powerpc64le-linux". This is because "powerpc64le-linux-gnu" is a GNU triplet identifying the new platform, but "powerpc64le-linux" is the name of a "system" (i.e., a platform) in Guix. Guix contains code that converts between the two as needed (see nix-system->gnu-triplet and gnu-triplet->nix-system in guix/utils.scm. When cross-compiling, you only need to specify the GNU triplet.

Note that before you can even do this, you must first update the glibc-dynamic-linker and system->linux-architecture procedures in Guix's code, as described in Porting. In addition, the versions of packages in Guix that make up the GNU toolchain (gcc, glibc, etc.) must already support the target platform. This pre-existing toolchain support needs to be good enough so that Guix can (1) build, on some already-supported platform, a cross-compilation toolchain for the target platform, (2) use, on the already-supported platform, the cross-compilation toolchain to cross-compile the bootstrap binaries for the target platform, and (3) use, on the target platform, the bootstrap binaries to natively build the rest of the Guix package collection. The above guix build command takes care of steps (1) and (2) automatically.

Step (3) is a little more involved. Once the bootstrap binaries for the target platform have been built, they must be published online for anyone to download. After that, Guix's code must be updated so that (a) it recognizes the "system" name (e.g., "powerpc64le-linux") that will be used to identify the new platform and (b) it fetches the new platform's bootstrap binaries from the right location. After all that is done, you just have to try building things and see what breaks. For example, you can run ./pre-inst-env guix build hello from your Git checkout to try building GNU Hello.

The actual bootstrap binaries for powerpc64le-linux are stored on the alpha.gnu.org FTP server. Chris Marusich built these bootstrap binaries in an x86_64-linux Guix System VM which was running on hardware owned by Léo Le Bouter. Chris then signed the binaries and provided them to Ludovic Courtès, who in turn verified their authenticity, signed them, and uploaded them to alpha.gnu.org. After that, we updated the code to use the newly published bootstrap binaries in commit 8a1118a. Once all that was done, we could begin bootstrapping the rest of the system - or trying to, at least.

There were many stumbling blocks. For example, to resolve some test failures, we had to update the code in Guix that enables it to make certain syscalls from scheme. In another example, we had to patch GCC so that it looks for the 64-bit libraries in /lib, rather than /lib64, since that is where Guix puts its 64-bit libraries by convention. In addition, some packages required in order to build Guix failed to build, so we had to debug those build failures, too.

For a list of all the changes, see the patch series or the actual commits, which are:

$ git log --oneline --no-decorate 8a1118a96c9ae128302c3d435ae77cb3dd693aea^..65c46e79e0495fe4d32f6f2725d7233fff10fd70
65c46e79e0 gnu: sed: Make it build on SELinux-enabled kernels.
93f21e1a35 utils: Fix target-64bit? on powerpc64le-linux.
8d9aece8c4 ci: %cross-targets: Add powerpc64le-linux-gnu.
c29bfbfc78 syscalls: Fix RNDADDTOENTCNT on powerpc64le-linux.
b57de27d03 syscalls: Fix clone on powerpc64le-linux.
a16eb6c5f9 Add powerpc64le-linux as a supported Guix architecture.
b50f426803 gnu: libelf: Fix compilation for powerpc64le-linux.
1a0f4013d3 gnu: texlive-latex-base: Fix compilation on powerpc64le*.
e9938dc8f0 gnu: texlive-bin: Fix compilation on powerpc64le*.
69b3907adf gnu: guile-avahi: Fix compilation on powerpc64le-linux.
4cc2d2aa59 gnu: bdb-4.8: Fix configure on powerpc64le-linux.
be4b1cf53b gnu: binutils-final: Support more Power architectures.
060478c32c gnu: binutils-final: Provide bash for binary on powerpc-linux.
b2135b5d57 gnu: gcc-boot0: Enable 128-bit long double for POWER9.
6e98e9ca92 gnu: glibc: Fix ldd path on powerpc*.
cac88b28b8 gnu: gcc-4.7: On powerpc64le, fix /lib64 references.
fc7cf0c1ec utils: Add target-powerpc? procedure.
8a1118a96c gnu: bootstrap: Add support for powerpc64le-linux.

In the end, through the combined efforts of multiple people, we slowly worked through the issues until we reached a point where we could do all of the following things successfully:

  • Build Guix manually on a Debian GNU/Linux ppc64el machine (this is Debian's name for a system using the powerpc64le-linux-gnu triplet), and verify that its make check tests passed.
  • Build GNU Hello using Guix and run it.
  • Run guix pull to build and install the most recent version of Guix, with powerpc64le-linux support.
  • Build a release binary tarball for powerpc64le-linux via: make guix-binary.powerpc64le-linux.tar.xz
  • Use that binary to install a version of Guix that could build/run GNU Hello and run guix pull successfully.

This was an exciting moment! But there was still more work to be done.

Originally, we did this work on the wip-ppc64le branch, with the intent of merging it into core-updates. By convention, the "core-updates" branch in Guix is where changes are made if they cause too many rebuilds. Since we were updating package definitions so deep in the dependency graph of the package collection, we assumed it wouldn't be possible to avoid rebuilding the world. For this reason, we had based the wip-ppc64le branch on core-updates.

However, Efraim Flashner proved us wrong! He created a separate branch, wip-ppc64le-for-master, where he adjusted some of the wip-ppc64le commits to avoid rebuilding the world on other platforms. Thanks to his work, we were able to merge the changes directly to master! This meant that we would be able to include it in the next release (Guix v.1.2.1).

In short, the initial porting work is done, and it is now possible for anyone to easily try out Guix on this new platform. Because guix pull works, too, it is also easy to iterate on what we have and work towards improving support for the platform. It took a lot of cooperation and effort to get this far, but there are multiple people actively contributing to this port in the Guix community who want to see it succeed. We hope you will join us in exploring the limits of this exciting new freedom-friendly platform!

Other Porting Challenges

Very early in the porting process, there were some other problems that stymied our work.

First, we actually thought we would try to port to powerpc64-linux (big-endian). However, this did not prove to be any easier than the little-endian port. In addition, other distributions (e.g., Debian and Fedora) have recently dropped their big-endian powerpc64 ports, so the little-endian variant is more likely to be tested and supported in the community. For these reasons, we decided to focus our efforts on the little-endian variant, and so far we haven't looked back.

In both the big-endian and little-endian case, we were saddened to discover that the bootstrap binaries are not entirely reproducible. This fact is documented in bug 41669, along with our extensive investigations.

In short, if you build the bootstrap binaries on two separate machines without using any substitutes, you will find that the derivation which cross-compiles %gcc-static (the bootstrap GCC, version 5.5.0) produces different output on the two systems. However, if you build %gcc-static twice on the same system, it builds reproducibly. This suggests that something in the transitive closure of inputs of %gcc-static is perhaps contributing to its non-reproducibility. There is an interesting graph toward the end of the bug report, shown below:

DifferingDerivations

This graph shows the derivations that produce differing outputs across two Guix System machines, when everything is built without substitutes. It starts from the derivation that cross-compiles %gcc-static for powerpc64-linux-gnu (from x86_64-linux) using Guix at commit 1ced8379c7641788fa607b19b7a66d18f045362b. Then, it walks the graph of derivation inputs, recording only those derivations which produce differing output on the two different machines. If the non-reproducibility (across systems) of %gcc-static is caused by a non-reproducible input, then it is probably caused by one or more of the derivations shown in this graph.

At some point, you have to cut your losses and move on. After months of investigation without resolving the reproducibility issue, we finally decided to move forward with the bootstrap binaries produced earlier. If necessary, we can always go back and try to fix this issue. However, it seemed more important to get started with the bootstrapping work.

Anyone who is interested in solving this problem is welcome to comment on the bug report and help us to figure out the mystery. We are very interested in solving it, but at the moment we are more focused on building the rest of the Guix package collection on the powerpc64le-linux platform using the existing bootstrap binaries.

Next Steps

It is now possible to install Guix on a powerpc64le-linux system and use it to build some useful software - in particular, Guix itself. So Guix is now "self-hosted" on this platform, which gives us a comfortable place to begin further work.

The following tasks still need to be done. Anyone can help, so please get in touch if you want to contribute!

About GNU Guix

GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom. Guix can be used on top of any system running the Hurd or the Linux kernel, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, and AArch64 machines.

In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. When used as a standalone GNU/Linux distribution, Guix offers a declarative, stateless approach to operating system configuration management. Guix is highly customizable and hackable through Guile programming interfaces and extensions to the Scheme language.

12 April, 2021 12:00AM by Chris Marusich and Léo Le Bouter

April 11, 2021

Andy Wingo

guile's reader, in guile

Good evening! A brief(ish?) note today about some Guile nargery.

the arc of history

Like many language implementations that started life when you could turn on the radio and expect to hear Def Leppard, Guile has a bottom half and a top half. The bottom half is written in C and exposes a shared library and an executable, and the top half is written in the language itself (Scheme, in the case of Guile) and somehow loaded by the C code when the language implementation starts.

Since 2010 or so we have been working at replacing bits written in C with bits written in Scheme. Last week's missive was about replacing the implementation of dynamic-link from using the libltdl library to using Scheme on top of a low-level dlopen wrapper. I've written about rewriting eval in Scheme, and more recently about how the road to getting the performance of C implementations in Scheme has been sometimes long.

These rewrites have a quixotic aspect to them. I feel something in my gut about rightness and wrongness and I know at a base level that moving from C to Scheme is the right thing. Much of it is completely irrational and can be out of place in a lot of contexts -- like if you have a task to get done for a customer, you need to sit and think about minimal steps from here to the goal and the gut doesn't have much of a role to play in how you get there. But it's nice to have a project where you can do a thing in the way you'd like, and if it takes 10 years, that's fine.

But besides the ineffable motivations, there are concrete advantages to rewriting something in Scheme. I find Scheme code to be more maintainable, yes, and more secure relative to the common pitfalls of C, obviously. It decreases the amount of work I will have when one day I rewrite Guile's garbage collector. But also, Scheme code gets things that C can't have: tail calls, resumable delimited continuations, run-time instrumentation, and so on.

Taking delimited continuations as an example, five years ago or so I wrote a lightweight concurrency facility for Guile, modelled on Parallel Concurrent ML. It lets millions of fibers to exist on a system. When a fiber would need to block on an I/O operation (read or write), instead it suspends its continuation, and arranges to restart it when the operation becomes possible.

A lot had to change in Guile for this to become a reality. Firstly, delimited continuations themselves. Later, a complete rewrite of the top half of the ports facility in Scheme, to allow port operations to suspend and resume. Many of the barriers to resumable fibers were removed, but the Fibers manual still names quite a few.

Scheme read, in Scheme

Which brings us to today's note: I just rewrote Guile's reader in Scheme too! The reader is the bit that takes a stream of characters and parses it into S-expressions. It was in C, and now is in Scheme.

One of the primary motivators for this was to allow read to be suspendable. With this change, read-eval-print loops are now implementable on fibers.

Another motivation was to finally fix a bug in which Guile couldn't record source locations for some kinds of datums. It used to be that Guile would use a weak-key hash table to associate datums returned from read with source locations. But this only works for fresh values, not for immediate values like small integers or characters, nor does it work for globally unique non-immediates like keywords and symbols. So for these, we just wouldn't have any source locations.

A robust solution to that problem is to return annotated objects rather than using a side table. Since Scheme's macro expander is already set to work with annotated objects (syntax objects), a new read-syntax interface would do us a treat.

With read in C, this was hard to do. But with read in Scheme, it was no problem to implement. Adapting the expander to expect source locations inside syntax objects was a bit fiddly, though, and the resulting increase in source location information makes the output files bigger by a few percent -- due somewhat to the increased size of the .debug_lines DWARF data, but also due to serialized source locations for syntax objects in macros.

Speed-wise, switching to read in Scheme is a regression, currently. The old reader could parse around 15 or 16 megabytes per second when recording source locations on this laptop, or around 22 or 23 MB/s with source locations off. The new one parses more like 10.5 MB/s, or 13.5 MB/s with positions off, when in the old mode where it uses a weak-key side table to record source locations. The new read-syntax runs at around 12 MB/s. We'll be noodling at these in the coming months, but unlike when the original reader was written, at least now the reader is mainly used only at compile time. (It still has a role when reading s-expressions as data, so there is still a reason to make it fast.)

As is the case with eval, we still have a C version of the reader available for bootstrapping purposes, before the Scheme version is loaded. Happily, with this rewrite I was able to remove all of the cruft from the C reader related to non-default lexical syntax, which simplifies maintenance going forward.

An interesting aspect of attempting to make a bug-for-bug rewrite is that you find bugs and unexpected behavior. For example, it turns out that since the dawn of time, Guile always read #t and #f without requiring a terminating delimiter, so reading "(#t1)" would result in the list (#t 1). Weird, right? Weirder still, when the #true and #false aliases were added to the language, Guile decided to support them by default, but in an oddly backwards-compatible way... so "(#false1)" reads as (#f 1) but "(#falsa1)" reads as (#f alsa1). Quite a few more things like that.

All in all it would seem to be a successful rewrite, introducing no new behavior, even producing the same errors. However, this is not the case for backtraces, which can expose the guts of read in cases where that previously wouldn't happen because the C stack was opaque to Scheme. Probably we will simply need to add more sensible error handling around callers to read, as a backtrace isn't a good user-facing error anyway.

OK enough rambling for this evening. Happy hacking to all and to all a good night!

11 April, 2021 07:51PM by Andy Wingo

April 08, 2021

sign of the times

Hello all! There is a mounting backlog of things that landed in Guile recently and to avoid having to eat the whole plate in one bite, I'm going to try to send some shorter missives over the next weeks.

Today's is about a silly thing, dynamic-link. This interface is dlopen, but "portable". See, back in the day -- like, 1998 -- there were lots of kinds of systems and how to make and load a shared library portably was hard. You'd have people with AIX and Solaris and all kinds of weird compilers and linkers filing bugs on your project if you hard-coded a GNU toolchain invocation when creating loadable extensions, or hard-coded dlopen or similar to use them.

Libtool provided a solution to create portable loadable libraries, which involved installing .la files alongside the .so files. You could use libtool to link them to a library or an executable, or you could load them at run-time via the libtool-provided libltdl library.

But, the .la files were a second source of truth, and thus a source of bugs. If a .la file is present, so is an .so file, and you could always just use the .so file directly. For linking against an installed shared library on modern toolchains, the .la files are strictly redundant. Therefore, all GNU/Linux distributions just delete installed .la files -- Fedora, Debian, and even Guix do so.

Fast-forward to today: there has been a winnowing of platforms, and a widening of the GNU toolchain (in which I include LLVM as well as it has a mostly-compatible interface). The only remaining toolchain flavors are GNU and Windows, from the point of view of creating loadable shared libraries. Whether you use libtool or not to create shared libraries, the result can be loaded either way. And from the user side, dlopen is the universally supported interface, outside of Windows; even Mac OS fixed their implementation a few years back.

So in Guile we have been in an unstable equilibrium: creating shared libraries by including a probably-useless libtool into the toolchain, and loading them by using a probably-useless libtool-provided libltdl.

But the use of libltdl has not been without its costs. Because libltdl intends to abstract over different platforms, it encourages you to leave off the extension when loading a library, instead promising to try a platform-specific set such as .so, .dll, .dylib etc as appropriate. In practice the abstraction layer was under-maintained and we always had some problems on Mac OS, for example.

Worse, as ltdl would search through the path for candidates, it would only report the last error it saw from the underlying dlopen interface. It was almost always the case that if A and B were in the search path, and A/foo.so failed to load because of a missing dependency, the error you would get as a user would instead be "file not found", because ltdl swallowed the first error and kept trucking to try to load B/foo.so which didn't exist.

In summary, this is a case where the benefits of an abstraction layer decline over time. For a few years now, libltdl hasn't been paying for itself. Libtool is dead, for all intents and purposes (last release in 2015); best to make plans to migrate away, somehow.

In the case of the dlopen replacement, in Guile we ended up rewriting the functionality in Scheme. The underlying facility is now just plain dlopen, for which we shim a version of dlopen on Windows, inspired by the implementation in cygwin. There are still platform-specific library extensions, but that is handled easily on the Scheme layer.

Looking forward, I think it's probably time to replace Guile's use of libtool to create its libraries and executables. I loathe the fact that libtool puts shell scripts in the place of executables in build directories and stashes the actual executables elsewhere -- like, visceral revulsion. There is no need for that nowadays. Not sure what to replace it with, nor on what timeline.

And what about autotools? That, my friends, would be a whole nother blog post. Until then, & probably sooner, happy hacking!

08 April, 2021 07:09PM by Andy Wingo

GNU Guix

Outreachy 'guix git log' internship wrap-up

Magali Lemes joined Guix in December for a three-month internship with Outreachy. Magali implemented a guix git log command to browse the history of packaging changes, with mentoring from Simon Tournier and Gábor Boskovits. In this blog post, Magali and Simon wrap up on what's been accomplished.

Magali

The first tasks I had to do were pretty simple and were mainly meant to both get me acquainted with the source code and set the building blocks of the project. They were very important so that I could gradually build the subcommand. For starters, I created a Guix repository on Gitlab, so that I could push all the work I had done there, tweaked a little bit of the source code, and then proceeded to have the guix git log subcommand show the default channel checkout path.

From there on, I started adding options to the subcommand. The oneline option was the first and simplest option, and it pretty much emulates what git log --oneline does: it displays the commit short hash id and title. Afterwards, other options such as format, pretty, and grep came along. The possibility of retrieving commits from other channels---and not only from the default one---was also implemented. An example of invoking the subcommand would be:

guix git log --oneline --grep=guile-git

The road to doing all of this wasn't always smooth. Right at the beginning of the internship, for instance, I struggled with getting a segmentation fault error. It was a known bug, and I was able to overcome it.

I also got to participate in the one-day Guix workshop---a FOSDEM 2021 fringe event---and presented the work I had done so far. It was quite nice demonstrating the subcommand, receiving feedback and questions, and I could also get to know other things that were being worked on in Guix.

In the post I wrote three months ago, I mention that I wish I could gain meaningful experience and improve my communication skills. I'm glad to say that I feel like I was able to achieve that. Sending emails, explaining what I had done, and asking questions about what I had to do during the weekly meetings were a few of the situations I had to face, and that made me improve these skills. I also had a taste of what it's like to take part in a free software project, got to know a few people, and learned quite a lot about Guile Scheme.

One thing, though, that I wasn't able to implement in due time was the commit limiting options, such as guix git log --after=YYYY-MM-DD and guix git log --before=YYYY-MM-DD.

Hopefully, soon users will be able to invoke guix git log, and have the commit history from all Guix channels they have.

Simon

It was my first experience mentoring for the Outreachy program and now I am glad I did it. I have learnt a lot on various topics. I had already mentored interns occasionally, though it was the first time fully remote, not on the same timezone, and with code on which I am not expert. Thanks Gábor, Ludovic and Ricardo for pushing me to jump in this journey.

Reading back the initial proposal coming from a 2019 question, I am happy by the insofar Magali's internship. It paves the way for future proposals or the implementation of other guix git subcommands.

Next Outreachy round & acknowledgment

Guix is participating in the upcoming Outreachy round. If you are eligible, please get in touch with us and consider applying by April 30th!

In light of recent changes at the Free Software Foundation (FSF) and Outreachy’s subsequent decision to refuse funds coming from the FSF, we are grateful to Software Freedom Conservancy (SFC) for their decision to sponsor our upcoming internship. We are working on a longer-term solution so we can keep participating in Outreachy. In the meantime, thanks a lot, Conservancy!

About GNU Guix

GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom. Guix can be used on top of any system running the kernel Linux, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, and AArch64 machines.

In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. When used as a standalone GNU/Linux distribution, Guix offers a declarative, stateless approach to operating system configuration management. Guix is highly customizable and hackable through Guile programming interfaces and extensions to the Scheme language.

08 April, 2021 05:00PM by Magali Lemes, Simon Tournier, Ludovic Courtès

April 07, 2021

FSF Blogs

March GNU Spotlight with Mike Gerwitz: 14 new GNU releases!

14 new GNU releases in the last month (as of March 25, 2021):

07 April, 2021 04:46PM

April 06, 2021

poke @ Savannah

[VIDEO] Terminal Hyperlinks in GNU poke

Terminal Hyperlinks are a new way for programs to print click-able text in terminals and terminal emulators.  Along with the app:// protocol, the hyperlinks can be used to greatly enhance the experience of using CLI (command-line interface) programs.  We are making extensive usage of this novel feature in GNU poke and we are very happy with the results.

This short video introduces the terminal hyperlinks, the app protocol and shows a few examples on how poke uses them.

https://www.youtube.com/watch?v=9Eg9Zn8AtY8

06 April, 2021 05:58PM by Jose E. Marchesi

libredwg @ Savannah

libredwg-0.12.4 released

Fixed many more minor fuzzing errors.
See https://www.gnu.org/software/libredwg/ and https://github.com/LibreDWG/libredwg/blob/0.12.4/NEWS

Here are the compressed sources:
http://ftp.gnu.org/gnu/libredwg/libredwg-0.12.4.tar.gz (17.4MB)
http://ftp.gnu.org/gnu/libredwg/libredwg-0.12.4.tar.xz (9MB)

Here are the GPG detached signatures[*]:
http://ftp.gnu.org/gnu/libredwg/libredwg-0.12.4.tar.gz.sig
http://ftp.gnu.org/gnu/libredwg/libredwg-0.12.4.tar.xz.sig

Use a mirror for higher download bandwidth:
https://www.gnu.org/order/ftp.html

Here are more binaries:
https://github.com/LibreDWG/libredwg/releases/tag/0.12.4

Here are the SHA256 checksums:

```
081e9a70be529542b905b04be73e3e7590d60b1e976c0227f47004f3373ed9b1  libredwg-0.12.4.tar.gz
918857f119c34d9bef17321b646c4ba0fbfaa93dcaced403bae1933e1d9a6517  libredwg-0.12.4.tar.xz
```

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:

gpg --verify libredwg-0.12.4.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

gpg --keyserver keys.gnupg.net --recv-keys B4F63339E65D6414

and rerun the gpg --verify command.

06 April, 2021 12:40PM by Reini Urban

April 05, 2021

Parabola GNU/Linux-libre

i686 desktop users should refrain from upgrading

users of a GTK-based desktops (LXDE, MATE, possibly others) on the i686 system, should refrain from upgrading for some time, or else the desktop may not start properly - this bug does not affect X86_64

05 April, 2021 11:22AM by bill auger

Sylvain Beucler

planet.gnu.org is looking for a new host and maintainer

planet.gnu.org logo

Around 3 years ago I revamped planet.gnu.org and hosted it myself, as the previous host was defunc.

I won't have the energy host it for much longer, so planet.gnu.org is now looking for a new host and maintainer.
In any case I'll shut down the service when I upgrade to Debian 11 "bullseye" in a few months.

Everything needed to run the service is documented and stored in the infra and config repositories, there is no private data. A previous blog post discusses upcoming tasks. The planet@gnu.org contact point is now managed by GNU's Mailman instance. The DNS alias is managed by the FSF sysadmins.

05 April, 2021 10:48AM

April 03, 2021

GNUnet News

GNUnet 0.14.1

GNUnet 0.14.1

Continuing to "release early / release often", we presentGNUnet 0.14.1. This is a bugfix release for gnunet 0.14.0.

Download links

The GPG key used to sign is: 3D11063C10F98D14BD24D1470B0998EF86F59B6A

Note that due to mirror synchronization, not all links may be functionalearly after the release. For direct access tryhttp://ftp.gnu.org/gnu/gnunet/

Noteworthy changes in 0.14.1 (since 0.14.0)

  • TNG: Various improvements to communicators. #6361,#5550
  • GNS: Use autogenerated records header file from GANA.
  • FS: Improve modularity of FS structs. #6743
  • SETU: Various improvements as part of the ongoing work on LSD0003.
  • IDENTITY: Fix wrong key construction for anonymous ECDSA identity.
  • RPS: Code cleanup mostly addressing warnings.
  • UTIL:
    • Added a Base32 en/decoded CLI gnunet-base32.
    • Use timeflakes as UUIDs. #6716
  • Buildsystem: Fix libunistring detection. #6485

A detailed list of changes can be found in the ChangeLog andthe 0.14.1 bugtracker.

Thanks

This release was the work of many people. The following people contributed code and were thus easily identified:Christian Grothoff, Florian Dold, t3sserakt, TheJackiMonster, Elias Summermatter, Julius Bünger and Thien-Thi Nguyen.

03 April, 2021 10:00PM

March 31, 2021

Christopher Allan Webber

The hurt of this moment, hopes for the future

Of the deeper thoughts I might give to this moment, I have given them elsewhere. For this blogpost, I just want to speak of feelings... feelings of hurt and hope.

I am reaching out, collecting the feelings of those I see around me, writing them in my mind's journal. Though I hold clear positions in this moment, there are few roots of feeling and emotion about the moment I feel I haven't steeped in myself at some time. Sometimes I tell this to friends, and they think maybe I am drifting from a mutual position, and this is painful for them. Perhaps they fear this could constitute or signal some kind of betrayal. I don't know what to say: I've been here too long to feel just one thing, even if I can commit to one position.

So I open my journal of feelings, and here I share some of the pages collecting the pain I see around me:

The irony of a movement wanting to be so logical and above feelings being drowned in them.

The feelings of those who found a comfortable and welcoming home in a world of loneliness, and the split between despondence and outrage for that unraveling.

The feelings of those who wanted to join that home too, but did not feel welcome.

The pent up feelings of those unheard for so long, uncorked and flowing.

The weight and shadow of a central person who seems to feel things so strongly but cannot, and does not care to learn to, understand the feelings of those around them.

I flip a few pages ahead. The pages are blank, and I interpret this as new chapters for us to write, together.

I hope we might re-discover the heart of our movement.

I hope we can find a place past the pain of the present, healing to build the future.

I hope we can build a new home, strong enough to serve us and keep us safe, but without the walls, moat, and throne of a fortress.

I hope we can be a movement that lives up to our claims: of justice, of freedom, of human rights, to bring these to everyone, especially those we haven't reached.

31 March, 2021 06:42PM by Christopher Lemmer Webber

GNU Guix

Cuirass 1.0 released

We are pleased to announce the release of Cuirass version 1.0, after almost five years of development and around 700 commits from 14 contributors.

Cuirass is the GNU Guix continuous integration software. It's a general purpose build automation server written in GNU Guile that checks out sources from VCS repositories, execute build jobs and store build results in a database. Cuirass also provides a web interface to monitor the build results.

Cuirass is running on the GNU Guix build farm.

Since January, the project is funded through the NGI0 PET Fund, a fund established by NLnet with financial support from the European Commission's Next Generation, as explained here.

Thanks to this support, we were able to speed up the developments and finally propose a first release of this software. Many things have changed in Cuirass over the years and now is the perfect time to give it a try.

Here are the highlights of this new release.

Database

Let's start with the database that is the core of Cuirass. Until recently Cuirass was using an SQLite3 database. This technological choice proved to be quite challenging, and we had some troubles to make it scale as discussed here.

Cuirass now uses a PostgreSQL database, bringing the performance issues to an end while providing much more stability. Almost all the SQL queries are covered by test cases.

Specifications

In order to build some derivations, Cuirass first needs to be told what to build. Originally, an obscure association list describing the requested build jobs had to be passed to Cuirass.

Cuirass now operates on specification records that are described here. This input format is much more easy to understand for the user. It relies on Guix channels, which are well-adopted.

Here are a few different specifications examples.

This will build all the packages of the my-channel channel.

(list (specification
       (name "my-channel")
       (build '(channels my-channel))
       (channels
        (cons (channel
               (name 'my-channel)
               (url "https://my-channel.git"))
              %default-channels))))

This will build the linux-libre package on the default Guix channel master branch.

(list (specification
           (name "my-linux")
           (build '(packages "linux-libre"))))

Finally, this will build the packages declared in the my-manifest file of the my-channel channel, against the core-updates branch of the default Guix channel.

(list (specification
       (name "my-core-manifest")
       (build '(manifests "my-manifest"))
       (channels
        (list (channel
               (name 'my-channel)
               (url "https://my-channel.git"))
              (channel
               (name 'guix)
               (url %default-channel-url)
               (branch "core-updates"))))))

For people willing to spare some parens, a specification edition form has been implemented in the Web interface.

Specification creation

The Cuirass home page has also been updated to reflect this new input format.

Notifications

This feature was rightfully requested many times as this is a basic of any respectable CI system. Cuirass can now report failing and fixed builds in three different ways:

New build mode

The traditional way of building things in Cuirass is to send batches of derivations that need to be built to the local Guix daemon. The daemon can possibly offload those builds to other machines. While it's probably the most sensible way to proceed, this solution doesn't scale well and suffers from some limitations.

  • There's no way to influence the scheduling decisions of the Guix daemon. It's quite delicate to prioritize builds or build machines from Cuirass.

  • The Guix daemon doesn't offer much feedback. Cuirass needs to parse the debug output of the daemon to detect build events such as start and stop events.

  • Using a unique daemon means using unique build parameters such as build timeout and max-silent-time properties. Some packages have different build properties and Cuirass cannot honor them.

  • When relying heavily on offloading, the Guix daemon scales badly. Builds that often take a longer time to complete, such as emulated builds can saturate the build queue.

For all those reasons, using a new build mode seemed like a necessary evil. The rationale behind this new build mode is to have Cuirass communicate directly with the Guix daemons of all the offloading machines. Instead of dealing with a single, local, Guix daemon, Cuirass can now interact with several Guix daemons on remote machines.

The build jobs are not submitted to the local Guix daemon. Instead, a remote server dispatches build requests to the connect remote workers, according to the build priorities.

The remote server and the connected workers communicate using ZeroMQ over TCP. The workers are able to discover the remote server using Avahi.

The built items are exchanged as substitutes by spawning Guix publish servers both on the remote server and on each connected remote worker.

It seems more complex, and it is indeed more complex. However, the performance gains are real.

Build machines CPU idle percentage

This chart shows the CPU idle time percentage of the GNU Guix build farm machines. The introduction of the remote building mechanism around January 2021 results in a much higher activity of the connected machines.

This remote build mode also unlocked new features such as:

  • The live streaming of build logs from remote workers to Cuirass so that they can be browsed in real time through the web interface.

  • The support for timeout and max-silent-time package properties.

  • The support for specification and package priorities.

  • The new "Workers status" and "Machine status" pages allowing to closely monitor remote machine activities.

The workers status page is accessible here.

Workers status page

The machine status page is accessible here.

Machine status page

Web interface

Besides the features related to the specification record introduction, several improvements were brought to the Web interface.

Some administration actions that previously required manual SQL intervention can now be performed directly through the Web interface.

Any Cuirass administrator can now:

  • Add a specification
  • Edit a specification
  • Delete a specification
  • Cancel an evaluation pending builds
  • Retry all builds of an evaluation
  • Retry an evaluation
  • Restart a build

The build page was also improved to display the build weather and a build history.

Build page

Several issues were also fixed such as the broken pagination and the negative build duration.

Metrics

Cuirass computes periodically various metrics such as:

  • Average evaluation duration per specification (seconds).
  • Difference between newly added derivations and built derivations per day.
  • Average time required for an evaluation to start its builds.
  • Evaluation completion speed.
  • Sum of currently pending builds.
  • Builds count per machine during the last day.
  • Percentage of failed evaluations.

Metrics

Those metrics can be browsed here.

Documentation

The Cuirass documentation is now updated to reflect those changes and can be browsed online.

The release itself is available on Cuirass home page.

The Guix's Cuirass package as well as the Cuirass service were also updated.

Going further

The NLNet grant will allow me to keep working on Cuirass for a couple more months. This will hopefully help us to:

  • Connect more armhf/aarch64 machines to the build farm.

  • Fix the build dependencies issue

  • Add a substitutes availability API and its counterpart in GNU Guix to improve the the channel-with-substitute-available procedure to take a manifest argument. This way, the guix pull command can be instructed to only update to Guix revisions where the manifest packages are all substitutable.

This release is an important milestone as, combined with the recent substitute improvements, the whole substitute availability & download speed situation is now largely mitigated, at least on Intel architectures.

Don't hesitate to run your own Cuirass server to build stuff ahead of the GNU Guix build farm, or to build your custom channels. Also feel free to share the features you would like to see in the next Cuirass release.

31 March, 2021 09:00AM by Mathieu Othacehe

March 30, 2021

FSF Blogs

FSF News

Mike Gran

Guile Potluck 2021 Part 1: Genshou and Anguish

Preface

Guile Potluck 2021 was an event where hackers got to advertise their exciting new projects.  It wrapped up a few weeks ago, and at that time I was my intention to blog my way through the entrants right away.  Well, I have not been expedient on that front.
I'm so very sorry it has taken me so long to get back to Guile Potluck 2021.  Somewhere between family, kids, the day job, actually working on Guile, and the vague depression that quarantine seems to instill in me, it all got away from me.
But hey, let's see what we've got. I'll start from the end, and work my way back to the beginning.

Genshou, by Walter Lewis

https://git.sr.ht/~wklew/genshou

Here, wklew implements an extensible effects system, that allows stateful computations without any mutation.  Thought provoking stuff, especially if you like pondering monads, denotational semantics and other such things.

Honestly, it is projects like this that activate my impostor syndrome with regards to Scheme. Many Scheme hackers approach it from a deep interest in Computer Science, and mostly I look at their work in awe whilst carrying on with my second-hand understanding of programming that somehow I've built a career on.
 

Anguish, by Rutger van Beusekom

https://gitlab.com/rutger.van.beusekom/anguish
 


 

rutger.van.beusekom has written as parser for the POSIX sh language
using PEG grammar, which he hopes to convert into a full fledged shell
in future. At the moment, it converts shell statements into an SXML-like representation.

I am excited to see someone exercise Guile's PEG parser, which is both powerful and under-utilized.

30 March, 2021 03:51AM by Mike (noreply@blogger.com)

March 29, 2021

poke @ Savannah

[VIDEO] Hacking the BPF Type Format with GNU poke

I just uploaded the pilot test of what will be a series of videos indended to show how to use poke, writing pickles, and the like.  It is very improvised and I have never made a screencap/video of this kind before, so please bear with me ;)

https://youtu.be/n3ErUiLwFN4

Happy poking!

29 March, 2021 02:24AM by Jose E. Marchesi

FSF News

March 28, 2021

GNU Taler news

Why a Digital Euro should be Online-first and Bearer-based

2021-3: "Why a Digital Euro should be Online-first and Bearer-based" published

We are happy to announce the publication of our paper on "Why a Digital Euro should be Online-first and Bearer-based".

The European Central Bank’s “Report on a Digital Euro” considerstwo distinct types of designs for a digital euro. It argues that all functionalrequirements laid out in the report can be fulfilled by operating the two systemsin parallel:

  • A bearer-based digital euro based on trusted hardware that can be usedoffline, anonymously, and without third-party intervention.
  • An account-based digital euro that can be used online, is fully software-based and excludes the possibility of anonymity.
The report does not discuss other choices of hybrid systems. However, thechoice is more arbitrary than it might seem at first sight: bearer-based systemsare not necessarily offline payment systems, and online payment systems do notneed to exclude anonymity.

We argue that operating a bearer-based payment system to complement anaccount-based CBDC in order to gain offline and privacy features is not a goodtrade-off. Adding permanent, regular offline capabilities via the bearer-basedpayment instrument constantly exposes the CBDC to the severe issues inherentin offline-capable payment systems. Instead, the offline mode of operationshould be restricted to scenarios where it is actually required, which mitigatesthe risks.

Download links

28 March, 2021 10:00PM

March 26, 2021

GNU Guix

Getting bytes to disk more quickly

Let’s face it: functional package managers like Guix provide unequaled support for reproducibility and transactional upgrades, but the price to pay is that users often spend a fair amount of time downloading (or building) packages. Download times are okay on day-to-day use but they’re a pain point when performing large upgrades or when installing Guix System for the first time.

With that in mind, it should come as no surprise that Michael Stapelberg’s excellent 2020 Arch Linux Conference talk and the installation speed achieved by distri were a great motivation boost. Michael proposes radical ideas to speed up package installation, such as downloading and mounting ready-to-use SquashFS images. Not everything can be transposed to Guix as-is, but it certainly got us thinking.

This article dives into improvements made over the last few months that will be in the upcoming 1.2.1 release, and which are already one guix pull away; they all contribute to making substitute download and installation “faster”. This is an evolution of the existing mechanisms rather than a revolution, but one that users will surely welcome.

Reducing latency

One of the first things we notice is latency between subsequent substitute downloads. It may sound ridiculous, but guix-daemon would spawn one helper process (running the internal guix substitute command) for each substitute download. That means that not only would it create a new process each time, it would also be unable to reuse connections to the substitute servers. This is particularly noticeable and wasteful when downloading many substitutes in a row, such as when installing Guix System for the first time.

The latency in between subsequent substitute downloads was primarily this: fork (creating a new process), TCP connection establishment and TLS connection handshake. When running perf timechart record guix build … (what a wonderful tool perf timechart is!), we get this Gantt diagram, which gives an idea of all the time wasted creating these processes, waiting for them to initialize and connect to the substitute server, and so on:

Gantt diagram without substitute agent.

Why was it done this way? Because the daemon, written in C++ and inherited from Nix, would historically delegate substitution to helper programs, with a flexible but naive protocol between the daemon and those helper programs.

Back in December, we tackled this issue (followup): the daemon would now launch a single guix substitute process and reuse it for subsequent substitute downloads. In turn, guix substitute would cache connections so we save time on connection establishment.

Another observation we made is that guix-daemon implemented post-processing steps after each download that would contribute to latency. Once guix substitute had completed a download and extracted the archive to the store, the daemon would traverse this store item a couple of times to reset file timestamps/permissions (“metadata canonicalization”), to deduplicate files, and to verify the integrity of the whole store item. This is I/O-intensive and particularly wasteful for store items with many files. Our next step was to delegate all this work to guix substitute, which allows it to pipeline archive extraction, integrity checks, deduplication, and metadata canonicalization. All this happens as the bytes flow in and no extra traversal is needed.

The speedup offered by these optimizations depends on several factors, including the latency of your network, the speed of your CPU and that of your hard disk, and it grows with the number of substitutes fetched in a row. What we can say is that even in a “favorable” situation—low-latency network, fast CPU, fast storage device—it definitely feels snappier.

Increasing bandwidth

With the latency issue pretty much solved, the next step was to look at bandwidth. When we introduced lzip-compressed substitutes back in 2019, the assumption was that a much higher compression ratio (compared to gzip), would inevitably translate to faster downloads. That is true… but only for some bandwidth/CPU power configurations.

Specifically, it turns out that, for someone with a fast connection, such as fiber-to-the-home (FTTH), downloads of lzip-compressed substitutes are actually CPU-bound. In other words, the limiting factor is the processing time to decompress those lzip’d archives—not the available bandwidth. Lzip currently achieves the best compression ratios so far, and that’s great, but decompression is compute-intensive.

Ever-increasing bandwidth is what drove the design and implementation of newer compression methods, such as “Z standard”, colloquially known as “zstd”. The decompression speed of zstd is on the order of 3.5 higher than that of gzip and an order of magnitude higher than that of lzip; but unlike the venerable lzo, zstd achieves high compression ratios: at level 19, the compression ratio of zstd is lower than that of lzip but in the same ballpark. Guillaume Le Vaillant provided an insightful comparison of gzip, lzip, and zstd on a plot showing their decompression speed as a function of the compression ratio:

Decompression speed vs. compression ratio of gzip, lzip, and zstd.

There are several takeaways. First, zstd decompression is always faster than the alternatives. Second, zstd compresses better than gzip starting from level 2, so gzip “loses” on both criteria. Last, zstd at level 19 achieves a compression ratio comparable to lzip level 5 or 6—lzip level 9 remains better in that regard.

With brand new Guile bindings to zstd, we were able to add zstd support to guix publish and guix substitute. But what policy should be adopted for the official substitute server at ci.guix.gnu.org?

Our goal is to maximize substitute download speed. In some configurations, for example on relatively slow connections, fetching lzip substitutes is not CPU-bound; in those cases, fetching lzip substitutes remains the fastest option. And of course, there are these other configurations where lzip decompression is the limiting factor, and where we’d rather fetch a slightly less compressed zstd substitute (or even a much less compressed gzip substitutes, sometimes).

The solution we came up with is a naive but efficient solution: client-side adaptive compression selection. When it fetches and decompresses a substitute, guix substitute monitors its CPU usage as reported by times. If the user time to wall-clock time ratio is close to one, that probably means the substitute fetch and decompression process was CPU-bound; in that case, choose a compression method that yields faster decompression next time—assuming the substitute server offers several options. Conversely, if CPU usage is close to zero, the process is probably network-bound, so next time we’ll choose a better-compressed option.

The official server at ci.guix.gnu.org now provides zstd-compressed substitutes in addition to lzip and gzip. An extra complication is that we cannot drop gzip compression just yet because pre-1.1.0 Guix installations understand nothing but gzip. To ease transition, the server will probably offer substitutes in all three compression formats for one more year or so.

There’s a good reason to upgrade your daemon though: you’ll be able to benefit from those zstd substitutes and if you have high bandwidth, you’ll quickly see the difference!

Grabbing substitutes from your neighbors

When it comes to increasing download speeds, another option is to download from your neighbors rather than from a server far away. This is particularly useful at the workplace, where machines around you are likely to already have the store items you’re looking for, or, say, at Guix gatherings—at least when we can meet physically again…

The idea had been floating around for some time as a direct benefit of reproducible builds and co-maintainer Mathieu Othacehe recently implemented it. As Mathieu explains in his blog post, guix publish can now advertise itself on the local network using the mDNS/DNS-SD protocol via Avahi; when guix-daemon is passed the --discover option, guix substitute automatically discovers local substitute servers and adds them as the preferred download location. The Guix System installation image even allows you to enable it to speed up the installation process:

Enabling substitute server discovery when installing Guix System.

Again, that only speeds things up if substitute servers use a compression method with fast decompression, and with either a cache or fast compression if they compress things on the fly. Zstd comes in handy for that: Guillaume’s measurements show that zstd compression is inexpensive at low compression levels, while achieving higher compression ratios than gzip.

Going further

Put together, these changes have the potential to noticeably improve user experience. But as I wrote in the introduction, it’s not revolutionary either—users still have to download all these things.

The next big step might come from fetching substitutes over peer-to-peer, content-addressed networks such as IPFS or GNUnet. Their content-addressed nature could allow users to download less. The performance characteristics of these networks is less clear though.

There is still value in a plain HTTP-based substitute protocol like the one currently used that is easy to set up, though. In that spirit, an option would be to “upgrade” the existing substitute protocol to take advantage of content-addressability. After all, the daemon already performs file-level deduplication and there’s a fair amount of identical files between subsequent builds of the same package. So… what if we only downloaded those files not already available locally? This idea is appealing but we need to go beyond the prototyping phase to get a better idea of its viability.

For completeness, another option currently investigated by the Nix developers is that of “content-addressed derivations”. While currently store file names contain a hash of the inputs used to produce them, the idea of content-addressed derivations is to make it a content hash; that way, if an input change has no effect on the build result, the output is the same and nothing needs to be re-downloaded (this is what Eelco Dolstra described as the intensional model in Chapter 6 of his seminal PhD thesis). This option is appealing, also for other reasons, but it’s a fundamental change with what looks like a high implementation complexity and transition cost. We have yet to gauge the pros and cons of following this approach.

Until then, we hope Guix 1.2.1 will bring your faster substitutes and happiness!

About GNU Guix

GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom. Guix can be used on top of any system running the Hurd or the Linux kernel, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, and AArch64 machines.

In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. When used as a standalone GNU/Linux distribution, Guix offers a declarative, stateless approach to operating system configuration management. Guix is highly customizable and hackable through Guile programming interfaces and extensions to the Scheme language.

26 March, 2021 02:00PM by Ludovic Courtès

FSF News

March 25, 2021

Andy Wingo

here we go again

Around 18 months ago, Richard Stallman was forced to resign from the Free Software Foundation board of directors and as president. It could have been anything -- at that point he already had a history of behaving in a way that was particularly alienating to women -- but in the end it was his insinuation that it was somehow OK if his recently-deceased mentor Marvin Minsky, then in his 70s or 80s, had sex with a 17-year-old on Jeffrey Epstein's private island. A weird pick of hill to stake one's reputation on, to say the least.

At the time I was relieved that we would finally be getting some leadership renewal at the FSF, and hopeful that we could get some mission renewal as well. I was also looking forward to the practical implications would be for the GNU project, as more people agreed that GNU was about software freedom and not about its founder.

But now we're back! Not only has RMS continued through this whole time to insist that he runs the GNU project -- something that is simply not the case, in my estimation -- but this week, a majority of a small self-selected group of people, essentially a subset of current and former members of the FSF board of directors and including RMS himself, elected to reinstate RMS to the board of the Free Software Foundation. Um... read the room, FSF voting members? What kind of message are you sending?

In this context I can only agree with the calls for the entire FSF board to resign. The board is clearly not fit for purpose, if it can make choices like this.

dissociation?

I haven't (yet?) signed the open letter because I would be in an inconsistent position if I did so. The letter enjoins people to "refuse to contribute to projects related to the FSF and RMS"; as a co-maintainer of GNU Guile, which has its origins in the heady 1990s of the FSF but has nothing to do any more with RMS, but whose copyrights are entirely held by the FSF, is hosted on FSF-run servers, and is even obliged (GPLv3 §5d, as referenced by LGPLv3) to print out Copyright (C) 1995-2021 Free Software Foundation, Inc. when it starts, I must admit that I contribute to a project that is "related to the FSF". But I don't see how Guile could continue this association, if the FSF board continues as it is. It's bad for contributors and for the future of the project.

It would be very tricky to disentangle Guile from the FSF -- consider hosting, for example -- so it's not the work of a day, but it's something to think about.

Of course I would rather that the FSF wouldn't allow itself to be seen as an essentially misogynist organization. So clean house, FSF!

on the nature of fire

Reflecting on how specifically we could have gotten here -- I don't know. I don't know the set of voting members at the FSF, what discussions were made, who voted what. But, having worked as a volunteer on GNU projects for almost two decades now, I have a guess. RMS and his closest supporters see themselves as guardians of the flame of free software -- a lost world of the late 70s MIT AI lab, reborn in a flurry of mid-80s hack, but since 25 years or so, slipping further and further away. These are dark times, in their view, and having the principled founder in a leadership role can only be a good thing.

(Of course, the environment in the AI lab was only good for some. The treatment of Margaret Hamilton as recounted in Levy's Hackers shows that not all were welcome. If this were just one story, I would discount it, but looking back, it does seem to be part of a pattern.)

But is that what the FSF is for today? If so, Guile should certainly leave. I'm not here for software as perfomative nostalgia -- I'm here to have fun with friends and start a fire. The FSF should look to do the same -- look at the world we are in, look where the energy is now, and engage in real conversations about success and failure and tactics. There is a world to win and doubling down on RMS won't get us there from here.

25 March, 2021 12:22PM by Andy Wingo

March 24, 2021

www-zh-cn @ Savannah

Letter to support RMS

This is the email I sent to <info@fsf.org>, cc  <directors@fsf.org>

Dear FSF,

I write this letter to support Dr. Richard Stallman as a board member of FSF.

Dr. Richard Stallman has been a strong leader in Free Software Movement ever since the beginning of free software. He has been always thinking from the free software point of view, and has been constantly promoting free software and free software community. This is what we need in Free Software Foundation. This is what we need to inspire people to work for the goal of Free Software Foundation.

I am expecting Dr. Richard Stall to do his best in FSF and wish him all the best.

best regards,
wxie

24 March, 2021 07:03AM by Wensheng XIE

March 22, 2021

parallel @ Savannah

GNU Parallel 20210322 ('2002-01-06') released [stable]

GNU Parallel 20210322 ('2002-01-06') [stable] has been released. It is available for download at: http://ftpmirror.gnu.org/parallel/

No new functionality was introduced so this is a good candidate for a stable release.

Please help spreading GNU Parallel by making a testimonial video like Juan Sierra Pons: http://www.elsotanillo.net/wp-content/uploads/GnuParallel_JuanSierraPons.mp4

It does not have to be as detailed as Juan's. It is perfectly fine if you just say your name, and what field you are using GNU Parallel for.

Quote of the month:

  GNU Parallel is my new favorite thing
    -- Will Tejeda @thewilltejeda

 

New in this release:

  • Bug fixes and man page updates.

News about GNU Parallel:

  • The very first version of Parallel dated 2002-01-06 was found in an old backup:

  #!/usr/bin/perl

  $processes=shift;

  chomp(@jobs=<>);
  for (@jobs) {
      $jobnr++;
      push @makefile,
      (".PHONY : job$jobnr\n",
       "job$jobnr :\n",
       "\t$_\n");
  }
  unshift @makefile, "all : ",(map { "job$_ " } 1 .. $jobnr),"\n";

 

  open (MAKE, "| make -k -f - -j $processes") || die;
  print MAKE @makefile;
  close MAKE;

Get the book: GNU Parallel 2018 http://www.lulu.com/shop/ole-tange/gnu-parallel-2018/paperback/product-23558902.html

GNU Parallel - For people who live life in the parallel lane.

If you like GNU Parallel record a video testimonial: Say who you are, what you use GNU Parallel for, how it helps you, and what you like most about it. Include a command that uses GNU Parallel if you feel like it.

About GNU Parallel

GNU Parallel is a shell tool for executing jobs in parallel using one or more computers. A job can be a single command or a small script that has to be run for each of the lines in the input. The typical input is a list of files, a list of hosts, a list of users, a list of URLs, or a list of tables. A job can also be a command that reads from a pipe. GNU Parallel can then split the input and pipe it into commands in parallel.

If you use xargs and tee today you will find GNU Parallel very easy to use as GNU Parallel is written to have the same options as xargs. If you write loops in shell, you will find GNU Parallel may be able to replace most of the loops and make them run faster by running several jobs in parallel. GNU Parallel can even replace nested loops.

GNU Parallel makes sure output from the commands is the same output as you would get had you run the commands sequentially. This makes it possible to use output from GNU Parallel as input for other programs.

For example you can run this to convert all jpeg files into png and gif files and have a progress bar:

  parallel --bar convert {1} {1.}.{2} ::: *.jpg ::: png gif

Or you can generate big, medium, and small thumbnails of all jpeg files in sub dirs:

  find . -name '*.jpg' |
    parallel convert -geometry {2} {1} {1//}/thumb{2}_{1/} :::: - ::: 50 100 200

You can find more about GNU Parallel at: http://www.gnu.org/s/parallel/

You can install GNU Parallel in just 10 seconds with:

    $ (wget -O - pi.dk/3 || lynx -source pi.dk/3 || curl pi.dk/3/ || \
       fetch -o - http://pi.dk/3 ) > install.sh
    $ sha1sum install.sh | grep c82233e7da3166308632ac8c34f850c0
    12345678 c82233e7 da316630 8632ac8c 34f850c0
    $ md5sum install.sh | grep ae3d7aac5e15cf3dfc87046cfc5918d2
    ae3d7aac 5e15cf3d fc87046c fc5918d2
    $ sha512sum install.sh | grep dfc00d823137271a6d96225cea9e89f533ff6c81f
    9c5198d5 31a3b755 b7910ece 3a42d206 c804694d fc00d823 137271a6 d96225ce
    a9e89f53 3ff6c81f f52b298b ef9fb613 2d3f9ccd 0e2c7bd3 c35978b5 79acb5ca
    $ bash install.sh

Watch the intro video on http://www.youtube.com/playlist?list=PL284C9FF2488BC6D1

Walk through the tutorial (man parallel_tutorial). Your command line will love you for it.

When using programs that use GNU Parallel to process data for publication please cite:

O. Tange (2018): GNU Parallel 2018, March 2018, https://doi.org/10.5281/zenodo.1146014.

If you like GNU Parallel:

  • Give a demo at your local user group/team/colleagues
  • Post the intro videos on Reddit/Diaspora*/forums/blogs/ Identi.ca/Google+/Twitter/Facebook/Linkedin/mailing lists
  • Get the merchandise https://gnuparallel.threadless.com/designs/gnu-parallel
  • Request or write a review for your favourite blog or magazine
  • Request or build a package for your favourite distribution (if it is not already there)
  • Invite me for your next conference

If you use programs that use GNU Parallel for research:

  • Please cite GNU Parallel in you publications (use --citation)

If GNU Parallel saves you money:

About GNU SQL

GNU sql aims to give a simple, unified interface for accessing databases through all the different databases' command line clients. So far the focus has been on giving a common way to specify login information (protocol, username, password, hostname, and port number), size (database and table size), and running queries.

The database is addressed using a DBURL. If commands are left out you will get that database's interactive shell.

When using GNU SQL for a publication please cite:

O. Tange (2011): GNU SQL - A Command Line Tool for Accessing Different Databases Using DBURLs, ;login: The USENIX Magazine, April 2011:29-32.

About GNU Niceload

GNU niceload slows down a program when the computer load average (or other system activity) is above a certain limit. When the limit is reached the program will be suspended for some time. If the limit is a soft limit the program will be allowed to run for short amounts of time before being suspended again. If the limit is a hard limit the program will only be allowed to run when the system is below the limit.

22 March, 2021 10:17PM by Ole Tange

FSF Blogs

March 21, 2021

www @ Savannah

The WWWorst App Store

The WWWorst App Store

by Alexandre Oliva

Picture the most abusive app store.

Programs in it are meant to run on your own computer.

However, you have to be online to run them.

Every time you start them, they contact the app store.

If there is an updated version, it's installed automatically, no questions asked. You'd rather run the earlier version? Tough.

If the app store decides you're no longer welcome, the program won't start any more.

If the app store servers are offline, or if you are, it won't start either. Read more...

21 March, 2021 01:32PM by Dora Scilipoti

poke @ Savannah

GNU poke 1.1 has been released

I am happy to announce a new release of GNU poke, version 1.1.

This is a bug fix release in the poke 1.x series, and is the result of
all the user feedback we have received since we did the first public
release.  Our big thanks to everyone who provided feedback :)

See the file NEWS in the released tarball for a detailed list of
changes in this release.

The tarball poke-1.1.tar.gz is now available at
https://ftp.gnu.org/gnu/poke/poke-1.1.tar.gz.

  GNU poke (http://www.jemarch.net/poke) is an interactive, extensible
  editor for binary data.  Not limited to editing basic entities such
  as bits and bytes, it provides a full-fledged procedural,
  interactive programming language designed to describe data
  structures and to operate on them.

This release is the product of a month of work resulting in 70
commits, made by 10 contributors.

Thanks to the people who contributed with code and/or documentation to
this release.  In certain but no significant order they are:

   Bruno Haible
   Egeyar Bagcioglu
   Luca Saiu
   Sergei Trofimovich
   Kostas Chasialis
   Mohammad-Reza Nabipoor
   Morten Linderud
   Sergio Durigan Junior
   Thomas Weißschuh

My gratitude to you all!  It is a real pleasure to hack with you.

And this is all for now.
Happy poking!

--
Jose E. Marchesi
Frankfurt am Main
21 March 2021

21 March, 2021 09:49AM by Jose E. Marchesi

Amin Bandali

LibrePlanet 2021: Jami and how it empowers users

I am giving my very first LibrePlanet talk today on March 20th. I will be talking about Jami, the GNU package for universal communication that respects the freedoms and privacy of its users. I'll be giving an introduction to Jami and its architecture, sharing important and exciting development news from the Jami team about rendezvous points, JAMS, the plugin SDK, Swarm chats, and more; and how these features each help empower users to communicate with their loved ones without sacrificing their privacy or freedom.

Here is the abstract for my talk, also available on the LibrePlanet 2021's speakers page:

Jami is free software for universal communication that respects the freedoms and privacy of its users. Jami is an official GNU package with a main goal of providing a framework for virtual communications, along with a series of end-user applications for audio/video calling and conferencing, text messaging, and file transfer.

With the outbreak of the COVID-19 pandemic, working from home has become the norm for many workers around the world. More and more people are using videoconferencing tools to work or communicate with their loved ones. The emergence of these tools has been followed by many questions and scandals concerning the privacy and freedom of users.

This talk gives an introduction to Jami, a free/libre, truly distributed, and peer-to-peer solution, and explains why and how it differs from all other existing solutions and how it empowers users.

I have been an attendee of LibrePlanet for some years, and am very excited to be giving my first ever talk at LibrePlanet 2021 this year! You can watch my talk and other speakers' talks live this weekend, from the LibrePlanet 2021 - Live page. Attendance is gratis (no cost), and you can register at https://u.fsf.org/lp21-sp.

Presentation slides: pdf (with notes) | bib
sources: tar.gz | zip

I hope to see you around this year's all-online LibrePlanet conference this weekend!

LibrePlanet is a conference about software freedom, happening March 20 through 21, 2021. The event is hosted by the Free Software Foundation (FSF), and brings together software developers, law and policy experts, activists, students, and computer users to learn skills, celebrate free software accomplishments, and face upcoming challenges. Newcomers are always welcome, and LibrePlanet 2021 will feature programming for all ages and experience levels.

21 March, 2021 05:15AM by bandali

March 20, 2021

FSF Blogs

March 18, 2021

GNU Guix

Risk of local privilege escalation via guix-daemon

A security vulnerability that can lead to local privilege escalation has been found in guix-daemon. It affects multi-user setups in which guix-daemon runs locally.

It does not affect multi-user setups where guix-daemon runs on a separate machine and is accessed over the network via GUIX_DAEMON_SOCKET, as is customary on cluster setups. Exploitation is more difficult, but not impossible, on machines where the Linux protected hardlinks feature is enabled, which is common — this is the case when the contents of /proc/sys/fs/protected_hardlinks are 1.

Vulnerability

The attack consists in having an unprivileged user spawn a build process, for instance with guix build, that makes its build directory world-writable. The user then creates a hardlink to a root-owned file such as /etc/shadow in that build directory. If the user passed the --keep-failed option and the build eventually fails, the daemon changes ownership of the whole build tree, including the hardlink, to the user. At that point, the user has write access to the target file.

Fix

This bug has been fixed. See below for upgrade instructions.

The fix consists in adding a root-owned “wrapper” directory in which the build directory itself is located. If the user passed the --keep-failed option and the build fails, the guix-daemon first changes ownership of the build directory, and then, in two stages, moves the build directory into the location where users expect to find failed builds, roughly like this:

  1. chown -R USER /tmp/guix-build-foo.drv-0/top
  2. mv /tmp/guix-build-foo.drv-0{,.pivot}
  3. mv /tmp/guix-build-foo.drv-0.pivot/top /tmp/guix-build-foo.drv-0

In step #1, /tmp/guix-build-foo.drv-0 remains root-owned, with permissions of #o700. Thus, only root can change directory into it or into top. Likewise in step #2.

The build tree becomes accessible to the user once step #3 has succeeded, not before. These steps are performed after the package build scripts have stopped running.

Upgrading

On multi-user systems, we recommend upgrading the guix-daemon now.

To upgrade the daemon on Guix System, run something like:

guix pull
sudo guix system reconfigure /run/current-system/configuration.scm
sudo herd restart guix-daemon

On other distros, use something like this:

sudo --login guix pull
sudo systemctl restart guix-daemon.service

Conclusions

One of the flagship features of GNU Guix is to enable unprivileged package management, which includes building packages. Building occurs in an isolated build environment. This environment is isolated from the rest of the system not only to control the build process to implement the functional packaging model, but also to protect the system from package build scripts.

Despite our best efforts, there is always the possibility that we have overlooked something, as in this case.

This issue is tracked as bug #47229; you can read the thread for more information.

We are grateful to Nathan Nye of WhiteBeam Security for reporting this bug.

Please report any issues you may have to guix-devel@gnu.org. See the security web page for information on how to report security issues.

About GNU Guix

GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom. Guix can be used on top of any system running the Hurd or the Linux kernel, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, and AArch64 machines.

In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. When used as a standalone GNU/Linux distribution, Guix offers a declarative, stateless approach to operating system configuration management. Guix is highly customizable and hackable through Guile programming interfaces and extensions to the Scheme language.

18 March, 2021 01:00PM by Ludovic Courtès and Leo Famulari

March 12, 2021

www @ Savannah

Let's Fight Back Nonfree JavaScript!

LibreJS Blocks JavaScript, But the Site Will Not Function

Here are some Guidelines and Suggestions to Fix That


Write site-specific extensions to replace sites' JavaScript code

Many websites damage users' freedom by sending nonfree JavaScript programs to the user's browser. We invite volunteers to develop free browser extensions to replace for the JavaScript sent by particular sites (see the lists below).

Our first response to the problem of nonfree JS code was to develop LibreJS, which enables Firefox-based browsers to detect and block that code. That protects us from running a site's nonfree JS programs, but does not make the site actually function. Writing an extension for it, as we propose here, would achieve that. It would also avoid the risk inherent in running software straight off someone else's website.

We could also solve the problem by convincing the webmasters to correct their sites to function without the JavaScript code, but convincing them proves to be very difficult, since mostly they don't understand the issue, let alone care about it. Maybe recommending use of these extensions for their sites will convince them to pay attention to supporting non-JavaScript access.

Therefore we invite volunteers to pick a site and write a browser extension to make that site function, assuming that LibreJS blocks the nonfree JavaScript sent by the site.

The first thing to do is to look briefly at the licenses of the JavaScript files on the site. Some of them might actually be free software. If some of the JS code sent by the site is free, you can include it in your extension, changing it as needed.

Next, check whether the site has published an API. If so, it is best to communicate using the API, if that can do the job. Otherwise, you need to use the browser debugging facilities to figure out what data and commands the JavaScript code sends to the server—in effect, its undocumented API.

The way to avoid infringing copyright on the site's own JavaScript code is not to study the code. Not any part of it, not even once. If you did not read the code, it follows that you did not copy any of it. Look only at the licenses.

These extensions should be honest—they should not “cheat.” If the site's JavaScript asks the user for information and sends it, the extension should ask the user for that information and send it. If the site asks per (1) to check a box to agree to XYZ, the extension should ask per to check a box to agree to XYZ. The extension should faithfully pass on whatever responses the user enters. If the site sends a cookie, the extension should let it be handled according to the browser settings for cookies.

It is impossible to implement real security via JS code sent to the user, but whatever the site does to try to implement something resembling security, the extension should carry out faithfully. In particular, if the site asks the user to answer questions to prove perself not to be a robot, the extension should show per the same questions, get the answers, and send them in—thus enabling per to demonstrate that perse is human.

Jeff Carpenter's librecaptcha might be useful if the site sends a captcha. We will start a project to convert it to JS, and we will need volunteers for that, so please write to me if you are interested in helping.

Meanwhile, if the site's JS code gathers information surreptitiously, it is admirable to thwart that snooping. One idea is to ask the user what answer to return—for example, “The site is trying to find out your location. What do you want to tell it?” But it would be good to avoid asking the user frequently or repeatedly.

When you have an extension working, please mail a copy to the GNU Project at <js-extensions@gnu.org>. You can also register it in Firefox's extensions list, if you can stomach running the nonfree software to do that.

We have set up a mailing list, js-extensions-discussion where you can talk with others who are developing extensions.

Once things are going, we would like to set up a savannah.gnu.org repo where we will put the extensions that are working. To do that, we need a volunteer or two to manage it. We expect this task not to be a lot of work; the reason to have two is for redundancy.

We could also have a Savannah project which you could (if you wish) use for developing an extension; that too would require volunteers to take care of it.

Here are some suggestions for sites to write extensions for. However, if some other site interests you more, by all means go where your interests take you. Read more...

12 March, 2021 07:53AM by Dora Scilipoti

March 10, 2021

FSF Blogs

GNU MediaGoblin

MediaGoblin 0.11.0: Punky Magmalian

Punky Magmalian Portrait
“Punky Magmalian Portrait” by Charlotte Koch (reproduced with permission)

This release of MediaGoblin removes support for Python 2 and marks the end of five years of concurrent support for both Python 2 and Python 3. That’s a major achievement, so congratulations to everyone who contributed.

As a bonus, the release also includes a completely rewritten replacement for the previously Python 2-only audio spectrograms feature. Thank you to Fernando Gutierrez for this contribution; it’s a significant piece of work. The release also includes contributions from Jeremy Bowman, Jesús Eduardo Estupiñan Medina, Charlotte Koch, Olivier Mehani, milquetoast and Ben Sturmfels.

On reflection, the Python 3 transition has been bitter-sweet. Without doubt, Python 3 is both technically and ergonomically superior to Python 2, but I don’t think anyone in the Python community realised quite how long or how much work the transition would be. It’s been an especially challenging time for small projects like MediaGoblin and for anyone supporting a significant Python codebase on limited resources. Looking forward though, ending support for Python 2 significantly simplifies the maintenance of the project, making it easier to add new features and prevent bugs. We’re really excited about this! Although we’re not bug-free yet, as of this release our test suite is passing 100% and we’ll be continuing with further quality improvements.

We would like to take this opportunity to acknowledge Boris Bobrov, project maintainer and long-time contributor. Boris recently retired from his maintainer role which he began in 2016. Thanks Boris for all your hard work, contributions and leadership, we really appreciate it!

This release is named Punky Magmalian after a character created by artist and MediaGoblin contributor Charlotte Koch. Take a look at Charlotte’s other work on her MediaGoblin site.

For more details on this release and on upgrading see the release notes. To join us and help improve MediaGoblin, please visit our getting involved page.

10 March, 2021 06:00AM by Ben Sturmfels

March 08, 2021

GNUnet News

No GSoC projects in 2021

No GSoC projects in 2021

For 2021, GNU has not been selected as a GSoC organization. This also means that GNUnet GSoC projects will not be offered through the GSoC programme. Thanks to all of those interested in our proposed projects and their efforts in preparing proposals, including preliminary discussions with us. If you are still interested in tackling any of the proposed open issues, you are very welcome to do so.

08 March, 2021 11:00PM

Andy Wingo

99% spam

Hey all, happy new year apparently! A quick service update on the old wingolog. For some time the site has been drowning in spam comments, despite my best efforts to point a bayesian classifier at the problem.

I don't keep logs of the number of attempts at posting comments that don't pass the classifier. But what I can say is that since I put in the classifier around 4 years ago, about 2500 comments a year made it through -- enough to turn the comment section into a bit of a dump. Icky, right??

At the same time of course, that's too many comments to triage manually, so I never got around to fixing the problem. So in fact I had two problems: lots 'o spam, and lots 'o incoming spam.

With regards to the existing spam, I took a heavyhanded approach. I took a look at all good emails and URLs that people had submitted for comments prior to 2017, assuming they were triaged. Then I made a goodlist of comments since 2017 that had those comments or emails. There were very few of those -- maybe 50 or 70 or so.

Then I took a look at when comments were made relative to the posts. Turns out, 98.3% of comments were made more than 21 days after their parent post was published -- and sometimes years afterwards. I used that as a first filter, that if a post wasn't from a known poster, and was made 3 weeks or more after the post, I just classified it as spam.

The list of comments made within 3 weeks of the parent post was small enough for me to triage manually, and there I was able to save a bit of wheat from the chaff. In the end, though, the result of winnowing was less than 1% of what went in.

As I don't really want to babysit this wobsite, I'll keep this policy in place in the future -- comments will be open for a while after articles are posted. Hopefully that should keep the ol' wingolog in tidy shape going forward, while still permitting people to comment -- something I have really appreciated in the past.

So happy 2021 to everybody, may the vaccine gods shine upon your shoulders, and happy hacking :)

08 March, 2021 02:36PM by Andy Wingo

mit-scheme @ Savannah

MIT/GNU Scheme version 11.2 is released

This includes a bunch of bug fixes to 11.1, but is otherwise the same.

Download from the usual place.

08 March, 2021 07:38AM by Chris Hanson

March 03, 2021

denemo @ Savannah

Release 2.5 out now.

New Features

    MusicXML export
        Supports export of multi-movement scores

    Support for Musical Sketches
        Cut selection as sketch

    Support for LilyPond 2.20.0

    Menu Navigation from Keyboard enabled

    Comments in Lyric verses

Bug Fixes

    Various fixes in MusicXML import
    Various fixes in LilyPond import
    Wrong Keyboard Shortcuts on MacOS

03 March, 2021 10:32AM by Richard Shann

March 02, 2021

Applied Pokology

Padding and aligning data in GNU poke

It is often the case in binary formats that certain elements are separated by some data that is not really used for any meaningful purpose other than occupy that space. The reason for keeping that space varies from case to case; sometimes to reserve it for future use, sometimes to make sure that the following data is aligned to some particular alignment. This is known as "padding". There are several ways to implement padding in GNU poke. This article shows these techniques and discusses their advantages and disadvantages.

02 March, 2021 12:00AM

March 01, 2021

Learning the Poke language in Y minutes

Mohammad-Reza Nabipoor has written a nice short tutorial called "Learn the Poke Language in Y minutes". The tutorial has the form of a Poke program itself, and I think it really highlights the most uncommon (and useful!) features of our domain-specific language.

01 March, 2021 12:00AM

February 28, 2021

Amin Bandali

How I do my Computing

inspired by the computing page of rms

Computers

My librebooted ThinkPad X200 computer is the machine I use the most and where I do most of my computing. I also have the privilege of having access to a fleet of servers through our school's Computer Science Club that I use for some more computationally intensive tasks every now and again, and also for hosting this very website.

GNU/Linux distribution

I used a wide variety of distros over the years; but I have since found Trisquel to be my favourite and it's put my "distro-hopping" days behind me. Sometimes I pair it up with GNU Guix. For the kernel, I usually use GNU Linux-libre from jxself's APT repository.

Actual computing

I spend most of my time in GNU Emacs.

TODO: elaborate

Maintaining this site

I took a great amount of inspiration from technomancy's setup. The pages of this site are written in plain HTML using GNU Emacs, with GNU M4 acting as a full-featured template engine. A GNUmakefile provides convenient make rules to build and publish the site. The bibliography of my publications is generated from bandali.bib using bibtex2html, and further processed and put together using GNU sed and another GNUmakefile. The git repository containing all the sources used to build this site are available here.

28 February, 2021 12:00PM by bandali

February 26, 2021

poke @ Savannah

GNU poke 1.0 released

I am happy to announce the first release of GNU poke, version 1.0.

The tarball poke-1.0.tar.gz is now available at
https://ftp.gnu.org/gnu/poke/poke-1.0.tar.gz.

  GNU poke (http://www.jemarch.net/poke) is an interactive, extensible
  editor for binary data.  Not limited to editing basic entities such
  as bits and bytes, it provides a full-fledged procedural,
  interactive programming language designed to describe data
  structures and to operate on them.

This release is the product of 3 years of work resulting in 4126
commits, made by 19 contributors.

The program is far from being perfect and there are known bugs and
limitations in place.  We also have lots of awesome ideas still to be
implemented, extensions we want to add, pickles for many data formats
to write, documentation to improve, and lots of work in
progress... the GUI, the machine-interface... working in poke is so
fun that it is difficult to stop :'D

But it is time to start the releasing cycles so everyone can benefit
from poke, which is already immensely useful for many activities like
systems programming, testing of software, design and documentation of
file formats and protocols, reverse engineering, and much more.
Releasing often will hopefully also bring in more developers to our
little but enthusiastic community... there is so much to do!

In any case, we wish you have fun with poke and that you find it
useful.

Please send us comments, suggestions, bug reports, patches,
questions, complaints, bitcoins, or whatever, to poke-devel@gnu.org.

Many of the poke developers and users populate the #poke IRC channel
at irc.freenode.net, and you are more than welcome to join us there
and say hello.

Now it is time to mention the names of all the people who have
contributed with code and/or documentation to this release.  In
certain but no significant order they are:

   John Darrington
   Tim Rühsen
   Luca Saiu
   Bruno Haible
   Mohammad-Reza Nabipoor
   Eric Blake
   Egeyar Bagcioglu
   Kostas Chasialis
   Darshit Shah
   Dan Čermák
   David Faust
   Carlo Caione
   Henner Zeller
   Aurelien Aptel
   Indu Bhagat
   Darkstar
   Michael Drüing
   Pierre-Evariste Dagand

My gratitude to you all!  It is a real pleasure to hack with you.

Finally, as a personal note, I would like to dedicate this release to
my father Eduardo.  For this is also your work in a sense, and I love
you very much.

And this is all for now.
Happy poking!

--
Jose E. Marchesi
Frankfurt am Main
26 February 2021

26 February, 2021 10:06AM by Jose E. Marchesi

libredwg @ Savannah

libredwg-0.12.3 released

Add llvmfuzz and oss-fuzz integration, fixed many minor fuzzing errors. libfuzzer is much better than afl++ and honggfuzz.

See https://www.gnu.org/software/libredwg/ and https://github.com/LibreDWG/libredwg/blob/0.12.3/NEWS

Here are the compressed sources:
http://ftp.gnu.org/gnu/libredwg/libredwg-0.12.3.tar.gz (17.4MB)
http://ftp.gnu.org/gnu/libredwg/libredwg-0.12.3.tar.xz (9MB)

Here are the GPG detached signatures[*]:
http://ftp.gnu.org/gnu/libredwg/libredwg-0.12.3.tar.gz.sig
http://ftp.gnu.org/gnu/libredwg/libredwg-0.12.3.tar.xz.sig

Use a mirror for higher download bandwidth:
https://www.gnu.org/order/ftp.html

Here are more binaries:
https://github.com/LibreDWG/libredwg/releases/tag/0.12.3

Here are the SHA256 checksums:

47933ccc0230c66c571606f7a5897fa1fb0f664fba871b883f1a785783f58a33  libredwg-0.12.3.tar.gz
b31a33466ba23312119138d0ac022399841ee0f40d9bbd970410a2fc471e15ee  libredwg-0.12.3.tar.xz

[*] Use a .sig file to verify that the corresponding file (without the
.sig suffix) is intact. First, be sure to download both the .sig file
and the corresponding tarball. Then, run a command like this:

gpg --verify libredwg-0.12.3.tar.gz.sig

If that command fails because you don't have the required public key,
then run this command to import it:

gpg --keyserver keys.gnupg.net --recv-keys B4F63339E65D6414

and rerun the gpg --verify command.

26 February, 2021 09:23AM by Reini Urban

February 24, 2021

Applied Pokology

Using maps in GNU poke

Editing data with GNU poke mainly involves creating mapped values and storing them in Poke variables. However, this may not be that convenient when poking several files simultaneously, and when the complexity of the data increases. poke provides a convenient mechanism for this: maps and map files.

24 February, 2021 12:00AM

February 22, 2021

GNU Taler news

How to issue a Central Bank Digital Currency

2021-2: "How to issue a Central Bank Digital Currency" published

We are happy to announce the publication of our paper on "How to Issue a Central Bank Digital Currency" by the Swiss National Bank.

With the emergence of Bitcoin and recently proposed stablecoins from BigTechs, such as Diem (formerly Libra), central banks face a choice of either leaving the field to private actors or offering their own digital alternative to physical cash. We do not address whether a central bank should issue a central bank digital currency (CBDC). Instead, we demonstrate how a central bank could do so, if desired or needed. We propose a token-based system without distributed ledger technology and show how earlier-deployed, software-only electronic cash can be improved upon to preserve transaction privacy, meet regulatory requirements in a compelling way, and offer a level of quantum-resistant protection against systemic privacy risk. Neither monetary policy nor financial stability would be materially affected because our CBDC would replicate physical cash rather than bank deposits.

Download links

22 February, 2021 11:00PM

libredwg @ Savannah

libredwg-0.12.2 released

Minor bugfix:

  • Fixed extending the write buffer for the 2 CRC bytes. Occurs very seldomly (GH #315)

See https://www.gnu.org/software/libredwg/ and https://github.com/LibreDWG/libredwg/blob/0.12.2/NEWS

Here are the compressed sources:
  http://ftp.gnu.org/gnu/libredwg/libredwg-0.12.2.tar.gz   (17.4MB)
  http://ftp.gnu.org/gnu/libredwg/libredwg-0.12.2.tar.xz   (9MB)

Here are the GPG detached signatures[*]:
  http://ftp.gnu.org/gnu/libredwg/libredwg-0.12.2.tar.gz.sig
  http://ftp.gnu.org/gnu/libredwg/libredwg-0.12.2.tar.xz.sig

Use a mirror for higher download bandwidth:
  https://www.gnu.org/order/ftp.html

Here are more binaries:
  https://github.com/LibreDWG/libredwg/releases/tag/0.12.2

Here are the SHA256 checksums:

8b4c0ddbd52598c5849e2c4b267411e557f282f336ef497afc919d516c0c394e  libredwg-0.12.2.tar.gz
9227f4cb8a4aa1b785038e2c583affe0d84194c97dca4794e143258b0302fb85  libredwg-0.12.2.tar.xz
6fe27f0e1f73b8ba1c9eb20a9597fe2781207c68cb3f8883e52c60f7b3ea2c27  libredwg-0.12.2-win32.zip
92d6fddb5dbe108edf8381e8c87889edd082d1c75b48b30bda8ca1b5fab00628  libredwg-0.12.2-win64.zip

[*] Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact.  First, be sure to download both the .sig file and the corresponding tarball.  Then, run a command like this:

  `gpg --verify libredwg-0.12.2.tar.gz.sig`

If that command fails because you don't have the required public key, then run this command to import it:

  `gpg --keyserver keys.gnupg.net --recv-keys B4F63339E65D6414`

and rerun the `gpg --verify` command.

22 February, 2021 05:47PM by Reini Urban

February 21, 2021

parallel @ Savannah

GNU Parallel 20210222 ('Ang Sang Su Kyi') released

GNU Parallel 20210222 ('Ang Sang Su Kyi') has been released. It is available for download at: http://ftpmirror.gnu.org/parallel/

Please help spreading GNU Parallel by making a testimonial video like Juan Sierra Pons: http://www.elsotanillo.net/wp-content/uploads/GnuParallel_JuanSierraPons.mp4

It does not have to be as detailed as Juan's. It is perfectly fine if you just say your name, and what field you are using GNU Parallel for.

Quote of the month:

  GNU Parallel is a priceless timesaver
    -- June "Wakalix" @TWakalix@twitter

 

New in this release:

  • --filter only run jobs where the filter is true. The filter can contain replacement strings and Perl code such as: '{1} < {2}+1'
  • --template takes a text file as a template with replacement strings. Then it replaces the replacement strings and saves it under a new filename.
  • --plus implements {0%} {0#} replacement string for zero padded slot and sequence.
  • Warn that you probably mean -d '\r\n' if the first 3 values end in \r\n (DOS newline).
  • {= perlexpression =} must return the same value, if run twice on the same input.
  • Man pages available as .rst-format.
  • Bug fixes and man page updates.

News about GNU Parallel:

Get the book: GNU Parallel 2018 http://www.lulu.com/shop/ole-tange/gnu-parallel-2018/paperback/product-23558902.html

GNU Parallel - For people who live life in the parallel lane.

If you like GNU Parallel record a video testimonial: Say who you are, what you use GNU Parallel for, how it helps you, and what you like most about it. Include a command that uses GNU Parallel if you feel like it.

About GNU Parallel

GNU Parallel is a shell tool for executing jobs in parallel using one or more computers. A job can be a single command or a small script that has to be run for each of the lines in the input. The typical input is a list of files, a list of hosts, a list of users, a list of URLs, or a list of tables. A job can also be a command that reads from a pipe. GNU Parallel can then split the input and pipe it into commands in parallel.

If you use xargs and tee today you will find GNU Parallel very easy to use as GNU Parallel is written to have the same options as xargs. If you write loops in shell, you will find GNU Parallel may be able to replace most of the loops and make them run faster by running several jobs in parallel. GNU Parallel can even replace nested loops.

GNU Parallel makes sure output from the commands is the same output as you would get had you run the commands sequentially. This makes it possible to use output from GNU Parallel as input for other programs.

For example you can run this to convert all jpeg files into png and gif files and have a progress bar:

  parallel --bar convert {1} {1.}.{2} ::: *.jpg ::: png gif

Or you can generate big, medium, and small thumbnails of all jpeg files in sub dirs:

  find . -name '*.jpg' |
    parallel convert -geometry {2} {1} {1//}/thumb{2}_{1/} :::: - ::: 50 100 200

You can find more about GNU Parallel at: http://www.gnu.org/s/parallel/

You can install GNU Parallel in just 10 seconds with:

    $ (wget -O - pi.dk/3 || lynx -source pi.dk/3 || curl pi.dk/3/ || \
       fetch -o - http://pi.dk/3 ) > install.sh
    $ sha1sum install.sh | grep 3374ec53bacb199b245af2dda86df6c9
    12345678 3374ec53 bacb199b 245af2dd a86df6c9
    $ md5sum install.sh | grep 029a9ac06e8b5bc6052eac57b2c3c9ca
    029a9ac0 6e8b5bc6 052eac57 b2c3c9ca
    $ sha512sum install.sh | grep f517006d9897747bed8a4694b1acba1b
    40f53af6 9e20dae5 713ba06c f517006d 9897747b ed8a4694 b1acba1b 1464beb4
    60055629 3f2356f3 3e9c4e3c 76e3f3af a9db4b32 bd33322b 975696fc e6b23cfb
    $ bash install.sh

Watch the intro video on http://www.youtube.com/playlist?list=PL284C9FF2488BC6D1

Walk through the tutorial (man parallel_tutorial). Your command line will love you for it.

When using programs that use GNU Parallel to process data for publication please cite:

O. Tange (2018): GNU Parallel 2018, March 2018, https://doi.org/10.5281/zenodo.1146014.

If you like GNU Parallel:

  • Give a demo at your local user group/team/colleagues
  • Post the intro videos on Reddit/Diaspora*/forums/blogs/ Identi.ca/Google+/Twitter/Facebook/Linkedin/mailing lists
  • Get the merchandise https://gnuparallel.threadless.com/designs/gnu-parallel
  • Request or write a review for your favourite blog or magazine
  • Request or build a package for your favourite distribution (if it is not already there)
  • Invite me for your next conference

If you use programs that use GNU Parallel for research:

  • Please cite GNU Parallel in you publications (use --citation)

If GNU Parallel saves you money:

About GNU SQL

GNU sql aims to give a simple, unified interface for accessing databases through all the different databases' command line clients. So far the focus has been on giving a common way to specify login information (protocol, username, password, hostname, and port number), size (database and table size), and running queries.

The database is addressed using a DBURL. If commands are left out you will get that database's interactive shell.

When using GNU SQL for a publication please cite:

O. Tange (2011): GNU SQL - A Command Line Tool for Accessing Different Databases Using DBURLs, ;login: The USENIX Magazine, April 2011:29-32.

About GNU Niceload

GNU niceload slows down a program when the computer load average (or other system activity) is above a certain limit. When the limit is reached the program will be suspended for some time. If the limit is a soft limit the program will be allowed to run for short amounts of time before being suspended again. If the limit is a hard limit the program will only be allowed to run when the system is below the limit.

21 February, 2021 09:58PM by Ole Tange

February 18, 2021

Mike Gran

Guile Potluck 2021

 Hello All-

In celebration of the (slightly belated) 10-year anniversary of Guile v2.0, we're having another Guile Potluck!  The Guile Potluck is a randomly annual event to give people a chance to show off their Guile projects and skills.  Think of it as a game jam, but, not constrained to games. 

To participate, on or before Mar 6, send an email to guile-user@gnu.org with Potluck in the subject line. Please include instructions on how to find your entry, which could be anything you like.  For example,

   - a script showing off some feature of Guile or your favorite Guile library
   - a blog post describing something interesting about Guile
   - an updated release of a neglected library
   - a mini-game
   - a graphical or audio demoscene-type demo
   
There probably won't be any prizes.  But there will definitely be an e-mail and blog post about the entries.

I'd love to see y'all participate. Feel free to e-mail me at spk121@yahoo.com if you'd like to discuss anything directly.

And please forward this info along, if you know of any other corners of the internet that might be interested.

Regards,
Mike Gran



18 February, 2021 08:09PM by Mike (noreply@blogger.com)

February 14, 2021

health @ Savannah

GNU Health Hospital Management component 3.8 released!

Dear community:

I am very proud to announce the release of the series 3.8 from the GNU Health Hospital Management Information System (HMIS) component!

Twelve years old, the GNU Health project has now become a Libre digital Health ecosystem, with different solutions to meet different realities, integrating them in the Federation.

The year 2020, the year of the COVID-19 pandemic, has put our societies against the ropes, and challenging the public health system of every country around the globe.
The GNU Health community responded swiftly to this formidable challenge. Within hours of the official World Health Organization announcement, we were able to deliver the new ICD-10 codes of the COVID-19 disease; Include the pathology in the person record when it was confirmed by laboratory and setting the disease as a notifiable disease so the Min. of Health could have uptodate epidemiological information.

GNU Health has played a crucial role in many public health systems, not only by providing real-time observatory of COVID-19, but also, very importantly, study the impact of the socioeconomic conditions in both the incidence and severity of the disease on the underprivileged.

Our community keeps growing! A notable example is that GNU Health is now also part of the KDE community! KDE has adopted MyGNUHealth, the GH Personal Health record.
We are very grateful to KDE for trusting us! Most GNU/Linux users will have in their favorite GNU/Linux distribution a Personal Health Record focused on privacy and integrated with Libre devices and trackers. MyGNUHealth also runs on the PinePhone!

What is new in GNU Health 3.8 series

  • New Dentistry package with odontogram and dental procedures
  • Enhanced Page of Life generation (PoL)
  • Use FODT (Flat ODT) format for reports
  • Integrated infectious diseases Contact Tracing
  • Epidemiological observatory
  • International Classification of diseases, 11th revision (ICD-11)
  • Improved integration with Weblate (now 23 languages!)
  • Updated the UNIPROT protein natural variants DB from 2020
  • The HL7 FHIR server is now ported to Python3
  • New repositories for the components (HMIS, client, plugins, Thalamus...)

Development focus

In addition of the GH HMIS server, we will focus the development in the following  areas of the GNU Health ecosystem:

  • MyGNUHealth: The GNU Health application for desktop and mobile devices
  • The GNU Health Federation Portal

The GH Federation Portal has already started. It is a VueJS application and provides a single point of entry for individuals, health professionals and epidemiologists to the GNU Health Information system.

The GNU Health Federation integrates information from many health institutions and people from a region or country. The GH Federation portal will allow to manage resources, as well as the main point for analytics and reporting of massive demographics and epidemiological data generated nationwide. People, health centers and research institutions can benefit from the GNU Health Federation and from the GNU Health ecosystem in general.

Upgrading from GNU Health 3.6

  • Make a FULL BACKUP your kernel, database and attach directories !!!
  • Follow the instructions on the Wikibooks.

As always, no matter how hard we try to avoid them, there will be bugs, so please test the new system, upgrade process, languages, and give us your feedback via them via health@gnu.org

The community server has been already migrated to 3.8.0, so you just need to download the GNU Health HMIS client and enjoy it.

Free Software day

Finally, today is the Free Software day. We have chosen this date as the release date of the GH HMIS component, as a way to remind and stress the importance of Libre Software and Open Science in our society.

Happy and Healthy Hacking !

--
Dr. Luis Falcon, M.D.
President, GNU Solidario
Advancing Social Medicine
https://www.gnuhealth.org

14 February, 2021 10:27PM by Luis Falcon

February 13, 2021

freeipmi @ Savannah

FreeIPMI 1.6.7 Released

FreeIPMI 1.6.7 - 02/12/21
-----------------------------------
o Do not require IPMI access when running ipmi-fru with the --fru-file option.
o Fix default permissions of various config and system files.
o Minor documentation updates.

https://ftp.gnu.org/gnu/freeipmi/freeipmi-1.6.7.tar.gz

13 February, 2021 10:45PM by Albert Chu

mailutils @ Savannah

Version 3.12

Version 3.12 of GNU mailutils is available for download.  This version includes the following bugfixes:

13 February, 2021 12:46PM by Sergey Poznyakoff

tar @ Savannah

Version 1.34

Version 1.34 of GNU tar is available for download (see the download directory for archives in other formats).  This version fixes the following bugs:

13 February, 2021 11:53AM by Sergey Poznyakoff

February 12, 2021

FSF Events

Sylvain Beucler

Godot GDScript REPL

When experimenting with Godot and its GDScript language, I realized that I missed a good old REPL (Read-Eval-Print Loop) to familiarize myself with the language and API.

This is now possible with this new Godot Editor plugin :)

Try it at:
https://godotengine.org/asset-library/asset/857

12 February, 2021 09:33AM

February 10, 2021

www-zh-cn @ Savannah

Free Software Foundation awarded perfect score from Charity Navigator, plus eighth consecutive four-star rating

Dear GNU CTT:

Thank you very much for the hard work in the past years.
Wish you all a good, happy and healthy Chinese New Year!

We are proud to know that:

Boston, Massachusetts, USA -- February 9th, 2021 -- The Free Software Foundation (FSF) has been awarded a four-star and 100% rating, the highest possible, from Charity Navigator, the largest independent evaluator of US-based nonprofit charities. The FSF was also selected for Charity Navigator's "Top Ten List" as one of "10 Charities Worth Watching." These designations exemplify the FSF's strong financial health and commitment to accountability and transparency.
Using objective analysis, Charity Navigator awards only the most fiscally responsible organizations a four-star rating, with metrics including governance, ethical practices, operations in accordance with industry best practices, and openness with donors and stakeholders. This is the eighth year in a row the FSF has received a four-star rating, a record attained by only six percent of the 160,000 charities evaluated by Charity Navigator. The FSF also earned perfect scores on "Financial Health" and "Accountability & Transparency," resulting in the organization's first-ever 100% rating, an accomplishment less than one percent of all charities evaluated by Charity Navigator are able to achieve. This is the second time the FSF has placed in the list of "10 Charities Worth Watching."
"The Free Software Foundation's exceptional four-star rating sets it apart from its peers and demonstrates its trustworthiness to the public,” according to Michael Thatcher, President and CEO of Charity Navigator. “Only a quarter of charities rated by Charity Navigator receive the distinction of our four-star rating. This adds the FSF to a preeminent group of charities working to overcome our world’s most pressing challenges. Based on its four-star rating, people can trust that their donations are going to a financially responsible and ethical charity when they decide to support the Free Software Foundation."
FSF executive director, John Sullivan, shared: "This is truly an accomplishment requiring the whole organization's efforts. It reflects excellence by our board of directors in its leadership, especially overseeing the FSF's financial management and key organizational policies, and by our whole staff, doing their work with exceptional efficiency and diligence, focused precisely on the FSF's mission. This is full validation of our supporters' confidence that when you contribute to the FSF, that hard-earned money will substantially advance the cause of software freedom."
The FSF's Charity Navigator profile can be visited at https://www.charitynavigator.org/index.cfm?bay=search.summary&orgid=8557.

10 February, 2021 01:30AM by Wensheng XIE

February 04, 2021

Riccardo Mottola

Arctic Fox 27.11.0 release

 This 2020 with COVID, quarantines and lockdown was and is a strange year, but it allowed me to take care of Arctic Fox quite a bit. A lot of work is going on in my Arctic Fox fork, which Matt dutifully imports.

Thousands of commits flew in into this new release, tackling JavaScript upgrades, build fixes, further metro removal, JIT optimizations. SO much was imported from Firefox that this is really exciting!

Arctic Fox continues to run very well on MacOS-X 10.7 for example, on my MacBook Pro:



But also Linux is fully supported, of course. 



Linux/PowerPC works as before, but still no JIT of course. Roy continues his fork with WindowsXP support which differs only by a minimal set of patches.


SPARC64 support was pursued, now NetBSD/SPARC64 compiles fully, but.... the browser crashes on startup. Help seeked!

The same goes for ARM, ARM64 and MIPS: we would love to get these platforms working again: they were probably lost in PaleMoon.


Arctic Fox thus continues the pursue of PaleMoon and Firefox heritage but with enhanced compatibility on more platforms, no Rust and legacy OS/Compiler support. If you like this, please help!

04 February, 2021 11:06AM by Riccardo (noreply@blogger.com)

February 01, 2021

FSF Events

LibrePlanet 2021: Empowering Users

Join us online for LibrePlanet 2021: Empowering Users, the FSF's annual conference on technology and social justice.

01 February, 2021 05:00AM