Planet GNU

www @ Savannah: Malware in Proprietary Software - 2024 Catch-up

Fri, 17 Jan 2025 19:04:37 +0000

The initial injustice of proprietary software often leads to further injustices: malicious functionalities.

The introduction of unjust techniques in nonfree software, such as back doors, DRM, tethering, and others, has become ever more frequent. Nowadays, it is standard practice.

We at the GNU Project show examples of malware that has been introduced in a wide variety of products and dis-services people use everyday, and of companies that make use of these techniques.

Here are our latest additions

November 2024

Malware In Cars

Kia cars were built with a back door that enabled the company's server to locate them and take control of them. The car's owner had access to these controls through the Kia server. This in itself is not objectionable. However, that Kia itself had such control is Orwellian, and ought to be illegal. The icing on the Orwellian cake is that the server had a security fault which allowed absolutely anyone to activate those controls for any Kia car. Many people will be outraged at that security bug, but this was presumably an accident. The fact that Kia had such control over cars after selling them to customers is what outrages us, and that must have been intentional on Kia's part.

BMW has retreated from making car owners pay for a subscription to the heated seats feature. Customers rejected it. Bravo for them! Instead BMW plans to require subscriptions for digital services and disservices—things related to the Orwellian tracking done by any “connected” car.

Proprietary Addictions

Dating apps exploit their users; fundamental features require an expensive subscription, and they are designed to be addictive.

Apple's Operating Systems Are Malware

A back door in Apple devices, present and abused from at least 2019 until 2023, allowed crackers to have full control over them by sending iMessage texts that installed malware without any action on the user's part. Infections, among other things, gave the intruders access to owners' microphone recordings, photos, location and other personal data.

July 2024

Proprietary Obsolescence

Spotify sold a music streaming device but they no longer support it. Due to its proprietary nature, it can no longer be updated or even used. Users requested Spotify to make the software that runs on the device libre, and Spotify refused, so these devices are now e-waste. Spotify is now offering refunds to save the purchasers from losing money on these products, but this wouldn't prevent the products from being e-waste, and wouldn't save users from being jerked around by Spotify. This is an example of how software that is not free controls the user instead of the user controlling the software. It is also an important lesson for us to insist the software in a device be libre before we buy it.

May 2024

Microsoft's Software is Malware

Microsoft is using malware tactics to get users to switch to their web browser, Microsoft Edge, and their search engine, Microsoft Bing. When users launch the Google Chrome browser Microsoft injects a pop up advertisement in the corner of the screen advising users to switch to Bing. Microsoft also imported users Chrome browsing data without their knowledge or consent.

April 2024

Malware In Cars

GM is spying on drivers who own or rent their cars, and give away detailed driving data to insurance companies through data brokers. These companies then analyze the data, and hike up insurance prices if they think the data denotes “risky driving.” For the car to make this data available to anyone but the owner or renter of the car should be a crime. If the car is owned by a rental company, that company should not have access to it either.

coreutils @ Savannah: coreutils-9.6 released [stable]

Fri, 17 Jan 2025 15:51:19 +0000

This is to announce coreutils-9.6, a stable release.
See the NEWS below for a summary of changes.

There have been 263 commits by 15 people in the 42 weeks since 9.5.
Thanks to everyone who has contributed!
The following people contributed changes to this release:

Bernhard Voelker (5)
Bruce Jerrick (1)
Bruno Haible (5)
Collin Funk (16)
Daniel Hofstetter (1)
Evgeny Nizhibitsky (1)
Lukáš Zaoral (1)
Masatake YAMATO (1)
Nikolaos Chatzikonstantinou (1)
Nikolay Nechaev (3)
Paul Eggert (123)
Pádraig Brady (95)
Richard Purdie (1)
Sam Russell (2)
Sylvestre Ledru (7)

Pádraig [on behalf of the coreutils maintainers]
==================================================================

Here is the GNU coreutils home page:
    https://gnu.org/s/coreutils/

Here are the compressed sources:
https://ftp.gnu.org/gnu/coreutils/coreutils-9.6.tar.gz   (15MB)
https://ftp.gnu.org/gnu/coreutils/coreutils-9.6.tar.xz   (5.9MB)

Here are the GPG detached signatures:
https://ftp.gnu.org/gnu/coreutils/coreutils-9.6.tar.gz.sig
https://ftp.gnu.org/gnu/coreutils/coreutils-9.6.tar.xz.sig

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

Here are the SHA1 and SHA256 checksums:

File: coreutils-9.6.tar.gz
SHA1 sum:   1da82e96486e0eedbd5257c8190f2cf9fcb71c2e
SHA256 sum: 2bec616375002c92c1ed5ead32a092b174fe44c14bc736d32e5961053b821d84

File: coreutils-9.6.tar.xz
SHA1 sum:   0ede2895e6089a02b67473b9761abcc18ce8dcb0
SHA256 sum: 7a0124327b398fd9eb1a6abde583389821422c744ffa10734b24f557610d3283

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 coreutils-9.6.tar.xz.sig

The signature should match the fingerprint of the following key:

pub   rsa4096/0xDF6FD971306037D9 2011-09-23 [SC]
        Key fingerprint = 6C37 DC12 121A 5006 BC1D B804 DF6F D971 3060 37D9
uid                   [ultimate] Pádraig Brady <P@draigBrady.com>
uid                   [ultimate] Pádraig Brady <pixelbeat@gnu.org>

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

gpg --locate-external-key P@draigBrady.com

gpg --recv-keys DF6FD971306037D9

wget -q -O- 'https://savannah.gnu.org/project/release-gpgkeys.php?group=coreutils&download=1' | gpg --import -

As a last resort to find the key, you can try the official GNU
keyring:

wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
gpg --keyring gnu-keyring.gpg --verify coreutils-9.6.tar.xz.sig

This release is based on the coreutils git repository, available as

git clone https://git.savannah.gnu.org/git/coreutils.git

with commit e2a405981ff5441dcfb217797699c94968218aca tagged as v9.6.

For a summary of changes and contributors, see:

https://git.sv.gnu.org/gitweb/?p=coreutils.git;a=shortlog;h=v9.6

or run this command from a git-cloned coreutils directory:

git shortlog v9.5..v9.6

This release was bootstrapped with the following tools:
Autoconf 2.72.70-9ff9
Automake 1.16.5
Gnulib 2025-01-17 2481e7a50d6535582856626b53009f419e2e05e2
Bison 3.8.2

NEWS

* Noteworthy changes in release 9.6 (2025-01-17) [stable]

** Bug fixes

cp fixes support for --update=none-fail, which would have been
rejected as an invalid option.
[bug introduced in coreutils-9.5]

cp,mv --update no longer overrides --interactive or --force.
[bug introduced in coreutils-9.3]

csplit no longer creates empty files given empty input.
[This bug was present in "the beginning".]

ls and printf fix shell quoted output in the edge case of escaped
first and last characters, and single quotes in the string.
[bug introduced in coreutils-8.26]

ls -l no longer outputs "Permission denied" errors on NFS
which may happen with files without read permission, and which resulted
in inaccurate indication of ACLs (missing '+' flag after mode).
[bug introduced in coreutils-9.4]

ls -l no longer outputs "Not supported" errors on virtiofs.
[bug introduced in coreutils-9.4]

mv works again with macFUSE file systems. Previously it would
have exited with a "Function not implemented" error.
[bug introduced in coreutils-8.28]

nproc gives more consistent results on systems with more than 1024 CPUs.
Previously it would have ignored the affinity mask on such systems.
[bug introduced with nproc in coreutils-8.1]

numfmt --from=iec-i now works with numbers without a suffix.
Previously such numbers were rejected with an error.
[bug introduced with numfmt in coreutils-8.21]

printf now diagnoses attempts to treat empty strings as numbers,
as per POSIX. For example, "printf '%d' ''" now issues a diagnostic
and fails instead of silently succeeding.
[This bug was present in "the beginning".]

pwd no longer outputs an erroneous double slash on systems
where the system getcwd() was completely replaced.
[bug introduced in coreutils-9.2]

'shuf' generates more-random output when the output is small.
[bug introduced in coreutils-8.6]

`tail --follow=name` no longer waits indefinitely for watched
file names that are moved elsewhere within the same file system.
[bug introduced in coreutils-8.24]

`tail --follow` without --retry, will consistently exit with failure status
where inotify is not used, when all followed files become inaccessible.
[This bug was present in "the beginning".]

`tail --follow --pid=PID` will now exit when the PID dies,
even in the presence of blocking inputs like unopened fifos.
[This bug was present in "the beginning".]

'tail -c 4096 /dev/zero' no longer loops forever.
[This bug was present in "the beginning".]

** Changes in behavior

'factor' now buffers output more efficiently in some cases.

install -C now dereferences symlink sources when comparing,
rather than always treating as different and performing the copy.

kill -l and -t now list signal 0, as it's a valid signal to send.

ls's -f option now simply acts like -aU, instead of also ignoring
some earlier options. For example 'ls -fl' and 'ls -lf' are now
equivalent because -f no longer ignores an earlier -l. The new
behavior is more orthogonal and is compatible with FreeBSD.

stat -f -c%T now reports the "fuseblk" file system type as "fuse",
given that there is no longer a distinct "ctl" fuse variant file system.

** New Features

cksum -a now supports the "crc32b" option, which calculates the CRC
of the input as defined by ITU V.42, as used by gzip for example.
For performance pclmul instructions are used where supported.

ls now supports the --sort=name option,
to explicitly select the default operation of sorting by file name.

printf now supports indexed arguments, using the POSIX:2024 specified
%<i>$ format, where '<i>' is an integer referencing a particular argument,
thus allowing repetition or reordering of printf arguments.

test supports the POSIX:2024 specified '<' and '>' operators with strings,
to compare the string locale collating order.

timeout now supports the POSIX:2024 specified -f, and -p short options,
corresponding to --foreground, and --preserve-status respectively.

** Improvements

cksum -a crc, makes use of AVX2, AVX512, and ARMv8 SIMD extensions
for time reductions of up to 40%, 60%, and 80% respectively.

'head -c NUM', 'head -n NUM', 'nl -l NUM', 'nproc --ignore NUM',
'tail -c NUM', 'tail -n NUM', and 'tail --max-unchanged-stats NUM’
no longer fail merely because NUM stands for 2**64 or more.

sort operates more efficiently when used on pseudo files with
an apparent size of 0, like those in /proc.

stat and tail now know about the "bcachefs", and "pidfs" file system types.
stat -f -c%T now reports the file system type,
and tail -f uses inotify for these file systems.

wc now reads a minimum of 256KiB at a time.
This was previously 16KiB and increasing to 256KiB was seen to increase
wc -l performance by about 10% when reading cached files on modern systems.

GNU Guix: Guix User and Contributor Survey 2024: The Results (part 1)

Thu, 16 Jan 2025 08:00:00 +0000

The results from the Guix User and Contributor Survey (2024) are in! This is the first time the Guix community has run this type of survey, and we're excited to share the results. The goal of the survey was to collect the views of both users and contributors, understanding how people adopt Guix, what they love and they're experiences contributing to the project.

There were 943 full responses to the survey, of this 53% were users and 32% were contributors. The table of survey participants is as follows:

**Table 1: Participant breakdown**
Category	Count	Percentage
User	496	52.60
Contributor	297	31.50
Previous user	92	9.76
Previous contributor	58	6.15

First, thank-you to everyone who made the effort to fill out the survey. For a volunteer community project it's fantastic to see over 900 people took part. It's notable that 150 people took the survey who were previous users or contributors — it's really great that people are willing to make this effort to share their experiences — thanks so much!

With this many participants we can see the range of view points and experience across our whole community, many of the comments were enlightening and are worth reading. There are links in many of the questions so anyone that's interested can go through them.

As the results are extensive I've split them into three separate posts, in this post we'll focus on the first 10 questions of the survey which focused on how users learnt about Guix and their experiences adopting it.

User backgrounds and experience

The survey started by asking participants, How knowledgeable a Linux are you? (Q1).

**Table 2: Participant's Linux knowledge**
Category	Count	Percentage
Beginner (e.g. just getting started)	18	2%
Explorer (e.g. comfortable installing it and using graphical apps)	18	2%
Intermediate (e.g. comfortable with the command-line and configuring many aspects)	445	47%
Advanced (e.g. you correct the Arch Linux Wiki!)	248	26%
Expert (e.g. able to contribute to large Free Software projects!)	212	22%
No answer	2	0.21%

Note that all the percentages in this table, and throughout the posts are rounded to make them easier to refer to.

Figure 1 shows this graphically:

Figure 1: Survey participants GNU/Linux knowledge

The next question (Q2) was, How long have you been using Guix?

**Table 3: Guix experience**
Category	Count	Percentage
Less than 1 year	245	26%
Between 1 and 2 years	218	23%
Between 2 and 4 years	234	25%
More than 4 years	160	17%
I've stopped using Guix	83	9%
No answer	3	0.3%

Figure 2 shows these results as a bar chart:

Figure 2: Survey participants GNU Guix experience

These two questions already tell us some interesting things about Guix users:

Guix users generally have a lot of Linux experience: 50% said they were Intermediates who were "comfortable with the command-line and configuring many aspects". A further 26% said they were Advanced, and 22% said they were experts.
Conversely, very few users (~4%) are beginners or exploring Linux users.
Many Guix users are new to Guix itself.
Guix's user-base is growing! Almost 75% of the user-base are recent converts to Guix, having used it for less than 4 years.
It's a similar distribution of users to Nix's. Their 2024 survey showed dramatic growth (~65%) in users from 0-2 years, Guix's is 49%.
It's fantastic to see new users are exploring and trying out Guix.
Unfortunately, 9% of users are no longer using Guix, but care enough to fill out the survey - so what can be done to help them come back?!

Adopting Guix

The next few questions explored how participants adopted Guix. It's important that new users have a great adoption experience so they'll keep using Guix. Conversely, if the initial experience is too difficult, they may simply move onto something else without seeing it's benefits!

The first question asked, (Q4) Why were you initially interested in Guix?

This question tells us what users had heard about Guix, and what they discovered during their initial investigation. The answers could impact how the project talks about Guix's strengths and capabilities.

For this question users could select more than one answer and many did so. The most selected choice was "Declarative configuration" where 82% of participants were interested in Guix because it had this quality. The option "Scheme, Guile, and Lisp are cool" was second, where 72% of the survey's participants were intrigued by Guix because of this aspect. The "Reproducibility" choice came third with 70% interested in this capability. The detailed results were:

**Table 4: Reason for adopting Guix**
Category	Count	Percentage
Reliability and transactions	537	57%
Declarative configuration	772	82%
Reproducibility	658	70%
Reproducible scientific workflows	199	21%
Fresh packages with latest versions	207	22%
Scheme, Guile and Lisp are cool	677	72%
Friendly community	256	27%
FSF certified project (100% Free Software)	404	43%
Alternative architectures (e.g. ARM)	90	10%
GNU Hurd	122	13%
Package management on another Linux distribution	319	34%
As a tool for packaging my own software	267	28%

There were 110 choices of 'Other' where participants could add their own comments, they're all available to read. Looking through them some themes came through:

Development environments:
- "General solution to rvm,pyenv etc"
- "As a Docker replacement for software development"
Documentation:
- "Initial interest in Nix, but hearing about Guix having more pleasant documentation also swayed me towards using Guix instead"
- "Documentation (not exhaustive but well-structured), simplicity of the CLI"
Free Software & GNU:
- "The possibility of releasing the GNU operating system version 1.0
- "100% free software yes, FSF no (FSFE are fine)"
- "Being a GNU project helped me decide between Guix and Nix."
Use for Continuous Integration:
- "used for CI, replacing docker with free software and user control"
Sandboxes and security:
- "Sandbox environment"
- "Security: containerized environments integrated in the OS."
Package definitions:
- "Writing packages for GNU Guix seemed more intuitive than for Gentoo Linux (Guix's hashes > Gentoo's slots)"
- "Ease of packaging"
An alternative to Nix:
- "Wanted to check out alternatives to Nix. Particularly interested in 1) grafting, 2) measures against ld.so stat storm, 3) performant guix packs without proot"
- "Use Nix a lot, want to explore that design space more"
Guile Scheme and Lisp:
- "One language for everything"
- "Not nixlang"
- "homogeneity of the configuration (one language for everything)"
Full source:
- "Full Source Bootstrap & Strict Policy to compile all software from source"
- "Full source auditability"

The next question the survey asked was, Which aspect of Guix did you initially adopt? (Q5). This is users initial entry point into using Guix.

The detailed results were:

