Language Selection

English French German Italian Portuguese Spanish

Gnu Planet

Syndicate content
Planet GNU - https://planet.gnu.org/
Updated: 5 hours 48 min ago

FSF Events: Richard Stallman - "Computing, freedom, and privacy" (Brno, Czech Republic)

Friday 24th of May 2019 01:35:00 PM
The way digital technology is developing, it threatens our freedom, within our computers and in the internet. What are the threats? What must we change?

This speech by Richard Stallman will be nontechnical, admission to just the speech is gratis—provided you register via the FSF link—and the public is encouraged to attend.

Location: Pavilion G1, Digital City Stage, Brno Fair Grounds (BVV), URBIS Smart City Fair, Výstaviště 405/1, 603 00

Please register, so that we can accommodate all the people who wish to attend.

Please fill out our contact form, so that we can contact you about future events in and around Brno.

Andy Wingo: lightening run-time code generation

Friday 24th of May 2019 08:44:56 AM

The upcoming Guile 3 release will have just-in-time native code generation. Finally, amirite? There's lots that I'd like to share about that and I need to start somewhere, so this article is about one piece of it: Lightening, a library to generate machine code.

on lightning

Lightening is a fork of GNU Lightning, adapted to suit the needs of Guile. In fact at first we chose to use GNU Lightning directly, "vendored" into the Guile source respository via the git subtree mechanism. (I see that in the meantime, git gained a kind of a subtree command; one day I will have to figure out what it's for.)

GNU Lightning has lots of things going for it. It has support for many architectures, even things like Itanium that I don't really care about but which a couple Guile users use. It abstracts the differences between e.g. x86 and ARMv7 behind a common API, so that in Guile I don't need to duplicate the JIT for each back-end. Such an abstraction can have a slight performance penalty, because maybe it missed the opportunity to generate optimal code, but this is acceptable to me: I was more concerned about the maintenance burden, and GNU Lightning seemed to solve that nicely.

GNU Lightning also has fantastic documentation. It's written in C and not C++, which is the right thing for Guile at this time, and it's also released under the LGPL, which is Guile's license. As it's a GNU project there's a good chance that GNU Guile's needs might be taken into account if any changes need be made.

I mentally associated Paolo Bonzini with the project, who I knew was a good no-nonsense hacker, as he used Lightning for a smalltalk implementation; and I knew also that Matthew Flatt used Lightning in Racket. Then I looked in the source code to see architecture support and was pleasantly surprised to see MIPS, POWER, and so on, so I went with GNU Lightning for Guile in our 2.9.1 release last October.

on lightening the lightning

When I chose GNU Lightning, I had in mind that it was a very simple library to cheaply write machine code into buffers. (Incidentally, if you have never worked with this stuff, I remember a time when I was pleasantly surprised to realize that an assembler could be a library and not just a program that processes text. A CPU interprets machine code. Machine code is just bytes, and you can just write C (or Scheme, or whatever) functions that write bytes into buffers, and pass those buffers off to the CPU. Now you know!)

Anyway indeed GNU Lightning 1.4 or so was that very simple library that I had in my head. I needed simple because I would need to debug any problems that came up, and I didn't want to add more complexity to the C side of Guile -- eventually I should be migrating this code over to Scheme anyway. And, of course, simple can mean fast, and I needed fast code generation.

However, GNU Lightning has a new release series, the 2.x series. This series is a rewrite in a way of the old version. On the plus side, this new series adds all of the weird architectures that I was pleasantly surprised to see. The old 1.4 didn't even have much x86-64 support, much less AArch64.

This new GNU Lightning 2.x series fundamentally changes the way the library works: instead of having a jit_ldr_f function that directly emits code to load a float from memory into a floating-point register, the jit_ldr_f function now creates a node in a graph. Before code is emitted, that graph is optimized, some register allocation happens around call sites and for temporary values, dead code is elided, and so on, then the graph is traversed and code emitted.

Unfortunately this wasn't really what I was looking for. The optimizations were a bit opaque to me and I just wanted something simple. Building the graph took more time than just emitting bytes into a buffer, and it takes more memory as well. When I found bugs, I couldn't tell whether they were related to my usage or in the library itself.

In the end, the node structure wasn't paying its way for me. But I couldn't just go back to the 1.4 series that I remembered -- it didn't have the architecture support that I needed. Faced with the choice between changing GNU Lightning 2.x in ways that went counter to its upstream direction, switching libraries, or refactoring GNU Lightning to be something that I needed, I chose the latter.

in which our protagonist cannot help himself

Friends, I regret to admit: I named the new thing "Lightening". True, it is a lightened Lightning, yes, but I am aware that it's horribly confusing. Pronounced like almost the same, visually almost identical -- I am a bad person. Oh well!!

I ported some of the existing GNU Lightning backends over to Lightening: ia32, x86-64, ARMv7, and AArch64. I deleted the backends for Itanium, HPPA, Alpha, and SPARC; they have no Debian ports and there is no situation in which I can afford to do QA on them. I would gladly accept contributions for PPC64, MIPS, RISC-V, and maybe S/390. At this point I reckon it takes around 20 hours to port an additional backend from GNU Lightning to Lightening.

Incidentally, if you need a code generation library, consider your choices wisely. It is likely that Lightening is not right for you. If you can afford platform-specific code and you need C, Lua's DynASM is probably the right thing for you. If you are in C++, copy the assemblers from a JavaScript engine -- C++ offers much more type safety, capabilities for optimization, and ergonomics.

But if you can only afford one emitter of JIT code for all architectures, you need simple C, you don't need register allocation, you want a simple library to just include in your source code, and you are good with the LGPL, then Lightening could be a thing for you. Check the gitlab page for info on how to test Lightening and how to include it into your project.

giving it a spin

Yesterday's Guile 2.9.2 release includes Lightening, so you can give it a spin. The switch to Lightening allowed us to lower our JIT optimization threshold by a factor of 50, letting us generate fast code sooner. If you try it out, let #guile on freenode know how it went. In any case, happy hacking!

GNU Guile: GNU Guile 2.9.2 (beta) released

Thursday 23rd of May 2019 09:00:00 PM

We are delighted to announce GNU Guile 2.9.2, the second beta release in preparation for the upcoming 3.0 stable series. See the release announcement for full details and a download link.

This release extends just-in-time (JIT) native code generation support to the ia32, ARMv7, and AArch64 architectures. Under the hood, we swapped out GNU Lightning for a related fork called Lightening, which was better adapted to Guile's needs.

GNU Guile 2.9.2 is a beta release, and as such offers no API or ABI stability guarantees. Users needing a stable Guile are advised to stay on the stable 2.2 series.

Users on the architectures that just gained JIT support are especially encouraged to report experiences (good or bad) to guile-devel@gnu.org. If you know you found a bug, please do send a note to bug-guile@gnu.org. Happy hacking!

Andy Wingo: bigint shipping in firefox!

Thursday 23rd of May 2019 12:13:59 PM

I am delighted to share with folks the results of a project I have been helping out on for the last few months: implementation of "BigInt" in Firefox, which is finally shipping in Firefox 68 (beta).

what's a bigint?

BigInts are a new kind of JavaScript primitive value, like numbers or strings. A BigInt is a true integer: it can take on the value of any finite integer (subject to some arbitrarily large implementation-defined limits, such as the amount of memory in your machine). This contrasts with JavaScript number values, which have the well-known property of only being able to precisely represent integers between -253 and 253.

BigInts are written like "normal" integers, but with an n suffix:

var a = 1n; var b = a + 42n; b << 64n // result: 793209995169510719488n

With the bigint proposal, the usual mathematical operations (+, -, *, /, %, <<, >>, **, and the comparison operators) are extended to operate on bigint values. As a new kind of primitive value, bigint values have their own typeof:

typeof 1n // result: 'bigint'

Besides allowing for more kinds of math to be easily and efficiently expressed, BigInt also allows for better interoperability with systems that use 64-bit numbers, such as "inodes" in file systems, WebAssembly i64 values, high-precision timers, and so on.

You can read more about the BigInt feature over on MDN, as usual. You might also like this short article on BigInt basics that V8 engineer Mathias Bynens wrote when Chrome shipped support for BigInt last year. There is an accompanying language implementation article as well, for those of y'all that enjoy the nitties and the gritties.

can i ship it?

To try out BigInt in Firefox, simply download a copy of Firefox Beta. This version of Firefox will be fully released to the public in a few weeks, on July 9th. If you're reading this in the future, I'm talking about Firefox 68.

BigInt is also shipping already in V8 and Chrome, and my colleague Caio Lima has an project in progress to implement it in JavaScriptCore / WebKit / Safari. Depending on your target audience, BigInt might be deployable already!

thanks

I must mention that my role in the BigInt work was relatively small; my Igalia colleague Robin Templeton did the bulk of the BigInt implementation work in Firefox, so large ups to them. Hearty thanks also to Mozilla's Jan de Mooij and Jeff Walden for their patient and detailed code reviews.

Thanks as well to the V8 engineers for their open source implementation of BigInt fundamental algorithms, as we used many of them in Firefox.

Finally, I need to make one big thank-you, and I hope that you will join me in expressing it. The road to ship anything in a web browser is long; besides the "simple matter of programming" that it is to implement a feature, you need a specification with buy-in from implementors and web standards people, you need a good working relationship with a browser vendor, you need willing technical reviewers, you need to follow up on the inevitable security bugs that any browser change causes, and all of this takes time. It's all predicated on having the backing of an organization that's foresighted enough to invest in this kind of long-term, high-reward platform engineering.

In that regard I think all people that work on the web platform should send a big shout-out to Tech at Bloomberg for making BigInt possible by underwriting all of Igalia's work in this area. Thank you, Bloomberg, and happy hacking!

parallel @ Savannah: GNU Parallel 20190522 ('Akihito') released

Wednesday 22nd of May 2019 08:29:50 PM

GNU Parallel 20190522 ('Akihito') has been released. It is available for download at: http://ftpmirror.gnu.org/parallel/

GNU Parallel is 10 years old in a year on 2020-04-22. You are here by invited to a reception on Friday 2020-04-17.

See https://www.gnu.org/software/parallel/10-years-anniversary.html

Quote of the month:

Amazingly useful script!
-- unxusr@reddit.com

New in this release:

  • --group-by groups lines depending on value of a column. The value can be computed.
  • How to compress (bzip/gzip) a very large text quickly? https://medium.com/@gchandra/how-to-compress-bzip-gzip-a-very-large-text-quickly-27c11f4c6681
  • Simple tutorial to install & use GNU Parallel https://medium.com/@gchandra/simple-tutorial-to-install-use-gnu-parallel-79251120d618
  • Bug fixes and man page updates.

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

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

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.

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 || curl pi.dk/3/ || fetch -o - http://pi.dk/3) | bash

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

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

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

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

If you like GNU Parallel:

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

If you use programs that use GNU Parallel for research:

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

If GNU Parallel saves you money:

About GNU SQL

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

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

When using GNU SQL for a publication please cite:

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

About GNU Niceload

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

FSF Events: Richard Stallman - "The Free Software Movement" (Brno, Czech Republic)

Wednesday 22nd of May 2019 11:10:00 AM
The Free Software Movement campaigns for computer users' freedom to cooperate and control their own computing. The Free Software Movement developed the GNU operating system, typically used together with the kernel Linux, specifically to make these freedoms possible.

This speech by Richard Stallman will be nontechnical, admission is gratis, and the public is encouraged to attend.

Location: University Cinema Scala, MoravskĂŠ nĂĄm. 127/3, 602 00 Brno, Czech Republic

Registration for this event is now closed. You might still be able to get a seat if you show up, but, to guarantee seating, please consider attending RMS's June 6 morning speech instead.

Please fill out our contact form, so that we can contact you about future events in and around Brno.

GNU Guix: Creating and using a custom Linux kernel on Guix System

Tuesday 21st of May 2019 10:00:00 AM

Guix is, at its core, a source based distribution with substitutes, and as such building packages from their source code is an expected part of regular package installations and upgrades. Given this starting point, it makes sense that efforts are made to reduce the amount of time spent compiling packages, and recent changes and upgrades to the building and distribution of substitutes continues to be a topic of discussion within Guix.

One of the packages which I prefer to not build myself is the Linux-Libre kernel. The kernel, while not requiring an overabundance of RAM to build, does take a very long time on my build machine (which my children argue is actually their Kodi computer), and I will often delay reconfiguring my laptop while I want for a substitute to be prepared by the official build farm. The official kernel configuration, as is the case with many GNU/Linux distributions, errs on the side of inclusiveness, and this is really what causes the build to take such a long time when I build the package for myself.

The Linux kernel, however, can also just be described as a package installed on my machine, and as such can be customized just like any other package. The procedure is a little bit different, although this is primarily due to the nature of how the package definition is written.

The linux-libre kernel package definition is actually a procedure which creates a package.

(define* (make-linux-libre version hash supported-systems #:key ;; A function that takes an arch and a variant. ;; See kernel-config for an example. (extra-version #f) (configuration-file #f) (defconfig "defconfig") (extra-options %default-extra-linux-options) (patches (list %boot-logo-patch))) ...)

The current linux-libre package is for the 5.1.x series, and is declared like this:

(define-public linux-libre (make-linux-libre %linux-libre-version %linux-libre-hash '("x86_64-linux" "i686-linux" "armhf-linux" "aarch64-linux") #:patches %linux-libre-5.1-patches #:configuration-file kernel-config))

Any keys which are not assigned values inherit their default value from the make-linux-libre definition. When comparing the two snippets above, you may notice that the code comment in the first doesn't actually refer to the #:extra-version keyword; it is actually for #:configuration-file. Because of this, it is not actually easy to include a custom kernel configuration from the definition, but don't worry, there are other ways to work with what we do have.

There are two ways to create a kernel with a custom kernel configuration. The first is to provide a standard .config file during the build process by including an actual .config file as a native input to our custom kernel. The following is a snippet from the custom 'configure phase of the make-linux-libre package definition:

(let ((build (assoc-ref %standard-phases 'build)) (config (assoc-ref (or native-inputs inputs) "kconfig"))) ;; Use a custom kernel configuration file or a default ;; configuration file. (if config (begin (copy-file config ".config") (chmod ".config" #o666)) (invoke "make" ,defconfig))

Below is a sample kernel package for one of my computers. Linux-Libre is just like other regular packages and can be inherited and overridden like any other:

(define-public linux-libre/E2140 (package (inherit linux-libre) (native-inputs `(("kconfig" ,(local-file "E2140.config")) ,@(alist-delete "kconfig" (package-native-inputs linux-libre))))))

In the same directory as the file defining linux-libre-E2140 is a file named E2140.config, which is an actual kernel configuration file. I left the defconfig keyword of make-linux-libre blank, so the only kernel configuration in the package is the one which I included as a native-input.

The second way to create a custom kernel is to pass a new value to the extra-options keyword of the make-linux-libre procedure. The extra-options keyword works with another function defined right below it:

(define %default-extra-linux-options `(;; https://lists.gnu.org/archive/html/guix-devel/2014-04/msg00039.html ("CONFIG_DEVPTS_MULTIPLE_INSTANCES" . #t) ;; Modules required for initrd: ("CONFIG_NET_9P" . m) ("CONFIG_NET_9P_VIRTIO" . m) ("CONFIG_VIRTIO_BLK" . m) ("CONFIG_VIRTIO_NET" . m) ("CONFIG_VIRTIO_PCI" . m) ("CONFIG_VIRTIO_BALLOON" . m) ("CONFIG_VIRTIO_MMIO" . m) ("CONFIG_FUSE_FS" . m) ("CONFIG_CIFS" . m) ("CONFIG_9P_FS" . m))) (define (config->string options) (string-join (map (match-lambda ((option . 'm) (string-append option "=m")) ((option . #t) (string-append option "=y")) ((option . #f) (string-append option "=n"))) options) "\n"))

And in the custom configure script from the make-linux-libre package:

;; Appending works even when the option wasn't in the ;; file. The last one prevails if duplicated. (let ((port (open-file ".config" "a")) (extra-configuration ,(config->string extra-options))) (display extra-configuration port) (close-port port)) (invoke "make" "oldconfig"))))

So by not providing a configuration-file the .config starts blank, and then we write into it the collection of flags that we want. Here's another custom kernel which I have:

(define %macbook41-full-config (append %macbook41-config-options %filesystems %efi-support %emulation (@@ (gnu packages linux) %default-extra-linux-options))) (define-public linux-libre-macbook41 ;; XXX: Access the internal 'make-linux-libre' procedure, which is ;; private and unexported, and is liable to change in the future. ((@@ (gnu packages linux) make-linux-libre) (@@ (gnu packages linux) %linux-libre-version) (@@ (gnu packages linux) %linux-libre-hash) '("x86_64-linux") #:extra-version "macbook41" #:patches (@@ (gnu packages linux) %linux-libre-5.1-patches) #:extra-options %macbook41-config-options))

From the above example %filesystems is a collection of flags I compiled enabling different filesystem support, %efi-support enables EFI support and %emulation enables my x86_64-linux machine to act in 32-bit mode also. %default-extra-linux-options are the ones quoted above, which had to be added in since I replaced them in the extra-options keyword.

This all sounds like it should be doable, but how does one even know which modules are required for their system? The two places I found most helpful to try to answer this question were the Gentoo Handbook, and the documentation from the kernel itself. From the kernel documentation, it seems that make localmodconfig is the command we want.

In order to actually run make localmodconfig we first need to get and unpack the kernel source code:

tar xf $(guix build linux-libre --source)

Once inside the directory containing the source code run touch .config to create an initial, empty .config to start with. make localmodconfig works by seeing what you already have in .config and letting you know what you're missing. If the file is blank then you're missing everything. The next step is to run:

guix environment linux-libre -- make localmodconfig

and note the output. Do note that the .config file is still empty. The output generally contains two types of warnings. The first start with "WARNING" and can actually be ignored in our case. The second read:

module pcspkr did not have configs CONFIG_INPUT_PCSPKR

For each of these lines, copy the CONFIG_XXXX_XXXX portion into the .config in the directory, and append =m, so in the end it looks like this:

CONFIG_INPUT_PCSPKR=m CONFIG_VIRTIO=m

After copying all the configuration options, run make localmodconfig again to make sure that you don't have any output starting with "module". After all of these machine specific modules there are a couple more left that are also needed. CONFIG_MODULES is necessary so that you can build and load modules separately and not have everything built into the kernel. CONFIG_BLK_DEV_SD is required for reading from hard drives. It is possible that there are other modules which you will need.

This post does not aim to be a guide to configuring your own kernel however, so if you do decide to build a custom kernel you'll have to seek out other guides to create a kernel which is just right for your needs.

The second way to setup the kernel configuration makes more use of Guix's features and allows you to share configuration segments between different kernels. For example, all machines using EFI to boot have a number of EFI configuration flags that they need. It is likely that all the kernels will share a list of filesystems to support. By using variables it is easier to see at a glance what features are enabled and to make sure you don't have features in one kernel but missing in another.

Left undiscussed however, is Guix's initrd and its customization. It is likely that you'll need to modify the initrd on a machine using a custom kernel, since certain modules which are expected to be built may not be available for inclusion into the initrd.

Suggestions and contributions toward working toward a satisfactory custom initrd and kernel are welcome!

About GNU Guix

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

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

FSF Events: Richard Stallman - "Copyright vs Community in the age of computer networks" (Nicosia, Cyprus)

Tuesday 21st of May 2019 09:53:33 AM

Richard Stallman will be speaking at the Unconference (2019-05-30–06-01).

Copyright developed in the age of the printing press, and was designed to fit with the system of centralized copying imposed by the printing press. But the copyright system does not fit well with computer networks, and only draconian punishments can enforce it. The global corporations that profit from copyright are lobbying for draconian punishments, and to increase their copyright powers, while suppressing public access to technology. But if we seriously hope to serve the only legitimate purpose of copyright–to promote progress, for the benefit of the public–then we must make changes in the other direction.

This speech will be nontechnical, admission is gratis, and the public is encouraged to attend.

Location: University of Nicosia, Cyprus

Please fill out our contact form, so that we can contact you about future events in and around Nicosia.

GNU Guix: GNU Guix 1.0.1 released

Sunday 19th of May 2019 09:30:00 PM

We are pleased to announce the release of GNU Guix version 1.0.1. This new version fixes bugs in the graphical installer for the standalone Guix System.

The release comes with ISO-9660 installation images, a virtual machine image, and with tarballs to install the package manager on top of your GNU/Linux distro, either from source or from binaries. Guix users can update by running guix pull.

It’s been just over two weeks since we announced 1.0.0—two weeks and 706 commits by 40 people already!

This is primarily a bug-fix release, specifically focusing on issues in the graphical installer for the standalone system:

  • The most embarrassing bug would lead the graphical installer to produce a configuration where %base-packages was omitted from the packages field. Consequently, the freshly installed system would not have the usual commands in $PATH—ls, ps, etc.—and Xfce would fail to start for that reason. See below for a “post-mortem” analysis.
  • The wpa-supplicant service would sometimes fail to start in the installation image, thereby breaking network access; this is now fixed.
  • The installer now allows you to toggle the visibility of passwords and passphrases, and it no longer restricts their length.
  • The installer can now create Btrfs file systems.
  • network-manager-applet is now part of %desktop-services, and thus readily usable not just from GNOME but also from Xfce.
  • The NEWS file has more details, but there were also minor bug fixes for guix environment, guix search, and guix refresh.

A couple of new features were reviewed in time to make it into 1.0.1:

  • guix system docker-image now produces an OS image with an “entry point”, which makes it easier to use than before.
  • guix system container has a new --network option, allowing the container to share networking access with the host.
  • 70 new packages were added and 483 packages were updated.
  • Translations were updated as usual and we are glad to announce a 20%-complete Russian translation of the manual.
Recap of bug #35541

The 1.0.1 release was primarily motivated by bug #35541, which was reported shortly after the 1.0.0 release. If you installed Guix System with the graphical installer, chances are that, because of this bug, you ended up with a system where all the usual GNU/Linux commands—ls, grep, ps, etc.—were not in $PATH. That in turn would also prevent Xfce from starting, if you chose that desktop environment for your system.

We quickly published a note in the system installation instructions explaining how to work around the issue:

  • First, install packages that provide those commands, along with the text editor of your choice (for example, emacs or vim):

    guix install coreutils findutils grep procps sed emacs vim
  • At this point, the essential commands you would expect are available. Open your configuration file with your editor of choice, for example emacs, running as root:

    sudo emacs /etc/config.scm
  • Change the packages field to add the “base packages” to the list of globally-installed packages, such that your configuration looks like this:

    (operating-system ;; … snip … (packages (append (list (specification->package "nss-certs")) %base-packages)) ;; … snip … )
  • Reconfigure the system so that your new configuration is in effect:

    guix pull && sudo guix system reconfigure /etc/config.scm

If you already installed 1.0.0, you can perform the steps above to get all these core commands back.

Guix is purely declarative: if you give it an operating system definition where the “base packages” are not available system-wide, then it goes ahead and installs precisely that. That’s exactly what happened with this bug: the installer generated such a configuration and passed it to guix system init as part of the installation process.

Lessons learned

Technically, this is a “trivial” bug: it’s fixed by adding one line to your operating system configuration and reconfiguring, and the fix for the installer itself is also a one-liner. Nevertheless, it’s obviously a serious bug for the impression it gives—this is not the user experience we want to offer. So how did such a serious bug go through unnoticed?

For several years now, Guix has had a number of automated system tests running in virtual machines (VMs). These tests primarily ensure that system services work as expected, but some of them specifically test system installation: installing to a RAID or encrypted device, with a separate /home, using Btrfs, etc. These tests even run on our continuous integration service (search for the “tests.*” jobs there).

Unfortunately, those installation tests target the so-called “manual” installation process, which is scriptable. They do not test the installer’s graphical user interface. Consequently, testing the user interface (UI) itself was a manual process. Our attention was, presumably, focusing more on UI aspects since—so we thought—the actual installation tests were already taken care of by the system tests. That the generated system configuration could be syntactically correct but definitely wrong from a usability viewpoint perhaps didn’t occur to us. The end result is that the issue went unnoticed.

The lesson here is that: manual testing should also look for issues in “unexpected places”, and more importantly, we need automated tests for the graphical UI. The Debian and Guix installer UIs are similar—both using the Newt toolkit. Debian tests its installer using “pre-seeds” (code), which are essentially answers to all the questions and choices the UI would present. We could adopt a similar approach, or we could test the UI itself at a lower level—reading the screen, and simulating key strokes. UI testing is notoriously tricky so we’ll have to figure out how to get there.

Conclusion

Our 1.0 party was a bit spoiled by this bug, and we are sorry that installation was disappointing to those of you who tried 1.0. We hope 1.0.1 will allow you to try and see what declarative and programmable system configuration management is like, because that’s where the real value of Guix System is—the graphical installer is icing on the cake.

Join us on #guix and on the mailing lists!

About GNU Guix

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

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

bison @ Savannah: Bison 3.4 released [stable]

Sunday 19th of May 2019 10:01:36 AM

We are happy to announce the release of Bison 3.4.

A particular focus was put on improving the diagnostics, which are now
colored by default, and accurate with multibyte input. Their format was
also changed, and is now similar to GCC 9's diagnostics.

Users of the default backend (yacc.c) can use the new %define variable
api.header.include to avoid duplicating the content of the generated header
in the generated parser. There are two new examples installed, including a
reentrant calculator which supports recursive calls to the parser and
Flex-generated scanner.

See below for more details.

==================================================================

Bison is a general-purpose parser generator that converts an annotated
context-free grammar into a deterministic LR or generalized LR (GLR) parser
employing LALR(1) parser tables. Bison can also generate IELR(1) or
canonical LR(1) parser tables. Once you are proficient with Bison, you can
use it to develop a wide range of language parsers, from those used in
simple desk calculators to complex programming languages.

Bison is upward compatible with Yacc: all properly-written Yacc grammars
work with Bison with no change. Anyone familiar with Yacc should be able to
use Bison with little trouble. You need to be fluent in C, C++ or Java
programming in order to use Bison.

Here is the GNU Bison home page:
https://gnu.org/software/bison/

==================================================================

Here are the compressed sources:
https://ftp.gnu.org/gnu/bison/bison-3.4.tar.gz (4.1MB)
https://ftp.gnu.org/gnu/bison/bison-3.4.tar.xz (3.1MB)

Here are the GPG detached signatures[*]:
https://ftp.gnu.org/gnu/bison/bison-3.4.tar.gz.sig
https://ftp.gnu.org/gnu/bison/bison-3.4.tar.xz.sig

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

[*] 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 bison-3.4.tar.gz.sig

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

gpg --keyserver keys.gnupg.net --recv-keys 0DDCAA3278D5264E

and rerun the 'gpg --verify' command.

This release was bootstrapped with the following tools:
Autoconf 2.69
Automake 1.16.1
Flex 2.6.4
Gettext 0.19.8.1
Gnulib v0.1-2563-gd654989d8

==================================================================

NEWS

* Noteworthy changes in release 3.4 (2019-05-19) [stable] ** Deprecated features The %pure-parser directive is deprecated in favor of '%define api.pure' since Bison 2.3b (2008-05-27), but no warning was issued; there is one now. Note that since Bison 2.7 you are strongly encouraged to use '%define api.pure full' instead of '%define api.pure'. ** New features *** Colored diagnostics As an experimental feature, diagnostics are now colored, controlled by the new options --color and --style. To use them, install the libtextstyle library before configuring Bison. It is available from https://alpha.gnu.org/gnu/gettext/ for instance https://alpha.gnu.org/gnu/gettext/libtextstyle-0.8.tar.gz The option --color supports the following arguments: - always, yes: Enable colors. - never, no: Disable colors. - auto, tty (default): Enable colors if the output device is a tty. To customize the styles, create a CSS file similar to /* bison-bw.css */ .warning { } .error { font-weight: 800; text-decoration: underline; } .note { } then invoke bison with --style=bison-bw.css, or set the BISON_STYLE environment variable to "bison-bw.css". *** Disabling output When given -fsyntax-only, the diagnostics are reported, but no output is generated. The name of this option is somewhat misleading as bison does more than just checking the syntax: every stage is run (including checking for conflicts for instance), except the generation of the output files. *** Include the generated header (yacc.c) Before, when --defines is used, bison generated a header, and pasted an exact copy of it into the generated parser implementation file. If the header name is not "y.tab.h", it is now #included instead of being duplicated. To use an '#include' even if the header name is "y.tab.h" (which is what happens with --yacc, or when using the Autotools' ylwrap), define api.header.include to the exact argument to pass to #include. For instance: %define api.header.include {"parse.h"} or %define api.header.include {<parser/parse.h>} *** api.location.type is now supported in C (yacc.c, glr.c) The %define variable api.location.type defines the name of the type to use for locations. When defined, Bison no longer defines YYLTYPE. This can be used in programs with several parsers to factor their definition of locations: let one of them generate them, and the others just use them. ** Changes *** Graphviz output In conformance with the recommendations of the Graphviz team, if %require "3.4" (or better) is specified, the option --graph generates a *.gv file by default, instead of *.dot. *** Diagnostics overhaul Column numbers were wrong with multibyte characters, which would also result in skewed diagnostics with carets. Beside, because we were indenting the quoted source with a single space, lines with tab characters were incorrectly underlined. To address these issues, and to be clearer, Bison now issues diagnostics as GCC9 does. For instance it used to display (there's a tab before the opening brace): foo.y:3.37-38: error: $2 of ‘expr’ has no declared type expr: expr '+' "number" { $$ = $1 + $2; } ^~ It now reports foo.y:3.37-38: error: $2 of ‘expr’ has no declared type 3 | expr: expr '+' "number" { $$ = $1 + $2; } | ^~ Other constructs now also have better locations, resulting in more precise diagnostics. *** Fix-it hints for %empty Running Bison with -Wempty-rules and --update will remove incorrect %empty annotations, and add the missing ones. *** Generated reports The format of the reports (parse.output) was improved for readability. *** Better support for --no-line. When --no-line is used, the generated files are now cleaner: no lines are generated instead of empty lines. Together with using api.header.include, that should help people saving the generated files into version control systems get smaller diffs. ** Documentation A new example in C shows an simple infix calculator with a hand-written scanner (examples/c/calc). A new example in C shows a reentrant parser (capable of recursive calls) built with Flex and Bison (examples/c/reccalc). There is a new section about the history of Yaccs and Bison. ** Bug fixes A few obscure bugs were fixed, including the second oldest (known) bug in Bison: it was there when Bison was entered in the RCS version control system, in December 1987. See the NEWS of Bison 3.3 for the previous oldest bug.

FSF News: Six more devices from ThinkPenguin, Inc. now FSF-certified to Respect Your Freedom

Thursday 16th of May 2019 05:44:36 PM

This is ThinkPenguin's second batch of devices to receive RYF certification this spring. The FSF announced certification of seven other devices from ThinkPenguin on March 21st. This latest collection of devices makes ThinkPenguin the retailer with the largest catalog of RYF-certified devices.

"It's unfortunate that so many of even the simplest devices out there have surprise proprietary software requirements. RYF is an antidote for that. It connects ethical shoppers concerned about their freedom with companies offering options respecting that freedom," said the FSF's executive director, John Sullivan.

Today's certifications expands the availability of RYF-certified peripheral devices. The Penguin USB 2.0 External USB Stereo Sound Adapter and the 5.1 Channels 24-bit 96KHz PCI Express Audio Sound Card help users get the most of their computers in terms of sound quality. For wireless connectivity, ThinkPenguin offers the Wireless N PCI Express Dual-Band Mini Half-Height Card and Penguin Wireless N Mini PCIe Card. For users with an older printer, the USB to Parallel Printer Cable can let them continue to use it with their more current hardware. Finally, the PCIe eSATA / SATA 6Gbps Controller Card help users to connect to external eSATA devices as well as internal SATA.

"I've spent the last 14 years working on projects aimed at making free software adoption easy for everyone, but the single greatest obstacle over the past 20 years has not been software. It's been hardware. The RYF program helps solve this problem by linking users to trustworthy sources where they can get hardware guaranteed to work on GNU/Linux, and be properly supported using free software," said Christopher Waid, founder and CEO of ThinkPenguin.

While ThinkPenguin has consistently sought certification since the inception of the RYF program -- gaining their first certification in 2013, and adding several more over the years since -- the pace at which they are gaining certifications now eclipses all past efforts.

"ThinkPenguin continues to impress with the rapid expansion of their catalog of RYF-certified devices. Adding 14 new devices in a little over a month shows their dedication to the RYF certification program and the protection of users it represents," said the FSF's licensing and compliance manager, Donald Robertson, III.

To learn more about the Respects Your Freedom certification program, including details on the certification of these ThinkPenguin devices, please visit https://fsf.org/ryf.

Retailers interested in applying for certification can consult https://www.fsf.org/resources/hw/endorsement/criteria.

About the Free Software Foundation

The Free Software Foundation, founded in 1985, is dedicated to promoting computer users' right to use, study, copy, modify, and redistribute computer programs. The FSF promotes the development and use of free (as in freedom) software -- particularly the GNU operating system and its GNU/Linux variants -- and free documentation for free software. The FSF also helps to spread awareness of the ethical and political issues of freedom in the use of software, and its Web sites, located at https://fsf.org and https://gnu.org, are an important source of information about GNU/Linux. Donations to support the FSF's work can be made at https://donate.fsf.org. Its headquarters are in Boston, MA, USA.

More information about the FSF, as well as important information for journalists and publishers, is at https://www.fsf.org/press.

About ThinkPenguin, Inc.

Started by Christopher Waid, founder and CEO, ThinkPenguin, Inc., is a consumer-driven company with a mission to bring free software to the masses. At the core of the company is a catalog of computers and accessories with broad support for GNU/Linux. The company provides technical support for end-users and works with the community, distributions, and upstream projects to make GNU/Linux all that it can be.

Media Contacts

Donald Robertson, III
Licensing and Compliance Manager
Free Software Foundation
+1 (617) 542 5942
licensing@fsf.org

ThinkPenguin, Inc.
+1 (888) 39 THINK (84465) x703
media@thinkpenguin.com

FSF Blogs: LibrePlanet 2019 videos now live!

Monday 13th of May 2019 08:35:00 PM

At the LibrePlanet 2019 conference, the Free Software Foundation (FSF) recorded 40 speaker sessions -- over 24 hours of video, and they are now online on our GNU MediaGoblin instance.

The FSF team put their heads together and selected a few of our favorites from the entire 2019 Libreplanet program for you to start with -- brought to you in a Digital Restrictions Management (DRM)-free, downloadable, free format.

  • In their talk, entitled "Sharing global opportunities for new developers in the Wikipedia community," Srishti Sethi gave us some valuable insights into how you can get involved in the Wikipedia community.

  • Amanda Sopkin's talk, "The secret battle of encryption algorithms," delved into the history of encryption, with lots of fun factoids about how encryption methods were invented, used and foiled.

  • Martha Esperilla and StefanĂ­a Acevedo joined us from Hackerspace Rancho ElectrĂłnico, sharing their work in building community around their work, including CoAA TV, an online audiovisual archive.

  • In "GPL enforcement and customer benefits: Evidence from OpenWRT," Do Yoon Kim explained to us how his research shows that free software wireless routers are valued higher and sell better.

  • Mary Kate Fain asked us "What free software can learn from successful social movements," and answered this question by sharing experiences as a grassroots organizer and as a free software activist.

  • Free Software Award winners OpenStreetMap and Deb Nicholson both shared their work talking about "OpenStreetMap" mapping developments, and the free software community challenges we face in "Free software/utopia," respectively.

These are just a few of the interesting and varied subjects discussed at the LibrePlanet 2019 conference. Please have a look at the entire collection of 2019 videos and photos for hours of viewing pleasure. And if you really can't get enough, you can scroll down to the archives, where you can revisit the 2018 videos and photos, and much more.

All the LibrePlanet 2019 videos were created using free software, with high resolution USB Web cameras and USB audio mixing desks, whose drivers are supported by Trisquel. We want to thank everyone who participated in LibrePlanet 2019, plus our sponsor, Red Hat, and you too, for your continued support of free software, the FSF, and LibrePlanet.

We look forward to welcoming you again in 2020!

GNUnet News: 2019-05-12: GNUnet 0.11.4 released

Sunday 12th of May 2019 03:53:25 PM
2019-05-12: GNUnet 0.11.4 released

We are pleased to announce the release of GNUnet 0.11.4.

This is a bugfix release for 0.11.3, mostly fixing minor bugs, improving documentation and fixing various build issues. In terms of usability, users should be aware that there are still a large 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 (about 200 peers) and thus unlikely to provide good anonymity or extensive amounts of interesting information. As a result, the 0.11.4 release is still only suitable for early adopters with some reasonable pain tolerance.

Download links

(gnunet-gtk and gnunet-fuse were not released again, as there were no changes and the 0.11.0 versions are expected to continue to work fine with gnunet-0.11.4.)

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/

Note that GNUnet is now started using gnunet-arm -s. GNUnet should be stopped using gnunet-arm -e.

Noteworthy changes in 0.11.4
  • gnunet-arm -s no longer logs into the console by default and instead into a logfile (in $GNUNET_HOME).
  • The reclaim subsystem is no longer experimental. Further, the internal encryption scheme moved from ABE to GNS-style encryption.
  • GNUnet now depends on a more recent version of libmicrohttpd.
  • The REST API now includes read-only access to the configuration.
  • All manpages are now in mdoc format.
  • gnunet-download-manager.scm removed.
Known Issues
  • There are known major design issues in the TRANSPORT, ATS and 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. Also CADET may unexpectedly deliver messages out-of-order.
  • 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.
  • Some high-level tests in the test-suite fail non-deterministically due to the low-level TRANSPORT issues.

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: ng0, Christian Grothoff, Hartmut Goebel, Martin Schanzenbach, Devan Carpenter, Naomi Phillips and Julius Bünger.

unifont @ Savannah: Unifont 12.1.01 Released

Saturday 11th of May 2019 08:59:48 PM

11 May 2019 Unifont 12.1.01 is now available. Significant changes in this version include the Reiwa Japanese era glyph (U+32FF), which was the only addition made in the Unicode 12.1.0 release of 7 May 2019; Rebecca Bettencourt has contributed many Under ConScript Uniocde Registry (UCSUR) scripts; and David Corbett and Johnnie Weaver modified glyphs in two Plane 1 scripts. Full details are in the ChangeLog file.

Download this release at:

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

or if that fails,

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

or, as a last resort,

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

FSF Blogs: GNU Guix 1.0.0 released

Friday 10th of May 2019 02:40:12 PM

On May 2, the GNU Guix project announced the release of version 1.0 of the Guix software manager. Since the project’s beginnings a little more than seven years ago, nearly 300 volunteers from all over the world have contributed more than 50,000 improvements. Guix now provides a huge collection of bit-reproducible free software packages consisting of close to 10,000 applications and libraries from a wide range of categories, including gaming, music production, video editing, programming, and specialized scientific software.

What distinguishes Guix from other free software distributions is that it is designed with reproducibility in mind. It builds packages in controlled environments to ensure that the results are bit for bit the same no matter when or where packages are built. This means that users can easily deploy the very same software environment or even the very same operating system, at different points in time or on different machines. Reproducibility provides strong assurances that are of fundamental value for security, for the use of software in computational science, and for user freedom.

While Guix offers package management features such as transactional upgrades, safe roll-backs, and per-user profiles, package management is just one special case of its general facilities for reproducible, declarative software environment management. Guix bends the notion of a traditional package manager by extending these features to building systems: lightweight containers, Docker images, virtual machine images or bare-metal operating systems -- Guix specifies a flexible, programmable configuration framework for reproducible software deployment at every level. With Guix’s simple, well-documented extension to the general purpose language Scheme, users and developers alike can easily declare custom packages and package variants, compose and inspect arbitrarily complex software environments, and generate full operating systems with minimal effort -- Guix is designed to be hackable!

Whether you’re a software developer, a user, or a free software enthusiast, we hope GNU Guix will provide you with the tools to deploy and manage software with confidence and ease, qualities that are not usually associated with software deployment. The Guix community would love to hear from you!

The FSF supports the work of GNU Guix through its Working Together for Free Software fund. Make a contribution here!

gettext @ Savannah: GNU gettext 0.20 released

Thursday 9th of May 2019 02:15:21 AM

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

New in this release:

  • Support for reproducible builds:

- msgfmt now eliminates the POT-Creation-Date header field from .mo files.

  • Improvements for translators:

- update-po target in Makefile.in.in now uses msgmerge --previous.

  • Improvements for maintainers:

- msgmerge now has an option --for-msgfmt, that produces a PO file meant for use by msgfmt only. This option saves processing time, in particular by omitting fuzzy matching that is not useful in this situation.
- The .pot file in a 'po' directory is now erased by "make maintainer-clean".
- It is now possible to override xgettext options from the po/Makefile.in.in through options in XGETTEXT_OPTIONS (declared in po/Makevars).
- The --intl option of the gettextize program (deprecated since 2010) is no longer available. Instead of including the intl sources in your package, we suggest making the libintl library an optional prerequisite of your package. This will simplify the build system of your package.
- Accordingly, the Autoconf macro AM_GNU_GETTEXT_INTL_SUBDIR is gone as well.

  • Programming languages support:

- C, C++:
xgettext now supports strings in u8"..." syntax, as specified in C11 and C++11.
- C, C++:
xgettext now supports 'p'/'P' exponent markers in number tokens, as specified in C99 and C++17.
- C++:
xgettext now supports underscores in number tokens.
- C++:
xgettext now supports single-quotes in number tokens, as specified in C++14.
- Shell:
o The programs 'gettext', 'ngettext' now support a --context argument.
o gettext.sh contains new function eval_pgettext and eval_npgettext for producing translations of messages with context.
- Java:
o xgettext now supports UTF-8 encoded .properties files (a new feature of Java 9).
o The build system and tools now support Java 9, 10, and 11. On the other hand, support for old versions of Java (Java 5 and older, GCJ 4.2.x and older) has been dropped.
- Perl:
o Native support for context functions (pgettext, dpgettext, dcpgettext, npgettext, dnpgettext, dcnpgettext).
o better detection of question mark and slash as operators (as opposed to regular expression delimiters).
- Scheme:
xgettext now parses the syntax for specialized byte vectors (#u8(...), #vu8(...), etc.) correctly.
- Pascal:
xgettext can now extract strings from .rsj files, produced by the Free Pascal compiler version 3.0.0 or newer.
- Vala:
xgettext now parses escape sequences in strings more accurately.
- JavaScript:
xgettext now parses template literals correctly.

  • Runtime behaviour:

- The interpretation of the language preferences on macOS has been fixed.
- Per-thread locales are now also supported on Solaris 11.4.
- The replacements for the printf()/fprintf()/... functions that are provided through <libintl.h> on native Windows and NetBSD are now POSIX compliant. There is no conflict any more between these replacements and other possible replacements provided by gnulib or mingw.

  • Libtextstyle:

- This package installs a new library 'libtextstyle', together with a new header file <textstyle.h>. It is a library for styling text output sent to a console or terminal emulator. Packagers: please see the suggested packaging hints in the file PACKAGING.

cssc @ Savannah: CSSC-1.4.1 released

Tuesday 7th of May 2019 08:27:17 PM
I'm pleased to announce the release of GNU CSSC, version 1.4.1. This is a stable release. The previous stable release was 1.4.0. Stable releases of CSSC are available from https://ftp.gnu.org/gnu/cssc/. Development releases and release candidates are available from https://alpha.gnu.org/gnu/cssc/. CSSC ("Compatibly Stupid Source Control") is the GNU project's replacement for the traditional Unix SCCS suite. It aims for full compatibility, including precise nuances of behaviour, support for all command-line options, and in most cases bug-for-bug compatibility. CSSC comes with an extensive automated test suite. If you are currently using SCCS to do version control of software, you should be able to just drop in CSSC, even for example if you have a large number of shell scripts which are layered on top of SCCS and depend on it. This should allow you to develop on and for the GNU/Linux platform if your source code exists only in an SCCS repository. CSSC also allows you to migrate to a more modern version control system (such as git). There is a mailing list for users of the CSSC suite. To join it, please send email to <cssc-users-request@gnu.org> or visit the URL http://lists.gnu.org/mailman/listinfo/cssc-users. There is also a mailing list for (usually automated) mails about bugs and changes to CSSC. This is http://lists.gnu.org/mailman/listinfo/bug-cssc. For more information about CSSC, please see http://www.gnu.org/software/cssc/. These people have contributed to the development of CSSC :- James Youngman, Ross Ridge, Eric Allman, Lars Hecking, Larry McVoy, Dave Bodenstab, Malcolm Boff, Richard Polton, Fila Kolodny, Peter Kjellerstedt, John Interrante, Marko Rauhamaa, Achim Hoffann, Dick Streefland, Greg A. Woods, Aron Griffis, Michael Sterrett, William W. Austin, Hyman Rosen, Mark Reynolds, Sergey Ostashenko, Frank van Maarseveen, Jeff Sheinberg, Thomas Duffy, Yann Dirson, Martin Wilck Many thanks to all the above people. Changes since the previous release stable are: New in CSSC-1.4.1, 2019-05-07 * This release - and future releases - of CSSC must be compiled with a C++ compiler that supports the 2011 C++ standard. * When the history file is updated (with admin or delta for example) the history file is not made executable simply because the 'x' flag is set. Instead, preserve the executable-ness from the history file we are replacing. * This release is based on updated versions of gnulib and of the googletest unit test framework. Checksums for the release file are: $ for sum in sha1sum md5sum ; do $sum CSSC-1.4.1.tar.gz; done bfb99cbd6255c7035e99455de7241d4753746fe1 CSSC-1.4.1.tar.gz c9aaae7602e39b7a5d438b0cc48fcaa3 CSSC-1.4.1.tar.gz Please report any bugs via this software to the CSSC bug reporting page, http://savannah.gnu.org/bugs/?group=cssc

GNU Guix: GNU Guix 1.0.0 released

Thursday 2nd of May 2019 02:00:00 PM

We are excited to announce the release of GNU Guix version 1.0.0!

The release comes with ISO-9660 installation images, a virtual machine image, and with tarballs to install the package manager on top of your GNU/Linux distro, either from source or from binaries. Guix users can update by running guix pull.

One-point-oh always means a lot for free software releases. For Guix, 1.0 is the result of seven years of development, with code, packaging, and documentation contributions made by 260 people, translation work carried out by a dozen of people, and artwork and web site development by a couple of individuals, to name some of the activities that have been happening. During those years we published no less than 19 “0.x” releases.

The journey to 1.0

We took our time to get there, which is quite unusual in an era where free software moves so fast. Why did we take this much time? First, it takes time to build a community around a GNU/Linux distribution, and a distribution wouldn’t really exist without it. Second, we feel like we’re contributing an important piece to the GNU operating system, and that is surely intimidating and humbling.

Last, we’ve been building something new. Of course we stand on the shoulders of giants, and in particular Nix, which brought the functional software deployment paradigm that Guix implements. But developing Guix has been—and still is!—a challenge in many ways: it’s a programming language design challenge, an operating system design challenge, a challenge for security, reproducibility, bootstrapping, usability, and more. In other words, it’s been a long but insightful journey! :-)

What GNU Guix can do for you

Presumably some of the readers are discovering Guix today, so let’s recap what Guix can do for you as a user. Guix is a complete toolbox for software deployment in general, which makes it different from most of the tools you may be familiar with.

This may sound a little abstract so let’s look at concrete use cases:

  • As a user, Guix allows you to install applications and to keep them up-to-date: search for software with guix search, install it with guix install, and maintain it up-to-date by regularly running guix pull and guix upgrade. Guix follows a so-called “rolling release” model, so you can run guix pull at any time to get the latest and greatest bits of free software.

    This certainly sounds familiar, but a distinguishing property here is dependability: Guix is transactional, meaning that you can at any time roll back to a previous “generation” of your package set with guix package --roll-back, inspect differences with guix package -l, and so on.

    Another useful property is reproducibility: Guix allows you to deploy the exact same software environment on different machines or at different points in time thanks to guix describe and guix pull.

    This, coupled with the fact that package management operations do not require root access, is invaluable notably in the context of high-performance computing (HPC) and reproducible science, which the Guix-HPC effort has been focusing on.

  • As a developer, we hope you’ll enjoy guix environment, which allows you to spawn one-off software environments. Suppose you’re a GIMP developer: running guix environment gimp spawns a shell with everything you need to hack on GIMP—much quicker than manually installing its many dependencies.

    Developers often struggle to push their work to users so they get quick feedback. The guix pack provides an easy way to create container images for use by Docker & co., or even standalone relocatable tarballs that anyone can run, regardless of the GNU/Linux distribution they use.

    Oh, and you may also like package transformation options, which allow you define package variants from the command line.

  • As a system administrator—and actually, we’re all system administrators of sorts on our laptops!—, Guix’s declarative and unified approach to configuration management should be handy. It surely is a departure from what most people are used to, but it is so reassuring: one configuration file is enough to specify all the aspects of the system config—services, file systems, locale, accounts—all in the same language.

    That makes it surprisingly easy to deploy otherwise complex services such as applications that depend on Web services. For instance, setting up CGit or Zabbix is a one-liner, even though behind the scenes that involves setting up nginx, fcgiwrap, etc. We’d love to see to what extent this helps people self-host services—sort of similar to what FreedomBox and YunoHost have been focusing on.

    With guix system you can instantiate a configuration on your machine, or in a virtual machine (VM) where you can test it, or in a container. You can also provision ISO images, VM images, or container images with a complete OS, from the same config, all with guix system.

The quick reference card shows the important commands. As you start diving deeper into Guix, you’ll discover that many aspects of the system are exposed using consistent Guile programming interfaces: package definitions, system services, the “init” system, and a whole bunch of system-level libraries. We believe that makes the system very hackable, and we hope you’ll find it as much fun to play with as we do.

So much for the overview!

What’s new since 0.16.0

For those who’ve been following along, a great many things have changed over the last 5 months since the 0.16.0 release—99 people contributed over 5,700 commits during that time! Here are the highlights:

  • The ISO installation image now runs a cute text-mode graphical installer—big thanks to Mathieu Othacehe for writing it and to everyone who tested it and improved it! It is similar in spirit to the Debian installer. Whether you’re a die-hard GNU/Linux hacker or a novice user, you’ll certainly find that this makes system installation much less tedious than it was! The installer is fully translated to French, German, and Spanish.
  • The new VM image better matches user expectations: whether you want to tinker with Guix System and see what it’s like, or whether you want to use it as a development environment, this VM image should be more directly useful.
  • The user interface was improved: aliases for common operations such as guix search and guix install are now available, diagnostics are now colorized, more operations show a progress bar, there’s a new --verbosity option recognized by all commands, and most commands are now “quiet” by default.
  • There’s a new --with-git-url package transformation option, that goes with --with-branch and --with-commit.
  • Guix now has a first-class, uniform mechanism to configure keyboard layout—a long overdue addition. Related to that, Xorg configuration has been streamlined with the new xorg-configuration record.
  • We introduced guix pack -R a while back: it creates tarballs containing relocatable application bundles that rely on user namespaces. Starting from 1.0, guix pack -RR (like “reliably relocatable”?) generates relocatable binaries that fall back to PRoot on systems where user namespaces are not supported.
  • More than 1,100 packages were added, leading to close to 10,000 packages, 2,104 packages were updated, and several system services were contributed.
  • The manual has been fully translated to French, the German and Spanish translations are nearing completion, and work has begun on a Simplified Chinese translation. You can help translate the manual into your language by joining the Translation Project.

That’s a long list already, but you can find more details in the NEWS file.

What’s next?

One-point-oh is a major milestone, especially for those of us who’ve been on board for several years. But with the wealth of ideas we’ve been collecting, it’s definitely not the end of the road!

If you’re interested in “devops” and distributed deployment, you will certainly be happy to help in that area, those interested in OS development might want to make the Shepherd more flexible and snappy, furthering integration with Software Heritage will probably be #1 on the to-do list of scientists concerned with long-term reproducibility, programming language tinkerers may want to push G-expressions further, etc. Guix 1.0 is a tool that’s both serviceable for one’s day-to-day computer usage and a great playground for the tinkerers among us.

Whether you want to help on design, coding, maintenance, system administration, translation, testing, artwork, web services, funding, organizing a Guix install party… your contributions are welcome!

We’re humans—don’t hesitate to get in touch with us, and enjoy Guix 1.0!

About GNU Guix

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

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

FSF Blogs: GNU Spotlight with Mike Gerwitz: 15 new GNU releases in April!

Friday 26th of April 2019 04:53:42 PM

For announcements of most new GNU releases, subscribe to the info-gnu mailing list: https://lists.gnu.org/mailman/listinfo/info-gnu.

To download: nearly all GNU software is available from https://ftp.gnu.org/gnu/, or preferably one of its mirrors from https://www.gnu.org/prep/ftp.html. You can use the URL https://ftpmirror.gnu.org/ to be automatically redirected to a (hopefully) nearby and up-to-date mirror.

This month, we welcome Tom Tromey as comaintainer of src-hilight and Abhilash Raj as comaintainer of mailman.

A number of GNU packages, as well as the GNU operating system as a whole, are looking for maintainers and other assistance: please see https://www.gnu.org/server/takeaction.html#unmaint if you'd like to help. The general page on how to help GNU is at https://www.gnu.org/help/help.html.

If you have a working or partly working program that you'd like to offer to the GNU project as a GNU package, see https://www.gnu.org/help/evaluation.html.

As always, please feel free to write to us at maintainers@gnu.org with any GNUish questions or suggestions for future installments.

More in Tux Machines

Linux 5.2-rc2

Hey, what's to say? Fairly normal rc2, no real highlights - I think most of the diff is the SPDX updates. Who am I kidding? The highlight of the week was clearly Finland winning the ice hockey world championships. So once you sober up from the celebration, go test, Linus Read more Also: Linux 5.2-rc2 Kernel Released As The "Golden Lions"

Audiocasts/Shows: Linux Action News, Linux Gaming News Punch, Open Source Security Podcast and GNU World Order

Review: Red Hat Enterprise Linux 8.0

My experiment with RHEL 8 got off to a rough start. Going through the on-line registration process produced some errors and ended up with me getting the wrong ISO which, in turn, resulted in some confusion and delays in getting the distribution installed. Things then began to look up as RHEL 8 did a good job of detecting my system's hardware, registered itself without incident and offered good performance on physical hardware. I was particularly pleased that the distribution appears to detect whether our video card will work well with Wayland and either displays or hides Wayland sessions in response. I did have some trouble with the GNOME Classic Wayland session and GNOME Shell on X.Org was a bit sluggish. However, the Classic session on X.Org and GNOME Shell on Wayland both worked very well. In short, it's worthwhile to explore each of the four desktop options to see what works best for the individual. The big issues I ran into with RHEL were with regards to software management. Both GNOME Software and the Cockpit screen for managing applications failed to work at all, whether run as root or a regular user. When using the command line dnf package manager, the utility failed to perform searches unless run with sudo and occasionally crashed. In a similar vein, the Bash feature that checks for matching packages when the user types a command name it doesn't recognize does not work and produces a lengthy error. There were some security features or design choices that I think will mostly appeal to enterprise users, but are less favourable in home or small office environments. Allowing remote root logins by default on the Workstation role rubs me the wrong way, though I realize it is often useful when setting up servers. The enforced complex passwords are similarly better suited to offices than home users. One feature which I think most people will enjoy is SELinux which offers an extra layer of security, thought I wish the Cockpit feature to toggle SELinux had worked to make trouble-shooting easier. I was not surprised that RHEL avoids shipping some media codecs. The company has always been cautious in this regard. I had hoped that trying to find and install the codecs would have provided links to purchase the add-ons or connect us with a Red Hat-supplied repository. Instead we are redirected through a chain of Fedora documentation until we come to a third-party website which currently does not offer the desired packages. Ultimately, while RHEL does some things well, such as hardware support, desktop performance, and providing stable (if conservative) versions of applications, I found my trial highly frustrating. Many features simply do not work, or crash, or use a lot of resources, or need to be worked around to make RHEL function as a workstation distribution. Some people may correctly point out RHEL is mostly targeting servers rather than workstations, but there too there are a number of problems. Performance and stability are provided, but the issues I ran into with Cockpit, permission concerns, and command line package management are all hurdles for me when trying to run RHEL in a server role. I find myself looking forward to the launch of CentOS 8 (which will probably arrive later this year), as CentOS 8 uses the same source code as RHEL, but is not tied to the same subscription model and package repositories. I am curious to see how much of a practical effect this has on the free, community version of the same software. Read more

GNOME 3.34 Revamps the Wallpaper Picker (And Fixes a Longstanding Issue Too)

The upcoming release of GNOME 3.34 will finally solve a long standing deficiency in the desktop’s background wallpaper management. Now, I’ve written about various quirks in GNOME wallpaper handling before, but it’s the lack of option to pick a random wallpaper from a random directory via the Settings > Background panel that is, by far, my biggest bug bear. Ubuntu 19.04 ships with GNOME 3.32. Here, the only wallpapers available to select via the Settings > Background section are those the system ships with and any top-level images placed in ~/Pictures — nothing else is selectable. So, to set a random image as a wallpaper in GNOME 3.32 I tend to ignore the background settings panel altogether and instead use the image viewer’s File > Set as background… option (or the similar Nautilus right-click setting). Thankfully, not for much longer! Read more