The 23rd release of GNU Astronomy Utilities (Gnuastro) is now available. See the full announcement for all the new features in this release and the many bugs that have been found and fixed: https://lists.gnu.org/archive/html/info-gnuastro/2024-07/msg00001.html
In this bachelor thesis Yann Doy presents his implementation of a concept of eKYC (electronic Knwo Your Customer procedure).
After rebuilding all added/modified packages in Trisquel, I have been circling around the elephant in the room: 99% of the binary packages in Trisquel comes from Ubuntu, which to a large extent are built from Debian source packages. Is it possible to rebuild the official binary packages identically? Does anyone make an effort to do so? Does anyone care about going through the differences between the official package and a rebuilt version? Reproducible-build.org‘s effort to track reproducibility bugs in Debian (and other systems) is amazing. However as far as I know, they do not confirm or deny that their rebuilds match the official packages. In fact, typically their rebuilds do not match the official packages, even when they say the package is reproducible, which had me surprised at first. To understand why that happens, compare the buildinfo file for the official coreutils 9.1-1 from Debian bookworm with the buildinfo file for reproducible-build.org’s build and you will see that the SHA256 checksum does not match, but still they declare it as a reproducible package. As far as I can tell of the situation, the purpose of their rebuilds are not to say anything about the official binary build, instead the purpose is to offer a QA service to maintainers by performing two builds of a package and declaring success if both builds match.
I have felt that something is lacking, and months have passed and I haven’t found any project that address the problem I am interested in. During my earlier work I created a project called debdistreproduce which performs rebuilds of the difference between two distributions in a GitLab pipeline, and display diffoscope output for further analysis. A couple of days ago I had the idea of rewriting it to perform rebuilds of a single distribution. A new project debdistrebuild was born and today I’m happy to bless it as version 1.0 and to announces the project! Debdistrebuild has rebuilt the top-50 popcon packages from Debian bullseye, bookworm and trixie, on amd64 and arm64, as well as Ubuntu jammy and noble on amd64 , see the summary status page for links. This is intended as a proof of concept, to allow people experiment with the concept of doing GitLab-based package rebuilds and analysis. Compare how Guix has the [guix challenge](https://guix.gnu.org/manual/en/html_node/On-Trusting-Binaries.html) command.
Or I should say debdistrebuild has attempted to rebuild those distributions. The number of identically built packages are fairly low, so I didn’t want to waste resources building the rest of the archive until I understand if the differences are due to consequences of my build environment (plain apt-get build-dep followed by dpkg-buildpackage in a fresh container), or due to some real difference. Summarizing the results, **debdistrebuild** is able to rebuild 34% of Debian bullseye on amd64, 36% of bookworm on amd64, 32% of bookworm on arm64. The results for trixie and Ubuntu are disappointing, below 10%.
So what causes my rebuilds to be different from the official rebuilds? Some are trivial like the classical problem of varying build paths, resulting in a different NT_GNU_BUILD_ID causing a mismatch. Some are a bit strange, like a subtle difference in one of perl’s headers file. Some are due to embedded version numbers from a build dependency. Several of the build logs and diffoscope outputs doesn’t make sense, likely due to bugs in my build scripts, especially for Ubuntu which appears to strip translations and do other build variations that I don’t do. In general, the classes of reproducibility problems are the expected. Some are assembler differences for GnuPG’s gpgv-static, likely triggered by upload of a new version of gcc after the original package was built. There are at least two ways to resolve that problem: either use the same version of build dependencies that were used to produce the original build, or demand that all packages that are affected by a change in another package are rebuilt centrally until there are no more differences.
The current design of debdistrebuild uses the latest version of a build dependency that is available in the distribution. We call this a “ idempotent rebuild “. This is usually not how the binary packages were built originally, they are often built against earlier versions of their build dependency. That is the situation for most binary distributions.
Instead of using the latest build dependency version, higher reproducability may be achieved by rebuilding using the same version of the build dependencies that were used during the original build. This requires parsing buildinfo files to find the right version of the build dependency to install. We believe doing so will lead to a higher number of reproducibly built packages. However it begs the question: can we rebuild that earlier version of the build dependency? This circles back to really old versions and bootstrappable builds eventually.
While rebuilding old versions would be interesting on its own, we believe that is less helpful for trusting the latest version and improving a binary distribution: it is challenging to publish a new version of some old package that would fix a reproducibility bug in another package when used as a build dependency, and then rebuild the later packages with the modified earlier version. Those earlier packages were already published, and are part of history. It may be that ultimately it will no longer be possible to rebuild some package, because proper source code is missing (for packages using build dependencies that were never part of a release); hardware to build a package could be missing; or that the source code is no longer publicly distributable.
I argue that getting to 100% idempotent rebuilds is an interesting goal on its own, and to reach it we need to start measure idempotent rebuild status.
One could conceivable imagine a way to rebuild modified versions of earlier packages, and then rebuild later packages using the modified earlier packages as build dependencies, for the purpose of achieving higher level of reproducible rebuilds of the last version, and to reach for bootstrappability. However, it may be still be that this is insufficient to achieve idempotent rebuilds of the last versions. Idempotent rebuilds are different from a reproducible build (where we try to reproduce the build using the same inputs), and also to bootstrappable builds (in which all binaries are ultimately built from source code). Consider a cycle where package X influence the content of package Y, which in turn influence the content of package X. These cycles may involve several packages, and it is conceivable that a cycle could be circular and infinite. It may be difficult to identify these chains, and even more difficult to break them up, but this effort help identify where to start looking for them. Rebuilding packages using the same build dependency versions as were used during the original build, or rebuilding packages using a bootsrappable build process, both seem orthogonal to the idempotent rebuild problem.
Our notion of rebuildability appears thus to be complementary to reproducible-builds.org’s definition and bootstrappable.org’s definition. Each to their own devices, and Happy Hacking!
Years ago I was wondering what this init freedom thing was all about. Today in the wakes of regreSSHion and xzUtils it dawns on me.
This article has been written in 2022 but could not be more up to date today.
#gnu #linux #foss #init #freedom #devuan #debian #backdoor #systemd
Distro Walk – Devuan
Devuan, with its promise of Init Freedom, provides users an alternative to systemd as an init process.
Long-time Linux users may remember a time when Debian was viewed as a collection of anarchists, with radical ideas about voting and decision-making. At times, Debian was even the lone dissenter among distributions about decisions made by the Free Software Foundation. However, over the years, Debian has developed its own hierarchy along the way to becoming the source for some two-thirds of active distributions. Today, the Debian derivative most reminiscent of early Debian is Devuan [1], which forked from Debian in 2014 over how decisions were made and the technical connotations of using systemd. Recently, two Devuan developers – fsmithred, who builds the live images and helps with support, and golinux, the community manager – took the time to recall Devuan's past and why their issues are still relevant today. Because Devuan lacks a formal hierarchy, they emphasize that their remarks are "unofficially official."
In 2014, major Linux distributions were transitioning from SysVinit to systemd as an init process – init being the first process to start on a system and the one that manages other processes. Ubuntu had started using Upstart a decade earlier with little controversy. By contrast, systemd was controversial from its earliest days. To start with, systemd is much more than an init system. Rather, as contributor dasein described on the Debian User Forums, "calling systemd an init system is like calling an automobile a cup holder" [2]. That is, while systemd includes the functions of an init system, dasein said systemd is also "an effort to recreate large portions of existing userspace (including login, job scheduling, and networking, just to name a few) inside a single process traditionally reserved for the sole purpose of starting *nix userspace. (Just in case it isn't clear, there is a huge difference between starting userspace (init) and being userspace (systemd).)"
From this perspective, not only is systemd overkill, but it is a violation of the basic tenet of Unix development that an application does only one thing and does it very well. As Christopher Barry stated in the Linux Kernel Archive, this philosophy is what makes Linux "a collection of simple modular components that could be plugged together at will to do real work" [3] – an operating system that is both flexible and accessible. Just as importantly, a modular structure allows the pieces to be assembled in different ways, so that each distribution can be unique. By contrast, systemd imposes a structure on all Linux systems that reduces variety – which is convenient in some ways, but needlessly limiting in time-honored ways.
As expected, the Debian mail forums debated these perspectives extensively. Unsurprisingly, the discussion culminated in a General Resolution among Debian users, with many Debian officials favoring systemd. The winning option was to use systemd, but at the same time, a more general resolution to favor systemd placed last – a decided ambiguity. Although rarely stated in so many words, much of the dissatisfaction implied that the decision to use systemd was imposed by the Debian hierarchy upon the general membership.
Whether this implication was valid is besides the point. Many believed it was. On November 24, 2014, the Devuan fork was announced. The intention was "to produce a reliable and minimalist base distribution that stays away from the homogenization and lock-in promoted by systemd" [4].
Introducing Init Freedom
Rather than being seen as simply an anti-systemd project, Devuan calls its position Init Freedom (Figure 1). The name invokes Richard Stallman's four essential freedoms, although the idea itself might seem less basic. Devuan's Init Freedom page [5] simply defines the idea as being "about restoring a sane approach to PID1 [init] that respects portability, diversity, and freedom of choice," assuming that the value of these goals is self-evident.
Figure 1: Devuan supports a choice of init alternatives.
In practice, Init Freedom means supporting a choice of init freedoms. Although systemd advocates often maintain that supporting multiple init systems would make packaging more difficult, from its first release, Devuan has continually added init alternatives without any apparent difficulties. Today, in addition to the default SysVinit, Devuan lists six alternatives: OpenRC, runit, sinit, s6, 66-devuan, and Shepherd, and it is open to considering others. Fsmithred suggests that most people simply use sysVinit, although OpenRC and runit, which use SysVinit scripts, are also available. Scripts are also being developed for runit and to extend usability of other shipped alternatives. For those interested in learning more, discussion can be found on the Dev1 Galaxy Forum [6] and on Devuan's IRC channel [7].
In addition, the Init Freedom page lists other Linux distributions that offer systemd-free alternatives, as well as other Unices such as the BSD Family. DistroWatch also offers a search filter for distros without systemd – currently, 97, a total far higher than many might suspect, although it includes only a handful of major distributions, such as MX Linux, Alpine Linux, and KNOPPIX [8]. Devuan keeps in close touch with these distributions, especially on the Dev1 Galaxy Forum.
Fsmithred adds that, "We rely heavily on Debian. Most of the packages in Devuan are unchanged from Debian. We only fork packages that require systemd. There is collaboration between Devuan and Debian on a few packages, and we occasionally send bug fixes or patches upstream to Debian for packages we do not fork."
Beyond Init Freedom
Devuan is usually referred to in terms of Init Freedom – often with the obviously mistaken assumption that it is a lost cause. However, Devuan also features Docker images and community-developed ARM packages. Chimaera, the latest Devuan release, also includes an option to not install PulseAudio to enable simultaneous speech synthesis in both a graphical and console session. In addition, at least one Devuan-derivative exists, Maemo Leste, whose goal is "to provide a free and open source Maemo experience on mobile phones and tablets like the Nokia N900, Motorola Droid 4, Motorola Bionic, PinePhone, PineTab, Allwinner tablets, and more" [9]. Although Devuan might be a niche distribution, clearly it is a thriving one.
But can Devuan's cause become mainstream? It's not impossible. Linux is in an era in which large parts of it are being written. If PulseAudio can be replaced with PipeWire – which is currently happening – then systemd's obsolescence is not impossible, either. Meanwhile, for those who disagree with the majority, Devuan provides a workable alternative, while keeping the early spirit of Debian alive.
Source: https://www.linux-magazine.com/Issues/2022/260/Devuan
At last, #KDE natively recognizes my external #touchscreen and natively maps the touch to the correct location on the it when it is acting as an extension to one side (right) of the laptop display. This was not possible previously under #Wayland. Pity it doesn't seem to be documented in a prominent location.
The Hyperbola Project is a community driven effort to provide a fully free (as in freedom) operating system that is stable, secure, simple, lightweight that tries to Keep It Simple Stupid (KISS) under a Long Term Support (LTS) way.
Hyperbola is an independent, free and libre system built from scratch using the package-management from Arch GNU/Linux and especially patchsets for security from Debian providing packages that meet the GNU Free System Distribution Guidelines (GNU FSDG). Packages are provided for the i686 and x86_64 architectures.
"Analysis for binutils and gcc: ... we review the needed code for our implementation and needed backporting. With this we have now a good base for a near first working pre-alpha version of HyperbolaBSD as full BSD-descendant operating-system and the next step for Hyperbola as project in a whole."
Have you ever wondered how to get a friend or colleague or even a complete stranger hooked up with free software? Here's the ultimate guide.
GNU direvent version 5.4 is available for download.
New in this version:
It is possible to limit number of command instances that are allowed to run simultaneously for a particular watcher. This is done using
the max-instances statement in watcher section.
In previous version, watchers waited for the handler to terminate, unless given the nowait option explicitly. It is now fixed and nowait is the default, as described in the documentation.
In some cases setting the sentinel effectively removed the original watcher. That happened if the full file name of the original watcher
and its directory part produced the same hash code.
When NeXT still existed and the black hardware was a thing, Steve Jobs made the announcement that OPENSTEP would be created and that the object model, not the operating system and not the hardware, was the important thing.
This is a concept that Apple has forgotten. With it's push towards Apple Silicon and a walled-garden, Apple has committed itself to the same pitfall that NeXT fell into. NeXT lacked the infrastructure to handle OPENSTEP running on multiple kinds of hardware, but the object model on different OSes was successful... this is evident in OPENSTEP1.1 for Solaris and OPENSTEP for NT.
GNUstep attempts to reach the same goal, but provides the APIs that are available with Cocoa. The object model IS the important thing and this is why GNUstep is so important. It breaks the walled garden and makes it possible for users to run their apps and tools on other operating systems. GNUstep HASN'T forgotten and we believe this is a core concept that Apple has left behind.
from arch:
After upgrading to openssh-9.8p1, the existing SSH daemon will be unable to accept new connections. When upgrading remote hosts, please make sure to restart the sshd service using systemctl try-restart sshd right after upgrading.
We are evaluating the possibility to automatically apply a restart of the sshd service on upgrade in a future release of the openssh-9.8p1 package.
I am happy to announce a new release of GNU poke, version 4.2.
This is a bugfix release in the 4.x series.
See the file NEWS in the distribution tarball for a list of issues
fixed in this release.
The tarball poke-4.2.tar.gz is now available at
https://ftp.gnu.org/gnu/poke/poke-4.2.tar.gz.
GNU poke (http://www.jemarch.net/poke) is an interactive, extensible
editor for binary data. Not limited to editing basic entities such
as bits and bytes, it provides a full-fledged procedural,
interactive programming language designed to describe data
structures and to operate on them.
Thanks to the people who contributed with code and/or documentation to
this release.
Happy poking!
Mohammad-Reza Nabipoor
11+ Reasons to Switch From Windows to Linux
https://www.lpi.org/fr/blog/2024/06/27/eleven-reasons-switch-windows-linux/
#Windows #GNU #Linux #FLOSS
The title of this article, “ Migrar, migrant, migrà rem “, comes from a beautiful poem written by Laia Porcar[1], that inspired the strikingly profound painting by Sara Belles [2] “ Jo per tu, fill meu “. The artists reflect the migrants ordeal to provide a better life to their children and families, even at the cost of losing their own lives.
GNU Health[3] is a Social project with some technology behind and the mission at Sea-Eye is one of the best examples. After all, GNU Solidario[4] is a NGO that focuses in the advancement of Social Medicine.
We live a world of injustice. Concentration of power, social gradient and poverty rates keep on the rise. Artificial intelligence is on the hands of mega private corporations, targeting our privacy and feeding the macabre business of war. The fight for scarce natural resources such as lithium or coltan creates coups in impoverished countries. Nature and non-human animals are used and abused as mere commodities. Our world turns a blind eye to the systematic crushing and eradication of civilian population by powerful armies. As a result, we live in a world where migration is not a choice, but the only way out for millions of human beings, even at the risk of becoming anonymous victims in the Atlantic ocean or Mediterranean sea mass graveyards.
“Jo per tu, fill meu”, by Sara Belles
But there is hope. The Sea-Eye mission is the end result of a network of solidarity, cooperation and empathy. The Free Software movement started by Richard Stallman[5]; Julian Sassencheidt message in Mastodon and his presentation at GNU Health Con 2023[6] ; The work of our representative in Germany, Gerald Wiese; the Chaos Computer Club[7]; the team from L’Aurora[8] providing logistic support to the Search and Rescue vessels; the phenomenal Sea-Eye family who made me feel at home: The cook, crew on deck, the logistics and medical team who stood stoically intensive hours of GNU Health training. Of course, Selene, the heart of GNU Solidario and the one that looks after the human and non-human family members while I’m away.
You will hardly see these people in the news, because most corporate-backed media neglect them and their organizations. Unlike some billionaire “philanthropists” that take the media spotlight, these anonymous heroes stand on the right side of history, making a difference on the present and future of those who need it most, with very limited resources.
Collage of several pictures during my stay at the Sea-eye
We’re very happy and proud to see that GNU Health can be of help to Sea-Eye in tasks such as guests registration, health evaluations, reporting, statistics and stock management. This is just the beginning and we will be optimizing and adding functionality on successive missions. That said, GNU Health will always play a secondary role compared to picking up somebody from the water and giving them a welcoming hug. Again, we’re a social project with a bit of technology behind.
Drawings made by the children rescued at the Sea-eye
I’d like to finish with a reflection on the picture I took to some of the drawings done by children during their stay at the Sea-Eye. The drawings exist because the Sea-eye crew rescued those kids. Otherwise, their corpses would be at the bottom of the Mediterranean sea, along with thousands who tragically perished trying to find dignity in this world. Thank you, Sea-eye. You are priceless.
A final note: shame on those countries and governments that detain and punish Search and Rescue vessels. Saving lives is not a crime.
Love, freedom and happy hacking
You can obtain Sara Belles painting and Laia Porcar poem from L’Aurora solidarity shop[8]
So... recently I was working for a bit (sweat equity or so I thought) for a company by the name of ImmortalData. The company is headed by a man by the name of Dale Amon. I have worked, on and off, for them for about 2-3 years. They are developing a piece of software that is used to extract data from their proprietary black box systems. This piece of software uses GNUstep. They were born from a previous company known as XCOR which was developing a space plane at the Mojave space port. That company is now defunct.
Okay, so with that bit of history, I worked for a while for XCOR and then, because ImmortalData inherited the software, for them as well. When I worked for XCOR it was as a contractor. There have been issues with the software (some GNUstep bugs and some bugs due to problems introduced by Dale) that I have been asked to address.
At the end of a meeting a few weeks ago Dale made a comment like "Well, this issue seems like a GNUstep bug, so there is no reason we should have to pay for any of this" which hit an EXTREMELY sour note with me.
Later on that week I tried to clarify it with Dale, and it seems as though he was under the impression that since I was working on Free Software any changes or fixes TO that software should not be billable. This is NOT true. Additionally, the issue that they are experiencing is because of something THEY did, and it is not a GNUstep bug.
I mentioned this in the previous post, but I feel strongly that this needs to be called out explicitly. Free Software is free as in FREEDOM. This means you are free to look at, examine, and modify the software as you see fit. It does NOT mean services performed on that software on your behalf by someone other than you are free.
This development was VERY upsetting to me and I feel the need to make the above VERY clear.