**Table 5: Initial aspect of Guix adopted**
Category	Count	Percentage
Package manager on top of another Linux distro (guix package)	336	36%
Dotfiles and home environment management on another Linux distro (guix home)	41	4%
Isolated development and runtime environments on another Linux distro (guix shell)	58	6%
GNU/Linux distro as a graphical desktop (guix system)	434	46%
GNU/Linux distro as a server (guix system)	47	5%
As a software build and deployment tool (guix image, guix package or guix deploy)	16	2%
Other	9	1%

Figure 3 shows this as a bar chart:

Figure 3: Guix initial adoption aspect

The summary is that almost 50% of users initially experienced Guix as a GNU/Linux distro: 44% in a graphical desktop configuration and a further 5% in a server configuration. Just over a third of users (36%) initial experience Guix as a package manager on top of another Linux distro. I found this surprising as I'd expected most users to use Guix as a hosted package manager first, what an interesting result! We can also see there's lots of room to develop Guix Home as an adoption path.

Adoption challenges

Adopting any new technology is difficult and time-consuming, so discovering what elements users find difficult is important. Q7 delved into this by asking, What were the biggest challenges getting started with Guix?

The results were:

**Table 6: Adoption challenges**
Category	Count	Percentage
Installing Guix as a package manager on a GNU/Linux distribution	80	8%
Installing Guix System as a full Linux distribution	236	25%
Level of Linux knowledge needed to use Guix	102	11%
Difficulties with the reference material (i.e. the manual)	236	25%
Shortage of how-to tutorials and videos	297	32%
Shortage of examples (e.g. examples of usage)	431	46%
Inexperience with Lisp syntax and/or Guile Scheme	374	40%
Differences between Guix's approach and other Linux distros	321	34%
It was so long ago I can't possibly remember!	44	5%
Other	218	23%

Figure 4 shows this as a bar chart:

Figure 4: Guix adoption challenges

As we can see the biggest challenge is a Shortage of examples (e.g examples of usage). And, if we consider shortage of how-to tutorials (32%) to be similar then overall we can see there's a clear need for focused goal-orientated documentation with examples. Inexperience with Lisp syntax and or Guile Scheme and Differences between Guix's approach and other Linux distros both speak to the unique nature of Guix and the approach it takes: perhaps there are implications for how Guix's tooling can make initial adoption as easy as possible.

There were 218 comments, which are worth reading through. I've summarised them into broad themes:

Conceptual complexity: comments about the overall knowledge required being too much. Examples are:

"Understanding the concepts on which guix runs"
"managing storage space, generations, GC roots, profiles; generally grasping the concepts"
"Some interesting free software is only available for other distros, it's hard to adapt to a system without file system hierarchy"

Lack of drivers: issues caused by drivers not being available. Examples are:

"can't really use linux-libre on the machine I installed it on (lack drivers)"
"Getting an initial installation with working non-free wifi"
"hiding nonguix"

Efficiency: comments regarding overall resource usage making Guix slow or unusable. Example comments are:

"The evaluation of Guix is slow and resource-intensive. My laptop was no match for it, I had to change it."
"Guix experimentation is still too slow. Make experimenting faster for new users by identifying rate limiting steps and speeding them up"
"Slow network when download guix substitute"

Missing packages and services: issues where Guix doesn't contain a required package or service.

"missing packages I needed and getting them upstreamed after I packaged them"
"Unpackaged free software, and nonfree software"
"Coming from Nix: smaller, less up-to-date package set, substantially fewer home services"

Quality and reliability: issues of quality and reliability that made Guix difficult to use. Some comments:

"hard time fixing config errors with reports"
"Broken integration between some components (packages and services)"
"Basic setup is pretty easy on paper, but in practice sometimes it breaks my system and I need to fiddle with shell profiles and environment variables and installing extra packages to get Guix programs play nice with native programs. And I feel like this kind of breakage isn't acknowledged or addressed enough."

Practical guides, how-to's and examples: situations where a lack of direct instructions or examples made Guix difficult to use.

"Guix-unique bugs and issues that I can't find an answer to online"
"Lack of docs mostly, common patterns, the fact that's it's a pain the butt to make things works for some ecosystems on the Guix distro (e.g any app written in Golang, Rust, JS,TS..)"

Error messages: poor experience caused by error messages that are difficult to understand. Example comments:

"Horrible error messages"
"Difficult guile scheme error messages!!"
"Hard-to-understand error messages"

Configuring on a hosted distribution): issues caused when using Guix on top of another distribution. Some comments:

"I found the setting of numerous variables and the comments recommending I do so contradictory and so confusing"
"SELinux blocked installation of packages: remount"
"Problems using it on a foreign distro. Guix Home particularly assumes that you are using guix system, I had to tweak the .profile a lot to get it working."

Encrypted boot / LUKS: encryption in various forms unavailable or missing certain features:

"Very poor support for full disk encryption."
"Also using a LUKS encrypted root file-system was a challenge at the time i started Guix"

Language ecosystems (e.g. Rust, PHP): issues due to missing packages, or attempts to package, from certain language ecosystems.

"Missing packages, and the difficulty of packaging rust or npm packages on guix dissuaded me from contributing them"

Mac availability: situations where being unavailable on Mac meant Guix could not be adopted.

"Linux only. nix has macos support too which would help adoption in a team environment."
"No MacOS official distribution"

Adoption satisfaction score

The survey asked (Q6), How satisfied were you with your experience adopting Guix?

This question explores the users overall satisfaction with the initial steps of researching, installing and initially using Guix. The question asked the participant to score their satisfaction on one of 5 levels.

**Table 7: Guix adoption satisfaction**
Category	Count	Percentage
Very Dissatisfied	22	2%
Dissatisfied	113	12%
Neutral	154	16%
Satisfied	408	43%
Very Satisfied	226	24%
Can't remember	20	2%

See Figure 5 for a visual representation:

Figure 5: Guix initial adoption satisfaction bar chart

This is probably the most important question in the entire survey when it comes to growing the number of Guix users. Overall, it's positive with Very Satisfied (24%) and Satisfied (43%) meaning that the majority of users are happy with their initial experience. The comments above show there's lots of room to find small ways to move users initial experience from Satisfied to being overjoyed! Unfortunately, on the other end of the scale 14% of users who were unhappy and the 16% neutral show some of the bigger challenges!

Which GNU/Linux distribution do you use Guix on?

As we saw earlier just over a third of users (36%) initial adopt Guix as a package manager on top of another GNU/Linux distribution. Question 8 asked, Which GNU/Linux distribution did you use Guix on top of?

The results:

**Table 8: Hosting Linux distributions**
Category	Count	Percentage
Alpine Linux	9	0.95%
Arch Linux	81	8.59%
Fedora Linux	33	3.50%
Gentoo Linux	19	2.01%
NixOS	22	2.33%
Ubuntu	111	11.77%
Other	170	18.03%

I errored when creating this question and somehow missed out Debian! Over 117 answers in the 'Other' category said Debian so it's the most popular distribution to use Guix on, Ubuntu is second (111) and then Arch Linux was third (81). There were also plenty of mentions of OpenSUSE, RHEL/CentOS and Void Linux.

Why did you stop using Guix?

Question 9 was targeted at those that had previously used Guix but had stopped. It asked, You previously used Guix but stopped, why?

This was a comment question and we got some fantastic answers. There were 147 comments from participants, which lines up well with the 150 people who took the survey and classed themselves as a 'Previous user' or 'Previous contributor'.

This was a free form text answer, the full comment are well worth a read through . As before I've clustered the comments into themes:

Complexity of maintenance too high: many commented that the overall experience of using Guix was too time-consuming and complex. A slow configuration feedback loop, inefficiency, and the overall maintenance burden were all concerns. Example comments:

"I needed to switch to a distribution that required less of my attention when I started my new job. I switched to NixOS with the intention of going back to Guix at a later date, but I am now reliant on so many parts of the nix ecosystem that I don't think I'll ever actually switch back."
"I was doing more work trying to make my setup perfect or fix issues with it rather than working on my other projects. A lot of things with my setup either broke with time or were just not compatible (My setup couldn't handle printing, screen sharing, audio, suspending/hibernation and I just didn't know how to fix all that) and I couldn't deal with it any longer, I simply went back to whatever worked for me earlier."

Learning curve too difficult: many aspects of Guix are completely different from how other distributions achieve the same result. In some instances this learning curve was too difficult and/or there was not enough assistance. Example comments:

"Mainly the learning curve is huge for a long-time *nix systems user. I knew it would be difficult to adapt, but for each and every little thing I would need to go dig how to fix something. Doing proper power management on my laptop, setting up mail (I've been using Gnus for years, but still...!), compile and test mainline kernels on my laptop, etc. It's awesome to learn all those things, but they all require time. And that's where I had to give up: I wanted a (reliable) system I could use for my day-to-day work, Guix would be great... if I could spend a few weeks only learning it (and Lisp!)."
"But the problem ends up to be that the whole ecosystem around guix basically assumes super knowledge about what scheme is, how to use it and worse of all deep comfort and will to use emacs as the main interface to it all. It's too high of a hurdle to dedicate when just wanting to write some files, evaluate them, declare some packages, shells, etc. I have zero interest and will to use or learn emacs and putting it so much upfront does a huge disservice to the whole project."

Lack of drivers within the distribution: the lack of drivers to enable hardware was the most commented on specific issue. Some examples of those comments:

"As a long time Arch user I found it difficult to configure Guix for daily use. I need proprietary video drivers (and possibly other bits to get everything working?) and I don't remember if I ever got those up and running."
"I have a lot of respect for the technical side of the project, but the politics of free software absolutism (to the point where we are supposed to tell people to replace perfectly functional hardware in order to use Guix, instead of telling them about Nonguix) and the user hostile email based contribution workflow made me realize Guix would likely never reach critical mass, so my time is best applied elsewhere."

Unavailable proprietary software: proprietary software not being available was also mentioned (not quite as much as drivers), often in comments that focused on Guix not being practical as a distribution for professional use. Some specific comments:

"Lack of proprietary software, primarily CUDA, MKL, etc."
"Although I like FSF license purity, NixOS was much more amenable to get working on various hardware & did not preclude using Nvidia CUDA."

Efficiency and resource usage: there were comments about guix pull taking too long, whether this was actually the fault of Guix pull locally or remote servers, the overall experience was mentioned multiple times. Some example comments were:

"The core tooling was far too slow (e.g. pulling updates, etc.); Nix is slow, but nowhere near as slow as Guix (was back then, but I'm not aware of the kind of order of magnitude improvements that would have been required). Core functionality was not reliable enough for a server operating system (shepherd, logging, system rollback). Arcane contribution requirements (no provisions for non-Emacs users, e.g. regarding code formatting; baroque and counterproductive changelog and commit factoring requirements); I didn't mind the email/patch based workflow btw"
"Guix pull is too slow. The guix ci servers are inaccessible from my location, requiring a proxy. Guix System does not have a large enough community to be reliable and universal enough for daily use (in my opinion)"

Missing packages and services: there were lots of comments about both missing packages or services and this making it difficult to use Guix. Example comments:

"Much of the software I needed wasn't packaged, and it eventually became frustrating. I tried to package what I could, but some things felt extremely difficult, E.g., `jujutsu` `ghc`. However unfortunate it may be, I also rely on various pieces of nonfree software, and Guix was working against me in that regard. I do not like that I have to use nonfree software, but I often have no choice."
"Still use to some extent as package manager on foreign distro. For desktop use, waited for usable KDE Plasma packaging, and for laptop, coverage of working builds for ARM. Hoping to return; there is progress on both of these fronts. Size of store and speed of guix pull where also issues (on limited hardware)."

Out of date packages: meaning that although there was a package within Guix it was lagging, with particular concern about security implications. Example comments:

"Outdated or absent FOSS software (ex: Gnome, KDE, etc)"
"Too many packages updates were lagging behind, this was raising concerns for me from a security point of view"

Quality and reliability: general issues with quality and reliability that undermined the users belief that the project was ready for real use. Examples:

"An upgrade broke the system and crippled it from booting. Moved on to other distribution"
"I like the whole idea of guix. But it feels like it is not really ready."

Guix not fully supporting disk encryption: full disk encryption in a variety of forms came up multiple times as a Guix weakness. Examples:

"Guix does not support an unencrypted /boot partition. But also does not fully support LUKS2 due to grub."
"I love Guix System, but it still misses a few quality-of-life improvements, such as better support for full disk encryption on install (entering two passwords!) and faster servers for South America. I kid you not, it takes me several hours to install a base system with MATE!"

Missing guides/how-to's and examples: we've already seen that lack of specific how-to documentation was an issue, there were various comments to that:

"Examples were insufficient, documentation expected much more in-depth linux knowledge. I would like to try again using it, as I love the concepts of it and I find that I resonate with the people representing Guix, and while I am on NixOS currently I find some social aspects of the Nix project concerning."
"I switched back to NixOS due to more Community support"

Free Software as a constraint: Free Software and GNU as an organisation were commented on as a constraint to having a practical, usable system that met user's needs. Note that the next bullet is the reverse of this. Some example comments:

"No ease of access to the tools I depend on without jumping through hoops. VSCode, Chrome, Discord, all required flatpaks. Gnome was extremely out of date and didn't work well with flatpaks making it even harder to use them. NVIDIA drivers unavailable. I would have to work entirely around Guix to make it usable for the real world. I can't just convince my friends to stop using Discord. I can't just convince my job to not depend on VSCode extensions. I have spent my time using VSCode Calva for my personal Clojure projects as well. I would have to spend a lot of time creating my own repository and writing guix packages for everything just to make it usable for myself. The GNU should be trying to meet users where they are to help liberate them, instead of creating an alternate reality where user needs are not addressed. This is a non-starter in the year 2024."
"Exclusion of all references to non-free software (and no suggested step-by-step easy setup) made a full-featured initial installation untenable."

Not enough GNU: there were also some comments that the Guix project was not sufficiently supportive of GNU and/or Richard Stallman:

"I am disappointed that you veered off the course of freedom and added nonguix. Also that you hate on RMS."
"I stopped using Guix after it ran a campaign against Richard Stallman. I don't plan to return back."

Language ecosystem issues: as tools like Docker, and languages like Go and Rust become more important, friction with them is more of an issue for users:

"my use case is to package tooling for other distros and use it to build docker images reproducibly for use in CI environments. it does not work for this use case very well. can't run guix daemon inside a container"
"Lack of packages, stance on 100% reproducibility which makes packaging software with transitive dependencies hard, slow evaluator, obscure communication and collaboration mediums, patches take months to even get a review, cryptic error messages."

Nix is more modern or practical: many users seem to have explored Guix as an alternative to Nix. Example comments:

"I looked at Guix as an alternative to NixOS, and like its design a lot, but struggle with the 100% free software approach as I need some non-free software (for various reasons, hardware support, required by work, etc.). I'm aware of the non-guix channel which mostly solves this, but having to compile most things myself got too cumbersome for me — I wish there was a more complete substitute server for that channel, or perhaps even a derivation based on guix with a less strict free-software policy more akin to those of NixOS or debian."
"There were too many packages missing or so out of date as to be de-facto missing. Using Guix was therefore much harder to use than Nix, where I had more packages (both Free and non-Free) and they were more up to date."

Old-fashioned communications: here were some comments about communications within the project being old-fashioned, both from general users and those that had tried to contribute:

"There seems to be shortage of packages and slow development. Email or only free software is definitely an hindrance to many people to daily drive guix. It has become hit and miss for me, so staying with nixos as its rich and I can followup on its development easily on git repo, discourse, matrix and all."
"The main two reasons are that I find the irc/email/emacs flow very hard to work with and I do not feel safe in the mailing lists."

Unavailable on Mac OSX: there were a few comments that in a professional context the fact that Guix isn't available for MacOS made it difficult to use:

"Being unavailable on macOS. I have my nix home manager setup on both linux and macOS. Also the lack of a number of packages was a challenge. Like typst, bottom, hugo, tree, ruff, and sd for example. I am interested in becoming a maintainer but I want my setup to also work in macOS."

Incompatibility with hosting Linux distro: running Guix on top of another distribution was confusing, particularly for graphical programs:

"Guix home breaking Fedora. Troubles with binary applications due to the non-fsh nature."
"Setting up the package manager & daemon was confusing. The command "guix pull" felt excessively slow. A lot of packages were not up to date. Breaking the FHS"

Poor contributor experience: the patch process itself, slow reviews and inconsistency in response were all mentioned as issues. Examples:

"I still use Guix, but am a previous contributor. Important patches (for me) which I submitted were/are ignored, so I’ve stopped contributing."
"Perceived Inconsistent patch reviews. I did create couple of patches for guix, I do believe to contribute to project that I use. Sometimes I see patches getting stuck without feedback on them (not necessarily mine), the process to review patches is unclear to me and most likely to most people. Also guix lack automation to help everyone understand what is going on, if patches break rules, if this trivial change could be merged easily, etc. maybe it’s there for you, but I dont see that."
"I was passed over for commit access (even though I surpassed the 50 commit requirement) because I could only find 2 people to vouch for me, not 3. Then my patches stopped being merged, and some 2-year-pending patches I sent were closed without good reason. With the way Guix is run and how they treat contributors, it is an insulting/degrading process that I am no longer willing to put myself through."

As we can see there are a wide variety of reasons why users stopped using Guix, many of them are similar to the challenges that many users find, but they're even more powerfully felt by these users. It's really useful to have these themes and comments captured, as contributors may be able to pick up some of these issues and work to resolve them!

How important is Guix?

Focusing back on all users, the next question was, (Q10) How important is Guix in your computing environment?

There was a good range of answers:

**Table 9: Adoption challenges**
Category	Count	Percentage
Not using	97	10%
Tinkering	156	17%
Slightly important	147	16%
Moderately important	194	21%
Important	133	14%
Essential	216	23%

A visual representation:

Figure 6: Guix's importance in users computing environments

This is an interesting mixture which is probably reflective of many new users, and how Guix is used as a package manager on top of another distribution. Over a third of users consider it to be essential/important where it would be difficult to replace, while the bottom third are tinkering or exploring it.

Some thoughts

We've looked at the first 10 questions of the survey which covered the composition of the Guix community, initial adoption and satisfaction, and challenges that led to users moving away from Guix. The first thing to say is how fantastic the response has been to the survey, it's amazing to have over 900 participants!

Some big take-aways:

Interest in declarative configuration, reproducibility along with Scheme, Guile and Lisp are bringing in lots of new user - around 50% have been using Guix for less than 2 years
Guix users are knowledgable Linux users who are comfortable being hands-on with their system
Around 50% of users adopt Guix as a GNU/Linux distribution, 36% as a hosted package manager on top of another Linux distro
The survey produced great feedback from current and previous users on areas where the project can improve
Around 67% of users were satisfied (or very satisfied) with their initial adoption experience
Guix is essential or important for over a third of users, part of their environment for the next third, and being explored by the last 27% of users

The next post will cover more of the survey — which parts of Guix are most used, what sorts of deployments are being used, architectures and drivers details, and how users view contributing to the project financially.

freeipmi @ Savannah: FreeIPMI 1.6.15 released

Thu, 16 Jan 2025 06:56:27 +0000

o In ipmi-config, fix incorrect output of
IPv6_Dynamic_Address_Source_Type.
o In ipmi-oem, increase precision of Dell cumulative energy output.
o Do not advertise options that are only available when special debugging is compiled into FreeIPMI.
o Fix build errors with implicit-function-declaration.
o libfreeipmi: remove unnecessary / duplicate parameter checks.
o Fix gcc 14.x build failures.
o Minor documentation updates.

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

FSF Events: Free Software Directory meeting on IRC: Friday, January 17, starting at 12:00 EST (17:00 UTC)

Fri, 10 Jan 2025 16:30:34 +0000

Join the FSF and friends on Friday, January 17 from 12:00 to 15:00 EST (17:00 to 20:00 UTC) to help improve the Free Software Directory.

FSF News: Anchoring the FSF in its values

Fri, 10 Jan 2025 15:25:00 +0000

FSF Blogs: FSF associate members to decide the logo for the FSF's fortieth anniversary

Thu, 09 Jan 2025 13:40:00 +0000

GNUnet News: libgnunetchat 0.5.2

Tue, 07 Jan 2025 23:00:00 +0000

libgnunetchat 0.5.2 released

We are pleased to announce the release of libgnunetchat 0.5.2.
This is a minor new release bringing compatibility with the major changes in latest GNUnet release 0.23.0. A few API updates and fixes are included. Additionally the messaging client applications using libgnunetchat got updated to stay compatible. This release will also require your GNUnet to be at least 0.23.0 because of that.

Download links

The GPG key used to sign is: 3D11063C10F98D14BD24D1470B0998EF86F59B6A

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

Noteworthy changes in 0.5.2

Implement iteration of tags by chat contact
Adjust types and API to improve consistency
Add more test cases and fix some older test cases
Adjust IV derivation for file encryption/decryption key

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

Messenger-GTK 0.10.2

This minor release will add optional notification sounds and contact filtering via tags. But mostly the release is intended to reflect changes in libgnunetchat 0.5.2.

Download links

Keep in mind the application is still in development. So there may still be major bugs keeping you from getting a reliable connection. But if you encounter such issue, feel free to consult our bug tracker at bugs.gnunet.org .

messenger-cli 0.3.1

This release will apply necessary changes to fix build issues with libgnunetchat 0.5.2.

FSF Blogs: Psychological care should grant you freedom and protection

Tue, 07 Jan 2025 21:50:00 +0000

The rise of proprietary parenting apps promising to improve mental health is concerning. Psychological care should grant you all the freedoms and protection you deserve!

FSF Blogs: FSF associate members to decide the logo for the FSF's fortieth anniversary

Mon, 06 Jan 2025 21:25:00 +0000

remotecontrol @ Savannah: Hackers Terrify US Intelligence After Infiltrating Guam

Fri, 03 Jan 2025 22:18:25 +0000

https://www.bloomberg.com/news/features/2025-01-03/chinese-cyber-hackers-terrify-us-intelligence-after-infiltrating-guam

FSF Blogs: FSD meeting recap 2025-01-03

Fri, 03 Jan 2025 21:25:00 +0000

Check out the important work our volunteers accomplished at today's Free Software Directory (FSD) IRC meeting.

FSF Blogs: Free Software Supporter -- Issue 201, January 2025

Fri, 03 Jan 2025 18:10:00 +0000

Welcome to the Free Software Supporter, the Free Software Foundation's (FSF) monthly news digest and action update -- being read by you and 231,379 other activists.

mailutils @ Savannah: GNU Mailutils Version 3.18

Fri, 03 Jan 2025 16:38:15 +0000

Version 3.18 of GNU Mailutils is available for download.
A short summary of changes follows.

New debugging shortcut: all

Using all in mailutils debug level specification enables all debugging categories. Syntactically, all can be used wherever an actual category name is allowed, thus, e.g., all.!=prot enables all levels except prot in all debugging categories.

mail: fix and document interaction between mailutils configuration files and mail command files.

In particular, mail variables that correspond to some mailutils configuration settings, now correctly reflect their value.

Bugfixes

Minor fix in handling of the EHLO command in smtp client.
Improve docs.
Minor fix in mhn and related tests.
mail utility: use the mailer configuration capability.

FSF Events: Free Software Directory meeting on IRC: Friday, January 10, starting at 12:00 EST (17:00 UTC)

Thu, 02 Jan 2025 17:19:49 +0000

Join the FSF and friends on Friday, January 10 from 12:00 to 15:00 EST (17:00 to 20:00 UTC) to help improve the Free Software Directory.

FSF Events: Free Software Directory meeting on IRC: Friday, January 3, starting at 12:00 EST (17:00 UTC)

Thu, 02 Jan 2025 17:16:27 +0000

Join the FSF and friends on Friday, January 3 from 12:00 to 15:00 EST (17:00 to 20:00 UTC) to help improve the Free Software Directory.

www-zh-cn @ Savannah: Summary 2024

Wed, 01 Jan 2025 01:52:27 +0000

Dear GNU CTT:

Thank you for your contribution and effort.

I am very proud of the performance in 2024 for this team.

Here is summary from GNU translation team for 2024.

Dear GNU translators!

2024 repeated the general traits of 2023: most active teams kept doing
a good job updating the translations, and a few new translations were
made. Currently, the total amount of translations is over 3350.

      General Statistics

Most new translations were made by the Chinese (zh-cn) team this year;
then the Polish and French teams follow. The Turkish team, although
it published no new translations this year, made a notable progress
in terms of keeping its translation up-to-date.

The table below shows the number and size of newly translated
articles in important directories and typical number of outdated
GNUNified translations throughout the year.

+-team--+-----new-----+--outdated--+
| de   | 1 (9.7Ki) * | 124 (61%) |
+-------+-------------+------------+
| es   | 1 ( 5.2Ki) | 0.5 (0.2%) |
+-------+-------------+------------+
| fr   | 4 ( 42.0Ki) | 0.5 (0.1%) |
+-------+-------------+------------+
| ja   | 2 ( 9.9Ki) | 48 ( 34%) |
+-------+-------------+------------+
| pl   | 6 ( 85.4Ki) | 54 ( 37%) |
+-------+-------------+------------+
| ru   | 2 ( 20.7Ki) | 0.3 (0.1%) |
+-------+-------------+------------+
| sq   | 2 ( 17.1Ki) | 2.3 (2.9%) |
+-------+-------------+------------+
| tr   | 0 ( 0.0Ki) | 0.1 (0.1%) |
+-------+-------------+------------+
| zh-cn | 23 ( 543Ki) |     0 &    |
+-------+-------------+------------+
+-------+-------------+
| total | 39 ( 723Ki) |
+-------+-------------+

I wish you all a freer, healthier, and more peaceful 2025.

Happy hacking
wxie

Jose E. Marchesi: Algol 68 Front-End for GCC

Wed, 01 Jan 2025 00:00:00 +0000

Just posted a WIP series for an Algol 68 front-end for GCC. It is about time to have support for the best programming language ever designed in the best optimizing compiler ever made ;)

Thanks to Marcel van der Veer for his awesome parser, that I took the liberty to borrow from Algol 68 Genie. Free Software for the win!

WIP patch series in gcc-patches...

gcide @ Savannah: GCIDE version 0.54

Tue, 31 Dec 2024 12:23:54 +0000

Version 0.54 of GNU Collaborative International Dictionary of Englis is available for download.

The dictionary corpus underwent a thorough spell-checking. A number of articles has been fixed or upgraded. All files has been reformatted to limit physical line length to 72 characters.

If you are using GNU dico to consult the dictionary, please upgrade to version 2.12.

dico @ Savannah: GNU dico version 2.12

Tue, 31 Dec 2024 10:14:10 +0000

GNU dico version 2.12 is available for download.

This versions provides important improvements in the gcide module:

idxgcide skips duplicated headwords.
Fixed some gcide entities, introduced missing ones.
Fixed Ancient Greek transliteration.

New option: "watch"

When given this option, the module will watch for modifications in the dictionary corpus files and rebuild the index file when necessary.

HTML output

HTML output is enabled by the "html" module option. It is produced only after "OPTION MIME" command command.

Input conversions

The argument to DEFINE or MATCH command can optionally be modified before being used in actual search. This allows, for example, to input search terms in transliteration instead of in the actual script.

Conversions are implemented by loadable modules and are associated with individual databases.

This version is shipped with the new module greek_kbd, which implements Greek transliteration.

Dicoweb

Switch to Python 3.11+ with type hints
Upgrade Django to version 4.2
Improve desktop and mobile views using HTML5
Implement a dark mode
Use Poetry and pyproject.toml
Integrate Pylint and Mypy for development
Implement various fixes and improvements

pcre module now requires libpcre2

Support for obsolescent libpcre has been withdrawn.

GNU Artanis: Demystify GNU Artanis service deployment in product environment

Mon, 30 Dec 2024 06:51:47 +0000

GNU Guix: Adding a fully-bootstrapped Mono

Sun, 29 Dec 2024 23:00:00 +0000

We used to have a Mono package. It was introduced on August 8 2016 by commit 763b3d50b6249b43fceda51445bbeb1f5f5fd7d0, at Mono version 4.4.1.0, but it was later discovered in April of 2022 that the release tarball that it was built from included prebuilt binaries. Further research revealed that these binaries were not optional. Due to this, a decision was made to remove the Mono package, carried out on September 1, 2022.

We now once again have a Mono package, due to a patch series I submitted on November 29, which after some revisions was committed on December 22. This patch series introduced a full, 17-mono-package sequence that takes us from a mono-1.2.6 built fully from source to mono-6.12.0 built fully from source, using only packages that already have full bootstrap paths. I make no promise that this is the shortest or most optimal path, but it exists and I have verified it works.

As I've spent what is probably an unreasonable amount of time working toward this, I thought I'd share some of my thoughts, experiences, and commentary. Sorry in advance if it gets a bit rambly or lecture-ish.

Prologue

I started down this road because someone I'm working on a project with decided to depend on a C# package that requires C# 12.0 features, and my personal Mono package based on the tarball releases (which include bootstrap binaries) only went up to C# 7.0. This meant that the C# package in question de facto required strictly Microsoft's (er, I mean, "the .NET foundation"'s) .NET implementation — hereafter referred to as "dotnet" — and a very recent version no less. The bootstrapping story with dotnet is very bad; even beginning to untangle it would probably require a relatively modern C# compiler, and something that at least sort of understands MSBuild. And there's not much point to "bootstrapping" dotnet from something that isn't bootstrapped itself. So I figured I may as well start with Mono.

History

While Mono is today probably the most well-known alternative to Microsoft's .NET offerings, it is not the only one. Indeed, in the early 2000s there were at least 2 competing free software implementations: Mono, and DotGNU's Portable.NET (abbreviated pnet). They differed in goals, licenses, and methods: Portable.NET was a GNU project concerned with, among other things, limiting the ability of Microsoft to impose vendor lock-in via its proprietary .NET implementation and software patents. As a GNU project, it used the GPL for its runtime and compiler, and the GPL with a linking exception for its standard library, pnetlib. Mono, on the other hand, used a mix of many copyleft and permissive licenses: X11 for the standard library, GPL for the compiler (later dual-licensed to add an X11 option), and LGPL for the runtime, with GPL and LGPL code also offered "under commercial terms for when the GPL and the LGPL are not suitable". In 2016 after its acquisition by Microsoft, the runtime was relicensed to use the Expat (MIT) license.

But perhaps most importantly to us, while Mono opted to write its C# compiler, mcs, in... C#, Portable.NET's runtime and C# compiler were both written in C. Portable.NET along with the entire DotGNU project (except for LibJIT) was decommissioned in 2012, but the source is still available, and it still works fine (with a few modifications for compatibility with newer versions of its dependencies). In September of 2022, Adam Faiz submitted patches to package pnet and pnetlib, along with one of their dependencies named treecc. These packages were based on the last release of Portable.NET, version 0.8.0, released in 2007. I initially used these packages as the basis for my bootstrap efforts, and even managed to get mono-1.2.6 built using them, but later discovered that using a more recent version from git made it much easier. For example, while pnet-0.8.0 can do pointer arithmetic inside unsafe code blocks, it doesn't support the += or -= operators specifically, which requires lots of patching (after all, who would use x = x + y when you could do x += y?). There are many other similar improvements in the git version, so for this patch series I've decided to go with pnet-git.

The start

After building mono-1.2.6, I tried a few later versions, and the third or fourth one would always fail with errors about missing methods. It turns out that the reason for this is that, contrary to what their marketing suggests, C# and Java are not "write once, run everywhere". This is because their compilers rely on the details of the libraries that the program will be run with at compile-time. This is used, for example, to do overload resolution. Suppose, for example, that a certain implementation of the == operator is present in version 1.0 of a library, and then in version 2.0 of a library a more specific implementation is introduced. Now code that is compiled against version 2.0 may instead automatically reference the more-specific implementation, as is in accordance with the rules of C#. But when it is run with version 1.0, it will fail because that implementation doesn't exist. In my case, for some reason the initial mcs and core libraries being built to compile the rest of Mono were being compiled against a 2.0 library and then run with a 1.0 library. It turns out that this was because mcs uses mono's code for producing assemblies (.NET dlls and exes), and mono decides which version to put in an assembly it writes based on "which runtime version" is being used, and that version is decided at startup based on... the version that was put in the assembly it is running. So for example, mono-1.9.1 would produce 2.0 assemblies because mono-1.2.6 produced 2.0 assemblies because pnet produced 2.0 assemblies. So I modified Mono's runtime in mono-1.9.1 to allow for this version to be overridden via environment variable, and set it to v1.1.4322, and things went a lot more smoothly after that.

From there on it was mostly the usual trial-and-error process of identifying where things had bitrotted. I made sure to unvendor libgc wherever possible, though eventually by mono-4.9.0 they explicitly dropped support in their configure script for using any libgc other than what was bundled, so at that point I switched to using their homebrewed sgen garbage collector.

A concerning development

Once I got to mono-2.11.4, though, things took a turn for the interesting: Mono started using git submodules, and the (recursive? #t) clones were all failing. It turns out that this is because their submodules reference github.com using the git:// protocol.

This is notable for a few reasons.

First, GitHub dropped support for the git:// protocol in 2021, so recursive clones won't work now. This means I have to explicitly list out every submodule, its commit, and its sha256 hash, for every Mono version until they switched to using http or https. mono-2.11.4 has only 4 submodules, but that doesn't last for long: by mono-4.9.0 it has 14 submodules. A significant portion of these patches is just listing these submodules and their hashes. It's a bit annoying.

The more concerning reason, though, is why GitHub dropped support for the git:// protocol: it is unencrypted and unauthenticated. This is mitigated somewhat by the use of sha-1 hashes to identify commits in the referenced submodules, putting a significant computational burden on anyone who would try to alter what was fetched corresponding to a given submodule. Significantly more risky, though, is the process of updating submodules that use git:// URLs. It is quite unlikely that a developer is going to independently clone one of the submodules over https, navigate to a desirable commit, copy the sha-1 hash, and manually update the submodule reference's commit. They're far more likely to run cd submodule; git pull; cd ..; git add submodule; git commit ... or an equivalent.

Of course, any changes a network man-in-the-middle might try to make here would still be reflected in the commit history, so even if a developer did that, they or any of their fellow committers could spot anything strange or malicious and point it out. Also, the changes couldn't be propagated to others trying to pull them who weren't on a network path containing the MITM because the potentially-malicious commit wouldn't be present in the real submodule's repository. So the transparency of git clearly showing changes to text files, combined with the fact that surely no git hosting platform would just allow arbitrary entities to make whatever commits they want accessible under any arbitrary repository URL, rather mitigate this security issue.

This usage of git:// URLs lasted all the way until September 28, 2021, when GitHub's removal of support for it forced the developers to change them to https.

Meanwhile, in reality

On November 28, 2016, Mono added a submodule named roslyn-binaries. Unsurprisingly, it included binary blobs for Microsoft's Roslyn compiler (which I believe had been open-sourced shortly prior). From here on, Mono's build system would default to using these binaries for building on little-endian systems (though another compiler could be specified with the --with-csc configure flag). I happen to know that it is extremely unlikely that many Mono developers used this configure flag. I know this because the 5.0 series is an absolute pain in the neck to build from source, because they consistently depend on new C# features before they implement them.

To go on a brief tangent: does anyone remember back when youtube-dl was temporarily taken down from GitHub due to the RIAA's DMCA request? Many were unhappy about that. One such unhappy person made news when they made the full contents of youtube-dl's repository available to access through the DMCA request repository. It turns out that there are many actions that one can take on GitHub that will make arbitrary commits available under arbitrary repository URLs.

So, in reality, for the span of time from November 28, 2016 to September 28, 2021, anybody sitting on the network path between GitHub and any Mono developer updating the roslyn-binaries submodule could decide on any arbitrary new commit to be used. Of course, merely inspecting the diff for the commit will reveal nothing of use, because the contents are binary blobs. And not only are these blobs those of a compiler, they are the blobs of a compiler that is sure to be used to compile another compiler, which will then be redistributed as an opaque, non-bootstrappable binary blob to be used for compiling other compilers.

You would be hard-pressed to find a more fertile breeding ground for Ken Thompson / Trusting Trust attacks. If every agent of the NSA (and whatever other agencies, including those of other countries, had access to the appropriate network traffic) somehow failed to capitalize on 6 years of opportunity to compromise an entire software ecosystem using only a basic MITM of unencrypted traffic, they deserve to be sacked. Whether such an attack actually occurred or not, this is a case study in carelessness and why bootstrappability is so important; discovering all this made me quite worried about having used a Mono version built from blobs previously, and has convinced me that, as time-wasting and tedious as this project has been, it is nevertheless probably an important one.

Another note on roslyn-binaries

If you're going to write a self-hosting compiler, the least you can do is keep it self-hosting. Deciding to write a self-hosting compiler is a valid choice, of course, with its own merits and demerits, but there is something bitterly poetic about Mono starting out requiring specifically Microsoft's C# compiler in order to build (Mono did its initial bootstrapping using Microsoft's proprietary csc), achieving independence through self-hosting, being acquired by Microsoft, and thereafter coming crawling back to Microsoft's C# compiler once more before eventually dying.

The funny thing is that it's not even necessary. The dependencies on new C# features are all in Mono's standard library (which increasingly borrowed code from Microsoft's corefx library), not in Mono's compiler.

More binary submodules?

Even before roslyn-binaries, there was binary-reference-assemblies, which contained prebuilt "reference" blobs for the various versions of the standard libraries. These exist, I assume, precisely because of the library incompatibility problems regarding overloading that I mentioned earlier. While later versions of Mono included sources and a build system for producing these reference binaries, mono-4.9.0 and earlier did not. Mono's build system still demanded something to install, though, so I told it to use the real standard library of the input Mono version. When I did get to a Mono version that at least claimed to support regenerating the reference binaries, I found that it didn't work with mcs due to differences in which libraries had to be referenced, so I had to patch it to add a bunch of references determined through trial and error.

The xunit-binaries submodule was also added sometime before mono-5.1.0. This dependency makes it impossible to run the full test suite without binary blobs. Presumably for this reason, Debian elects to only run tests within the mono/mini/ and mono/tests/ subdirectories. For my part, I've disabled all tests except for those of mono-6.12.0, the final version, limited to the two aforementioned subdirectories. This is because it would take extra time for the builds, because several of the tests depend on binary blobs bundled into the Mono repository itself (which my thorough cleaning of all dlls and exes from the sources removes), because a large chunk of the tests depend on binary blobs in xunit-binaries in later versions, and because "expect some test failures" is part of the Mono documentation and I don't have the time to figure out for the Mono developers every reason why each of 17 versions of their test suite is broken.

The long march through the 5.0s

The 5.0 series was when Microsoft acquired Mono, and it shows. You'll notice I needed to introduce pre- packages for various versions because in several cases a tagged release could not build the following tagged release. For that matter, they couldn't build the pre- package either, but it at least took fewer patches to get them working. The reason for this is that Mono added a dependency on Microsoft's corefx library source code, and it usually started using C# features well before mcs was able to compile them. Because of this, despite taking 8 versions to get from 1.2.6 to 4.9.0, it took another 8 versions to get through the 5.0 series, and 5 of them required nontrivial patching to massage the source into a form compilable by mcs.

The final stretch

Eventually I realized that the dependencies on new features were all coming from corefx, not from Mono's compiler. Consequently, the only reason for this particular bootstrap-hostile ordering of builds is that it happened to be the order the Mono devs committed things. So I just cherry-picked every commit I could find touching mcs/mcs (magit was quite useful for this) and applied it to 5.10.0 to produce what is essentially the 6.12.0 compiler, then used it to jump straight to building 6.12.0.

Use of this technique earlier on in the bootstrap process may be of interest to anyone looking to shorten the chain of packages.

The finishing touches

My initial goal was to package dotnet, and I had tried to progress toward that from mono-4.9.0 for a period, but with no success. During that time, though, I did encounter a bug in Mono's xbuild condition parser, which I wrote a patch for, and included in mono-6.12.0.

I also discovered that xbuild would wrongly complain about missing references even when the proper assemblies were in MONO_PATH or MONO_GAC_PREFIX, because xbuild would erroneously only consider the path /gnu/store/...mono-6.12.0/lib/mono/gac when looking for global assembly caches, completely ignoring MONO_GAC_PREFIX. So I wrote a patch to fix that, and included it in mono-6.12.0.

Having witnessed how much nicer it is to package things that use rpath / runpath than things that use environment variables (like python) and therefore require constant wrapping of executables and use of propagated-inputs, I devised a patch that would extend Mono's per-assembly config files to support a <runpath> element. For example, if you have a file /tmp/dir2/test2.exe, and there is also a file /tmp/dir2/test2.exe.config, and its contents are

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <runpath path="/tmp/dir1"/>
</configuration>

and it references test1.dll, it will first look for it at /tmp/dir1/test1.dll. Note that, of course, test1.dll still needs to be accessible to the compiler at compile-time through MONO_PATH or an explicitly-specified path passed on the mcs command line.

It is my hope that this feature will be of use to anybody interested in developing a build system.

Future work

Mono had several difficult points in bootstrapping and packaging, but at the end of the day it still met the basic description of a software package: well-defined environment-supplied inputs and sources, a user-supplied install prefix, and files installed under that prefix.

The dotnet world is an entirely different beast. The first step of most build systems I have encountered from that realm is downloading an entire toolchain, among other dependencies, as a binary blob. They heavily depend on the exact packages they specify being available exactly where they say to install them. There is no "install", there are no "install directories" to my knowledge. A build that doesn't contact nuget.org is an aberration. I am at a loss how to build these things, much less package them. I badly need help.

There are also some portability issues with the current bootstrap path. While Portable.NET can fall back to an interpreter written in C where LibJIT isn't supported, old versions of Mono have no such capability. Strictly speaking, there is some bitrotted code for an interpreter that used to work, but has stopped working by mono-1.2.6. It was left unmaintained until it was eventually removed in 2014, only to be revived in 2017. This poses a dilemma for anybody wanting to bootstrap Mono on a platform that wasn't supported by mono-1.2.6's JIT compiler. There are a number of possible ways to try resolving this, ranging from backporting the new interpreter, to fixing up the old one for every version prior to the new interpreter, to forward-porting the old compiler and class libraries to the new interpreter, etc.

The most interesting option, though, in my opinion, would be to port mcs to Portable.NET. This would achieve the intended portability, while also allowing individual builds to be much faster since we're only building mcs, not the runtime and class library each time. It would also allow us to make much bigger version jumps, since, as we discovered earlier, many of the new C# feature dependencies in Mono come from the class library rather than the compiler. Such a shortened bootstrap could also make the bootstrap path more appealing for other distributions to use instead of binaries.

Closing thoughts

"You wish now that our places had been exchanged. That I had died, and DotGNU had lived?"
"... Yes. I wish that."

Maintenance of Mono was recently transferred over to WineHQ. With that announcement this statement was placed at https://www.mono-project.com:

"We want to recognize that the Mono Project was the first .NET implementation on Android, iOS, Linux, and other operating systems. The Mono Project was a trailblazer for the .NET platform across many operating systems. It helped make cross-platform .NET a reality and enabled .NET in many new places and we appreciate the work of those who came before us."

I would like to clarify that, according to Miguel de Icaza himself, DotGNU "started working on the system about the same time". According to this DotGNU newsletter, Portable.NET began "in January 2001". While it's unclear exactly when Portable.NET reached various milestones, and the significance of the various milestones varies somewhat (for example, Mono probably does not care that Portable.NET also includes a Java and C compiler), I think that there is cause to dispute the claim that Mono was "the first" .NET implementation on Linux.

On a related note, if we haven't looked at the possibility of using Portable.NET in the Java bootstrap process, it may be worth visiting at some point.

Thank you to the DotGNU project, for the .NET implementation that made this bootstrap possible, Adam Faiz, for the initial packaging of it that let me jump straight in, the Mono project, for... Mono, and you, for your time.

GNU Artanis: Demystify GNU Artanis service deployment in product environment

Sun, 29 Dec 2024 14:10:56 +0000

GNU Artanis: Build Artanis-0.6 on Ubuntu-24.04

Sat, 28 Dec 2024 11:48:57 +0000

GNU Artanis: MVC in GNU Artanis

Fri, 27 Dec 2024 17:49:16 +0000

FSF Events: Free Software Directory meeting on IRC: Friday, December 27, starting at 12:00 EST (17:00 UTC)

Tue, 24 Dec 2024 20:33:55 +0000

Join the FSF and friends on Friday, December 27 from 12:00 to 15:00 EST (17:00 to 20:00 UTC) to help improve the Free Software Directory.

parallel @ Savannah: GNU Parallel 20241222 ('Bashar') released [stable]

Tue, 24 Dec 2024 00:11:30 +0000

GNU Parallel 20241222 ('Bashar') has been released. It is available for download at: lbry://@GnuParallel:4

Quote of the month:

"Do this with gnu parallel" is the Copilot hack of the day
-- Chase Clark @chasingmicrobes.bsky.social

New in this release:

No new features. This is a candidate for a stable release.
Bug fixes and man page updates.

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 883c667e01eed62f975ad28b6d50e22a
    12345678 883c667e 01eed62f 975ad28b 6d50e22a
    $ md5sum install.sh | grep cc21b4c943fd03e93ae1ae49e28573c0
    cc21b4c9 43fd03e9 3ae1ae49 e28573c0
    $ sha512sum install.sh | grep ec113b49a54e705f86d51e784ebced224fdff3f52
    79945d9d 250b42a4 2067bb00 99da012e c113b49a 54e705f8 6d51e784 ebced224
    fdff3f52 ca588d64 e75f6033 61bd543f d631f592 2f87ceb2 ab034149 6df84a35
    $ 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:

(Have your company) donate to FSF https://my.fsf.org/donate/

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.

gtypist @ Savannah: GNU Typist 2.10 released

Mon, 23 Dec 2024 22:02:58 +0000

This is a major release

Changes in 2.10:

- new welcome screen
- new P lesson series for programmers
- fixes for various lessons
- new Romanian lessons
- expand the S lesson series with a new quotation and a few more passages from Shakespeare
- jump over whitespace characters at the beginning of lines in lessons
- fix the terminal resize bug
- fix a few compilation warnings
- add the Romanian translation
- updates to a few translations
- few updates to the documentation
- update the project license to GPL3+
- remove or update the lessons incompatible with the new license
- update the KTouch lesson import script
- fix warnings from help2man generated manual pages
- fix a few comments

Sources for this release can be downloaded here:

https://ftp.gnu.org/gnu/gtypist/gtypist-2.10.tar.gz

texinfo @ Savannah: Texinfo 7.2 released

Mon, 23 Dec 2024 18:37:03 +0000

We have released version 7.2 of Texinfo, the GNU documentation format.

It's available via a mirror (xz is much smaller than gz, but gz is available too just in case):

http://ftpmirror.gnu.org/texinfo/texinfo-7.2.tar.xz
http://ftpmirror.gnu.org/texinfo/texinfo-7.2.tar.gz

Please send any comments to bug-texinfo@gnu.org.

Full announcement:

https://lists.gnu.org/archive/html/bug-texinfo/2024-12/msg00043.html

Simon Josefsson: Guix Container Images for GitLab CI/CD

Wed, 18 Dec 2024 18:43:38 +0000

I am using GitLab CI/CD pipelines for several upstream projects (libidn, libidn2, gsasl, inetutils, libtasn1, libntlm, …) and a long-time concern for these have been that there is too little testing on GNU Guix. Several attempts have been made, and earlier this year Ludo’ came really close to finish this. My earlier effort to idempotently rebuild Debian recently led me to think about re-bootstrapping Debian. Since Debian is a binary distribution, it re-use earlier binary packages when building new packages. The prospect of re-bootstrapping Debian in a reproducible way by rebuilding all of those packages going back to the beginning of time does not appeal to me. Instead, wouldn’t it be easier to build Debian trixie (or some future release of Debian) from Guix, by creating a small bootstrap sandbox that can start to build Debian packages, and then make sure that the particular Debian release can idempotently rebuild itself in a reproducible way? Then you will eventually end up with a reproducible and re-bootstrapped Debian, which pave the way for a trustworthy release of Trisquel. Fortunately, such an endeavour appears to offer many rabbit holes. Preparing Guix container images for use in GitLab pipelines is one that I jumped into in the last few days, and just came out of.

Let’s go directly to the point of this article: here is a GitLab pipeline job that runs in a native Guix container image that builds libksba after installing the libgpg-error dependency from Guix using the pre-built substitutes.

test-amd64-latest-wget-configure-make-libksba:
  image: registry.gitlab.com/debdistutils/guix/container:latest
  before_script:
  - lndir /gnu/store/*profile/etc/ /etc
  - rm -f /etc/group
  - groupadd --system guixbuild
  - for i in $(seq -w 1 10); do useradd -g guixbuild -G guixbuild -d /var/empty -s $(command -v nologin) -c "Guix build user $i" --system guixbuilder$i; done
  - export HOME=/
  - export LANG=C.UTF-8
  - guix-daemon --disable-chroot --build-users-group=guixbuild &
  - guix archive --authorize < /share/guix/ci.guix.gnu.org.pub
  - guix archive --authorize < /share/guix/bordeaux.guix.gnu.org.pub
  - guix describe
  - guix package -i libgpg-error
  - GUIX_PROFILE="//.guix-profile"
  - . "$GUIX_PROFILE/etc/profile"
  script:
  - wget https://www.gnupg.org/ftp/gcrypt/libksba/libksba-1.6.7.tar.bz2
  - tar xfa libksba-1.6.7.tar.bz2
  - cd libksba-1.6.7
  - ./configure
  - make V=1
  - make check VERBOSE=t V=1

You can put that in a .gitlab-ci.yml and push it to GitLab and you will end up with a nice pipeline job output.

As you may imagine, there are several things that are sub-optimal in the before_script above that ought to be taken care of by the Guix container image, and I hope to be able to remove as much of the ugliness as possible. However that doesn’t change that these images are useful now, and I wanted to announce this work to allow others to start testing them and possibly offer help. I have started to make use of these images in some projects, see for example the libntlm commit for that.

You are welcome to join me in the Guix container images for GitLab CI/CD project! Issues and merge requests are welcome – happy hacking folks!

GNU Taler news: GNU Taler 0.14 released

Sun, 15 Dec 2024 23:00:00 +0000

We are happy to announce the release of GNU Taler v0.14.

libiconv @ Savannah: GNU libiconv 1.18 released

Sun, 15 Dec 2024 13:35:15 +0000

The GNU libiconv package provides the basis for character set conversion of text, for systems that don't use glibc.
It contains an implementation of the iconv() POSIX:2024 API and of the 'iconv' program, in a way that is mostly glibc compatible.

New in this release:

Many more transliterations, in particular also of Emoji characters.

The iconv_open function is now POSIX:2024 compliant: it recognizes a suffix //NON_IDENTICAL_DISCARD in the 'tocode' argument, with the effect that characters that cannot be represented in the target character set will be silently discarded. Whereas the suffix //IGNORE in the 'tocode' argument has the effect of discarding not only characters that cannot be represented in the target character set, but also invalid multibyte sequences in the input. Accordingly, the iconvctl function accepts requests ICONV_GET_DISCARD_INVALID, ICONV_SET_DISCARD_INVALID, ICONV_GET_DISCARD_NON_IDENTICAL, ICONV_SET_DISCARD_NON_IDENTICAL.

The iconv_open function and the iconv program now support multiple suffixes, such as //TRANSLIT//IGNORE, not only one.

GB18030 is now an alias for GB18030:2005. A new converter for GB18030:2022 is added. Since this encoding merely cleans up a few private-use-area mappings, you can continue to use the GB18030 converter, for backward compatibility. Its Unicode to GB18030 conversion direction has been enhanced, to help transitioning away from PUA code points.

When converting from/to an EBCDIC encoding, a non-standard way of converting newlines can be requested
- at the C level, by calling iconvctl with argument ICONV_SET_FROM_SURFACE or ICONV_SET_TO_SURFACE, or
- from the iconv program, by setting the environment variable ICONV_EBCDIC_ZOS_UNIX to a non-empty value.

Special support for z/OS: The iconv program adds a charset metadata tag to its output file. (Contributed by Mike Fulton.)

For conversions from UCS-2, UCS-4, UTF-16, UTF-32, invoking iconv(cd,NULL,NULL,...) now preserves the byte order state.

FSF Events: Free Software Directory meeting on IRC: Friday, December 20, starting at 12:00 EST (17:00 UTC)

Fri, 13 Dec 2024 15:40:00 +0000

Join the FSF and friends on Friday, December 20 from 12:00 to 15:00 EST (17:00 to 20:00 UTC) to help improve the Free Software Directory.

GNU Guix: The Shepherd 1.0.0 released!

Thu, 12 Dec 2024 12:00:00 +0000

Finally, twenty-one years after its inception (twenty-one!), the Shepherd leaves ZeroVer territory to enter a glorious 1.0 era. This 1.0.0 release is published today because we think Shepherd has become a solid tool, meeting user experience standards one has come to expect since systemd changed the game of free init systems and service managers alike. It’s also a major milestone for Guix, which has been relying on the Shepherd from a time when doing so counted as dogfooding.

To celebrate this release, the amazing Luis Felipe López Acevedo designed a new logo, available under CC-BY-SA, and the project got a proper web site!

Let’s first look at what the Shepherd actually is and what it can do for you.

At a glance

The Shepherd is a minimalist but featureful service manager and as such, it herds services: it keeps track of services, their state and their dependencies, and it can start, stop, and restart them when needed. It’s a simple job; doing it right and providing users with insight and control over services is a different story.

The Shepherd consists of two commands: shepherd is the daemon that manages services, and herd is the command that lets you interact with it to inspect and control the status of services. The shepherd command can run as the first process (PID 1) and serve as the “init system”, as is the case on Guix System; or it can manage services for unprivileged users, as is the case with Guix Home. For example, running herd status ntpd as root allows me to know what the Network Time Protocol (NTP) daemon is up to:

$ sudo herd status ntpd
● Status of ntpd:
  It is running since Fri 06 Dec 2024 02:08:08 PM CET (2 days ago).
  Main PID: 11359
  Command: /gnu/store/s4ra0g0ym1q1wh5jrqs60092x1nrb8h9-ntp-4.2.8p18/bin/ntpd -n -c /gnu/store/7ac2i2c6dp2f9006llg3m5vkrna7pjbf-ntpd.conf -u ntpd -g
  It is enabled.
  Provides: ntpd
  Requires: user-processes networking
  Custom action: configuration
  Will be respawned.
  Log file: /var/log/ntpd.log

Recent messages (use '-n' to view more or less):
  2024-12-08 18:35:54  8 Dec 18:35:54 ntpd[11359]: Listen normally on 25 tun0 128.93.179.24:123
  2024-12-08 18:35:54  8 Dec 18:35:54 ntpd[11359]: Listen normally on 26 tun0 [fe80::e6b7:4575:77ef:eaf4%12]:123
  2024-12-08 18:35:54  8 Dec 18:35:54 ntpd[11359]: new interface(s) found: waking up resolver
  2024-12-08 18:46:38  8 Dec 18:46:38 ntpd[11359]: Deleting 25 tun0, [128.93.179.24]:123, stats: received=0, sent=0, dropped=0, active_time=644 secs
  2024-12-08 18:46:38  8 Dec 18:46:38 ntpd[11359]: Deleting 26 tun0, [fe80::e6b7:4575:77ef:eaf4%12]:123, stats: received=0, sent=0, dropped=0, active_time=644 secs

It’s running, and it’s logging messages: the latest ones are shown here and I can open /var/log/ntpd.log to view more. Running herd stop ntpd would terminate the ntpd process, and there’s also a start and a restart action.

Services can also have custom actions; in the example above, we see there’s a configuration action. As it turns out, that action is a handy way to get the file name of the ntpd configuration file:

$ head -2 $(sudo herd configuration ntpd)
driftfile /var/run/ntpd/ntp.drift
pool 2.guix.pool.ntp.org iburst

Of course a typical system runs quite a few services, many of which depend on one another. The herd graph command returns a representation of that service dependency graph that can be piped to dot or xdot to visualize it; here’s what I get on my laptop:

It’s quite a big graph (you can zoom in for details!) but we can learn a few things from it. Each node in the graph is a service; rectangles are for “regular” services (typically daemons like ntpd), round nodes correspond to one-shot services (services that perform one action and immediately stop), and diamonds are for timed services (services that execute code periodically).

Blurring the user/developer line

A unique feature of the Shepherd is that you configure and extend it in its own implementation language: in Guile Scheme. That does not mean you need to be an expert in that programming language to get started. Instead, we try to make sure anyone can start simple for their configuration file and gradually get to learn more if and when they feel the need for it. With this approach, we keep the user in the loop, as Andy Wingo put it.

A Shepherd configuration file is a Scheme snippet that goes like this:

(register-services
  (list (service '(ntpd) …)
        …))

(start-in-the-background '(ntpd …))

Here we define ntpd and get it started as soon as shepherd has read the configuration file. The ellipses can be filled in with more services.

As an example, our ntpd service is defined like this:

(service
  '(ntpd)
  #:documentation "Run the Network Time Protocol (NTP) daemon."
  #:requirement '(user-processes networking)
  #:start (make-forkexec-constructor
           (list "…/bin/ntpd"
                 "-n" "-c" "/…/…-ntpd.conf" "-u" "ntpd" "-g")
           #:log-file "/var/log/ntpd.log")
  #:stop (make-kill-destructor)
  #:respawn? #t)

The important parts here are #:start bit, which says how to start the service, and #:stop, which says how to stop it. In this case we’re just spawning the ntpd program but other startup mechanisms are supported by default: inetd, socket activation à la systemd, and timers. Check out the manual for examples and a reference.

There’s no limit to what #:start and #:stop can do. In Guix System you’ll find services that run daemons in containers, that mount/unmount file systems (as can be guessed from the graph above), that set up/tear down a static networking configuration, and a variety of other things. The Swineherd project goes as far as extending the Shepherd to turn it into a tool to manage system containers—similar to what the Docker daemon does.

Note that when writing service definitions for Guix System and Guix Home, you’re targeting a thin layer above the Shepherd programming interface. As is customary in Guix, this is multi-stage programming: G-expressions specified in the start and stop fields are staged and make it into the resulting Shepherd configuration file.

New since 0.10.x

For those of you who were already using the Shepherd, here are the highlights compared to the 0.10.x series:

Support for timed services has been added: these services spawn a command or run Scheme code periodically according to a predefined calendar.
herd status SERVICE now shows high-level information about services (main PID, command, addresses it is listening to, etc.) instead of its mere “running value”. It also shows recently-logged messages.
To make it easier to discover functionality, that command also displays custom actions applicable to the service, if any. It also lets you know if a replacement is pending, in which case you can restart the service to upgrade it.
herd status root is no longer synonymous with herd status; instead it shows information about the shepherd process itself.
On Linux, reboot --kexec lets you reboot straight into a new Linux kernel previously loaded with kexec --load.

The service collection has grown:

The new log rotation service is responsible for periodically rotating log files, compressing them, and eventually deleting them. It’s very much like similar log rotation tools from the 80’s since shepherd logs to plain text files like in the good ol’ days.
There’s a couple of be benefits that come from its integration into the Shepherd. First, it already knows all the files that services log to, so no additional configuration is needed to teach it about these files. Second, log rotation is race free: no single line of log can be lost in the process.
The new system log service what’s traditionally devoted to a separate syslogd program. The advantage of having it in shepherd is that it can start logging earlier and integrates nicely with the rest of the system.
The timer service provides functionality similar to the venerable at command, allowing you to run a command at a particular time:

herd schedule timer at 07:00 -- mpg123 alarm.mp3

The transient service maker lets you run a command in the background as a transient service (it is similar in spirit to the systemd-run command):

herd spawn transient -d $PWD -- make -j4

The GOOPS interface that was deprecated in 0.10.x is now gone.

As always, the NEWS file has additional details.

In the coming weeks, we will most likely gradually move service definitions in Guix from mcron to timed services and similarly replace Rottlog and syslogd. This should be an improvement for Guix users and system administrators!

Cute code

I did mention that the Shepherd is minimalist, and it really is: 7.4K lines of Scheme, excluding tests, according to SLOCCount. This is in large part thanks to the use of a high-level memory-safe language and due to the fact that it’s extensible—peripheral features can live outside the Shepherd.

Significant benefits also come from the concurrency framework: the concurrent sequential processes (CSP) model and Fibers. Internally, the state of each service is encapsulated in a fiber. Accessing a service’s state amounts to sending a message to its fiber. This way to structure code is itself very much inspired by the actor model. This results in simpler code (no dreaded event loop, no callback hell) and better separation of concern.

Using a high-level framework like Fibers does come with its challenges. For example, we had the case of a memory leak in Fibers under certain conditions, and we certainly don’t want that in PID 1. But the challenge really lies in squashing those low-level bugs so that the foundation is solid. The Shepherd itself is free from such low-level issues; its logic is easy to reason about and that alone is immensely helpful, it allows us to extend the code without fear, and it avoids concurrency bugs that plague programs written in the more common event-loop-with-callbacks style.

In fact, thanks to all this, the Shepherd is probably the coolest init system to hack on. It even comes with a REPL for live hacking!

What’s next

There’s a number of down-to-earth improvements that can be made in the Shepherd, such as adding support for dynamically-reconfigurable services (being able to restart a service but with different options), integration with control groups (“cgroups”) on Linux, proper integration for software suspend, etc.

In the longer run, we envision an exciting journey towards a distributed and capability-style Shepherd. Spritely Goblins provides the foundation for this; using it looks like a natural continuation of the design work of the Shepherd: Goblins is an actor model framework! Juliana Sims has been working on adapting the Shepherd to Goblins and we’re eager to see what comes out of it in the coming year. Stay tuned!

Enjoy!

In the meantime, we hope you enjoy the Shepherd 1.0 as much as we enjoyed making it. Four people contributed code that led to this release, but there are other ways to help: through graphics and web design, translation, documentation, and more. Join us!

Originally published on the Shepherd web site.

GNUnet News: GNUnet 0.23.0

Sun, 08 Dec 2024 23:00:00 +0000

GNUnet 0.23.0 released

We are pleased to announce the release of GNUnet 0.23.0.
GNUnet is an alternative network stack for building secure, decentralized and privacy-preserving distributed applications. Our goal is to replace the old insecure Internet protocol stack. Starting from an application for secure publication of files, it has grown to include all kinds of basic protocol components and applications towards the creation of a GNU internet.

This is a new major release. It breaks protocol compatibility with the 0.22.0X versions. Please be aware that Git master is thus henceforth (and has been for a while) INCOMPATIBLE with the 0.22.0X GNUnet network, and interactions between old and new peers will result in issues. In terms of usability, users should be aware that there are still a number of known open issues in particular with respect to ease of use, but also some critical privacy issues especially for mobile users. Also, the nascent network is tiny and thus unlikely to provide good anonymity or extensive amounts of interesting information. As a result, the 0.23.0 release is still only suitable for early adopters with some reasonable pain tolerance .

Download links

gnunet-0.23.0.tar.gz ( signature )
gnunet-0.23.0-meson.tar.xz ( signature ) NEW: Test tarball made using the meson build system.
gnunet-gtk-0.23.0.tar.gz ( signature )
gnunet-fuse-0.23.0.tar.gz ( signature )

The GPG key used to sign is: 3D11063C10F98D14BD24D1470B0998EF86F59B6A

Note that due to mirror synchronization, not all links might be functional early after the release. For direct access try http://ftp.gnu.org/gnu/gnunet/

Changes

A detailed list of changes can be found in the git log , the NEWS and the bug tracker . Noteworthy highlights are

Code review: A number of issues found during a code review have been addressed.
util : A GNUNET_OS_ProjectData must now be passed to some APIs that are commonly used by third parties using libgnunetutil (e.g. Taler, GNUnet-Gtk) as to properly handle cases where the GNUnet installation directory is different from the third-party directory.
Build System : Improved build times by outsourcing handbook to prebuilt files and only generating GANA source files manually.

Known Issues

There are known major design issues in the CORE subsystems which will need to be addressed in the future to achieve acceptable usability, performance and security.
There are known moderate implementation limitations in CADET that negatively impact performance.
There are known moderate design issues in FS that also impact usability and performance.
There are minor implementation limitations in SET that create unnecessary attack surface for availability.
The RPS subsystem remains experimental.

In addition to this list, you may also want to consult our bug tracker at bugs.gnunet.org which lists about 190 more specific issues.

Thanks

This release was the work of many people. The following people contributed code and were thus easily identified: Christian Grothoff, TheJackiMonster, oec, ch3, and Martin Schanzenbach.

GNU Artanis: The best practice to port Scheme application to Artanis

Tue, 03 Dec 2024 18:08:51 +0000

unifont @ Savannah: Unifont 16.0.02 Released

Sun, 01 Dec 2024 19:25:29 +0000

1 December 2024 Unifont 16.0.02 is now available. This is a minor release with many glyph improvements. See the ChangeLog file for details.

Download this release from GNU server mirrors at:

     https://ftpmirror.gnu.org/unifont/unifont-16.0.02/

or if that fails,

     https://ftp.gnu.org/gnu/unifont/unifont-16.0.02/

or, as a last resort,

     ftp://ftp.gnu.org/gnu/unifont/unifont-16.0.02/

These files are also available on the unifoundry.com website:

     https://unifoundry.com/pub/unifont/unifont-16.0.02/

Font files are in the subdirectory

     https://unifoundry.com/pub/unifont/unifont-16.0.02/font-builds/

A more detailed description of font changes is available at

      https://unifoundry.com/unifont/index.html

and of utility program changes at

      https://unifoundry.com/unifont/unifont-utilities.html

Information about Hangul modifications is at

      https://unifoundry.com/hangul/index.html

and

      http://unifoundry.com/hangul/hangul-generation.html

gettext @ Savannah: GNU gettext 0.23 released

Sun, 01 Dec 2024 14:04:15 +0000

Download from https://ftp.gnu.org/pub/gnu/gettext/gettext-0.23.tar.gz

New in this release:

Internationalized data formats:
- XML:
  - The escaping of characters such as & < > has been changed:
    - No escaping is done any more by xgettext, when creating a POT file.
    - Instead, extra escaping can be requested for the msgfmt pass, when merging into an XML file.
    - The default value of 'escape' in the <gt:escapeRule> was "yes"; now it is "no".
  - This means that existing translations of older POT files may no longer fully apply. As a maintainer of a package that has translatable XML files, you need to regenerate the POT file and pass it on to your translators.
  - XML schemas for .its and .loc files are now provided.
  - The value of the xml:lang attribute, inserted by msgfmt, now conforms to W3C standards.
  - 'msgfmt --xml' accept an option --replace-text, that causes the output to be a mono-lingual XML file instead of a multi-lingual XML file.
  - xgettext and 'msgfmt --xml' now support DocBook XML files.
- Desktop: xgettext now produces POT files with correct line numbers.

Programming languages support:
- Python:
  - xgettext now assumes source code for Python 3 rather than Python 2. This affects the interpretation of escape sequences in string literals.
  - xgettext now recognizes the f-string syntax.
- Scheme:
  - xgettext now supports the option '-L Guile' as an alternative to '-L Scheme'. They are nearly equivalent. They differ in the interpretation of escape sequences in string literals: While 'xgettext -L Scheme' assumes the R6RS and R7RS syntax of string literals, 'xgettext -L Guile' assumes the syntax of string literals understood by Guile 2.x and 3.0 (without command-line option '--r6rs' or '--r7rs', and before a '#!r6rs' directive is seen).
  - xgettext now recognizes comments of the form '#; <expression>'.
- Java: xgettext now has an improved recognition of format strings when the String.formatted method is used.
- JavaScript:
  - xgettext now parses template literals inside JSX correctly.
- xgettext has a new option --tag that customizes the behaviour of tagged template literals.
- C#:
  - The build system and tools now also support 'dotnet' (.NET) as C# implementation. In order to declare a preference for 'dotnet' over 'mono', you can use the configure option '--enable-csharp=dotnet'.
  - xgettext now recognizes strings with embedded expressions (a.k.a. interpolated strings).
- awk: xgettext now recognizes string concatenation by juxtaposition.
- Smalltalk: xgettext now recognizes the string concatenation operator ','.
- Vala: xgettext now has an improved recognition of format strings when the string.printf method is used.
- Glade: xgettext has improved support for GtkBuilder 4.
- Tcl: With the recently released Tcl 9.0, characters outside the Unicode BMP in Tcl message catalogs (.msg files) will work regardless of the locale's encoding.
- Perl:
  - xgettext now reports warnings instead of fatal errors.
  - xgettext now recognizes strings with embedded expressions (a.k.a. interpolated strings).
- PHP:
  - xgettext now recognizes strings with embedded expressions.
  - xgettext now scans Heredoc and Nowdoc strings correctly.
  - xgettext now regards the format string directives %E, %F, %g, %G, %h, %H as valid.

Runtime behaviour:
- In the C.UTF-8 locale, like in the C locale, the *gettext() functions now return the msgid untranslated. This is relevant for GNU systems, Linux with musl libc, FreeBSD, NetBSD, OpenBSD, Cygwin, and Android.

Documentation:
- The section "Preparing Strings" now gives more advice how to deal with string concatenation and strings with embedded expressions.

xgettext:
- Most of the diagnostics emitted by xgettext are now labelled as "warning" or "error".

msgmerge:
- The option '--sorted-output' is now deprecated.

libgettextpo library:
- This library is now multithread-safe.
- The function 'po_message_set_format' now supports resetting a format string mark.

GNU Taler news: libeufin independent security audit report and developer response published

Thu, 28 Nov 2024 23:00:00 +0000

We received a grant from NLnet foundation to pay for the development of libeufin for regional- and event-currencies. NGI assists these projects by paying for independent security audits. Thus, we are happy that RadicallyOpenSecurity performed an external crystal-box security audit of the libeufin component of GNU Taler. You can find the final report here. We already addressed all significant findings and compiled a response detailing the changes. We thank RadicallyOpenSecurity for their work, and NLnet and the European Commission's Horizion 2020 NGI initiative for funding this work.

Parabola GNU/Linux-libre: i686 users - manual intervention required

Thu, 28 Nov 2024 22:00:08 +0000

i686 users will probably be unable to upgrade, due to a problem with the latest archlinux32-keyring 20241114-1

the solution is posted on the bug tracker https://labs.parabola.nu/issues/3679

remotecontrol @ Savannah: Smart gadgets’ failure to commit to software support could be illegal, FTC warns

Thu, 28 Nov 2024 12:38:21 +0000

https://arstechnica.com/gadgets/2024/11/smart-gadgets-failure-to-commit-to-software-support-could-be-illegal-ftc-warns/

GNU Guix: Guix/Hurd on a Thinkpad X60

Sun, 24 Nov 2024 18:00:00 +0000

A lot has happened with respect to the Hurd since our Childhurds and GNU/Hurd Substitutes post. As long as two years ago some of you have been asking for a progress update and although there have been rumours on a new blog post for over a year, we were kind of waiting for the rumoured x86_64 support.

With all the exciting progress on the Hurd coming available after the recent (last?) merger of core-updates we thought it better not to wait any longer. So here is a short overview of our Hurd work over the past years:

Update Hurd to 3ff7053, gnumach 1.8+git20220827, and fix build failures,
A native compilation fix for gcc-boot0,
Initial rumpdisk support, more on this below, which needed to wait for:
A libc specific to Hurd, updating gnumach to 1.8+git20221224 and hurd to 0.9.git20230216,
Some 40 native package build fixes for the Hurd so that all development dependencies of the guix package are now available,
A hack to use Git source in commencement to update and fix cross build and native build for the Hurd,
Support for buiding guix natively on the Hurd by splitting the build into more steps for 32-bit hosts
Even nicer offloading support for Childhurds by introducing Smart Hurdloading so that now both the Bordeaux and Berlin build farms build packages for i586-gnu,
Locale fixes for wrong glibc-utf8-locales package used on GNU/Hurd,
More locale fixes to use glibc-utf8-locales/hurd in %standard-patch-inputs,
And even more locale fixes for using the right locales on GNU/Hurd,
A new glibc 2.38 allowing us to do (define-public glibc/hurd glibc)—i.e., once again use the same glibc for Linux and Hurd alike, and: Better Hurd support!,
Creation of hurd-team branch with build fixes, updating gnumach to 1.8+git20230410 and hurd to 0.9.git20231217,
A constructive meeting with sixteen people during the Guix Days just before FOSDEM '24 with notes that contain some nice ideas,
Another new glibc 2.39; even better Hurd support, opening the door to x86_64 support,
Yet another restoring of i586-gnu (32-bit GNU/Hurd) support,
The installer just learnt about the Hurd! More on this below, and finally,
Another set of updates: gnumach (1.8+git20240714), mig (1.8+git20231217), hurd (0.9.git20240714), netdde (c0ef248d), rumpkernel (f1ffd640), and initial support for x86_64-gnu, aka the 64bit Hurd.

NetDDE and Rumpdisk support

Back in 2020, Ricardo Wurmus added the NetDDE package that provides Linux 2.6 network drivers. At the time we didn't get to integrate and use it though and meanwhile it bitrotted.

After we resurrected the NetDDE build, and with kind help of the Hurd developers we finally managed to support NetDDE for the Hurd.. This allows the usage of the Intel 82573L Gigabit Ethernet Controller of the Thinkpad X60 (and many other network cards, possibly even WIFI). Instead of using the builtin kernel driver in GNU Mach, it would be running as a userland driver.

What sparked this development was upstream's NetBSD rumpdisk support that would allow using modern hard disks such as SSDs, again running as a userland driver. Hard disk support builtin in GNU Mach was once considered to be a nice hack but it only supported disks up to 128 GiB…

First, we needed to fix the cross build on Guix.

After the initial attempt at rumpdisk support for the Hurd it took (v2) some (v3) work (v4) to finally arrive at rumpdisk support for the Hurd, really, *really* (v5)

Sadly when actually using them, booting hangs:

start: pci.arbiter:

What did not really help is that upstream's rumpkernel archive was ridiculously large. We managed to work with upstream to remove unused bits from the archive. Upstream created a new archive that instead of 1.8 GiB (!) now “only” weighs 670 MiB.

Anyway, after a lot of building, rebuilding, and debugging and some more with kind help from upstream we finally got Rumpdisk and NetDDE to run in a Childhurd.

Initial Guix/Hurd on the Thinkpad X60

Now that the last (!) core-updates merge has finally happened (thanks everyone!), the recipe of installing Guix/Hurd has been much simpfilied. It goes something along these lines.

Install Guix/Linux on your X60,
Reserve a partition and format it for the Hurd:
```
mke2fs -o hurd -L hurd /dev/sdaX
```

In your config.scm, add some code to add GRUB menuentries for booting the Hurd, and mount the Hurd partition under /hurd:

(use-modules (srfi srfi-26)
             (ice-9 match)
             (ice-9 rdelim)
             (ice-9 regex)
             (gnu build file-systems))

(define %hurd-menuentry-regex
  "menuentry \"(GNU with the Hurd[^{\"]*)\".*multiboot ([^ \n]*) +([^\n]*)")
(define (text->hurd-menuentry text)
  (let* ((m (string-match %hurd-menuentry-regex text))
         (label (match:substring m 1))
         (kernel (match:substring m 2))
         (arguments (match:substring m 3))
         (arguments (string-split arguments #\space))
         (root (find (cute string-prefix? "root=" <>) arguments))
         (device-spec (match (string-split root #\=)
                        (("root" device) device)))
         (device (hurd-device-name->device-name device-spec))
         (modules (list-matches "module ([^\n]*)" text))
         (modules (map (cute match:substring <> 1) modules))
         (modules (map (cute string-split <> #\space) modules)))
    (menu-entry
     (label label)
     (device device)
     (multiboot-kernel kernel)
     (multiboot-arguments arguments)
     (multiboot-modules modules))))

(define %hurd-menuentries-regex
  "menuentry \"(GNU with the Hurd[^{\"]*)\" \\{([^}]|[^\n]\\})*\n\\}")
(define (grub.cfg->hurd-menuentries grub.cfg)
  (let* ((entries (list-matches %hurd-menuentries-regex grub.cfg))
         (entries (map (cute match:substring <> 0) entries)))
    (map text->hurd-menuentry entries)))

(define (hurd-menuentries)
  (let ((grub.cfg (with-input-from-file "/hurd/boot/grub/grub.cfg"
                    read-string)))
    (grub.cfg->hurd-menuentries grub.cfg)))

...
(operating-system
   ...
  (bootloader (bootloader-configuration
               (bootloader grub-bootloader)
               (targets '("/dev/sda"))
               (menu-entries (hurd-menuentries))))
  (file-systems (cons* (file-system
                         (device (file-system-label "guix"))
                         (mount-point "/")
                         (type "ext4"))
                       (file-system
                         (device (file-system-label "hurd"))
                         (mount-point "/hurd")
                         (type "ext2"))
                       %base-file-systems))
  ...)

Create a config.scm for your Hurd system. You can get inspiration from bare-hurd.tmpl and inherit from %hurd-default-operating-system. Use grub-minimal-bootloader and add a static-networking-service-type. Something like:

(use-modules (srfi srfi-1) (ice-9 match))
(use-modules (gnu) (gnu system hurd))

(operating-system
  (inherit %hurd-default-operating-system)
  (bootloader (bootloader-configuration
               (bootloader grub-minimal-bootloader)
               (targets '("/dev/sda"))))
  (kernel-arguments '("noide"))
...
  (services
    (cons*
      (service static-networking-service-type
               (list %loopback-static-networking
                     (static-networking
                      (addresses
                       (list
                        (network-address
                         (device "eth0")
                         (value "192.168.178.37/24"))))
                      (routes
                       (list (network-route
                              (destination "default")
                              (gateway "192.168.178.1"))))
                      (requirement '())
                      (provision '(networking))
                      (name-servers '("192.168.178.1")))))
    ...)))

Install the Hurd. Assuming you have an ext2 filesystem mounted on /hurd, do something like:

guix system build --target=i586-pc-gnu vuurvlieg.hurd --verbosity=1
sudo -E guix system init --target=i586-pc-gnu --skip-checks \
    vuurvlieg.hurd /hurd
sudo -E guix system reconfigure vuurvlieg.scm

Reboot and...

Hurray!

We now have Guix/Hurd running on Thinkpad.

Guix/Hurd on Real Iron

While the initial manual install on the X60 was an inspiring milestone, we can do better. As mentioned above, just recently the installer learnt about the Hurd, right after some smaller problems were addressed, like guix system init creating essential devices for the Hurd, not attempting to run a cross-built grub-install to install Grub, soft-coding the hard-coded part:1:device:wd0 root file-system, adding support for booting Guix/Hurd more than once.

To install Guix/Hurd, first, build a 32bit installation image and copy it to a USB stick:

guix system image --image-type=iso9660 --system=i686-linux gnu/system/install.scm
dd if=/gnu/store/cabba9e-image.iso of=/dev/sdX status=progress
sync

then boot it on a not-too-new machine that has wired internet (although installation over WIFI is possible, there is currently no WIFI support for the installed Hurd to use it). On the new Kernel page:

choose Hurd. Do not choose a desktop environment, that's not available yet. On the Network management page:

choose the new Static networking service. In the final Configuration file step, don't forget to edit:

and fill-in your IP and GATEWAY:

You may want to add some additional packages such as git-minimal from (gnu packages version-control) and sqlite from (gnu packages sqlite).

If you also intend to do Guix development on the Hurd—e.g., debugging and fixing native package builds—then you might want to include all dependencies to build the guix package, see the devel-hurd.tmpl for inspiration on how to do that. Note that any package you add must already have support for cross-building.

Good luck, and let us know if it works for you and on what kind of machine, or why it didn't!

What's next?

In an earlier post we tried to answer the question “Why bother with the Hurd anyway?” An obvious question because it is all too easy to get discouraged, to downplay or underestimate the potential social impact of GNU and the Hurd.

The most pressing problem currently is that the guix-daemon fails when invoking guix authenticate on the Hurd, which means that we cannot easily keep our substitutes up to date. guix pull is known to work but only by pulling from a local branch doing something like:

mkdir -p ~/src/guix
cd src/guix
git clone https://git.savannah.gnu.org/git/guix.git master
guix pull --url=~/src/guix/master

kinda like we did it in the old days. Sometimes it seems that guix does not grok the sqlite store database. This is needs to be resolved but as sqlite does read it this can be easily worked around by doing something like:

mv /var/guix/db/db.sqlite /var/guix/db/db.sqlite.orig
sqlite3 /var/guix/db/db.sqlite.orig .dump > /var/guix/db/db.sqlite.dump
sqlite3 -init /var/guix/db/db.sqlite.dump /var/guix/db/db.sqlite .quit

Also, the boot process still fails to handle an unclean root file system. Whenever the Hurd has suffered an unclean shutdown, cleaning it must currently be done manually, e.g., by booting from the installer USB stick.

Upstream now has decent support for 64bit (x86_64) albeit with more bugs and fewer packages. As mentioned in the overview we are now working to have that in Guix and have made some progress:

more on that in another post. Other interesting task for Guix include:

Have guix system reconfigure work on the Hurd,
Figure out WiFi support with NetDDE (and add it to installer!),
An isolated build environment (or better wait for, err, contribute to the Guile guix-daemon?),
An installer running the Hurd, and,
Packages, packages, packages!

We tried to make Hurd development as easy and as pleasant as we could. As you have seen, things start to work pretty nicely and there is still plenty of work to do in Guix. In a way this is “merely packaging” the amazing work of others. Some of the real work that needs to be done and which is being discussed and is in progress right now includes:

Audio support (this is sponsored by NLnet, thanks!),
Rumpnet,
SMP,
AArch64.

All these tasks look daunting, and indeed that’s a lot of work ahead. But the development environment is certainly an advantage. Take an example: surely anyone who’s hacked on device drivers or file systems before would have loved to be able to GDB into the code, restart it, add breakpoints and so on—that’s exactly the experience that the Hurd offers. As for Guix, it will make it easy to test changes to the micro-kernel and to the Hurd servers, and that too has the potential to speed up development and make it a very nice experience.

Join #guix and #hurd on libera.chat or the mailing lists and get involved!

Addendum

It has been brought to our attention that people haven't heard that Debian GNU/Hurd has been a reality for some years now. While Guix GNU/Hurd has an exciting future, please be aware that it lacks many packages and services, including Xorg. If you would simply like to install the Hurd on bare metal running your favorite window manager (eg: i3, icewm, etc.) or lightweight desktop environment (Xfce) right now, then installing Debian GNU/Hurd is a good choice. Though we hope to catch up to them soon!

gnuboot @ Savannah: GNU Boot November 2024 News

Sat, 23 Nov 2024 19:05:25 +0000

A lot has changed since the two last news from the GNU Boot project.

GNU Boot install party in Paris the 7 and 8 December 2024

People involved in the GNU Boot project will be organizing a 100% free
software install party within a bigger event that also has a regular
install party. There will also be a presentation about 100% free
software in there. The event will be mainly in French.

More details are available in French and in English in the following
link:
https://lists.gnu.org/archive/html/help-guix/2024-11/msg00112.html

GNU Boot 0.1 RC4

Many changes were made since the RC3 and since then we fixed an
important bug that prevented Trisquel from booting (If during the
Trisquel installation you chose "LVM2" and didn't encrypt the
storage, GNU Boot images with GRUB would not find the Trisquel
installation).

Because of that we decided to do a new RC4 (release candidate 4)
and to publish new GNU Boot images.

There are still some work needed before doing a 0.1 release as we want
to make it easier for less technical users to install and use GNU
Boot, but more and more of the project structure are getting in place
(website, manual, automatic tests, guix, good development procedures,
enabling build on all distributions, etc) which then makes it easier
to contribute.

We also decided to use Guix for more of the software components
we build, and since this is a big change, we will need people to
help more with testing.

Nonfree software found again, no supported device affected.

The last announcement we made was "Nonfree software found in GNU Boot
releases again, many distros affected"[1].

Some people misunderstood it (maybe we could have been more clear):
the nonfree software that we found was code that GNU Boot didn't use,
so it was easy to remove and it didn't affect the supported devices in
any way.

Finding nonfree software in 100% free distribution is also common:
this is part of the work to ensure these distribution remains 100%
free.

The first time it happened in GNU Boot we publicized it to explain why
we were re-releasing some of the GNU Boot files as it could be very
scary if this happens without any public communication.

The second time we published a news about it mainly to help propagate
the information to the affected distributions and this is probably why
it was misunderstood: it was mainly targeted at GNU Boot users and
maintainers of the affected packages. We also contacted upstream and
some affected distributions directly as well but contacting everybody
takes a lot of time so having a news about it helps. At least Debian
and Trisquel fixed the issue but we still need to contact some
distributions.

After that, and probably thanks to the previous news, Leah Rowe
contacted us on one of the GNU Boot mailing lists[2] to notify us that
she also found additional similar nonfree software in GNU Boot.

So we confirmed that and promptly removed them and re-made again the
source release. And here again even if the work was delayed a bit,
this was fast to do and it doesn't affect the supported devices in any
way.

But we also need help contacting distributions again because one of
the issue she found is very serious because it affects many
distributions and also important devices that GNU Boot doesn't
support.

The ARM trusted firmware ships a nonfree hdcp.bin binary in its source
code. ARM trusted firmware is a dependency of u-boot that is used to
support many ARM computers in other distributions (like Guix, Debian,
etc).

As contacting affected distributions is a tedious task, we also need
help to propagate the information and contact them especially because
we don't know if Leah intend or not to do that work (so far she didn't
reply when asked twice about it), so it's probably up to the GNU Boot
community as a whole (which also includes its maintainers and readers
of this news) to help here.

The details are in the commit 343515aee7ef34695ac45830fad419d9562f9c15
("coreboot: blobs.list: arm-trusted-firmware: Remove RK3399 hdcp.bin
firmware.") in the GNU Boot source code[3].

[1]https://savannah.gnu.org/news/?id=10684
[2]https://lists.gnu.org/archive/html/gnuboot-patches/2024-10/msg00028.html
[3]https://git.savannah.gnu.org/cgit/gnuboot.git/commit/?id=343515aee7ef34695ac45830fad419d9562f9c15

Website and documentation

Jordán (isf) has been contributing some Spanish translations of the
most important website pages (the landing, status and how to
contribute pages). This is important as it could help get more
contributors. These contributions also helped us improve the process
for accepting pseudonymous contributions and enabled us to fix issues.

The work on improving the website in general also continued. Many of
the website pages were reviewed and improved (there is a lot of work
there and mentioning it all would make the news way too long).

The website also now shows the git revision from which it is build and
we also helped the FSF fix some server configuration that created
issue with the deployment of the GNU Boot website (more details are in
the commit message[1]) by reporting the issue to them and testing the
fix.

Patches for making a manual are also being reviewed. While there isn't
much in the manual yet, it also enables to better organize the
documentation and it has the potential to make GNU Boot more
accessible to less technical people.

The next goals is to look how to merge part of the website inside the
manual and continue improving both the website and the manual.

[1]https://git.savannah.gnu.org/cgit/gnuboot.git/commit/?id=d1df672383f6eb8d4218fdef7fbe9ec5e41803e4

Authenticating GNU Boot source code

We now have the ability to verify the source code when downloading it
from git. This is important to avoid certain type of attacks and it
also enables to write code to automatically download, verify and build
the GNU Boot source code.

The source can be verified with the following command (it requires to
have Guix installed):
$ guix git authenticate $(git rev-parse HEAD) \
"E23C 26A5 DEEE C5FA 9CDD D57A 57BC 26A3 6871 16F6" \
-k origin/keyring

If the authentication works it will print a message like that:

guix git: successfully
authenticated commit 05c09293d9660ea1f26b5b705a089b466a0aa718

The 05c09293d9660ea1f26b5b705a089b466a0aa718 might be different in
your case.

The "E23C 26A5 DEEE C5FA 9CDD D57A 57BC 26A3 6871 16F6" part in the
command above is Adrien Bourmault (neox)'s GPG key.

How to use that will be documented more in depth in the upcoming GNU
Boot manual that is currently being reviewed. Its importance will also
be explained in more details for people not familiar with the security
issues it's meant to solve. Also note that we also welcome help for
reviewing patches.

Licensing

The GNU Boot source code has a complex history. It is based on the
last fully free software releases of Libreboot. And the Libreboot
source code history is very complex.

We found some missing authorship information in some of the files that
come from Libreboot and so we started such information from the
various git repositories that were used at some point by Libreboot or
some of the projects it was based on.

To help with this task we also added a page on the GNU Boot website
(https://www.gnu.org/software/gnuboot/web/docs/history/) to track the
status of the reconstruction of the missing authorship and to document
the GNU Boot source code history.

Upstream contributions and easier building of GNU Boot

GNU Boot is just a distribution and like most distributions, it tries
to collaborate with various upstream projects whenever possible.

Since GNU Boot relies on Guix, we improved the Guix documentation
directly to help people install Guix on Trisquel and Parabola. We also
helped Trisquel fix security issues in the Guix package by bug
reporting and testing fixes (some bugs still need to be fixed in
Parabola and Debian, and reporting issues upstream takes time).

Since we also advise to use PureOS or Trisquel to build GNU Boot we
also enabled people with Guix to produce PureOS or Trisquel chroots
with Debootstrap. This was done through contributions to Debootstrap,
and to the Guix Debootstrap package. We could then mention that in the
GNU Boot build documentation
(https://www.gnu.org/software/gnuboot/web/docs/build/) and added a
script (in contrib/start-guix-daemon.py) to support building GNU Boot
in chroots. However there are still issue with the build in chroots
that need to be fixed to producing all released files. Instructions on
how to do build in chroots is also lacking.

In addition we also added the ability to build GNU Boot with Trisquel
11 (aramo).

An apt-cacher-ng package was also contributed in Guix upstream as it
can then be used to speed-up one of the automatic tests used in GNU
Boot but the support for apt-cacher-ng was not integrated yet in GNU
Boot. Last year we also contributed a GRUB package in Guix but we
didn't have the occasion to use it yet. It will probably happen soon
though.

Building GNU Boot

How to build GNU Boot has changed a lot since GNU Boot 0.1 RC3.

Before Guix could only be optionally used to build the website.

In addition to that, Guix is now integrated in the build system so we
can now rely on Guix packages to build GNU Boot images. This also
means that you need to install Guix to build GNU Boot images.

We currently use Guix packages to build some tests. We also build some
installation utilities for the I945 ThinkPads (ThinkPad X60, X60s,
X60T and T60) but we don't have documentation for less technical
people yet on how to use them. We also would need help for testing
these computers as we have no idea if they still work fine or which
fully free distributions still work on them in practice.

We now also support the './configure' and 'make' commands to build GNU
Boot but not yet the 'make install' command as to work we would need
to adapt many of the scripts that are used during the build to be
compatible with that.

There is also less visible work that was done, like cleaning up a lot
of code, adding tests for code quality, documenting a bit the GNU Boot
source code structure, and so on.

Work on making GNU Boot reproducible also started. See
https://reproducible-builds.org/ or
https://en.wikipedia.org/wiki/Reproducible_builds for more detail on
the issue.

We took an extremely strict approach and put the checksum of some of
the things we build directly into GNU Boot and verify it the checksum
during the compilation. This enables us to automatically detect
issues without having to do anything.

We started to enable that for easy things, and we also added the
infrastructure to also use that in Guix packages as well by validating
one of the packages we use during automatic testing.

However at one point this guix package stopped being
reproducible. Since we wanted to keep that code (especially as it was
showing a good example of how to do it), we fixed the bug instead of
removing the test.

This then helped us detect a very subtle and interesting bug in one of
the components we use for automatic tests.

The bug could not be caught during testing because some time
information stored inside the FAT32 file system has a granularity of a
day, and since all the testing happened the same day, it was caught
only later on.

This bug was then fixed and the details are in the fix[1]. A bug
report was also opened upstream because bugs were found in diffoscope
along the way[2]. We still need to do some testing though to
understand if the bug is in diffoscope or one of the underlying
libraries (libguestfs) and then to report the remaining bugs to the
distributions we used during this work.

We also made it easier to update the checksum in the Guix package. If
you package software with Guix, this change is also a good example of
how not to break the '--without-tests' option when you override the
tests in the package you contribute. The commit message[3] and the
change have more details and references on all that.

[1]https://git.savannah.gnu.org/cgit/gnuboot.git/commit/?id=4c3de49fbb3b43940b43f8fdccc8e51ee7df8f46
[2]https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/390
[3]https://git.savannah.gnu.org/cgit/gnuboot.git/commit/?id=40fcb94e2f7ab1df8d320f78311e623f801d8602

LVM2 bug

WodeShengli reported a very important bug[1]: GNU Boot images with
GRUB can't find LVM2 partitions if the partition itself is not
encrypted. For instance if you have LVM2 and no encryption at all or
if the disk is encrypted and that on top you have LVM2, GNU Boot will
not find the partition.

Since this is an extremely serious usability issue (because images
with GRUB are supposed to work out of the box) we spent time to fix
it.

The issue was that the GRUB configuration we ship hardcoded the name
of the LVM volumes to try to boot from. Fixing it required to be able
loop over all the partitions being found, but we found no command to
do that in GRUB (which is probably why the LVM partition names were
hardcoded in the first place).

So we started adding GRUB command options to do that but while the
code worked fine, it didn't integrate in GRUB well. So we contacted
GRUB looking for help as we would have needed to upstream our command
option in GRUB anyway.

And we were told that GRUB already had a way to do what we were
looking for so we used that to fix the issue.

We also added tests that automatically download the Trisquel installer
and installs Trisquel with LVM2 and test if GNU Boot can boot the new
Trisquel installation[2].

While this test is skipped for 32bit computers, it is still good to
have as some people will run it. The test also paves the way to add
more tests that would enable us to improve further the GRUB
configuration without breaking the boot.

[1]https://savannah.gnu.org/bugs/index.php?65663
[2]https://git.savannah.gnu.org/cgit/gnuboot.git/commit/?id=860b00bf1e798d86c8bb2a70d77633599dfa1da2
[3]https://git.savannah.gnu.org/cgit/gnuboot.git/commit/?id=9cc02ddde1e164fabfbddc8bbd3832ef9468d92d

parallel @ Savannah: GNU Parallel 20241122 ('Ahoo Daryaei') released

Fri, 22 Nov 2024 22:22:18 +0000

GNU Parallel 20241122 ('Ahoo Daryaei') has been released. It is available for download at: lbry://@GnuParallel:4

Quote of the month:

GNU parallel is so satisfying
-- James Coman @jcoman.bsky.social

New in this release:

--pipe --block works similar to --pipepart --block if --block size is negative.
DBURLs can be written with / instead of %2F for sqlite and CSV.
Bug fixes and man page updates.

News about GNU Parallel:

Embarrassingly GNU parallel https://dengin.xyz/blog/2024/10/24/embarrassingly-gnu-parallel/
GNU Parallel for Your Terminal Tasks https://erolrecep.github.io/posts/gnuparallel_for_your_terminal_tasks/
How to leverage GNU parallel to utilize multiple cores while running AUGUSTUS https://lifescienceshub.wixsite.com/lifesciencehub/post/how-to-leverage-gnu-parallel-to-utilize-multiple-cores-while-running-augustus
GNU Parallel: The Good Parts https://diekmeier.de/posts/2024-11-17-gnu-parallel/
Put your CPU to work with GNU Parallel https://www.redhat.com/en/blog/gnu-parallel

About 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:

(Have your company) donate to FSF https://my.fsf.org/donate/

About GNU SQL

About GNU Niceload

www-zh-cn @ Savannah: Welcome our new member - bingchuanjuzi

Thu, 21 Nov 2024 02:01:47 +0000

Hi, All:

Please join me in welcoming our new member:

User Details:
-------------
Name:    Haoran Du
Login:   bingchuanjuzi
Email:   dududu233@outlook.com

I wish bingchuanjuzi a wonderful journey in GNU CTT.

Happy Hacking
wxie

libtool @ Savannah: libtool-2.5.4 released [stable]

Wed, 20 Nov 2024 20:27:33 +0000

Libtoolers!

The Libtool Team is pleased to announce the release of libtool 2.5.4.

GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl, which
hides the complexity of loading dynamic runtime libraries (modules)
behind a consistent, portable interface.

There have been 49 commits by 16 people in the 8 weeks since 2.5.3.

See the NEWS below for a brief summary.

Thanks to everyone who has contributed!
The following people contributed changes to this release:

Adrien Destugues (1)
Alastair McKinstry (6)
Bruno Haible (1)
Ileana Dumitrescu (27)
Jerome Duval (1)
Jonathan Nieder (2)
Joshua Root (1)
Khalid Masum (1)
Markus Mützel (1)
Martin Storsjö (1)
Richard Purdie (1)
Sergey Poznyakoff (1)
Tim Schumacher (1)
Vincent Lefevre (2)
mintsuki (1)
streaksu (1)

Ileana
[on behalf of the libtool maintainers]
==================================================================

Here is the GNU libtool home page:
    https://gnu.org/s/libtool/

For a summary of changes and contributors, see:
https://git.sv.gnu.org/gitweb/?p=libtool.git;a=shortlog;h=v2.5.4
or run this command from a git-cloned libtool directory:
git shortlog v2.5.3..v2.5.4

Here are the compressed sources:
https://ftpmirror.gnu.org/libtool/libtool-2.5.4.tar.gz   (2.0MB)
https://ftpmirror.gnu.org/libtool/libtool-2.5.4.tar.xz   (1.1MB)

Here are the GPG detached signatures:
https://ftpmirror.gnu.org/libtool/libtool-2.5.4.tar.gz.sig
https://ftpmirror.gnu.org/libtool/libtool-2.5.4.tar.xz.sig

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

Here are the SHA1 and SHA256 checksums:

77227188ead223ed8ba447301eda3761cb68ef57 libtool-2.5.4.tar.gz
2o67LOTc9GuQCY2vliz/po9LT2LqYPeY0O8Skp7eat8= libtool-2.5.4.tar.gz
9781a113fe6af1b150571410b29d3eee2e792516 libtool-2.5.4.tar.xz
+B9YYGZrC8fYS63e+mDRy5+m/OsjmMw7rKavqmAmZnU= libtool-2.5.4.tar.xz

Verify the base64 SHA256 checksum with cksum -a sha256 --check
from coreutils-9.2 or OpenBSD's cksum since 2007.

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 libtool-2.5.4.tar.gz.sig

The signature should match the fingerprint of the following key:

pub   rsa4096 2021-09-23 [SC]
        FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354
uid   Ileana Dumitrescu <ileanadumi95@protonmail.com>
uid   Ileana Dumitrescu <ileanadumitrescu95@gmail.com>

If that command fails because you don't have the required public key,
or that public key has expired, try the following commands to retrieve
or refresh it, and then rerun the 'gpg --verify' command.

gpg --locate-external-key ileanadumi95@protonmail.com

gpg --recv-keys 6570EA01146F7354

wget -q -O- 'https://savannah.gnu.org/project/release-gpgkeys.php?group=libtool&download=1' | gpg --import -

As a last resort to find the key, you can try the official GNU
keyring:

wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg
gpg --keyring gnu-keyring.gpg --verify libtool-2.5.4.tar.gz.sig

This release was bootstrapped with the following tools:
Autoconf 2.72e
Automake 1.17
Gnulib v1.0-1108-gea58a72d4d

NEWS

Noteworthy changes in release 2.5.4 (2024-11-20) [stable]

** New features:

- New libtool command line flag, --no-finish, to skip executing
    finish_cmds that would alter the shared library cache during testing.

- New libtool command line flag, --reorder-cache=DIRS, to reorder the
    shared library cache, only on OpenBSD.

** Bug fixes:

- Fix incorrect use of workarounds designed for Darwin versions that
    don't have -single_module support.

- Fix errors when executing 'make distclean' and 'make maintainer-clean'.

- Fix bug where the constructed rpath omit directories, instead of
    appending them to the end.

- Fix configure error for when variable 'multlib' is unset.

- Fix searching for -L in link paths being over-greedy and incorrectly
    handling paths with -L in them.

- Avoid using AC_TRY_EVAL macro, "dangerous and undocumented".

- Fix linking libraries at runtime with tcc by adding run path.

- Fix path comparison by removing trailing slashes on install commands.

- Fix linking for mingw with lld by prefering response files over the
    linker script.

- Fix '-Fe' usage with linking in MSVC.

- Fix '--no-warnings' flag.

- Fix handling xlc(1)-specific options.

- Fix Haiku support.

** Changes in supported systems or compilers:

- Support additional flang-based compilers, 'f18' and 'f95'.

- Support for 'netbsdelf*-gnu'.

- Support for '*-mlibc', and subsequently Ironclad and Managarm.

- Support for SerenityOS.

- Support for wasm32-emscripten.

Enjoy!

GNU Guix: Take the Guix User and Contributor Survey

Sun, 10 Nov 2024 10:01:00 +0000

To understand the views of the Guix community we're running a survey that we'd love you to take part in! The Guix User and Contributor Survey is live now, and should take about 10 minutes to fill out. Perfect for doing with a cup of tea and a biscuit!

The Guix project continues to grow and change, with new contributors and users joining our community. We decided to run this survey as it's the best way to gather good quality feedback across the widest cross-section of the community. Of course, there's lots of interesting topics a survey could ask about! We decided to focus on how Guix is used, and how contributors take part in the project.

The survey is being run on LimeSurvey which is a Free Software project and has been used by many other projects for similar surveys. The survey's hosted on the LimeSurvey SaaS so that we don't have the additional task of operating the software. No personal data is asked for (e.g. email addresses), no tracking data is being collected (e.g. IP addresses) and the entries are anonymised.

We'll be making the results and the anonymised data available under the Creative Commons CCO: that way anyone can analyse the data for further insights.

We hope the results of the survey will be used to understand both the Guix project's strengths and areas we can improve. Which is why your input is so important. If you can, please take the survey!

Take the survey now!

GNUnet News: GNUnet 0.22.2

Mon, 28 Oct 2024 23:00:00 +0000

GNUnet 0.22.2

This is a bugfix release for gnunet 0.22.1. It fixes some regressions and minor bugs.

Parabola GNU/Linux-libre: manual intervention required for local pacman repositories

Thu, 24 Oct 2024 06:11:30 +0000

NOTE: pacman v7 is currently in [libre-testing]; but it will be promoted to libre soon

from arch:

With the release of [version 7.0.0] pacman has added support for downloading packages as a separate user with dropped privileges.

For users with local repos however this might imply that the download user does not have access to the files in question, which can be fixed by assigning the files and folder to the alpm group and ensuring the executable bit (+x) is set on the folders in question.

$ chown :alpm -R /path/to/local/repo

Remember to [merge the .pacnew] files to apply the new default.

Pacman also introduced [a change] to improve checksum stability for git repos that utilize .gitattributes files. This might require a one-time checksum change for PKGBUILDs that use git sources.

www-ru @ Savannah: Разговор о свободных программах в Москве

Wed, 23 Oct 2024 13:17:54 +0000

Компьютеры и сети содействуют нам в борьбе за свободу: они помогают посвятить время и силы важным общественным инициативам, организовывать протесты, защищаться от цензуры.

Но свободны ли наши компьютеры? И свободны ли мы как пользователи?

Обсудим эти вопросы 25 октября в 19:00 в Открытом пространстве с Глебом Ерофеевым — активистом движения за свободные программы и волонтёром проекта "ГНУ", который в 1983 году запустил философ и активист Ричард Столлман.

Команда проекта "ГНУ" занимается разработкой свободного софта и техноэтическим активизмом, чтобы дать пользователям контроль над их компьютерами и искоренить несправедливость, которую приносят в общество собственнические программы.

Адрес: Плетешковский пер., 8с1 (м. "Бауманская").

Участие бесплатно. Приветствуются пожертвования в пользу пространства.

FSF News: FSF is working on freedom in machine learning applications

Tue, 22 Oct 2024 21:40:00 +0000

BOSTON (October 22, 2024) -- The Free Software Foundation (FSF) has announced today that it is working on a statement of criteria for free machine learning applications, which will require the software, as well as the raw training data and associated scripts, to grant users the four freedoms.

FSF News: FSF associate members to assist in review of current board members

Mon, 21 Oct 2024 20:00:00 +0000

parallel @ Savannah: GNU Parallel 20241022 ('Sinwar Nasrallah') released [stable]

Mon, 21 Oct 2024 19:31:05 +0000

GNU Parallel 20241022 ('Sinwar Nasrallah') has been released. It is available for download at: lbry://@GnuParallel:4

Quote of the month:

GNU Parallel is one of the most helpful tools I've been using recently, and it's just something like: parallel -j4 'gzip {}' ::: folder/*.csv
-- Milton Pividori @miltondp@twitter

New in this release:

No new features. This is a candidate for a stable release.
Bug fixes and man page updates.

News about GNU Parallel:

Separate arguments with a custom separator in GNU Parallel https://boxofcuriosities.co.uk/post/separate-arguments-with-a-custom-separator-in-gnu-parallel
GNU parallel is underrated https://amontalenti.com/2021/11/10/parallel
Unlocking the Power of Supercomputers: My HPC Adventure with 2800 Cores and GNU Parallel https://augalip.com/2024/03/10/unlocking-the-power-of-supercomputers-my-hpc-adventure-with-2800-cores-and-gnu-parallel/
Converting WebP Images to PNG Using parallel and dwebp https://bytefreaks.net/gnulinux/bash/converting-webp-images-to-png-using-parallel-and-dwebp

About 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:

(Have your company) donate to FSF https://my.fsf.org/donate/

About GNU SQL

About GNU Niceload

GNU Health: GHCon2024, the GNU Health Conference . Palermo, Italy

Sat, 19 Oct 2024 17:30:49 +0000

Dear community:

We’re excited to announce the IX International GNU Health Conference, that will take place in beautiful Sicily, Italy, at the University of Palermo this December 15th.

Mount Etna rising over suburbs of Catania, Sicily (Wikimedia)

The GNU Health Conference (GHCon) is the annual conference that brings together enthusiasts and developers of GNU Health, the Libre digital health ecosystem. The conference will have thematic sessions, lightning talks and implementation cases to get to know the GNU Health and other Free/Libre software communities from around the world.

We will show the upcoming features of the Health and Hospital Information System, standards, security, privacy, the GNU Health Federation and MyGNUHealth (the Personal Health Record).

GHCon2024 – The IX International GNU Health Conference

The XVII International Workshop on eHealth in Emerging Economies (IWEEE) is about Social Medicine and addressing the reality of the underprivileged around the world. There will be workshops to debate, and share experiences from humanitarian organizations and from those working in field of Social Medicine.

In the evening we will announce and honor the winners of the GNU Health Social Medicine awards.

We are counting on you to get the most out of the conference. Most importantly, we want you to have fun, feel at home, and enjoy being part
of the GNU Health community.

Looking forward to seeing you in Sicily!

Happy Hacking!

GHCon2024 homepage: https://www.gnuhealth.org/ghcon
Registration: https://my.gnusolidario.org/ghcon2024-registration/

You can share the news using the tag #GHCon2024

gnuboot @ Savannah: Nonfree software found in GNU Boot releases again, many distros affected.

Sat, 19 Oct 2024 13:27:22 +0000

The GNU Boot project previously found nonfree microcode in the first
RC1 release (in gnuboot-0.1-rc1_src.tar.xz to be exact).

This was announced in the "GNU Boot December 2023 News"
(https://lists.gnu.org/archive/html/gnuboot-announce/2023-12/msg00000.html). It
was fixed by re-making the affected tarball by hand with the nonfree
software removed and by contacting Canoeboot that had the same issue,
and by bug reporting and proposing patches to fix the issue in Guix as
well (they are still pending as we need to find a reviewer familiar
with Coreboot).

But recently we found a more problematic issue that also affects many
more distributions and all the previous GNU Boot release candidates.

The vboot source code used in Coreboot and in the vboot-utils package
available in many GNU/Linux distributions contains nonfree code in
their test data in tests/futility/data (nonfree microcode, nonfree
BIOS, nonfree Management Engine firmwares, etc).

So we had to re-release all the affected tarballs (like
gnuboot-0.1-rc1_src.tar.xz, gnuboot-0.1-rc2_src.tar.xz, etc).

We made and we improved the process along the way (we now store the
changes in tag inside our git repository and simply regenerate the
tarballs with the build system that is available for a given tag).

We are also in the process of contacting distributions and/or
coordinating with them and we also need help as there are many
distributions to contact.

To do that we started contacting the free GNU/Linux distros
(https://www.gnu.org/distros/free-distros.html) that ship the vboot
source code. We also contacted Replicant that is a free Android distro
that also ships vboot source code.

We also started to contact common distros that require certain
repositories to only have free software (so far we only contacted
Debian as that will help Trisquel fix the issue, but we also need to
contact Fedora for instance). Finding which distro to contact is made
much easier thanks to GNU's review of common distros policies
(https://www.gnu.org/distros/common-distros.html).

We coordinate that work on our bug report system at Savannah,
especially in the bug #66246
(https://savannah.gnu.org/bugs/index.php?66246).

health @ Savannah: GHcon2024, the GNUHealth Conference will be in Palermo, Italy - December 15th

Sat, 19 Oct 2024 08:46:46 +0000

Dear community:

We're excited to announce the IX International GNU Health Conference, that will take place in beautiful Sicily, Italy, at the University of Palermo this December 15th.

The GNU Health Conference (GHCon) is the annual conference that brings together enthusiasts and developers of GNU Health, the Libre digital health ecosystem. The conference will have thematic sessions, lightning talks and implementation cases to get to know the GNU Health and other Free/Libre software communities from around the world.

We will show the upcoming features of the Health and Hospital Information System, standards, security, privacy, the GNU Health Federation and MyGNUHealth (the Personal Health Record)

The XVII International Workshop on eHealth in Emerging Economies (IWEEE) is about Social Medicine and addressing the reality of the underprivileged around the world. There will be workshops to debate, and share experiences from humanitarian organizations and from those working in field of Social Medicine.

In the evening we will announce and honor the winners of the GNU Health Social Medicine awards.

We are counting on you to get the most out of the conference. Most importantly, we want you to have fun, feel at home, and enjoy being part of the GNU Health community.

Happy Hacking!

Homepage: https://www.gnuhealth.org/ghcon

Registration: https://my.gnusolidario.org/ghcon2024-registration/

Follow us in Mastodon (https://mastodon.social/@gnuhealth) for the latest news.

You can share the news using the tag #GHCon2024

libunistring @ Savannah: GNU libunistring-1.3 released

Wed, 16 Oct 2024 18:49:44 +0000

Download from https://ftp.gnu.org/gnu/libunistring/libunistring-1.3.tar.gz

This is a stable release.

New in this release:

The data tables and algorithms have been updated to Unicode version 16.0.0.
New function uc_is_property_modifier_combining_mark and new constant UC_PROPERTY_MODIFIER_COMBINING_MARK.
Fixed a bug in the *printf functions: The %ls and %lc directives could lead to a crash on Solaris and MSVC.

GNUnet News: GNUnet 0.22.1

Wed, 09 Oct 2024 22:00:00 +0000

GNUnet 0.22.1

This is a bugfix release for gnunet 0.22.0. It addresses some issues in HELLO URI handling and formatting as well as regressions in the DHT subsystem along with other bug fixes.

FSF News: Free Software Foundation to serve on "artificial intelligence" safety consortium

Wed, 09 Oct 2024 14:05:00 +0000

BOSTON (October 8, 2024) -- The Free Software Foundation (FSF) has announced that it is taking part in the US National Institute of Standards and Technology (NIST)'s consortium on the safety of (so-called) artificial intelligence, particularly with reference to "generative" AI systems. The FSF will ensure the free software perspective is adequately represented in these discussions.

health @ Savannah: Time to take back the Internet

Thu, 26 Sep 2024 18:08:49 +0000

It’s no news. They’re stealing the Internet from us and we must do something about it. What it used to be a fun, collaborative hacking space is now ruled by corporations and narcissistic billionaires. Proprietary centralized social networks have become a space for hate, discrimination and propaganda. The messages that you see are those that they want you to see. Your data is no longer yours. They have become a massive thought control machine. You read what they want you to read and, in the end, you will end up writing and doing what they want you to write and to do. It’s a matter of time and money, and they have both.

These corporate-driven social networks are deceiving. They make us fall into false assumptions in a distorted reality. This delusion hits both individuals and organizations. For instance, in GNU Solidario and GNU Health, we fight for Social Medicine and for the rights of human and non-human animals. When we want to share an event, to make a fundraising campaign or to denounce human or animal rights violations we want the message to reach out as many people as possible. We could think, why not share it with our followers on Twitter / X? Experience has it, corporate social networks have not really made a difference in the outcomes. They will promote or “shadow ban” the message depending on who wrote it. You can guess the results for those who fight against neoliberal capitalism.

Social pressure exists, and is not trivial to overcome. Many fear that leaving proprietary centralized social networks that have been using for years will result in losing the status and contacts they’ve built throughout the years. Again, it’s not really a big deal. And we have great news, there are decentralized, community-driven alternatives! Some of those alternatives are Mastodon, Friendica or Diaspora. Not only social networks, today there is an free software alternative to pretty much any proprietary solution (search engines, scientific programs, multimedia, office suites, databases, games…)

There is a correlation between Free Software, freedom and privacy. The more Free Software, the more freedom and privacy you enjoy. The contrary also applies: Proprietary software is inversely proportional to our freedom, both at individual and collective level. There is no transparency, no privacy, no control, no rights in proprietary applications, networks or clouds.

In the last decades, the tech giants have been busy in a campaign to dismantle the Free Software philosophy and community. The “open source” euphemism is one of them. Richard Stallman (creator of the GNU project and the Free Software Foundation) has been warning us about the dangers of “Open Source”. Free societies are built with free software, not with open source. I know some members in the free software community use both terms interchangeably, but I am convinced using the “Free Software” terms not only delivers software, but also freedom to our society.

Internet is no longer fun or empathetic. It has become a hostile and toxic environment, the medium for corporations and elites that increase concentration of power, social gradient and create very unjust societies. They use our data to control individuals and governments. We certainly don’t want to be part of that.

It is our moral duty to bring back spirit of solidarity that RMS delivered in the late 80’s, and that made possible the GNU movement, the best operating systems, programming languages, web servers and database engines for everyone. The GNU project was the inspiration for projects like GNU Health, helping millions around the globe, delivering freedom and equity in healthcare.

In the end, it is up to us to embrace federated, community driven social networks and free software applications. Millions of individuals, activists, free software projects, NGOs and even the European Union have already joined the Fediverse and Mastodon. It only takes an initial push to break the social pressure to set ourselves and our societies free.

Citing our friends from GNUnet: “You broke the Internet… we’ll build a GNU one”.

Happy hacking!

Follow us in Mastodon: https://mastodon.social/@gnuhealth

Original post: https://my.gnusolidario.org/2024/09/26/time-to-take-back-the-internet/