Planet GNU

Aggregation of development blogs from the GNU Project

December 10, 2019

FSF Blogs

Replicant needs your help to liberate Android in 2020

The Free Software Foundation (FSF) supports the work of several important free software projects through fiscal sponsorship in a program we call Working Together for Free Software.

Donations to any of the Working Together for Free Software projects directly benefit the work that can be done. Too often, these projects are underfunded and developers are putting in a lot of personal time and effort to keep the project moving forward. Because of the FSF fiscal sponsorship, they can receive donations and apply for funding.

Our annual fundraiser is happening right now. If you're able to, please consider making a donation to Replicant through their dedicated sponsorship page. Every dollar you contribute helps this inspiring project work towards a freer mobile future.

Associate members are at the heart of our foundation and strengthen our ability to help other free software projects like Replicant. Join today to help us reach our goal of welcoming 600 new associate members before December 31st. As a special bonus, all new and renewing annual associate members ($120+) can choose to receive one of our exclusive year-end gifts. If you get a minimum of three people to mention you as a referral, you can get them too!

Below is an update from developer Denis "GNUtoo" Carikli, who is one of three people on the "steering committee" of Replicant: a fully free Android distribution running on several devices. It is a free software mobile operating system putting the emphasis on freedom, privacy, and security.


Mobile devices such as phones and tablets are becoming an increasingly important part in our computing, hence they are particularly subject to freedom and security concerns. These devices aren't simply "phones" or "tablets." They are full computers with powerful hardware, running complete operating systems that allow for updates, software changes, and installable applications. This makes it feasible to run free software on them. Thus, it is possible to choose a device that runs a free bootloader and free mobile operating system -- Replicant -- as well as fully free apps for the user. You can read more about privacy and security on mobile phones and the solutions that Replicant offers, as well as learn some valuable lessons on how better to protect your freedom on mobile devices on the Replicant Web site.

Replicant is currently steered by a team of three people: Fil Bergamo, Joonas Kylmälä (Putti), and myself. At the beginning of this year, we successfully applied for funding from a program from the European Union called Next Generation Internet. We also received a sizeable donation from Handshake, which allowed us to make some significant investments.

The most notable changes we are working on are building a new version of Replicant based on Android 9, which will enable a wider range of users to use a fully free Android distribution for the first time. We are also reducing maintenance costs to increase sustainability. The Replicant project is now using the official linux kernel with very few patches, and we contribute patches upstream as well. This means we send our work back to the main developers of the kernel Linux so that everyone can benefit. This allows us to create a virtuous circle that makes Replicant benefit GNU/Linux and GNU/Linux development benefit from Replicant. Working with upstream would not be possible without funding, as it requires a lot more work than what we used to do with previous Replicant versions.

Getting people more acquainted with the work we do helps us source new contributors, as well as convince people to use Replicant. This year, we managed to travel to a few important conferences, as well as organize our own Replicant conference. A full report of the conference is available, along with slides, videos, and a summary of the discussions that took place. The conference allowed us to bring together the people who care about Replicant and who understand the importance of the work we do. Watching these presentations can help any new Replicant developers to contribute to the project, as they explain a lot about our architecture, our history, and how to begin making a version of Replicant for newer devices and Android versions.

Being awarded a large grant is a highly competitive process, which means we cannot rely on that for continuous funding to pay for all of our work, so we choose to spend money on tasks that have a long-term impact. For instance, this could include completing the library that communicates with the Samsung IPC modem protocol (libsamsung-ipc), which would enable other Android distributions to use it and share the changes they make with us. It could also help us to continue our work on free WiFi firmware. These investments will ensure that developers can continue to maintain Replicant even when larger donations are not available.


Projects like Replicant rely on individual donations like yours to continue their work independent of large donations and funding. They can always use your help, whether that help is financial, or provided in time and effort. To further assist them, you can use Replicant and become part of the project's community by using its forums, contributing to its wiki, and submitting any bugs you discover.

10 December, 2019 07:50PM

December 09, 2019

At SeaGL 2019, free software was in fine feather

While the satisfactions of software freedom are quite enjoyable on your own, some of the greatest joys of free software come from our opportunities to flock together with other members of our community: to collaborate on our work, teach new skills, or simply show off new achievements. A grassroots gathering like the Seattle GNU/Linux Conference (SeaGL) is fun because it’s so thoroughly participatory: everyone comes into the room with something they’re excited to tell you about, and they’re equally excited to hear what you’re working on. The people at the front of the room giving a keynote talk are just as likely to be sitting next to you in the next session, so you can tell them what you thought of their talk, and even find out how to participate in their projects!

As someone who is fairly new to the free software world and comparatively short on tech knowledge, I mostly attended talks on free software culture and more easily understood technological talks, although these were hardly the only topics on offer. Having unfortunately missed the opening keynotes by Lisha Sterling and Abigail Cabunoc Mayes due to some bad allergies, I began the day with a talk on DIY decentralization, by Aeva Black. Black set an irreverent tone for their talk with a reference to the notoriously goofy nineties movie Hackers, but quickly veered into much more serious territory: major digital communication platforms have exercised bias and even overt censorship against marginalized groups. How do we navigate around the power of Facebook, Twitter, Google, and the rest? Decentralization, federation, and self-hosting provide some good solutions, and a quick demonstration showed that if you have some basic know-how and tools, anyone can do it.

Next, I checked out Audrey Eschright’s talk called “Organizing your way to a long and healthy career.” Jumping off from the recent walkouts at companies including Facebook and Wayfair, as well as her own experiences trying to correct issues in past workplaces, Eschright laid out some of the basics of workplace organizing without a union. If nothing else, some of these strategies can be crucial for your sanity: as Eschright pointed out, just knowing “I’m not alone in what I want” can be a great relief.

My next talk was “Empowering new programmers through introductory Arduino workshops,” presented by Hailee Kennedy, a developer and co-organizer of the Django Girls PDX program, of Portland, Oregon. Kennedy has put a lot of time and thought into the best ways to introduce women and girls to programming in order to help diversify the computing world, and she spent a lot of the talk comparing various workshops she’s given in order to highlight best practices. The most important take-home message I got from this talk (and have continued to repeat to everyone since): actually learning a new skill takes practice, so nobody’s going to learn a skill they can immediately reuse from a one-day workshop. The goal of these courses, instead, is to pique the curiosity and confidence of the attendees – to give them an experience they’ll enjoy so that they’re eager to take on more programming projects on their own! So, an onerous experience that focuses on training and rote learning isn’t going to do the trick: instead, participants need a social, fun, and satisfying experience that they come out of having created something concrete, creating an itch to try more programming.

My final talk of the day was “Make it official: In praise of official programs for diversity and inclusion,” presented by 2018 Free Software Award winner Deb Nicholson. In this talk, Deb noted that a lot of the previous practices attempted by many companies to bump up diversity have failed simply because people don’t like them: trainings, for instance, can feel like a punishment. On the other hand, participants on both sides of mentoring programs like Outreachy absolutely love how these paid internships work – and they really do help interns get the tech jobs they’re aiming for! The FSF has hosted internships for several Outreachy participants so far, and I'm glad to hear that in our small way, we're helping to open doors.

I spent the rest of Friday at the FSF table in the exhibit hall, chatting with visitors and selling GNU Press gear, and then running our meetup at Herb & Bitter Public House, a few blocks away from the venue -- they completely merit the shout-out here, since they took wonderful care of us, and all of our guests seemed quite satisfied! We organize these informal meetups at most free software conferences that have staff attendees, to provide our supporters with opportunities to mingle, cross-pollinate their projects, and tell us how they feel about our current efforts. After all, our members and other supporters enable the FSF to exist, so we need to be available and accountable to you!

Day two of the conference started with keynotes by Benjamin Mako Hill (“How markets coopted free software’s most powerful weapon”) and Sage Sharp (“Countering impostor syndrome culture”). Mako’s talk began with data tracking the popularity of the Couchsurfing Web site versus Airbnb, and laid out a somewhat grim forecast for the future of free software: proprietary software companies borrowing techniques from commons-based peer production projects like free software are replacing, displacing, and outcompeting what's available in the commons. Mako delivered a similar talk at LibrePlanet 2018, which you can view on our MediaGoblin instance.

Sage Sharp’s keynote was particularly useful for me, as someone with limited technical know-how at a tech conference: their goal was to educate us all on how to avoid worsening everyone else’s impostor syndrome, since it’s likely that we’ve all got at least a little bit! My favorite take-home message from this talk: telling someone that their project, or their talk, or their artwork is “very good and you’re very talented” has a way of exacerbating people’s insecurities. You can avoid making them feel this way, however, by telling them, instead, how their work made you feel: as Sharp put it, “I can’t argue with your feelings.” Thus, when Sharp sat down next to me at the end of their talk, I told them, “I’m now going to use a skill you’ve just taught me: your talk made me feel very seen.”

My last stopoff before a long stint behind the FSF table was at Eva Monsen’s talk on “Learning natural language processing through the Regender Project.” This was one of those rare talks that had everyone in the room buzzing with excitement: the Regender Project is an open-ended experiment wherein Monsen is attempting to reverse (or neutralize) all gendered language in books that are available in the public domain, entirely through machine learning. You’d think this would be simple – just program your computer to change “he” to “she,” right? But at each stage of the project, Monsen found that she had to add more steps, and discovered more roadblocks, which she laid out as a fascinating narrative about how thoroughly gender is built into the English language (and, of course, many others). By the Q&A session at the end, hands were flying into the air with suggestions for other steps to try, and insights about gendered language, demonstrating the participatory and creative potential built into the world of free software, and how it opens so many possibilities to explore and reach a new understanding of personal and political realities.

After a few more hours selling T-shirts and talking free software at our table, I finished off the day with a talk that I knew would be too amusing to miss: “The Death Star Postmortem,” delivered by Gareth J. Greenaway. Every complicated project needs a postmortem, whether your project is a smashing success or a ludicrous failure like the fictional Death Star, which was destroyed not once but twice. Mostly maintaining a pretty impressive deadpan throughout, Greenaway started by explaining best practices for a postmortem on any project, with emphasis on how a properly done postmortem avoids placing blame, maintains team cohesion, and helps to avoid making the same errors twice. He then went into how Darth Vader, the Emperor, and the Galactic Empire proceeded to… make the same errors twice, and some new ones, besides. It was a very informative and entertaining finish to an excellent conference.

The FSF presence at SeaGL couldn't possible have done without the time, skills, generosity, and patience of our local volunteers, who did a masterful job setting up, running, and breaking down our table, selling GNU gear, and answering all the questions I couldn’t. I cannot possibly offer enough gratitude to Pean Lim, McCoy Smith, Jeff Silverman, and Mike (whose last name I didn't catch), all of whom were completely indispensable and deserve your applause. Along with countless other organizers, presenters, and free software supporters, they demonstrated to me that the power of our movement lies in our collective commitment to the cause, and our constant willingness to welcome and bring new people into the fold so that we can keep growing stronger every day. If everyone reading this is half as good as they were at making a relative newbie feel welcome, nothing can stop us in our mission to make all software free!

Finally: whether you live in the great Northwest or not, and whether you're inclined to attend grassroots free software conferences or not, you can help SeaGL keep soaring by donating to the FSF. SeaGL is one of the projects that's fiscally sponsored through our Working Together for Free Software Fund, so you can also contribute directly through their fiscal sponsorship page!

Photos by Dana Morgenstein Copyright © 2019 Free Software Foundation, Inc., licensed under CC-BY-SA 4.0.

09 December, 2019 05:34PM

December 08, 2019

www-zh-cn @ Savannah

The FSF tech team: Doing more for free software

Dear CTT translators:

At the Free Software Foundation, we like to set big goals for ourselves, and cover a lot of ground in a short time. The FSF tech team, for example, has just four members -- two senior systems administrators, one Web developer, and a part-time chief technology officer -- yet we manage to run over 120 virtual servers. These run on about a dozen machines hosted at four different data centers. These include many public-facing Web sites and community services, as well as every single IT requirement for the staff: workstations, data storage and backup, networking, printing, accounting, telephony, email, you name it.

We don't outsource any of our daily software needs because we need to be sure that they are done using only free software. Remember, there is no "cloud," just other people's computers. For example: we don't outsource our email, so every day we send over half a million messages to thousands of free software hackers through the community mailing lists we host. We also don't outsource our Web storage or networking, so we serve tens of thousands of free software downloads -- over 1.5 terabytes of data -- a day. And our popularity, and the critical nature of the resources we make available, make us a target for denial of service attacks (one is ongoing as we write this), requiring constant monitoring by the tech team, whose members take turns being ready for emergency work so that the resources our supporters depend on stay available.

As hard as we work, we still want to do more, like increasing our already strict standards on hardware compliance, so in 2020, we will finish replacing the few remaining servers that require a nonfree BIOS. To be compliant to our own high standards, we need to be working with devices that are available through Respects Your Freedom retailers. We plan to add new machines to our farm, so that we can host more community servers like the ones we already host for KDE, SugarLabs, GNU Guix, Replicant, gNewSense, GNU Linux-Libre, and FSFLA. We provide completely virtual machines that these projects use for their daily operations, whether that's Web hosting, mailing lists, software repositories, or compiling and testing software packages.

We know that many software projects and individual hackers are looking for more options on code hosting services that focus on freedom and privacy, so we are working to set up a public site that anybody can use to publish, collaborate, or document their progress on free software projects. We will follow strict criteria to ensure that this code repository hosts only fully free software, and that it follows the very best practices towards freedom and privacy.

Another project that we are very excited about for this year is a long-awaited refresh of https://www.fsf.org. Not only will it be restyled, but also easier to browse on mobile devices. As our campaigns and licensing teams are eager to create and publish more resources in different formats, we will also work to improve the support for publishing audio and video files on the site. And to enable you to do more, too, we are also developing a site to organize petitions and collect signatures, so that together we can run more effective grassroots campaigns and fight for the freedom of all computer users.

All of these efforts require countless hours of hard work, and the use of high quality hardware. These come to us at a significant cost, not just to purchase, but to keep running and to host at specialized data centers (if you have rack space in the Boston area, we are always looking for donors). For all this work, we depend on the continuous commitment of individual contributors to keep providing the technical foundation to fight for software freedom.

In solidarity,

Ruben Rodriguez Perez
Chief Technology Officer

08 December, 2019 02:20AM by Wensheng XIE

December 06, 2019

GNU Guile

GNU Guile 2.9.6 (beta) released

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

This release fixes bugs caught by users of the previous 2.9.5 prerelease, and adds some optimizations as well as a guile-3 feature for cond-expand.

In this release, we also took the opportunity to do some more rigorous benchmarking:

Comparison of microbenchmark performance for Guile 2.2.6 and 2.9.6

GNU Guile 2.9.6 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.

As always, experience reports with GNU Guile 2.9.6, good or bad, are very welcome; send them to guile-devel@gnu.org. If you know you found a bug, please do send a note to bug-guile@gnu.org. Happy hacking!

06 December, 2019 01:15PM by Andy Wingo (guile-devel@gnu.org)

Gary Benson

GNOME 3 won’t unlock

Every couple days something on my RHEL 7 box goes into a swapstorm and uses up all the memory. I think it’s Firefox, but I never figured out why, generally I have four different Firefoxes running with four different profiles, so it’s hard to tell which one’s failing (if it even is that). Anyway, sometimes it makes the screen lock crash or something, and I can’t get in, and I can never remember what process you have to kill to get back in, so here it is: gnome-shell. You have to killall -9 gnome-shell, and it lets you back in. Also killall -STOP firefox and killall -STOP "Web Content" are handy if the swapstorm is still under way.

06 December, 2019 10:17AM by gbenson

December 05, 2019

FSF Blogs

What's new in the GNU Press Shop

Greetings from the GNU Press Shop! This is an update on what's new and exciting at the Free Software Foundation's (FSF) online store, your source for GNU apparel, programming manuals, and more. We know at this time of year you'll be looking for GNU gifts for your favorite free software enthusiasts, and we have some terrific new picks for you to choose from! For holiday gifting, shipped within the US, we recommend placing your order before December 17th.

For starters, we've got just the thing for the chilly season: we have replaced our extended selection of hooded sweatshirts with a single, user-friendly zip-up design. It still comes in our signature maroon color, but with an all-new "happy computer" graphic by the FSF's superstar 2019 intern Valessio Brito. Between this sweatshirt and the satisfying feeling of helping spread the word about software freedom, we think you'll be quite warm and cozy this winter.

But what to wear under the hoodie? As in past years, the autumn brings a fresh color variation of our GNU head T-shirt. This year's GNU is a snazzy maroon-on-mustard color scheme sure to make anyone who sees it hungry for freedom: the tangy condiment without which the sausage of computing lacks savor. You can also spill nonmetaphorical mustard on it, and nobody will notice.

In addition to the new GNU, we also introduced our Emacs logo T-shirt in a scintillating color combination of purple-on-green. These arrived at the shop in late June, and sold out faster than you can say "M-x apropos-variable RET case-fold-search RET." They are once again fully stocked, and yes, they will make you look a little like a super hero (kind of like a more customizable and self-documenting Green Lantern).

Still want more T-shirts? The LibrePlanet 2020 conference T-shirt is available to order now: they won't be printed until March, but we are accepting early orders for shipping or pick-up at the conference. The shirt is a very handsome muted aquamarine color, and features another excellent illustration by Valessio Brito.

Want something that's not a T-shirt? Customers who welcome the unexpected will be pleased to learn that a new version of the popular NeuG USB True Random Number Generator is now available. The NeuG has undergone an update to both its physical design and firmware, and provides higher-quality random numbers than ever before.

Your purchases support the mission of the FSF and help us empower the world through the use of free software. Associate members are the heart of our commitment to create a world where all software respects our freedom and dignity. By becoming an associate member, you'll help us reach our goal of 600 new members by the end of the year, and of course you receive a 20% discount at the GNU Press Shop. This means, for instance, if you are starting a free software manual book club and tea drinking society, the fifth member of your club can be outfitted with books and mug gratis.

I'm proud to say that I personally fill and ship every order from the shop, so if you have any queries regarding shipping, please send them my way. I also lead in selecting and designing new products, and I can tell you that we are more than happy to receive your suggestions and opinions about our merchandise. For any of this correspondence, simply reply to this email or write me at sales@fsf.org.

Thanks for reading this update! I hope that you find something in the GNU Press Shop for all the software freedom enthusiasts in your life, yourself included.

05 December, 2019 05:45PM

December 04, 2019

The FSF tech team: doing more for free software

The Free Software Foundation (FSF) tech team works everyday to maintain and improve the infrastructure that supports hundreds of free software projects, along with the FSF itself, in its mission to create a world where all software respects our freedom and dignity. Our associate members are the heart of this commitment, and we couldn't do it without your help.

Our annual fundraiser is happening right now. Will you encourage your friends and family to join today to help us reach our goal of welcoming 600 new associate members before December 31st, or to support us with a donation? As a special bonus, all new and renewing annual associate members ($120+) can choose to receive one of our exclusive year-end gifts. If you get a minimum of three people to mention you as a referral, you can get them too!

Below is a message from our chief technology officer, Ruben Rodriguez Perez, about the services provided by our tech team.

At the Free Software Foundation (FSF), we like to set big goals for ourselves, keeping a relatively small group of dedicated activists determined to cover a lot of ground in a short time. The FSF tech team, for example, has just four members -- two senior systems administrators, one Web developer, and a part-time chief technology officer -- yet we manage to run over 120 virtual servers. These run on about a dozen machines hosted at four different data centers. These include many public-facing Web sites and community services, as well as every single IT requirement for the staff: workstations, data storage and backup, networking, printing, accounting, telephony, email, you name it.

We don't outsource any of our daily software needs because we need to be sure that they are done using only free software. Remember, there is no "cloud," just other people's computers. For example: we don't outsource our email, so every day we send over half a million messages to thousands of free software hackers through the community mailing lists we host. We also don't outsource our Web storage or networking, so we serve tens of thousands of free software downloads -- over 1.5 terabytes of data -- a day. And our popularity, and the critical nature of the resources we make available, make us a target for denial of service attacks (one is ongoing as we write this), requiring constant monitoring by the tech team, whose members take turns being ready for emergency work so that the resources our supporters depend on stay available.

As hard as we work, we still want to do more, like increasing our already strict standards on hardware compliance, so in 2020, we will finish replacing the few remaining servers that require a non-free BIOS. To be compliant to our own high standards, we need to be working with devices that are available through Respects Your Freedom retailers. We plan to add new machines to our farm, so that we can host more community servers like the ones we already host for KDE, SugarLabs, GNU Guix, Replicant, gNewSense, GNU Linux-Libre, and FSFLA. We provide dedicated virtual machines that these projects use for their daily operations, whether that's Web hosting, mailing lists, software repositories, or compiling and testing software packages.

We know that many software projects and individual hackers are looking for more options on code hosting services that focus on freedom and privacy, so we are working to set up a public site that anybody can use to publish, collaborate, or document their progress on free software projects. We will follow strict criteria to ensure that this code repository hosts only fully free software, and that it follows the very best practices towards freedom and privacy.

Another project that we are very excited about for this year is a long-awaited refresh of https://www.fsf.org. Not only will it be restyled, but also easier to browse on mobile devices. As our campaigns and licensing teams are eager to create and publish more resources in different formats, we will also work to improve the support for publishing audio and video files in the site. And to enable you to do more, too, we are also developing a site to organize petitions and collect signatures, so that together we can run more effective grassroots campaigns and fight for the freedom of all computer users.

All of these efforts require countless hours of hard work, and the use of high quality hardware. These come to us at a significant cost, not just to purchase, but to keep running and to host at specialized data centers (if you have rack space in the Boston area, we are always looking for donors). For all this work, we depend on the continuous commitment of individual contributors to keep providing the technical foundation to fight for software freedom.

Photo by Michael McMahon Copyright © 2019 Free Software Foundation, Inc., licensed under CC-BY-SA 4.0.

04 December, 2019 05:55PM

December 02, 2019

remotecontrol @ Savannah

November 27, 2019

FSF Blogs

Ethical Tech Giving Guide: Freedom is the gift that keeps on giving

For many of us, the holiday season is about bringing our loved ones together to celebrate. Most of the time, this includes giving them a neatly wrapped present or two. We go through the buying process carefully, using a friend or family member's likes and dislikes to sift through the Web and find the right item. But when choosing a tech gift, we need to be careful to give them something that doesn't harm them instead.

This is why we at the Free Software Foundation (FSF) publish our Ethical Tech Giving Guide each year, as a way to help free software supporters choose gifts that won't burden the people they care about with proprietary software or venomous Digital Restrictions Management (DRM). Devices may come and go, but introducing another person to software freedom is the start of a lifelong journey.

We create resources like the Ethical Tech Giving Guide to let others know that true freedom is dependent on software freedom. Our annual fundraiser is happening right now, and we're looking to bring 600 new associate members into the fold before December 31st. Our membership program is the heart of our work here at the FSF, and we couldn't do it without community support. If you're not already one of our valued members, will you take the next step in your commitment to software freedom and become an associate member today? Beginning at the $120 level of contribution, new and renewing members can choose from a great array of fundraiser premiums, including FSF and GNU patches, an FSF-emblazoned thermos, an FSF backpack, or all at once! We also encourage you to share this Guide, and our message, with friends.

The Giving Guide is a tool that will help you avoid the temptation to get your loved ones the latest offerings from companies like Apple or Amazon, whose business model revolves around subjecting people to proprietary malware and surveillance. Digital personal assistants and other devices running proprietary software did not become the norm overnight. Rather, they achieved their popularity through convincing one person at a time that they were useful. Tech corporations have billions of marketing dollars to convince people to use their products -- but our movement has more and more people every day, who can make daily choices to refuse them, and deprive them of power.

Computing in the free world received a major gift of its own this year with our Respects Your Freedom (RYF) certification of the Talos II and Talos II Lite, mainboards that are based on the promising POWER9 CPU architecture. The Talos mainboards and the POWER9 architecture are off to a great start where user freedoms are concerned, and may in time replace the more restrictive X86 motherboards that are popular today. It's a great start for the next phase of the RYF program, something we've taken into consideration when making major improvements to its Web site.

The Purism Librem 5 cell phone is another exciting addition to the Giving Guide this year: we're giving it a tentative recommendation because the company has publicly committed to doing the right things for prioritizing user freedom and privacy. We also have evaluated and endorsed the operating system that the Librem 5 will run, the fully free PureOS, and the phone is designed for maximum privacy, security, and user freedom.

We are still strong in our resistance, and Apple, Microsoft, Netflix, and company still haven't won the fight despite their efforts. The free software movement continues on, and the FSF is still here to fight for the freedom of computer users around the globe.

Share the Guide with your friends and family, and use it to give a few gifts yourself! Just like the free software movement, the FSF community is spread around the globe. Earlier this month we sent over 12,000 letters to supporters far and wide, and take our own holiday joy in seeing how far the fight for a free society has come since its humble beginnings. Although it's winter here in Boston, your sustained support, feedback, and positivity helps us keep the free software fires burning.

27 November, 2019 04:40PM

GNU Guix

Guix on an ARM Board

Increasingly people discovering Guix want to try it on an ARM board, instead of their x86 computer. There might be various reasons for that, from power consumption to security. In my case, I found these ARM boards practical for self-hosting, and I think the unique properties of GNU Guix are making it very suitable for that purpose. I have installed GNU Guix on a Cubietruck, so my examples below will be about that board. However, you should be able to change the examples for your own use case.

Installing the Guix System on an ARM board is not as easy as installing it on an x86 desktop computer: there is no installation image. However, Guix supports ARM and can be installed on a foreign distribution running on that architecture. The trick is to use the Guix installed on that foreign distribution to initialize the Guix System. This article will show you how to install the Guix System on your board, without using an installer image. As we have previously mentioned it is possible to generate an installation image yourself, if your board is supported.

Most boards can be booted from an existing GNU+Linux distribution. You will need to install a distribution (any of them) and install GNU Guix on it, using e.g. the installer script. Then, my plan was to install the Guix System on an external SSD drive, instead of the SD card, but we will see that both are perfectly possible.

The first part of the article will focus on creating a proper u-boot configuration and an operating system declaration that suits your board. The second part of this article will focus on the installation procedure, when there is no installer working for your system.

Writing a configuration file for an ARM board

A configuration file for an ARM board is not very different from a configuration file for a desktop or a server running on another architecture. However, most boards use the u-boot bootloader and require some less common modules to be available at boot time.

The root file system

First of all, you should decide where your root file system is going to be installed. In my case, I wanted to install is on the external SSD, so I chose it:

(file-systems
  (cons* (file-system
           (mount-point "/")
           (device "/dev/sda1")
           (type "ext4"))
         %base-file-systems))

If you instead want to install the root file system on an SD card, you'll need to find its device name, usually /dev/mmcblk0 and the partition number. The device corresponding to the first partition should be /dev/mmcblk0p1. In that case, you would have:

(file-systems
  (cons* (file-system
           (mount-point "/")
           (device "/dev/mmcblk0p1")
           (type "ext4"))
         %base-file-systems))

The bootloader

Because of the way the Guix System is designed, you cannot use an already existing bootloader to boot your system: it wouldn't know where to look for the kernel, because it doesn't know its store path. It wouldn't be able to let you boot older generations either. Most boards use the u-boot bootloader, so we will focus on that bootloader here.

Contrary to grub, there are multiple variants of u-boot, one per board type. The installation procedure for u-boot is also somewhat specific to the board, so there are two things that you need to take care of: the u-boot package and the bootloader declaration.

Guix already define a few u-boot based bootloaders, such as u-boot-a20-olinuxino-lime-bootloader or u-boot-pine64-plus-bootloader among others. If your board already has a u-boot-*-bootloader defined in (gnu bootloader u-boot), you're lucky and you can skip this part of the article!

Otherwise, maybe the bootloader package is defined in (gnu packages bootloaders), such as the u-boot-cubietruck package. If so, you're a bit lucky and you can skip creating your own package definition.

If your board doesn't have a u-boot-* package defined, you can create one. It could be as simple as (make-u-boot-package "Cubietruck" "arm-linux-gnueabihf"). The first argument is the board name, as expected by the u-boot build sysetem. The second argument is the target triplet that corresponds to the architecture of the board. You should refer to the documentation of your board for selecting the correct values. If you're really unlucky, you'll need to do some extra work to make the u-boot package you just created work, as is the case for the u-boot-puma-rk3399 for instance: it needs additional phases to install firmware.

You can add the package definition to your operating system configuration file like so, before the operating-system declaration:

(use-modules (gnu packages bootloaders))

(define u-boot-my-board
  (make-u-boot-package "Myboard" "arm-linux-gnueabihf"))

(operating-system
  [...])

Then, you need to define the bootloader. A bootloader is a structure that has a name, a package, an installer, a configuration file and a configuration file generator. Fortunately, Guix already defines a base u-boot bootloader, so we can inherit from it and only redefine a few things.

The Cubietruck happens to be based on an allwinner core, for which there is already a u-boot bootloader definition u-boot-allwinner-bootloader. This bootloader is not usable as is for the Cubietruck, but it defines most of what we need. In order to get a proper bootloader for the Cubietruck, we define a new bootloader based on the Allwinner bootloader definition:

(define u-boot-cubietruck-bootloader
  (bootloader
    (inherit u-boot-allwinner-bootloader)
    (package u-boot-cubietruck)))

Now that we have our definitions, we can choose where to install the bootloader. In the case of the Cubietruck, I decided to install it on the SD card, because it cannot boot from the SSD directly. Refer to your board documentation to make sure you install u-boot on a bootable device. As we said earlier, the SD card is /dev/mmcblk0 on my device.

We can now put everything together like so:

(use-modules (gnu packages bootloaders))

(define u-boot-cubietruck
  (make-u-boot-package "Cubietruck" "arm-linux-gnueabihf"))

;; u-boot-allwinner-bootloader is not exported by (gnu bootloader u-boot) so
;; we use @@ to get it.  (@ (module) variable) means: get the value of "variable"
;; as defined (and exported) in (module).  (@@ (module) variable) is the same, but
;; it doesn't care whether it is exported or not.
(define u-boot-allwinner-bootloader
  (@@ (gnu bootloader u-boot) u-boot-allwinner-bootloader))

(define u-boot-cubietruck-bootloader
  (bootloader
    (inherit u-boot-allwinner-bootloader)
    (package u-boot-cubietruck)))

(operating-system
  [...]
  (bootloader
    (bootloader-configuration
      (target "/dev/mmcblk0")
      (bootloader u-boot-cubietruck-bootloader)))
  [...])

The kernel modules

In order for Guix to be able to load the system from the initramfs, it will probably need to load some modules, especially to access the root file system. In my case, the SSD is on an ahci device, so I need a driver for it. The kernel defines ahci_sunxi for that device on any sunxi board. The SD card itself also requires two drivers: sunxi-mmc and sd_mod.

Your own board may need other kernel modules to boot properly, however it is hard to discover them. Guix can tell you when a module is missing in your configuration file if it is loaded as a module. Most distros however build these modules in the kernel directly, so Guix cannot detect them reliably. Another way to find what drivers might be needed is to look at the output of dmesg. You'll find messages such as:

[    5.193684] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[    5.219697] sunxi-mmc 1c0f000.mmc: initialized, max. request size: 16384 KB
[    5.221819] sunxi-mmc 1c12000.mmc: allocated mmc-pwrseq
[    5.245620] sunxi-mmc 1c12000.mmc: initialized, max. request size: 16384 KB
[    5.255341] mmc0: host does not support reading read-only switch, assuming write-enable
[    5.265310] mmc0: new high speed SDHC card at address 0007
[    5.268723] mmcblk0: mmc0:0007 SD32G 29.9 GiB

or

[    5.614961] ahci-sunxi 1c18000.sata: controller can't do PMP, turning off CAP_PMP
[    5.614981] ahci-sunxi 1c18000.sata: forcing PORTS_IMPL to 0x1
[    5.615067] ahci-sunxi 1c18000.sata: AHCI 0001.0100 32 slots 1 ports 3 Gbps 0x1 impl platform mode
[    5.615083] ahci-sunxi 1c18000.sata: flags: ncq sntf pm led clo only pio slum part ccc 
[    5.616840] scsi host0: ahci-sunxi
[    5.617458] ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port 0x100 irq 37
[    5.933494] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Also note that module names are not consistent between what Guix expects and what is printed by dmesg, especially when the contain a "-" or a "_". You will find the correct file name by building (or using a substitute for) linux-libre beforehand:

find `guix build linux-libre`/lib/modules -name '*mmc*'

Here, I could find a file named "kernel/drivers/mmc/host/sunxi-mmc.ko", hence the module name sunxi-mmc. For the other driver, I found a "kernel/drivers/ata/ahci_sunxi.ko", hence the name ahci_sunxi, even if dmesg suggested ahci-sunxi.

Once you have found the modules you want to load before mounting the root partition, you can add them to your operating-system declaration file:

(initrd-modules (cons* "sunxi-mmc" "sd_mod" "ahci_sunxi" %base-initrd-modules))

Installing the Guix System

Installing on another drive

In my case, I wanted to install the system on an external SSD, while the currently running foreign distribution was running from the SD card. What is nice with this setup is that, in case of real trouble (you SSD caught fire or broke), you can still boot from the old foreign system with an installed Guix and all your tools by re-flashing only the bootloader.

In this scenario, we use the foreign system as we would the installer iso, using the manual installation procedures described in the manual. Essentially, you have to partition your SSD to your liking, format your new partations and make sure to reference the correct partition for the root file system in your configuration file. Then, initialize the system with:

mount /dev/sda1 /mnt
mkdir /mnt/etc
$EDITOR /mnt/etc/config.scm # create the configuration file
guix system init /mnt/etc/config.scm /mnt

You can now reboot and enjoy your new Guix System!

Installing on the same drive

Another option is to install the Guix System over the existing foreign distribution, replacing it entirely. Note that the root filesystem for the new Guix System is the current root filesystem, so no need to mount it. The following will initialize your system:

$EDITOR /etc/config.scm # create the configuration file
guix system init /etc/config.scm /

Make sure to remove the files from the old system. You should at least get rid of the old /etc directory, like so:

mv /etc{,.bak}
mkdir /etc

Make sure there is an empty /etc, or the new system won't boot properly. You can copy your config.scm to the new /etc directory. You can now reboot and enjoy your new Guix System!

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.

27 November, 2019 12:00PM by Julien Lepiller

www-zh-cn @ Savannah

Come together for free software

Here at the Free Software Foundation (FSF), we strongly believe that one person can make a difference. Our main task, as the principal organization in the fight for user freedom, is one of connection; to bring people together around an unwavering set of principles. We will achieve global software freedom by staying the course, by focusing on education, and by making tools and solutions available, all by working together with this passionate and diverse community.

Every individual that takes action now will help us reach our goal of welcoming 600 new associate members by December 31st. Associate members give us the strength to amplify the free software message -- each new member exponentially increases our reach and our ability to make change. Visit fsf.org/appeal to learn more about all the different ways we can stand strong together and for access to engaging images to help you spread the message using the hashtag #ISupportFreeSoftware!

The FSF is supported by thousands of individuals like you who form the heart of the movement. Thank you for being an associate member we can depend on. While it's humbling to have thousands of people around the world giving us their votes of confidence, we also know we need to connect with millions more. Please take this moment to publicly share your passion for free software. If each associate member inspires just one other, we can double our strength. Plus, if you manage to get a minimum of three people to mention you as a referral before December 31st, you will receive an exclusive year-end gift. If you can do a little more, any extra donation you can make will help us reach even more people on your behalf.

This year, our staff of only fourteen used your financial support to unite people all over the world around our mission, with increased opportunities both in-person and online.

The only way to make sure free software stays free is through enforcing copyleft licenses, like the GNU General Public License, according to the Principles of Community-Oriented GPL Enforcement. In addition to their GPL enforcement work, our Licensing and Compliance Lab also provides educational resources to guide people through myriad licensing choices. With the help of a dedicated volunteer team, they help organizations and individuals properly distribute software while protecting user freedom.

    This October we organized a Continuing Legal Education (CLE) seminar on GPL Compliance and Legal Ethics, educating law professionals, students, and anyone interested about a range of relevant free software licensing topics.

    We invested in the development of a brand new Respects Your Freedom (RYF) Web site, so that we can connect retailers with potential customers. Our RYF program provides anyone looking for freedom-respecting products with an increasingly wide range of options. Our Licensing and Compliance Lab does the important leg work of verifying devices for users.

More and bigger seminars are in the pipeline, and we are currently processing 55 RYF certification applications. Any financial support will go into increased infrastructure, sourcing volunteers, certification, and hosting in-person, educational events.

    For years, people everywhere have been able to participate remotely in the annual LibrePlanet conference through our fully free livestream. This year, our tech team was able to share that knowledge with the EmacsConf team, as well as with the WikiConference team so that they could successfully stream their online conferences using only free software for the first time. For EmacsConf, the FSF also organized one of only two satellite instances, and hosted two of the speakers.

    Our tech team supports the development of free software by providing server space for FSF infrastructure, for the GNU Project, and for other free software projects. We recently moved our cluster of 100+ virtual machines to a new location, where we will continue to work on upgrading and expanding it. With an upgraded cluster, we'll be able to provide even more new and promising free software projects with a fully free hosting location. Rent, equipment, and RYF-compliant hardware are necessary to be able to offer this service more professionally to the public.

    The thirteenth International Day Against DRM (IDAD) hosted activists in Boston for protests and a sprint on writing educational materials, but also brought together fourteen online partners who amplified IDAD further worldwide. They organized activities ranging from promotional offers to increased writing and local activism. The dust jacket that was specially designed for the event was translated into eight languages by supporters from around the world, which is a testament to its effectiveness and our reach.

    Lastly, every six months, we find ourselves in the FSF office working with some thirty volunteers to hold true to our promise of sending the print version of our biannual free software publication to our associate members. A combined 300 hours of connecting with local free software enthusiasts allows us to send over 12,500 Bulletins to dedicated advocates in 53 countries. It will soon be published online as well.

This is just a snapshot of the many ways we were able to form new connections this year. Upholding free software and copyleft standards; providing technical infrastructure for free software developers globally; educating about free software; campaigning; organizing events; speaking and tabling at other industry events; and publishing advocacy articles, are at the core of the Foundation's work. We use funds for design, venue logistics, equipment, and operational support; we offer the possibility of attending our events to those who typically would not have the funds; and we also provide guidance and fiscal sponsorship for other free software projects and conferences who are making a difference.

We will continue to do this work and to establish and motivate connections that allow us to build awareness about the unjust power of proprietary software. We achieve a lot for little with the help of volunteers, and often repurpose equipment where we can. We have received Charity Navigator's top rating for six consecutive years. And you can read our financial statements and annual reports online.

Thank you for everything you do to help this cause. The faces behind the free software movement may change, but with your support, the Free Software Foundation will not diverge from our continued defense of the four freedoms -- not now, not ever. We advocate for and facilitate the creation of free software because it is the right thing to do -- and we need you. Our connection with you is valuable to us because you connect the movement to the world.

Thank you.

Zoë Kooyman
Program Manager

27 November, 2019 09:36AM by Wensheng XIE

November 26, 2019

gnuastro @ Savannah

Gnuastro 0.11 released

The 11th release of GNU Astronomy Utilities (Gnuastro) is now available. Please see the announcement for more.

26 November, 2019 04:46PM by Mohammad Akhlaghi

November 25, 2019

FSF News

Contract opportunity: Bookkeeper

The contractor will work closely with our business operations manager and the rest of the operations team to ensure that the organization's day-to-day financial functions run smoothly. We are looking for a hands-on and detail-oriented professional who is comfortable working both independently and with multiple teams as needed. Ideal candidates will be proactive and highly adaptable, with an aptitude for learning new tools and paying close attention to minutiae despite dense financial material. Applicants should have at least three years of experience with nonprofit bookkeeping and finance. Familiarity with tools we use is a plus, such as SQL Ledger, CiviCRM, LibreOffice, and Request Tracker.

Contract expectations include:

  • preparing weekly accounts receivable, payables, deposits, and purchasing,

  • assisting with monthly financial reconciliation,

  • processing incoming tickets in our internal/external ticketing system, and

  • supporting the annual audit.

Contract details

This is a 3-month contract position at 10 to 20 hours per week, with responsibilities to be performed on-site at the FSF's downtown Boston office. All work will be done in the office with free software. Compensation is competitive.

Application instructions

Applications must be submitted via email to hiring@fsf.org. The email must contain the subject line "Bookkeeper." A complete application should include:

  • cover letter,
  • resume,
  • hourly rate requirements, and
  • three recent references.

All materials must be in a free format (such as text, LibreOffice, or PDF files). Email submissions that do not follow these instructions will probably be overlooked. No phone calls, please.

Applications will be reviewed on a rolling basis until the position is filled. To guarantee consideration, submit your application by December 11, 2019.

The FSF is an equal opportunity employer and does not discriminate against any employee, contractor, or application for employment or contracting, on the basis of race, color, marital status, religion, age, sex, sexual orientation, national origin, handicap, or any other legally protected status recognized by federal, state or local law. We value diversity in our workplace.

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 fsf.org and 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. We are based in Boston, MA, USA.

25 November, 2019 09:21PM

November 23, 2019

health @ Savannah

GNU Health patchset 3.6.2 released !

Dear community

GNU Health 3.6.2 patchset has been released !

Priority: High

Table of Contents

  • About GNU Health Patchsets
  • Updating your system with the GNU Health control Center
  • Summary of this patchset
  • Installation notes
  • List of issues related to this patchset

About GNU Health Patchsets

We provide "patchsets" to stable releases. Patchsets allow applying bug fixes and updates on production systems. Always try to keep your production system up-to-date with the latest patches.

Patches and Patchsets maximize uptime for production systems, and keep your system updated, without the need to do a whole installation.

NOTE: Patchsets are applied on previously installed systems only. For new, fresh installations, download and install the whole tarball (ie, gnuhealth-3.6.2.tar.gz)

Updating your system with the GNU Health control Center

Starting GNU Health 3.x series, you can do automatic updates on the GNU Health HMIS kernel and modules using the GNU Health control center program.

Please refer to the administration manual section ( https://en.wikibooks.org/wiki/GNU_Health/Control_Center )

The GNU Health control center works on standard installations (those done following the installation manual on wikibooks). Don't use it if you use an alternative method or if your distribution does not follow the GNU Health packaging guidelines.

Summary of this patchset

Patch 3.6.2 fixes a problem in the obstetric history (OBS command) on representing the weeks at the end of pregnancy.

Installation Notes

You must apply previous patchsets before installing this patchset. If your patchset level is 3.6.1, then just follow the general instructions.

In most cases, GNU Health Control center (gnuhealth-control) takes care of applying the patches for you. 
Login as gnuhealth user

$ cdutil
$ gnuhealth-control update

For detailed information, follow the general instructions at

After applying the patches, make a full update of your GNU Health database as explained in the documentation.

  • Restart the GNU Health server

List of issues and tasks related to this patchset

  • GH HMIS server. health_gyneco . Bug #57292: OBS command generates a traceback
  • GH HMIS server. health_federation.  Enforce unicode on setup read method

 For detailed information about each issue, you can visit https://savannah.gnu.org/bugs/?group=health
 For detailed information about each task, you can visit https://savannah.gnu.org/task/?group=health

 For detailed information you can read about Patches and Patchsets

Happy and healthy hacking !

Dr. Luis Falcon, MD, MSc
President, GNU Solidario
GNU Health: Freedom and Equity in Healthcare
http://www.gnuhealth.org
GPG Fingerprint :ACBF C80F C891 631C 68AA  8DC8 C015 E1AE 0098 9199

Join us at GNU Health Con 2019 https://www.gnuhealthcon.org

23 November, 2019 04:51PM by Luis Falcon

parallel @ Savannah

GNU Parallel 20191122 ('Quantum Supremacy') released [stable]

GNU Parallel 20191122 ('Quantum Supremacy') [stable] has been released. It is available for download at: http://ftpmirror.gnu.org/parallel/

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

GNU Parallel is 10 years old next 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:

  [L]earning about parallel was amazing for me, it gives us many beautiful solutions.
    -- SergioAraujo@stackoverflow

New in this release:

  • 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.

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

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

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

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

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

You can install GNU Parallel in just 10 seconds with:

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

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

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

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

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

If you like GNU Parallel:

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

If you use programs that use GNU Parallel for research:

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

If GNU Parallel saves you money:

About GNU SQL

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

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

When using GNU SQL for a publication please cite:

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

About GNU Niceload

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

23 November, 2019 01:03PM by Ole Tange

November 22, 2019

GNU Guile

GNU Guile 2.9.5 (beta) released

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

Besides the usual set of optimizations, this release adds an --r6rs option for better R6RS support out of the box, and also adds a new --r7rs corresponding to R&RS. Guile's core exception handling has also been rebased onto the raise-exception and with-exception-handler primitives, enabling better compatibility going forward with structured exception objects, which are more common in the broader Scheme community than Guile's old throw and catch.

GNU Guile 2.9.5 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.

Experience reports with GNU Guile 2.9.5, good or bad, are very welcome; send them to guile-devel@gnu.org. If you know you found a bug, please do send a note to bug-guile@gnu.org. Happy hacking!

22 November, 2019 03:15PM by Andy Wingo (guile-devel@gnu.org)

Sylvain Beucler

Android Rebuilds updates

What is it already?

Android Rebuilds provides freely-licensed builds of Android development tools written by somebody else.

New builds

SDK 10 (API 29) and NDK 20 rebuilds are now available, as unattended build scripts as well as binaries you shan't trust.

sdkmanager integration will be complete when we figure out how to give our repo precedence over somebody else's.

Evolution of the situation

SDK build remains monolithic and growing (40GB .git, 7h multi-core build, 200GB build space).

But there are fewer build issues, thanks to newer "prebuilts" deps straight in Git, now including OpenJDK.
I expect we'll soon chroot in Git before build.

Also for the first time ever I could complete a NDK windows build.

Licensing

Official binaries are still click-wrapped with a proprietary license.

It was discovered that such a license is also covering past versions of android.jar & al. hidden in a prebuilts directory and somehow necessary to the builds.
Archeological work already successfully started to rebuild SDKs from the start of the decade.

Fanbase

Android Rebuilds is showcased in ungoogled-chromium-android, a lightweight approach to removing Google web service dependency.

F-Droid mirror

After some back and forth, the F-Droid mirror is stable and limited to the experimental sdkmanager repository.
F-Droid showed high dedication to implementing upload restrictions and establishing procedures.
I have great hope that they will soon show the same level of dedication dropping non-free licenses and freeing their build server.

22 November, 2019 01:35PM

November 19, 2019

health @ Savannah

GNU Health patchset 3.6.1 released !

Dear community

GNU Health 3.6.1 patchset has been released !

Priority: High

Table of Contents

  • About GNU Health Patchsets
  • Updating your system with the GNU Health control Center
  • Summary of this patchset
  • Installation notes
  • List of issues related to this patchset

About GNU Health Patchsets

We provide "patchsets" to stable releases. Patchsets allow applying bug
fixes and updates on production systems. Always try to keep your
production system up-to-date with the latest patches.

Patches and Patchsets maximize uptime for production systems, and keep
your system updated, without the need to do a whole installation.

NOTE: Patchsets are applied on previously installed systems only. For
new, fresh installations, download and install the whole tarball (ie,
gnuhealth-3.6.1.tar.gz)

Updating your system with the GNU Health control Center

Starting GNU Health 3.x series, you can do automatic updates on the GNU
Health HMIS kernel and modules using the GNU Health control center
program.

Please refer to the administration manual section (
https://en.wikibooks.org/wiki/GNU_Health/Control_Center )

The GNU Health control center works on standard installations (those
done following the installation manual on wikibooks). Don't use it if
you use an alternative method or if your distribution does not follow
the GNU Health packaging guidelines.

Summary of this patchset

Patch 3.6.1 mainly fixes crash / tracebacks on medicament computation,
which is now using the standard product location quantities. Version
3.6.1 also provides the latest gnuhealth-control center tool. 

Installation Notes

You must apply previous patchsets before installing this patchset. If
your patchset level is 3.6.0 , then just follow the general
instructions.

In most cases, GNU Health Control center (gnuhealth-control) takes care
of applying the patches for you.

Follow the general instructions at

After applying the patches, make a full update of your GNU Health
database as explained in the documentation.

  • Restart the GNU Health server

List of issues and tasks related to this patchset

  https://savannah.gnu.org/bugs/?57267

  • bug #57266: Remove the 2to3 conversion in updates

  https://savannah.gnu.org/bugs/?57266

For detailed information about each issue, you can visit
 https://savannah.gnu.org/bugs/?group=health

For more information you can read about Patches and Patchsets

Happy and healthy hacking !
--
Dr. Luis Falcon, M.D.
President, GNU Solidario
GNU Health: Freedom and Equity in Healthcare
http://www.gnuhealth.org
GPG Fingerprint :ACBF C80F C891 631C 68AA  8DC8 C015 E1AE 0098 9199

Join us at GNU Health Con 2019 https://www.gnuhealthcon.org

19 November, 2019 11:04PM by Luis Falcon

November 18, 2019

Sylvain Beucler

SCP Foundation needs you!

SCP is a mind-blowing, diverse, high-quality collection of writings and illustrations, all released under the CC-BY-SA free license.
If you never read horror stories written with scientific style -- have a try :)

[obviously this has nothing to do with OpenSSH Secure CoPy ;)]

Faced with a legal threat through the aggressive use of a RU/EU trademark, the SCP project is raising a legal fund.
I suggest you have a look.

18 November, 2019 12:57PM

November 17, 2019

GNU Guix

Running a Guix Xfce Desktop on CentOS 7

This tutorial will show how to run a fully fledged Xfce desktop environment installed with Guix on top of an existing GNU/Linux distribution. This guide uses CentOS 7 as the base operating system and assumes that Xorg is already configured and running on VT2 under a different user account.

We will borrow Xorg and xinit from the host distribution and run Guix Xfce on virtual terminal 4 as user alice. No system-wide configuration files need to be touched (apart from the Guix install), but we do make a couple of changes for convenience.

From scratch to Xfce

If Guix is not already installed, go grab the installation script and run it as sudo bash guix-install.sh.

The script creates /gnu/store/ and /var/guix/ and configures a system service for guix-daemon. By default the daemon runs from the root users Guix; we won't be using the root account in this guide, so let's start by making the guix-daemon service refer to our local user alice instead.

sudo sed -i 's/root/alice/' /etc/systemd/system/guix-daemon.service

Now every time Alice runs 'guix pull', the daemon gets updated too. If you installed Guix just now, make sure to run guix pull before proceeding further.

Next we'll add some lines to Alices .bash_profile to set up PATH and related variables:

~/.bash_profile:

GUIX_PROFILE="${HOME}/.guix-profile"
[[ -L "${GUIX_PROFILE}" ]] && . "${GUIX_PROFILE}/etc/profile"

export PATH="${HOME}/.config/guix/current/bin:${PATH}"
export INFOPATH="${HOME}/.config/guix/current/share/info:${INFOPATH}"
export MANPATH="${HOME}/.guix-profile/share/man:/usr/share/man"

export XDG_CONFIG_DIRS="${HOME}/.desktop-profile/etc/xdg:${HOME}/.guix-profile/etc/xdg"
export XDG_DATA_DIRS="${HOME}/.desktop-profile/share:${HOME}/.guix-profile/share"

This will look familiar if you have used Guix on a foreign distribution before. The XDG_ variables tell desktop environments where to look for installed programs and things like autostart files: we want minimal interference from the host system, so we "hard code" them to refer to just our Guix profiles.

We will install Xfce and related programs to a separate Guix profile that can be updated and rolled back independently of the main user profile. That allows us to distinguish between "stable desktop environment" and "end user packages". To keep things manageable, we create a manifest for the desktop profile that can be kept in version control, and which allows us to reproduce the exact same environment in the future (even on a different computer!).

~/desktop-manifest.scm:

(specifications->manifest
 '("xfce" "xfce4-session" "xfconf" "xfce4-battery-plugin"
   "pulseaudio" "xfce4-volumed-pulse" "xfce4-notifyd"
   ;; Helpful graphical programs.
   "mousepad" "orage"
   ;; System configuration utilities.
   "xbacklight" "pavucontrol" "stow"
   ;; For HTTPS access.
   "nss-certs"
   ;; These utilities are provided by the host, but we want the Guix versions
   ;; because they are likely better integrated and up to date.
   "fontconfig" "bash-completion" "gnupg" "man-db" "git"))

Create the initial profile generation:

guix package -p ~/.desktop-profile -m ~/desktop-manifest.scm

That installs a union of all packages listed in the manifest to ~/.desktop-profile, and creates a script we will use to "activate" it later. To update this profile, simply invoke the same command again after running guix pull or modifying the manifest.

Before Xfce can be started, we need to create a configuration file for the X server to ensure the host executable is used, and we will tell it to to stay on virtual terminal 4. We also create a .xinitrc script that automatically starts Xfce every time xinit is invoked.

~/.xserverrc:

exec /usr/bin/Xorg -novtswitch -nolisten tcp "$@" vt$XDG_VTNR

~/.xinitrc:

#!/bin/sh

# Get the default xinit configuration for CentOS.
. /etc/X11/xinit/xinitrc-common

exec startxfce4

.xinitrc needs to be executable:

chmod +x ~/.xinitrc

Now let's activate the desktop profile and start the X server, using ":1" as DISPLAY (remember that we have another X server running on VT2, occupying the default ":0" display).

GUIX_PROFILE=~/.desktop-profile
source ~/.desktop-profile/etc/profile
xinit -- :1

Cool, we're in Xfce! Let's open a terminal and install a browser & some fonts:

guix install icecat font-liberation font-dejavu

To make the newly installed fonts available right away we need to invoke fc-cache:

fc-cache -rv

Finally, we'll configure the shell to source scripts installed by Guix so that bash completions and similar work, by adding these lines at the end of .bashrc:

~/.bashrc:

# Source the Guix shell configuration directories, for vte.sh and bash completions.
GUIX_PROFILES=("${HOME}/.desktop-profile"
               "${HOME}/.guix-profile"
               "${HOME}/.config/guix/current")
for profile in "${GUIX_PROFILES[@]}"; do
    for dir in "${profile}/etc/bash_completion.d" "${profile}/etc/profile.d"; do
        if [[ -d "${dir}" ]]; then
            for f in "${dir}"/*; do
                . $f
            done
        fi
    done
done

Phew! It took some work, but by now you should have a working Xfce desktop environment, with bash completions and all. If you are content with starting it manually, skip to "final tweaks" below. Otherwise, read on.

(If you do not have a working desktop after following these steps, please email guix-devel@gnu.org so we can adjust the tutorial!)

Starting Xfce automatically on boot

We can configure our login shell to run xinit every time we log in to VT4 by adding these lines at the end of ~/.bash_profile:

# Start Xorg on display :1 when logged in to VT4, unless DISPLAY is already set.
if [[ -z "${DISPLAY}" && "${XDG_VTNR}" == 4 ]]; then
    GUIX_PROFILE="${HOME}/.desktop-profile"
    source "${HOME}/.desktop-profile/etc/profile"
    exec xinit -- :1
fi

To avoid the need for typing username and password at the console, instruct the getty service for TTY4 to automatically log in user 'alice':

/etc/systemd/system/getty@tty4.service.d/override.conf:

[Unit]
After=graphical.target

[Service]
# Delay for a few seconds, to ensure the Xorg server on VT2 starts first.
ExecStartPre=/bin/sleep 3
ExecStart=
ExecStart=-/sbin/agetty --autologin alice --noclear %I $TERM
Restart=on-success

Now just switching to VT4 will start Xfce! To do this when the system boots, simply enable the getty@tty4 service:

sudo systemctl enable getty@tty4.service

Final tweaks

Some issues were found during usage of the Xfce environment. Launching programs from the file manager failed because gio-launch-desktop was unavailable, and xfce4-terminal complained that the shell function __vte_prompt_command was not found.

These problems will be fixed in Guix eventually, but for now we'll work around them by adding the glib:bin and vte packages to our manifest:

~/desktop-manifest.scm:

(specifications->manifest
 '("xfce" "xfce4-session" "xfconf" "xfce4-battery-plugin"
   ...
   "glib:bin"                  ;for 'gio-launch-desktop'
   "vte"))                     ;for vte.sh, required by xfce4-terminal

We also found that closing the lid would not send the system to sleep, even though xfce4-power-manager --dump showed no problems. To work around it, we told systemd to ignore any "inhibitors" and take care of lid handling itself:

/etc/systemd/logind.conf:

HandleLidSwitch=suspend
LidSwitchIgnoreInhibited=yes

Additionally it is strongly recommended to enable the name service cache daemon if not already running. On CentOS this can be done by:

sudo yum install nscd

Bonus section: Installing programs with a custom build of Qt

One additional issue was that Qt programs did not work due to the stock CentOS kernel being too old. Specifically it lacks the renameat2() system call. Luckily Qt can be configured not to use it. A patch has been submitted to Guix, but since we are in a hurry, we will add a procedure to our manifest so we can use Qt programs (here wpa-supplicant-gui) until the Guix fix is merged:

~/.desktop-manifest.scm:

(use-modules (guix packages)
             (guix utils)
             (gnu)
             (gnu packages admin)
             (gnu packages qt))

(define qtbase/fixed
  (package/inherit
   qtbase
   (arguments
    (substitute-keyword-arguments (package-arguments qtbase)
      ((#:phases phases)
       `(modify-phases ,phases
          (add-after 'unpack 'disable-renameat2
            (lambda _
              ;; Mimic the '-no-feature-renameat2' configure flag.
              (substitute* "src/corelib/configure.json"
                (("config\\.linux && tests\\.renameat2")
                 "false"))
              #t))))))))

(define with-fixed-qt
  ;; This procedure recursively rewrites any references to 'qtbase'
  ;; with our patched version.
  (package-input-rewriting `((,qtbase . ,qtbase/fixed))))

(packages->manifest
 (append (list (with-fixed-qt wpa-supplicant-gui))
         (map specification->package
              '("xfce" "xfce4-session" "xfconf" "xfce4-battery-plugin"
                ...))))

...and now wpa_gui works after installing the new manifest!

Acknowledgements

Special thanks to Ocean Space Acoustics AS for sponsoring this work.

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.

17 November, 2019 07:00PM by Marius Bakke

denemo @ Savannah

Version 2.3 was released

This is a belated notice that version 2.3 has been released.

New Features

    Seek Locations in Scores
        Specify type of object sought
        Or valid note range
        Or any custom condition
        Creates a clickable list of locations
        Each location is removed from list once visited
    Syntax highlighting in LilyPond view
    Playback Start/End markers draggable
    Source window navigation by page number
        Page number always visible
    Rapid marking of passages
    Two-chord Tremolos
    Allowing breaks at half-measure for whole movement
        Also breaks at every beat
    Passages
        Mark Passages of music
        Perform tasks on the marked passages
        Swapping musical material with staff below implemented
    Search for lost scores
        Interval-based
        Searches whole directory hierarchy
        Works for transposed scores
    Compare Scores
    Index Collection of Scores
        All scores below a start directory indexed
        Index includes typeset incipit for music
        Title, Composer, Instrumentation, Score Comment fields
        Sort by composer surname
        Filter by any Scheme condition
        Open files by clicking on them in Index
    Intelligent File Opening
        Re-interprets file paths for moved file systems
    Improved Score etc editor appearance
    Print History
        History records what part of the score was printed
        Date and printer included
    Improvements to Scheme Editor
        Title bar shows open file
        Save dialog gives help
    Colors now differentiate palettes, titles etc. in main display
    Swapping Display and Source positions
        for switching between entering music and editing
        a single keypress or MIDI command
    Activate object from keyboard
        Fn2 key equivalent to mouse-right click
        Shift and Control right-click via Shift-Fn2 and Control-Fn2
    Help via Email
    Auto-translation to Spanish

Bug Fixes

    Adding buttons to palettes no longer brings hidden buttons back

    MIDI playback of empty measures containing non-notes

    Instrument name with Ambitus clash in staff properties menu fixed

    Visibility of emmentaler glyphs fixed

    Update of layout on staff to voice change

    Open Recent anomalies fixed

    Failures to translate menu titles and palettes fixed

17 November, 2019 05:05PM by Richard Shann

November 12, 2019

FSF Events

Hang out with the FSF staff in Seattle, November 15

We are hosting this get-together to show our appreciation for your support of the FSF's work and to provide an opportunity to meet other FSF members and supporters in the area. We'll give updates on what the FSF is currently working on and we are curious to hear your thoughts, as well as answer any questions you may have.

  • WHEN: Friday, November 15, from 18:30 - 20:30 PDT

  • WHERE: Herb & Bitter, 516 Broadway, East Seattle, WA 98102

  • RSVP: RSVP to campaigns@fsf.org before Thursday, November 14, if you're thinking of attending

We will be providing appetizers, including vegan/vegetarian friendly items. We reserve some space in the venue for the amount of people we expect based on the RSVP, but we still welcome people that have not planned ahead. This is an informal gathering for anyone who is interested in participating in the free software community or wants to learn more about the FSF; you don't have to be a current member to attend.

We look forward to meeting you in person!

12 November, 2019 03:50PM

GNU Guix

Spreading the news

Like most free software projects, Guix has no shortage of communication channels: there’s this blog, the NEWS file for release notes, a bunch of mailing lists, an IRC channel, there’s also an unofficial sub-Reddit and certainly more. Yet, as developers, we often find it hard to communicate important changes to our users. Starting from a few weeks ago, guix pull --news tells users what’s new, and it already feels very helpful! This post is about our motivations and the implementation of this new feature.

Getting the word out

Developers keep adding crazy features, fixing bugs, and generally improving things. But how good is it if users aren’t aware of these new things? As an example, since June, our build farm has been offering lzip-compressed binaries, which results in better performance when installing software. But to take advantage of that, users need to be aware of its existence, and they need to upgrade their Guix daemon. Likewise, how do we get people to learn about the new guix deploy command that’s now available at their fingertips, about security issues that were fixed, about important infrastructure changes, new options added to existing commands, and so forth?

Our (frustrating!) experience has been that release notes, blog posts, and mailing list announcements aren’t quite enough to get the word out. There’s always people who’ll miss important info and realize when it’s already late, sometimes too late. Hence this simple idea: wouldn’t it be nice if important information would reach users right in their terminal?

guix pull news

Alright, that’s not exactly a novel idea! In Debian for example, apt-listchanges shows news at the level of individual packages, taken from the NEWS.Debian or changelog.Debian files that package maintainers update. In addition, apt dist-upgrade and similar commands typically display dialog boxes and menus when special actions need to be taken when upgrading. That’s more or less what we’re looking for.

The situation in Guix is a little different: all of it lives in a single Git repository that contains the core, the command-line interfaces, as well as package definitions and operating system service definitions. The guix pull command is sort-of equivalent to apt update, except that it updates not only the set of available packages but also the guix tools themselves and all the operating system interfaces. Under the hood, guix pull essentially does git pull and consequently updates all of this. Guix very much follows a “rolling release” model.

For some time already, guix pull has been able to extract information about new and upgraded packages and to present it to the user. Our goal was to complement it with high-level information about important changes written with users in mind. Clearly, showing the Git commit log is not an option: commit logs are meant for developers and there’s roughly a thousand commits per month—way too much information. We needed high-level news entries, explicitly written for users.

The end result is this: guix pull now displays, in addition to a summary of the new and upgraded packages, the headlines of applicable news entries contributed by developers. Users can view the details by running guix pull --news:

'guix pull' displaying news.

Users can no longer miss the news, for the benefit of both users and developers!

Under the hood

How does this all work? There were several goals and constraints. First, like commit logs, our high-level news entries should be anchored in the Git history. Second, unlike commit logs, it should be possible to amend them—to fix typos, provide additional info, and so on. Third, the project has been paying a lot of attention to internationalization, with translations available for user interface messages, for package descriptions, and for the user manual—it’s one of these things that helps free software reach out to more people; thus, we naturally wanted news to be internationalized. Last, since Guix supports third-party “channels”, which are extensions of the official guix channel, why not provide channel authors access to that news feature?

With all these things in mind, we designed a simple news format. In essence, channel authors, including Guix developers, can provide a news file that looks like this:

(channel-news
 (version 0)

 (entry (commit "3e962e59d849e4300e447d94487684102d9d412e")
        (title (en "@command{guix graph} now supports package
transformations")
               (de "@command{guix graph} unterstützt nun Paketumwandlungen"))
        (body
         (en "The @command{guix graph} command now supports the common package
transformation options (see @command{info \"(guix) Package Transformation
Options\"}).  This is useful in particular to see the effect of the
@option{--with-input} dependency graph rewriting option.")
         (de "Der Befehl @command{guix graph} unterstützt nun die mit anderen
Befehlen gemeinsamen Umwandlungsoptionen (siehe @command{info \"(guix.de)
Paketumwandlungsoptionen\"}).  Sie helfen insbesondere dabei, die Wirkung der
Befehlszeilenoption @option{--with-input} zum Umschreiben des
Abhängigkeitsgraphen zu sehen.")))

 (entry (commit "49af34cfac89d384c46269bfd9388b2c73b1220a")
        (title (en "@command{guix pull} now honors
@file{/etc/guix/channels.scm}")
               (es "Ahora @command{guix pull} tiene en cuenta
@file{/etc/guix/channels.scm}"))
        (body
         (en "The @command{guix pull} command will now read the
@file{/etc/guix/channels.scm} file if it exists and if the per-user
@file{~/.config/guix/channels.scm} is not present.  This allows administrators
of multi-user systems to define site-wide defaults.")
         (es "Ahora la orden @command{guix pull} lee el fichero
@file{/etc/guix/channels.scm} si existe y el fichero personalizable
@file{~/.config/guix/channels.scm} no está presente. Esto permite a quienes
administran sistemas con múltiples usuarias definir valores predeterminados
en el sistema."))))

Each news entry refers to a commit, the commit that introduced the change it documents, and it has a title and body. Those can use Texinfo markup for rich formatting, and translations can be provided directly within the news file.

When guix pull --news runs, it determines which news entries are applicable given the user’s previous Guix instance. The (guix channels) module provides a simple programming interface for that:

(use-modules (guix channels) (srfi srfi-1))

(channel-news-for-commit (first %default-channels)
                         "66b707a7d2325daadeed5ca913637eea3a2628e7"
                         "ac19950507e941b6263f62f4ee4e8934c1b1598e")
⇒ (#<<channel-news-entry> commit: "3e962e59d849e4300e447d94487684102d9d412e" tag: #f title: (("en" . "@command{guix graph} now supports package\ntransformations") …) body: …> #<<channel-news-entry> commit: "49af34cfac89d384c46269bfd9388b2c73b1220a" tag: #f title: (("en" . "@command{guix pull} now honors\n@file{/etc/guix/channels.scm}") …) body: …>)

One thing is quite unusual (one might say “weird” :-)) about this news format: it refers to commit IDs “in-band”. In other words, unlike Git commit logs, which are “out-of-band”, the news file is contained inside the repository that it refers to. Technically, it means that before pushing a news entry, one must make sure it refers to the right commit ID (the news format allows you to refer to tags as well, but one may not want to create tags for every “news-worthy” change). Likewise, rebasing might invalidate commit IDs that appear in the news file. So this whole “in-band” log has drawbacks, but the big win is that it allows us to amend news entries to fix typos, add translations, and so on.

In other news…

Since it was applied a bit more than a month ago, we’ve already put the news mechanism to good use on quite a few occasions: giving users instructions on how to deal with locales after the last glibc upgrade, giving them upgrade info for CVE-2019-18192, telling them about new command-line options, and more.

In parallel, given that reading the mailing lists is akin to “drinking from a fire hose” as they say, Christopher Baines has been thinking about how to provide regular development updates to interested users and developers. Chris announced last week a prototype of a “Guix Weekly News” web site that would aggregate information about package updates automatically extracted from the Guix Data Service, along with manually written updates. It would seem that this service could readily grab info from channel news as well.

What about you, what do you expect in terms of news distribution? Join us on the mailing list and on IRC and let us know!

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.

12 November, 2019 02:00PM by Ludovic Courtès

November 10, 2019

health @ Savannah

GNU Health HMIS 3.6 released !

Dear community:

I am very proud to announce the release of the GNU Health 3.6 series !

This version is the result of many developments and integration of ideas from the community.

We are now 11 years old. We should all be very proud because not only we have built the best Libre Health and Hospital Information System, but we have created a strong, committed and friendly international community around it.

What is new in GNU Health 3.6 series

  • Both GNU Health client and server are now in Python3
  • Remove Python2 support
  • GH HMIS server uses Tryton 5.0 LTS kernel (5 year support)
  • Client is based on Tryton GTK client 5.2
  • Automation on the GH Federation queue management
  • Integration to Orthanc DICOM server
  • Pages of Life models fully integrated with patient evaluation & GH Federation
  • GNU Health camera plugin integrated with the latest OpenCV
  • GH Client uses GI. Removed pygtkcompat.
  • GH Federation HIS has been migrated from MongoDB to PostgreSQL
  • New demo database downloader
  • Thalamus uses now uwsgi as the default WSGI
  • SSL is the default method for Thalamus and the GH Federation

Upgrading from GNU Health 3.4

  • Make a FULL BACKUP your kernel, database and attach directories !!!
  • Follow the instructions on the Wikibooks
  • Read specific instructions found under scripts/upgrade/3.6 of the main source installation tarball, an apply the scripts in the specified order.

Development focus

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

  • The GNU Health Federation Portal
  • The mobile client
  • Interoperability

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

The GNU Health Federation now receives information coming from many health institutions and people from a region or country. The GH Federation portal will allow to manage resources, as well as the main point for analytics and reporting of massive amount of demographics health data generated nationwide. People, health centers and research institutions (eg genomics already can enjoy the benefits from the GNU Health Federation.

The mobile client (MyGNUHealth) development will remain in QT and will be focus on KDE plasma mobile technology, and run in Libre mobile operating systems and devices (such as Pine64). We need fully libre mobile devices if we want to preserve privacy in healthcare.

As far as Interoperability goes, GNU Health is now very interoperable. It uses open coding standards, as well as open formats (XML, JSON, .. ) to exchange messages. We currently have support for read operations in HL7 FHIR for a number of resources. Needless to say, we are open to other open standard communities that are willing to integrate to GNU Health.

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

Happy and Healthy Hacking !

--
Dr. Luis Falcon, M.D.
President, GNU Solidario
GNU Health: Freedom and Equity in Healthcare
https://www.gnuhealth.org
GNUPG Fingerprint :ACBF C80F C891 631C 68AA  8DC8 C015 E1AE 0098 9199

10 November, 2019 10:42PM by Luis Falcon

November 09, 2019

GNUnet News

GNS@ICANN66

GNS@ICANN66

The ICANN Annual General Meeting is concluded. We were invited to join a panel discussion on Emerging Internet Identifier Technologies in order to share our ideas and work on the GNU Name System (GNS).

You can find the presentation on GNS in our video section. The handshake.org project, which proposes a decentralized, blockchain-based governance of the root zone (as opposed to governance by ICANN), joined us on the panel. The full video including questions and answers can be found here.

09 November, 2019 11:00PM

November 08, 2019

libredwg @ Savannah

libredwg-0.9.2 released

This is a minor patch update.
Added the -x,--extnames option to dwglayers for r13-r14 DWGs,
Fixed some more leaks,
Added DICTIONARY.itemhandles[] for r13 and r14,
Added geom utils to some programs: dwg2SVG and dwg2ps,
Added basic POLYLINE_2D and LWPOLYLINE support to dwg2SVG.

Here are the compressed sources:
  http://ftp.gnu.org/gnu/libredwg/libredwg-0.9.2.tar.gz   (9.8MB)
  http://ftp.gnu.org/gnu/libredwg/libredwg-0.9.2.tar.xz   (3.7MB)

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

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

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

Here are the SHA256 checksums:

e80dd6006c3622df76d2a684e3119d32f61c1d522d54922799149f6ab84aada4  libredwg-0.9.2.tar.gz
d4ba88bfd031a0901f6f3ad007ec87f5d9f328fb10d1bce2daf66315625d0364  libredwg-0.9.2.tar.xz

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

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

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

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

and rerun the 'gpg --verify' command.

08 November, 2019 08:32AM by Reini Urban

November 07, 2019

FSF News

Talos II Mainboard and Talos II Lite Mainboard now FSF-certified to Respect Your Freedom

Talos II

BOSTON, Massachusetts, USA -- Thursday, November 7th, 2019 -- The Free Software Foundation (FSF) today awarded Respects Your Freedom (RYF) certification to the Talos II and Talos II Lite mainboards from Raptor Computing Systems, LLC. The RYF certification mark means that these products meet the FSF's standards in regard to users' freedom, control over the product, and privacy.

While these are the first devices from Raptor Computing Systems to receive RYF certification, the FSF has supported their work since 2015, starting with the original Talos crowdfunding effort. Raptor Computing Systems has worked very hard to protect the rights of users.

"From our very first products through our latest offerings, we have always placed a strong emphasis on returning control of computing to the owner of computing devices -- not retaining it for the vendor or the vendor's partners. We hope that with the addition of our modern, powerful, owner-controlled systems to the RYF family, we will help spur on industry adoption of a similar stance from the many silicon vendors required to support modern computing," said Timothy Pearson, Chief Technology Officer, Raptor Computing Systems, LLC.

These two mainboards are the first PowerPC devices to receive certification. Several GNU/Linux distributions endorsed by the FSF are currently working towards offering support for PowerPC platform.

"These certifications represent a new era for the RYF program. Raptor's new boards were designed to respect our rights, and will open up new possibilities for free software users everywhere," said the FSF's executive director, John Sullivan.

The Talos II and Talos II Lite also represent an interesting first in terms of reproducible builds. When two people compile the same code, the resulting object code usually differs slightly because of variables like build timestamps and other differences affecting the object code. Making it so users can independently reproduce exactly the same builds for important free software programs makes it so that anyone can distribute the builds with more certainty that they do not contain hidden malware. For the Talos II, the FSF was able to reproduce the build that is loaded onto the FPGA chip of the board that was tested, and will include the checksum of that build along with the source code we publish.

"We want to congratulate Raptor Engineering on this, and we encourage vendors to ship more reproducible builds, which we will be happy to reproduce as part of the RYF certification," said the FSF's senior system administrator, Ian Kelling.

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

Retailers interested in applying for certification can consult https://ryf.fsf.org/about/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 Raptor Computing Systems, LLC

Raptor Computing Systems, LLC is focused on developing and marketing user-controlled devices.

Media Contacts

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

Raptor Computing Systems, LLC sales@raptorcs.com

Image of Talos II by Raptor Computing Systems, LLC Copyright 2018 licensed under CC-BY-SA 4.0.

07 November, 2019 07:13PM

LibrePlanet returns in 2020 to Free the Future! March 14-15, Boston area

BOSTON, Massachusetts, USA -- Thursday, November 7, 2019 -- The Free Software Foundation (FSF) today announced that registration is open for the twelfth LibrePlanet conference on free software. The annual technology and social justice conference will be held in the Boston area on March 14 and 15, 2020, with the theme "Free the Future." Session proposals will be accepted through November 20.

The FSF invites activists, hackers, law professionals, artists, students, developers, young people, policymakers, tinkerers, newcomers to free software, and anyone looking for technology that respects their freedom to register to attend, and to submit a proposal for a session for LibrePlanet: "Free the Future."

Submissions to the call for sessions are being accepted through Wednesday, November 20, 2019, at 12:00 EST (17:00 UTC).

LibrePlanet provides an opportunity for community activists, domain experts, and people seeking solutions for themselves to come together in order to discuss current issues in technology and ethics.

"LibrePlanet attendees and speakers will be discussing the hot button issues we've all been reading about every day, and their connection to the free software movement. How do you fight Facebook? How do we make software-driven cars safe? How do we stop algorithms from making terrible, unreviewable decisions? How do we enjoy the convenience of mobile phones and digital home assistants without being constantly under surveillance? What is the future of digital currency? Can we have an Internet that facilitates respectful dialogue?" said FSF's executive director, John Sullivan.

The free software community has continuously demanded that users and developers be permitted to understand, study, and alter the software they use, offering hope and solutions for a free technological future. LibrePlanet speakers will display their unique combination of digital knowledge and educational skills in the two day conference, as well as give more insights into their ethical dedication to envision a future rich with free "as in freedom" software and without network services that mistreat their users. The FSF's LibrePlanet 2020 edition is therefore aptly named "Free the Future."

"For each new technological convenience we gain, it seems that we lose even more in the process. To exchange intangible but vital rights to freedom and privacy for the latest new gadget can make the future of software seem bleak," said ZoĂŤ Kooyman, program manager for the FSF. "But there is resistance, and it is within our capabilities to reject this outcome."

Thousands of people have attended LibrePlanet over the years, both in person and remotely. The conference welcomes visitors from up to 15 countries each year, with many more joining online. Hundreds of impressive free software speaker sessions, including keynote talks by Edward Snowden and Cory Doctorow, can be viewed on the conference's MediaGoblin instance, in anticipation of further program announcements.

For those who cannot attend LibrePlanet in person, there are plenty of other ways to participate remotely. The FSF is encouraging free software advocates worldwide to use the tools provided on libreplanet.org to host satellite viewing parties and other events. They also opened applications for scholarships for people around the globe to attend the conference in Boston, and encourage supporters who are able to help others attend by donating to the LibrePlanet travel fund.

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://www.fsf.org and https://www.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.

MEDIA CONTACT

ZoĂŤ Kooyman
Program Manager
Free Software Foundation
+1 (617) 542 5942
campaigns@fsf.org

07 November, 2019 05:10PM

Christopher Allan Webber

Terminal Phase: building a space shooter that runs in your terminal

Yeah you read (and saw, via the above gif) that right! A space shooter! That runs in your terminal! Pew pew pew!

Well it's most of one, anyway. It's a prototype that I built as a test program for Spritely Goblins.

I've satisfied the technical needs I had in building the program; I might still finish it as a game, and it's close enough where making a satisfying game rather than just a short demo is super feasible, but I've decided to see whether or not there's actually enough interest in that at all by leaving that as a milestone on my Patreon. (We're actually getting quite close to meeting it... would be cool if it happened!)

But what am I, a person who is mostly known for work on a federated social web protocol, doing making a game demo, especially for a singleplayer game? Was it just for fun? It turns out it has more to do with my long term plans for the federated social web than it may appear.

And while it would be cool to get something out there that I would be proud of for its entertainment value, in the meanwhile the most interesting aspects of this demo to me are actually the technical ones. I thought I'd walk through what those are in this post, because in a sense it's a preview of some of the stuff ahead in Spritely. (Now that I've written most of this post, I have to add the forewarning that this blogpost wanders a lot, but I hope all the paths it goes down are sufficiently interesting.)

Racket and game development

Before we get to the Spritely stuff, I want to talk about why I think Racket is an underappreciated environment for making games. Well, in a certain sense Racket been advertised for its association with game-making, but in some more obscure ways. Let's review those:

  • Racket has historically been built as an educational teaching-programming environment, for two audiences: middle schoolers, and college freshmen. Both of them to some degree involve using the big-bang "toy" game engine. It is, by default, functional in its design, though you can mix it with imperative constructs. And yet maybe to some that makes it sound like it would be more complicated, but it's very easy to pick up. (DrRacket, Racket's bundled editor, also makes this a lot easier.) If middle schoolers can learn it, so can you.
  • Along those lines, there's a whole book called Realm of Racket that's all about learning to program by making games. It's pretty good!
  • Game studio Naughty Dog has used Racket to build custom in-house tools for their games.
  • Pioneering game developer John Carmack built prototypes for the Oculus Rift using Racket. (It didn't become production code, though John's assessments of Racket's strengths appear to align with my own largely; I was really pleased to see him repost on twitter my blogpost about Racket being an acceptable Python. He did give a caveat, however.)

So, maybe you've already heard about Racket used in a game development context, but despite that I think most people don't really know how to start using Racket as a game development environment. It doesn't help that the toy game engine, big-bang, is slowed down by a lot of dynamic safety checks that are there to help newcomers learn about common errors.

It turns out there are a bunch of really delightful game development tools for Racket, but they aren't very well advertised and don't really have a nice comprehensive tutorial that explains how to get started with them. (I've written up one hastily for a friend; maybe I should polish it up and release it as its own document.) Most of these are written by Racket developer Jay McCarthy, whom I consider to be one of those kind of "mad genius hacker" types. They're fairly lego-like, so here's a portrait of what I consider to be the "Jay McCarthy game development stack":

  • Lux, a functional game engine loop. Really this is basically "big-bang for grown-ups"; the idea is very similar but the implementation is much faster. (It has some weird naming conventions in it though; turns out there's a funny reason for that...)
  • By default Lux ships with a minimal rendering engine based on the Racket drawing toolkit. Combined with (either of) Racket's functional picture combinator libraries (pict or the 2htdp/image library), this can be used to make game prototypes very quickly, but they're still likely to be quite slow. Fortunately, Lux has a clever design by which you can swap out different rendering engines (and input mechanisms) which can compose with it.
  • One of these engines is mode-lambda which has the hilarious tagline of "the best 2d graphics of the 90s, today!" If you're making 2d games, this library is very fast. What's interesting about this library is that it's more or less designed off of the ideas from the Super Nintendo graphics engine (including support for Mode-7 style graphics, the graphic hack that powered games like the Super Nintendo version of Mario Kart). Jay talks about this in his "Get Bonus!" talk from a few years ago. (As a side note, for a while I was confused about Get Bonus's relationship to the rest of the Jay McCarthy stack; at 2018's RacketCon I queried Jay about this and he explained to me that that's more or less the experimental testing grounds for the rest of his libraries, and when the ideas congeal they get factored out. That makes a lot of sense!)
  • Another rendering engine (and useful library in general) is Jay's raart library. This is a functional picture library like pict, but instead of building up raster/vector graphic images, you're building up ascii art. (It turns out that ascii art is a topic of interest for me so I really like raart. Unsurprisingly, this is what's powering Terminal Phase's graphics.)

As I said before, the main problem with these is knowing how to get started. While the reference documentation for each library is quite good, none of them really have a tutorial that show off the core ideas. Fortunately each project does ship with examples in its git repository; I recommend looking at each one. What I did was simply split my editor and type in each example line by line so I could think about what it was doing. But yeah, we really could use a real tutorial for this stuff.

Okay, so 2d graphical and terminal programs are both covered. What about 3d? Well, there's really two options so far:

  • There's a very promising library called Pict3d that does functional 3d combinators. The library is so very cool and I highly, highly recommend you watch the Pict3d RacketCon talk which is hands down one of the coolest videos I've ever seen. If you use DrRacket, you can compose together shapes and not only will they display at the REPL, you can rotate around and view them from different angles interactively. Unfortunately it hasn't seen much love the last few years and it also mostly only provides tools out of the box for very basic geometric primitives. Most people developing 3d games would want to import their meshes and also their skeletal animations and etc etc and Pict3d doesn't really provide any of that yet. I don't think it even has support for textures. It could maybe have those things, but probably needs development help. At the moment it's really optimized for building something with very abstract geometry; a 3d space shooter that resembles the original Star Fox game could be a good fit. (Interestingly my understanding is that Pict3d doesn't really store things as meshes; I think it may store shapes in their abstract math'y form and raytrace on the GPU? I could be wrong about this.)
  • There's also an OpenGL library for Racket but it's very, very low level. (There's also this other OpenGL library but I haven't really looked at it.) However raw OpenGL is so extremely low level that you'll need to build a lot of abstractions on top of it to make it usable for anything.

So that covers the game loop, input, display.

That leaves us with audio and game behavior. I'll admit that I haven't researched audio options sufficiently; rsound seems like a good fit though. (I really need a proper Guix package of this for it to work on my machine for FFI-finding-the-library reasons...)

As for game behavior, that kind of depends on what your game is. When I wrote Racktris I really only had a couple of pieces of state to manage (the grid, where the falling piece was, etc) and it was fairly easy to do it using very basic functional programming constructs (really you're just creating a new version of these objects every time that a tick or input happens). As soon as I tried moving to a game with many independently operating objects doing their own thing, that approach fell apart.

The next thing I tried using was Racket's classes and object system. That was... okay, but it also felt like I was losing out on a lot. Previously I had the pleasant experience that "Woo, yeah! It's all functional!" A functional game engine is nice because returning to a prior snapshot in time is always possible (you can trivially make a game engine where you can rewind time, for instance; great for debugging) and it's much easier to poke and prod at a structure because you aren't changing it, you just are getting it back. Now I lost that feature.

In that conversation I had with Jay at RacketCon 2018, he suggested that I look at his DOS library for game behavior. I won't as quickly recommend this one; it's good for some game designs but the library (particularly the DOS/Win part) is fairly opinionated against objects ("processes") communicating with each other on the same tick; the idea is that each processes only can read what each other wrote on the previous tick. The goal here as I understand it is to eliminate an entire class of bugs and race conditions, but I quickly found that trying to work around the restrictions lead me to creating terrible hacks that were themselves very buggy.

This became really clear to me when I tried to implement a very simple wild west "quick draw" game a-la the Kirby quick draw and Samurai Kirby type games. (All this happened months back, when I was doing the anniversary animation I made earlier this year.) These are very simple games where two players wait for "Draw!" to appear on the screen before they press the button to "fire their gun". Fire first, you win. Fire second, you lose. Fire too early, you lose. Both fire at the same time, you draw. This is a very simple game, but trying to build it on top of DOS/Win (or my DOS/Hurd variant) was extremely hard to do while splitting the judge and players into separate objects. I ended up writing very contorted code that ultimately did communicate on the same tick, but via a layered approach that ended up taking me an hour to track down all the bugs in. I can't imagine scaling it up further.

But DOS had some good ideas, and I got to thinking about how to extend the system to allow for immediate calls, what would it look like? That's when I hit a series of epiphanies which resulted in a big rewrite of the Spritely Goblins codebase (which turned out to make it more useful for programming game behavior in a way that even fits very nicely into the Lux game loop). But I suppose I should really explain the what and why of Spritely Goblins, and how it fits into the larger goals of Spritely.

Terminal Phase and Spritely Goblins and stuff

Spritely Goblins is part of the larger Spritely project. Given Spritely's ambitious goal of "leveling up" the fediverse by extending it into the realm of rich and secure virtual worlds, we have to support distributed programming in a way that assumes a mutually suspicious network. (To get in the right mindset for this, maybe both watch my keynote and Mark Miller's keynote from the ActivityPub conference.) We really want to bake that in at the foundation of our design to build this right.

Thus Spritely Goblins is an asynchronous actor-ish distributed programming system on top of Racket. Kind of like Erlang, but with a focus on object capability security. Most of the good ideas have been taken from the E programming language ("the most interesting programming language you've never heard of"). The only programming environments I would consider viable to build Spritely on top of are ones that have been heavily informed by E, the best other candidate being the stuff Agoric is building on top of Javascript, such as their SwingSet architecture and Jessie (big surprise, since the folks behind E are mostly the folks behind Agoric), or some other more obscure language environments like Monte or, yes, Goblins. (Though, currently despite hanging out in Racket-land, which drinks deeply into the dream of everyone building their own languages, Goblins is just a library. If you want to run code you don't trust though, you'll have to wait until I release Spritely Dungeon, which will be a secure module / language restriction system for Racket. All in due time.)

Spritely Goblins already has some interesting properties:

  • All objects/actors are actually just procedures, waiting to be invoked! All "state" is merely the lexical scope of the enclosed procedure. Upon being invoked, a procedure can both return a value to its invoker (or in asynchronous programming, that fulfills the promise it is listening to) as well as specify what the next version of itself should be (ie, what procedure should be called the next time it handles a message).
  • Objects can only invoke other objects they have a reference to. This, surprisingly, is a sufficient security model as the foundation for everything we need (well, plus sealers/unsealers but I won't get into those here). This is the core observation from Jonathan Rees's A Security Kernel Based on the Lambda Calculus; object capability security is really just everyday programming via argument passing, which pretty much all programmers know how to do. (This applies to modules too, but more on that in a future post.)
  • In most cases, objects live in a "vat". This strange term from the object capability literature really means an event loop. Objects/actors can send messages to other objects in other vats; for the most part it doesn't matter where (on what machine, in what OS process, etc) other objects are when it comes to asynchronous message passing.
  • When asynchronous message passing, information is eventually resolved via promises. (Initially I had promises hidden behind coroutines in the core of the system, but it turns out that opens you to re-entrancy attacks if you aren't very careful. That may come back eventually, but with great care.)
  • While any object can communicate with any other object on any vat via message passing, objects on the same vat can do something that objects on separate vats can't: they can perform immediate calls (ie, something that looks like normal straight-ahead programming code, no coroutines required: you invoke the other object like a procedure, and it returns with a value). It turns out this is needed if you want to implement many interesting transactional things like financial instruments built on top of pure object capabilities. This also is nice for something like a game like Terminal Phase, where we really aren't doing anything asynchronous, are running on a fixed frame rate, and want to be deterministic. But a user should remember that (for important reasons I won't get into in this post) that immediate calls are strictly less universal than asynchronous message passing, since those can only be done between objects in the same vat. It's pleasant that Goblins can support both methods of development, including in an intermixed environment.
  • There is actually a lower level of abstraction than a vat, it turns out! This is something that is different than both E and Agoric's SwingSet I think and maybe even mildly novel; all the core operations (receiving a message, spawning an actor, etc) to operate on the actormap datastructure are exposed to the user. Furthermore, all of these operations are transactional! When using the lower-level actormap, the user receives a new actormap (a "transactormap") which is a delta to the parent actormap (either another transactormap or the root protected weak-hashtable actormap, a "whactormap").
  • This transactionality is really exciting. It means that if something bad happens, we can always roll back to a safe state (or rather, never commit the unsafe state at all). In the default vat, if a message is received and an uncaught exception occurs, the promise is broken, but all the effects caused by interactions from unhandling the message are as if they never occured. (Well that is, as long as we use the "become this procedure" mechanism in Goblins to manage state! If you mutate a variable, you're on your own. A Racket #lang could prevent your users from doing such naughty things if you so care.)
  • It also means that snapshotting an actormap is really easy. Elm used to advertise having a "time traveling debugger" where they showed off Mario running around, and you could reverse time to a previous state. Apparently this was removed but maybe is coming back. Anyway it's trivial to do such a thing with Goblins' actormap, and I built such a (unpublished due to being unpolished) demo.
  • Most users won't work with the actormap though, they'll work with the builtin vat that takes care of all this stuff for them. You can build your own vat, or vat-like tools, though.

Anyway, all the above works and exists. Actors can even speak to each other across vats... though, what's missing so far is the ability to talk to other objects/vats on other machines. That's basically what's next on my agenda, and I know how to do it... it's just a matter of getting the stuff done.

Well, the other thing that's missing is documentation. That's competing for next thing on the agenda.

But why a synchronous game right now?

If the really exciting stuff is the distributed secure programming stuff, why did I stop to do a synchronous non-distributed game on top of Spritely Goblins? Before I plowed ahead, given that the non-distributed aspects still rest on the distributed aspects, I wanted to make sure that the fundamentals of Spritely Goblins were good.

A space shooter is simple enough to implement and using ascii art in a terminal meant I didn't need to spend too much time thinking about graphics (plus it's an interesting area that's under-explored... most terminal-based games are roguelikes or other turn-based games, not real time). Implementing it allowed me to find many areas that could be improved usability-wise in Goblins (indeed, it's been a very active month of development for Goblins). You really know what things are and aren't nice designs by using them.

It's also a great way to identify performance bottlenecks. I calculated that roughly 1 million actor invocations could happen per second on my cheapo laptop... not bad. But that was when the actors didn't update themselves; when it came to the transactional updates, I could only seem to achieve about 65k updates per second. I figured this must be the transactionality, but it turns out it wasn't; the transactionality feature is very cheap. Can you believe that I got a jump from 65k updates per second to 680k updates per second just by switching from a Racket contract to a manual predicate check? (I expected a mild performance hit for using a contract over a manual predicate, but 10x...?) (I also added a feature so you can "recklessly" commit directly to the actormap without transactions... I don't recommend this for all applications, but if you do that you can get up to about 790k updates per second... which means that transactionality adds only about a 17% overhead, which isn't even close to the 10x gap I was seeing.) Anyway, the thing that lead me to looking into that in the first place was doing an experiment where I decided I wanted to see how many objects I could have updating at once. I might not have caught it otherwise. So making a game demo is useful for that kind of thing.

I feel now that I've gotten most of the churn out of that layer of the design out of the way so that I can move forward with the design on the distributed side of things next. That allows me to have tighter focus of things in layers, and I'm happy about that.

What's next?

So with that out of the way, the next task is to work on both the mutually suspicious distributed programming environment and the documentation. I'm not sure in which order, but I guess we'll find out.

I'll do something similar with the distributed programming environment as well... I plan to write something basic which resembles a networked game at this stage to help me ensure that the components work nicely together.

In the meanwhile, Terminal Phase is very close to being a nice game to play, but I'm deciding to leave that as a funding milestone on my Patreon. This is because, as far as my technical roadmap has gone, Terminal Phase has performed the role it needs to play. But it would be fun to have, and I'm sure other people would like to play it as a finished game (heck, I would like to play it as a finished game), but I'd like to know... do people actually care enough about free software games? About this direction of work? Am I on the right track? Not to mention that funding this work is also simply damn hard.

But, at the time of writing we're fairly close, (about 85% of the way there), so maybe it will happen. If it sounds fun to you, maybe pitch in.

But one way or another, I'll have interesting things to announce ahead. Stay tuned here, or follow me on the fediverse or on Twitter if you so prefer.

Onwards and upwards!

07 November, 2019 03:15PM by Christopher Lemmer Webber

remotecontrol @ Savannah

Fitbit is doomed: Here's why everything Google buys turns to garbage | ZDNet

07 November, 2019 01:07PM by Stephen H. Dawson DSL

November 06, 2019

health @ Savannah

GNU Health 3.6RC3 available at community server & demo database

Dear community

The Release Candidate 3 (RC3) for the upcoming GNU Health 3.6 has been installed in the community server.

You can download the latest GTK client, either using pip (from pypi test repository) or the source tarball as explained in the developer's corner chapter.

Login Info:
    Server information : federation.gnuhealth.org:9555
    Database: ghdemo36rc3
    Username: admin
    Password: gnusolidario

Alternatively, the demo database can be downloaded and installed locally via the demo db installer

    $ bash ./install_demo_database 36rc3

Please download and test the follow files:

  • gnuhealth-3.6RC3.tar.gz: Server with the 45 packages
  • gnuhealth-client-3.6RC3.tar.gz  : The GH HMIS GTK client
  • gnuhealth-client-plugins-3.6RC1.tar.gz : The Federation Resource Locator; the GNU Health Camera and the crypto plugin. Note that There have been no changes on the plugins

Remember that all the components of the 3.6 series run in Python 3

You can download the RC tarballs from the development dir:

https://www.gnuhealth.org/downloads/development/unstable/

There is a new section on the Wikibook for the GH Hackers.

https://en.wikibooks.org/wiki/GNU_Health/Developer's_corner

Please check it before you install it. It contains important information on dependencies and other installation instructions.

Happy and healthy hacking !

Luis

06 November, 2019 11:54PM by Luis Falcon

mailutils @ Savannah

Version 3.8

Version 3.8 of GNU mailutils is available for download.

This version fixes important security flow. The maidag utility has been withdrawn and three new programs have been included to provide its functionality: local mail delivery agent mda, LMTP daemon lmtpd, and user mail delivery tool putmail.

See the NEWS file for a detailed discussion of changes.

06 November, 2019 01:05PM by Sergey Poznyakoff

cpio @ Savannah

Version 2.13

GNU cpio version 2.13 is available for download.  This version fixes the following vulnerabilities: CVE-2015-1197, CVE-2016-2037, CVE-2019-14866.

06 November, 2019 08:20AM by Sergey Poznyakoff

November 05, 2019

guile-ncurses @ Savannah

guile-ncurses v3.0 released

I am pleased to announce the release of guile-ncurses 3.0

guile-ncurses is a library for the creation of text user interfaces in the GNU Guile dialect of the Scheme programming language.  It is a wrapper to the ncurses TUI library.  It contains some basic text display and keyboard and mouse input functionality, as well as a menu widget and a form widget.  It also has lower level terminfo and termios functionality.

Because of big changes to data representation, this release may have regressions.  Please report bugs to bug-guile-ncurses@gnu.org

NEWS

- Require Guile 2.2.4 or greater.
- Assume Guile characters are Unicode codepoints.
- New build option --enable-hardening to compile with some hardening options
- New procedures termios-vmin-get and termios-vmin-set!
- New procedures termios-vtime-get and termios-vtime-set!
- New openpt procedure to open pseudoterminals
- eliminate SMOBs and use foreign objects instead
  - This breaks the custom equality procedures, so use new item=?,
    window=?, menu=?

05 November, 2019 10:04PM by Mike Gran

FSF Events

LibrePlanet 2020: Free the Future, March 14-15, Boston area, MA

LibrePlanet 2020: Free the Future, March 14-15, Boston area

What: LibrePlanet is an annual conference hosted by the Free Software Foundation for free software enthusiasts and anyone who cares about the intersection of technology and social justice. LibrePlanet brings together software developers, law and policy experts, activists, students, and computer users to learn skills, celebrate free software accomplishments, and face upcoming challenges to software freedom. Newcomers are always welcome, and LibrePlanet 2020 will feature programming for all ages and experience levels. The theme for LibrePlanet 2020 is "Free the Future."

Where: Boston area

When: Saturday and Sunday, March 14-15, 9:00 - 18:00 EDT

Registration: Registration for this event is now open.

Call for Sessions: LibrePlanet is accepting session proposals until November 20th, 12:00 EST.

Contact: For questions, email the FSF campaigns team campaigns@fsf.org

Have a look at our call for sessions blog post to learn more about the event and about the kinds of sessions we are looking for. We are also hosting an information session every Thursday to answer any questions you have about submitting a proposal for LibrePlanet, until submissions close on November 20. To participate in these information sessions, join us in the #libreplanet Internet Relay Chat (IRC) channel during these time slots:

  • November 7th: 13:00 - 14:00 EST (18:00 UTC)

  • November 14th: 13:00 - 14:00 EST (18:00 UTC)

We have a limited amount of funding to bring conference participants to LibrePlanet from all around the world. You can apply for a scholarship now! The application deadline is Monday, December 2nd, 2019, at 10:00 EST (15:00 UTC). Scholarship recipients will be notified in mid-December.

If you don't need a scholarship, you can help us to free the future, and welcome the broadest possible audience, by making a contribution to support those who do.

We hope to see you at LibrePlanet!

05 November, 2019 08:55PM

GNUnet News

05 November, 2019 10:53AM

Applied Pokology

Array boundaries and closures in Poke

Poke arrays are rather peculiar. One of their seemingly bizarre characteristics is the fact that the expressions calculating their boundaries (when they are bounded) evaluate in their own lexical environment, which is captured. In other words: the expressions denoting the boundaries of Poke arrays conform closures. Also, the way they evaluate may be surprising. This is no capricious.

05 November, 2019 09:53AM

November 04, 2019

remotecontrol @ Savannah

GNU Guix

Managing Servers with GNU Guix: A Tutorial

The outcome of this year's GSoC is a Guile-based programming interface named guix deploy for automatically creating, upgrading, and changing the configurations of machines running the Guix System. The tool is comparable to Ansible or NixOps, but makes use of the system configuration facilities provided by Guix. A post from earlier this summer described an early version of the programming interface, but we're already a few months into autumn, so it's time for guide on how you can use guix deploy in production.

Simple case: managing a home server

If the machine you need to manage is already running the Guix System, it shouldn't be too hard to incorporate guix deploy into your workflow. All that's needed is the <operating-system> declaration you've been passing to guix system reconfigure and some information about the machine (specifically its IP address and architecture). The guix deploy command is invoked with the filename of a "deployment specification" as an argument, whose contents should look something like this:

;; Module imports
(use-modules (gnu) (guix))
(use-service-modules networking ssh)
(use-package-modules bootloaders)

;; Operating system description
(define os
  (operating-system
    (locale "en_US.utf8")
    (timezone "America/New_York")
    (keyboard-layout (keyboard-layout "us" "altgr-intl"))
    (bootloader (bootloader-configuration
                 (bootloader grub-bootloader)
                 (target "/dev/sda")
                 (keyboard-layout keyboard-layout)))
    (file-systems (cons* (file-system
                          (mount-point "/")
                          (device "/dev/sda1")
                          (type "ext4"))
                         %base-file-systems))
    (host-name "alyssas-home-server")
    (users (cons* (user-account
                   (name "alyssa")
                   (comment "Alyssa")
                   (group "users")
                   (home-directory "/home/alyssa")
                   (supplementary-groups
                    '("wheel" "netdev" "audio" "video")))
                  %base-user-accounts))
    (sudoers-file (plain-file "sudoers" "\
root ALL=(ALL) ALL
%wheel ALL=NOPASSWD: ALL\n"))
    (services (append
               (list (service openssh-service-type
                              (openssh-configuration
                               (permit-root-login #t)))
                     (service dhcp-client-service-type))
               %base-services))))

;; List of machines to deploy
(list (machine
       (operating-system os)
       (environment managed-host-environment-type)
       (configuration (machine-ssh-configuration
                       (host-name "alyssa-p-hacker.tld")
                       (system "i686-linux")
                       (identity "/path/to/ssh-key")))))

Even if Scheme isn't your fortĂŠ, parts of this should look familiar if you've used Guix before. The "operating system description" section in particular is something you might use with guix system reconfigure. What's new is the last part: We construct a list containing one machine of the managed-host-environment-type, for which we've specified that os is the operating-system declaration that we want to install on it, and that we can connect to it using the parameters specified by the machine-ssh-configuration.

Let's take a step back for a moment and explain what a machine is. guix deploy aims to support a number of different use-cases, which we abstract as "environment types". We'll see other environment types later in this article, but the general idea is that these environments specify how resources should be "provisioned" or created. For example, an environment type designed for working with a Virtual Private Server (VPS) provider might make calls the provider's API to request a virtual machine before installing the machine's operating-system declaration on it.

The environment type used in this example, managed-host-environment-type, is intended for machines that are already running Guix System and are accessible over SSH. It expects that the configuration field of the machine be an instance of machine-ssh-configuration, whose available fields are described in the manual. This gives guix deploy the information it needs to connect to the machine's SSH daemon.

Running guix deploy with this file would build the "operating system closure" of os -- a bundle of the packages, configuration files, and other dependencies necessary to realize that configuration -- for the architecture specified by system (in this case i686-linux), send it over SSH to alyssa-p-hacker.tld, and then remotely "activate" the configuration by creating a new system generation and upgrading running services. Sweet! Upgrading our single server setup has been reduced to an endeavour involving just over a dozen keystrokes.

More advanced case: managing a virtual private server deployment

One server not cutting it for you? guix deploy can still help. Suppose we run a web service that we'd like to split up across multiple machines for performance reasons.

(define %forum-server-count 4)

(define (forum-server n)
  (operating-system
    (host-name (format #f "forum-server-~a" n))
    ...
    (services (append (list (service httpd-service-type
                                     (httpd-configuration
                                      ...)))
                      %base-services))))

(map (lambda (n)
       (machine
        (system (forum-server n))
        (environment digital-ocean-environment-type)
        (configuration (digital-ocean-configuration
                        (region "nyc3")
                        (size "s-1vcpu-1gb")
                        (enable-ipv6 #t)))))
     (iota %forum-server-count))

This example isn't as concrete as the first one; I'm intentionally omitting parts of the configuration to make the example clearer. Here, we automate the creation of %forum-server-count Digital Ocean "droplets" in their NYC3 region by creating a list of 4 machines.

Assuming that the environment variable GUIX_DIGITAL_OCEAN_TOKEN is properly set, running guix deploy with this file will do much of the same as the previous example. The difference is that four virtual machines will be automatically created on Digital Ocean.

One important thing to note about the digital-ocean-environment-type is that, currently, it does not automatically clean up unused virtual machines. If you change something in the deployment specification and run guix deploy again, the virtual machines from the previous deployment will remain until you destroy them yourself.

A quick peek into the internals of digital-ocean-environment-type

It would be an overstatement to say that the process of implementing a new environment type is easy, but a fair amount of the work has already been done for you. We'll use the definition of digital-ocean-environment-type as an example.

(define digital-ocean-environment-type
  (environment-type
   (machine-remote-eval digital-ocean-remote-eval)
   (deploy-machine      deploy-digital-ocean)
   (roll-back-machine   roll-back-digital-ocean)
   (name                'digital-ocean-environment-type)
   (description         "Provisioning of \"droplets\": virtual machines
 provided by the Digital Ocean virtual private server (VPS) service.")))

The environment-type record specifies a small amount of metadata (name and description), as well as the names of three procedures: one for remotely evaluating a G-Expression on the host (machine-remote-eval), one for deploying an operating-system declaration to the host, and one for rolling the host back one generation.

This might sound like a lot, but the pattern for these high-level environment types is to somehow obtain a machine running Guix System, set up an SSH daemon, and then delegate to managed-host-environment-type. digital-ocean-remote-eval is a pretty good example of this:

(define (digital-ocean-remote-eval target exp)
  "Internal implementation of 'machine-remote-eval' for MACHINE instances with
an environment type of 'digital-ocean-environment-type'."
  (mlet* %store-monad ((name (droplet-name target))
                       (network -> (droplet-public-ipv4-network name))
                       (address -> (hash-ref network "ip_address"))
                       (ssh-key -> (digital-ocean-configuration-ssh-key
                                    (machine-configuration target)))
                       (delegate -> (machine
                                     (inherit target)
                                     (environment managed-host-environment-type)
                                     (configuration
                                      (machine-ssh-configuration
                                       (host-name address)
                                       (identity ssh-key)
                                       (system "x86_64-linux"))))))
    (machine-remote-eval delegate exp)))

As you can see, you could reasonably go about implementing an environment type without ever having to learn what a G-Expression is. Here, droplet-name derives the name of the droplet from the machine's operating-system declaration, the information necessary to connect to the droplet is found using droplet-public-ipv4-network, and that's used to create machine of managed-host-environment-type.

In conclusion

I sincerely hope that guix deploy proves to be a useful to anyone dealing with system administration or software development. Transactional upgrades should provide peace of mind to those managing servers (it's worth noting that few existing tools are capable of recovering from failed deployments), and I believe that procedurally-generated deployment configurations could very well be the future of distribution for software such as web services: Imagine if setting up a Mastodon instance were as easy as downloading a Scheme file and handing it off to guix deploy. The ease of writing code that generates code isn't the only benefit of using Guile for something like this. Guile is a general-purpose programming language, so more advanced tooling can reasonably be built atop guix deploy. A GTK or Emacs DevOps interface, perhaps? (If that idea sounds outlandish, consider that the latter has already happened for the package management interface.)

It's been a great summer working alongside everyone in the Guix community. guix deploy is brand new (and a little unstable!), but we've had enthusiastic adoption by several on the mailing lists who were quick to report any issues they found. I'd like to thank everyone on the #guix IRC channel and the mailing lists who got me up to speed with the code, answered my questions, gave feedback when I submitted my patches, and put guix deploy under the pressure of use in production. And of course, I want to thank my mentors Christopher Lemmer Webber and David Thompson. I had to make some hard design decisions, but this was made easier thanks to the guidance of two experienced Guix veterans.

Oh, and this isn't a goodbye. I really feel I've found my place as a Guix contributor, and I can't wait to see what the future will bring for guix deploy. Catch ya on the mailing lists!

Editor's note

Thank you for all of your hard work, Jakob!

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.

04 November, 2019 03:00PM by Jakob L. Kreuze

October 29, 2019

GNUnet News

GNUnet 0.11.8

GNUnet 0.11.8 released

We are pleased to announce the release of GNUnet 0.11.8.
This is a hotfix release for 0.11.7. As always: 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.8 release is still only suitable for early adopters with some reasonable pain tolerance.

Download links

gnunet-fuse and gnunet-gtk were not released again, as there were no changes and the 0.11.0/0.11.7 versions are expected to continue to work fine with gnunet-0.11.8. The GPG key used to sign is: A88C8ADD129828D7EAC02E52E22F9BBFEE348588

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/

Noteworthy changes in 0.11.8 (since 0.11.7)

  • GNS Portability fixes.
  • PQ: Fixed build with postgresql plugin. (Regression introduces as part of #5733)

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.
  • 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, Daniel Golle.

29 October, 2019 11:00PM

October 28, 2019

libredwg @ Savannah

libredwg-0.9.1 released

Only minor bugfixes.

More here: https://www.gnu.org/software/libredwg/ and http://git.savannah.gnu.org/cgit/libredwg.git/tree/NEWS

Here are the compressed sources:
  http://ftp.gnu.org/gnu/libredwg/libredwg-0.9.1.tar.gz   (11MB)
  http://ftp.gnu.org/gnu/libredwg/libredwg-0.9.1.tar.xz   (4.3MB)

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

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

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

Here are the SHA256 checksums:
767d6300e6781e523a013c02296f22133481e52107933c5516a55237f400721a  libredwg-0.9.1.tar.gz
7563a923a9f1846a0cc122ae59e8306034a04b8b85ed32e3640658f7d3c81f19  libredwg-0.9.1.tar.xz

[*] Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact.  First, be sure to download both the .sig file and the corresponding tarball.  Then, run a command like this:
  gpg --verify libredwg-0.9.1.tar.gz.sig
If that command fails because you don't have the required public key, then run this command to import it:
  gpg --keyserver keys.gnupg.net --recv-keys B4F63339E65D6414
and rerun the 'gpg --verify' command.

28 October, 2019 11:22AM by Reini Urban

October 26, 2019

GNUnet News

GNUnet 0.11.7

GNUnet 0.11.7 released

We are pleased to announce the release of GNUnet 0.11.7.
This is a bugfix release for 0.11.6, fixing a lot of minor bugs, improving stability and code quality. Further, win32 support was removed for reasons you may read below. In this release, we again improved the webpage in general and updated our documentation. As always: 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.7 release is still only suitable for early adopters with some reasonable pain tolerance.

Download links

gnunet-fuse is 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.7. The GPG key used to sign is: A88C8ADD129828D7EAC02E52E22F9BBFEE348588

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/

Noteworthy changes in 0.11.7 (since 0.11.6)

  • ARM: GNUnet CLI tools are now able to detect if gnunet(-arm) is not running and will exit with a warning (before the command would just hang and wait for GNUnet to be started). #5906
  • win32 and mingw support were dropped, which resulted in a significant number of lines of code to be gone. The code has been unmaintained in our code base for many years and there are no known users. For details and further reasons refer to the discussion in our archives.
  • Removal of plibc, win32 and mingw support means you can now compile gnunet without requiring a Cxx compiler (you just need a C compiler). #5877
  • REST: The new config endpoints can now be used to read and write the GNUnet config. #5808
  • REST: The service is not started per user in multiuser setups.
  • REST: Added tests for namestore and GNS. #5638
  • re:claimID / OIDC: Now supports PKCE. #5807
  • SUID binary detection mechanisms implemented to improve compatiblity with some distributions.
  • CREDENTIAL subsystem reworked and renamed to ABD (attribute-based delegation).
  • Minor TRANSPORT fixes and NAT changes.
  • GNS prepared code for LSD001 changes. #5920
  • Documentation, comments and code quality was improved.

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.
  • 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: Martin Schanzenbach, ng0, Christian Grothoff, Alexia Pagkopoulou, Andreas Ebner, Corvus Corax, xrs and t3sserakt.

26 October, 2019 10:00PM

health @ Savannah

GNU Health HMIS 3.6 Release Candidate 2 ready for test

Dear developers

GNU Health 3.6RC2 is out !

Please download and test the follow files:

  • gnuhealth-3.6RC2.tar.gz: Server with the 45 packages
  • gnuhealth-client-3.6RC2.tar.gz  : The GH HMIS GTK client
  • gnuhealth-client-plugins-3.6RC1.tar.gz : The Federation Resource Locator; the GNU Health Camera and the crypto plugin. Note that There have been no changes on the plugins

Remember that all the components of the 3.6 series run in Python 3

You can download the RC tarballs from the development dir:

https://www.gnuhealth.org/downloads/development/unstable/

There is a new section on the Wikibook for the GH Hackers.

https://en.wikibooks.org/wiki/GNU_Health/Developer's_corner

Please check it before you install it. It contains important information on dependencies and other installation instructions.

Happy and healthy hacking !

Luis

26 October, 2019 05:41PM by Luis Falcon

Sylvain Beucler

More GNU Planet feeds from Savannah

planet.gnu.org logo

GNU Planet now automatically fetches news feeds from 'www.gnu.org portions' and 'www.gnu.org translation teams' Savannah projects.

26 October, 2019 04:07PM

October 25, 2019

GNU Guix

Guix Profiles in Practice

Note: An updated version of this article is available in the brand new cookbook.

Guix provides a very useful feature that may be quite foreign to newcomers: profiles. They are a way to group package installations together and all users on the same system are free to use as many profiles as they want.

Whether you're a developer or not, you may find that multiple profiles bring you great power and flexibility. While they shift the paradigm somewhat compared to traditional package managers, they are very convenient to use once you've understood how to set them up.

If you are familiar with Python's virtualenv, you can think of a profile as a kind of universal virtualenv that can hold any kind of software whatsoever, not just Python software. Furthermore, profiles are self-sufficient: they capture all the runtime dependencies which guarantees that all programs within a profile will always work at any point in time.

Multiple profiles have many benefits:

  • Clean semantic separation of the various packages a user needs for different contexts.

  • Multiple profiles can be made available into the environment either on login or within a dedicated shell.

  • Profiles can be loaded on demand. For instance, the user can use multiple shells, each of them running different profiles.

  • Isolation: Programs from one profile will not use programs from the other, and the user can even install different versions of the same programs to the two profiles without conflict.

  • Deduplication: Profiles share dependencies that happens to be the exact same. This makes multiple profiles storage-efficient.

  • Reproducible: when used with declarative manifests, a profile can be fully specified by the Guix commit that was active when it was set up. This means that the exact same profile can be set up anywhere, anytime, with just the commit information. See section “Reproducible profiles” below.

  • Easier upgrades and maintenance: Multiple profiles make it easy to keep package listings at hand and make upgrades completely friction-less.

Concretely, here follows some typical profiles:

  • The dependencies of a project you are working on.

  • Your favourite programming language libraries.

  • Laptop-specific programs (like powertop) that you don't need on a desktop.

  • TeXlive (this one can be really useful when you need to install just one package for this one document you've just received over email).

  • Games.

Let's dive in the set up!

Basic setup with manifests

A Guix profile can be set up via a so-called manifest specification that looks like this:

(specifications->manifest
  '("package-1"
    ;; Version 1.3 of package-2.
    "package-2@1.3"
    ;; The "lib" output of package-3.
    "package-3:lib"
    ; ...
    "package-N"))

See (guix) Invoking guix package for the syntax details.

We can create a manifest specification per profile and install them this way:

GUIX_EXTRA_PROFILES=$HOME/.guix-extra-profiles
mkdir -p "$GUIX_EXTRA_PROFILES"/my-project # if it does not exist yet
guix package --manifest=/path/to/guix-my-project-manifest.scm --profile="$GUIX_EXTRA_PROFILES"/my-project/my-project

Here we set an arbitrary variable GUIX_EXTRA_PROFILES to point to the directory where we will store our profiles in the rest of this article.

Placing all your profiles in a single directory, with each profile getting its own sub-directory, is somewhat cleaner. This way, each sub-directory will contain all the symlinks for precisely one profile. Besides, "looping over profiles" becomes obvious from any programming language (e.g. a shell script) by simply looping over the sub-directories of $GUIX_EXTRA_PROFILES.

Note that it's also possible to loop over the output of

guix package --list-profiles

although you'll probably have to filter out ~/.config/guix/current.

To enable all profiles on login, add this to your ~/.bash_profile (or similar):

for i in $GUIX_EXTRA_PROFILES/*; do
    profile=$i/$(basename "$i")
    if [ -f "$profile"/etc/profile ]; then
        GUIX_PROFILE="$profile"
        . "$GUIX_PROFILE"/etc/profile
    fi
    unset profile
done

Note to Guix System users: the above reflects how your default profile ~/.guix-profile is activated from /etc/profile, that latter being loaded by ~/.bashrc by default.

You can obviously choose to only enable a subset of them:

for i in "$GUIX_EXTRA_PROFILES"/my-project-1 "$GUIX_EXTRA_PROFILES"/my-project-2; do
    profile=$i/$(basename "$i")
    if [ -f "$profile"/etc/profile ]; then
        GUIX_PROFILE="$profile"
        . "$GUIX_PROFILE"/etc/profile
    fi
    unset profile
done

When a profile is off, it's straightforward to enable it for an individual shell without "polluting" the rest of the user session:

GUIX_PROFILE="path/to/my-project" ; . "$GUIX_PROFILE"/etc/profile

The key to enabling a profile is to source its etc/profile file. This file contains shell code that exports the right environment variables necessary to activate the software contained in the profile. It is built automatically by Guix and meant to be sourced. It contains the same variables you would get if you ran:

guix package --search-paths=prefix --profile=$my_profile"

Once again, see (guix) Invoking guix package for the command line options.

To upgrade a profile, simply install the manifest again:

guix package -m /path/to/guix-my-project-manifest.scm -p "$GUIX_EXTRA_PROFILES"/my-project/my-project

To upgrade all profiles, it's easy enough to loop over them. For instance, assuming your manifest specifications are stored in ~/.guix-manifests/guix-$profile-manifest.scm, with $profile being the name of the profile (e.g. "project1"), you could do the following in Bourne shell:

for profile in "$GUIX_EXTRA_PROFILES"/*; do
  guix package --profile="$profile" --manifest="$HOME/.guix-manifests/guix-$profile-manifest.scm"
done

Each profile has its own generations:

guix package -p "$GUIX_EXTRA_PROFILES"/my-project/my-project --list-generations

You can roll-back to any generation of a given profile:

guix package -p "$GUIX_EXTRA_PROFILES"/my-project/my-project --switch-generations=17

Required packages

Activating a profile essentially boils down to exporting a bunch of environmental variables. This is the role of the etc/profile within the profile.

Note: Only the environmental variables of the packages that consume them will be set.

For instance, MANPATH won't be set if there is no consumer application for man pages within the profile. So if you need to transparently access man pages once the profile is loaded, you've got two options:

  • Either export the variable manually, e.g.

    export MANPATH=/path/to/profile${MANPATH:+:}$MANPATH
  • Or include man-db to the profile manifest.

The same is true for INFOPATH (you can install info-reader), PKG_CONFIG_PATH (install pkg-config), etc.

Default profile

What about the default profile that Guix keeps in ~/.guix-profile?

You can assign it the role you want. Typically you would install the manifest of the packages you want to use all the time.

Alternatively, you could keep it "manifest-less" for throw-away packages that you would just use for a couple of days. This way makes it convenient to run

guix install package-foo
guix upgrade package-bar

without having to specify the path to a profile.

The benefits of manifests

Manifests are a convenient way to keep your package lists around and, say, to synchronize them across multiple machines using a version control system.

A common complaint about manifests is that they can be slow to install when they contain large number of packages. This is especially cumbersome when you just want get an upgrade for one package within a big manifest.

This is one more reason to use multiple profiles, which happen to be just perfect to break down manifests into multiple sets of semantically connected packages. Using multiple, small profiles provides more flexibility and usability.

Manifests come with multiple benefits. In particular, they ease maintenance:

  • When a profile is set up from a manifest, the manifest itself is self-sufficient to keep a "package listing" around and reinstall the profile later or on a different system. For ad-hoc profiles, we would need to generate a manifest specification manually and maintain the package versions for the packages that don't use the default version.

  • guix package --upgrade always tries to update the packages that have propagated inputs, even if there is nothing to do. Guix manifests remove this problem.

  • When partially upgrading a profile, conflicts may arise (due to diverging dependencies between the updated and the non-updated packages) and they can be annoying to resolve manually. Manifests remove this problem altogether since all packages are always upgraded at once.

  • As mentioned above, manifests allow for reproducible profiles, while the imperative guix install, guix upgrade, etc. do not, since they produce different profiles every time even when they hold the same packages. See the related discussion on the matter.

  • Manifest specifications are usable by other guix commands. For example, you can run guix weather -m manifest.scm to see how many substitutes are available, which can help you decide whether you want to try upgrading today or wait a while. Another example: you can run guix pack -m manifest.scm to create a pack containing all the packages in the manifest (and their transitive references).

  • Finally, manifests have a Scheme representation, the <manifest> record type. They can be manipulated in Scheme and passed to the various Guix APIs.

It's important to understand that while manifests can be used to declare profiles, they are not strictly equivalent: profiles have the side effect that they "pin" packages in the store, which prevents them from being garbage-collected and ensures that they will still be available at any point in the future.

Let's take an example:

  1. We have an environment for hacking on a project for which there isn't a Guix package yet. We build the environment using a manifest, and then run guix environment -m manifest.scm. So far so good.

  2. Many weeks pass and we have run a couple of guix pull in the mean time. Maybe a dependency from our manifest has been updated; or we may have run guix gc and some packages needed by our manifest have been garbage-collected.

  3. Eventually, we set to work on that project again, so we run guix environment -m manifest.scm. But now we have to wait for Guix to build and install stuff!

Ideally, we could spare the rebuild time. And indeed we can, all we need is to install the manifest to a profile and use GUIX_PROFILE=/the/profile; . "$GUIX_PROFILE"/etc/profile as explained above: this guarantees that our hacking environment will be available at all times.

Security warning: While keeping old profiles around can be convenient, keep in mind that outdated packages may not have received the latest security fixes.

Reproducible profiles

To reproduce a profile bit-for-bit, we need two pieces of information:

  • a manifest,
  • a Guix channel specification.

Indeed, manifests alone might not be enough: different Guix versions (or different channels) can produce different outputs for a given manifest.

You can output the Guix channel specification with guix describe --format=channels. Save this to a file, say channel-specs.scm.

On another computer, you can use the channel specification file and the manifest to reproduce the exact same profile:

GUIX_EXTRA_PROFILES=$HOME/.guix-extra-profiles
GUIX_EXTRA=$HOME/.guix-extra

mkdir "$GUIX_EXTRA"/my-project
guix pull --channels=channel-specs.scm --profile "$GUIX_EXTRA/my-project/guix"

mkdir -p "$GUIX_EXTRA_PROFILES/my-project"
"$GUIX_EXTRA"/my-project/guix/bin/guix package --manifest=/path/to/guix-my-project-manifest.scm --profile="$GUIX_EXTRA_PROFILES"/my-project/my-project

It's safe to delete the Guix channel profile you've just installed with the channel specification, the project profile does not depend on it.

Special thanks

Chris Marusich and Simon Tournier for their thorough feedback.

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.

25 October, 2019 12:15PM by Pierre Neidhardt

Applied Pokology

Endianness in Poke - And a little nice hack

Byte endianness is an important aspect of encoding data. As a good binary editor poke provides support for both little and big endian, and will soon acquire the ability to encode exotic endianness like PDP endian. Endianness control is integrated in the Poke language, and is designed to be easily used in type descriptions. Let's see how.

25 October, 2019 12:00AM

October 22, 2019

www @ Savannah

No radical changes in the GNU Project

Chief GNUisance Richard Stallman announces there will be no radical changes in the GNU Project:

From:         Richard Stallman
Subject:         No radical changes in GNU Project
Date:         Tue, 08 Oct 2019 16:48:23 -0400

As Chief GNUisance, I'd like to reassure the community
that there won't be any radical changes in the GNU Project's
goals, principles and policies.

I would like to make incremental changes in how some decisions are
made, because I won't be here forever and we need to ready others to
make GNU Project decisions when I can no longer do so.  But these
won't lead to unbounded or radical changes.

--
Dr Richard Stallman
Founder, Free Software Foundation (https://gnu.org, https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

22 October, 2019 07:33PM by Dora Scilipoti

GNU Kind Communications Guidelines

Through the GNU Kind Communications Guidelines the GNU Project encourages the community to communicate in ways that are friendly, welcoming and kind.

by Richard Stallman

The GNU Project encourages contributions from anyone who wishes to advance the development of the GNU system, regardless of gender, race, ethnic group, physical appearance, religion, cultural background, and any other demographic characteristics, as well as personal political views.

People are sometimes discouraged from participating in GNU development because of certain patterns of communication that strike them as unfriendly, unwelcoming, rejecting, or harsh. This discouragement particularly affects members of disprivileged demographics, but it is not limited to them. Therefore, we ask all contributors to make a conscious effort, in GNU Project discussions, to communicate in ways that avoid that outcome—to avoid practices that will predictably and unnecessarily risk putting some contributors off.

These guidelines suggest specific ways to accomplish that goal.

Please assume other participants are posting in good faith, even if you disagree with what they say. When people present code or text as their own work, please accept it as their work. Please do not criticize people for wrongs that you only speculate they may have done; stick to what they actually say and actually do.

Please think about how to treat other participants with respect, especially when you disagree with them. For instance, call them by the names they use, and honor their preferences about their gender identity[1].

Please do not take a harsh tone towards other participants, and especially don't make personal attacks against them. Go out of your way to show that you are criticizing a statement, not a person.

Please recognize that criticism of your statements is not a personal attack on you. If you feel that someone has attacked you, or offended your personal dignity, please don't “hit back” with another personal attack. That tends to start a vicious circle of escalating verbal aggression. A private response, politely stating your feelings as feelings, and asking for peace, may calm things down. Write it, set it aside for hours or a day, revise it to remove the anger, and only then send it.

Please avoid statements about the presumed typical desires, capabilities or actions of some demographic group. They can offend people in that group, and they are always off-topic in GNU Project discussions.

Please be especially kind to other contributors when saying they made a mistake. Programming means making lots of mistakes, and we all do so—this is why regression tests are useful. Conscientious programmers make mistakes, and then fix them. It is helpful to show contributors that being imperfect is normal, so we don't hold it against them, and that we appreciate their imperfect contributions though we hope they follow through by fixing any problems in them.

Likewise, be kind when pointing out to other contributors that they should stop using certain nonfree software. For their own sake, they ought to free themselves, but we welcome their contributions to our software packages even if they don't do that. So these reminders should be gentle and not too frequent—don't nag.

By contrast, to suggest that others use nonfree software opposes the basic principles of GNU, so it is not allowed in GNU Project discussions.

Please respond to what people actually said, not to exaggerations of their views. Your criticism will not be constructive if it is aimed at a target other than their real views.

If in a discussion someone brings up a tangent to the topic at hand, please keep the discussion on track by focusing on the current topic rather than the tangent. This is not to say that the tangent is bad, or not interesting to discuss—only that it shouldn't interfere with discussion of the issue at hand. In most cases, it is also off-topic, so those interested ought to discuss it somewhere else.

If you think the tangent is an important and pertinent issue, please bring it up as a separate discussion, with a Subject field to fit, and consider waiting for the end of the current discussion.

Rather than trying to have the last word, look for the times when there is no need to reply, perhaps because you already made the relevant point clear enough. If you know something about the game of Go, this analogy might clarify that: when the other player's move is not strong enough to require a direct response, it is advantageous to give it none and instead move elsewhere.

Please don't argue unceasingly for your preferred course of action when a decision for some other course has already been made. That tends to block the activity's progress.

If other participants complain about the way you express your ideas, please make an effort to cater to them. You can find ways to express the same points while making others more comfortable. You are more likely to persuade others if you don't arouse ire about secondary things.

Please don't raise unrelated political issues in GNU Project discussions, because they are off-topic. The only political positions that the GNU Project endorses are (1) that users should have control of their own computing (for instance, through free software) and (2) supporting basic human rights in computing. We don't require you as a contributor to agree with these two points, but you do need to accept that our decisions will be based on them.

By making an effort to follow these guidelines, we will encourage more contribution to our projects, and our discussions will be friendlier and reach conclusions more easily.

Footnote

[1] Honoring people's preferences about gender identity includes not referring to them in ways that conflict with that identity. For instance, not to use pronouns for them that conflict with it. There are several ways to avoid that; one way is to use gender-neutral pronouns, since they don't conflict with any possible gender identity. One choice is singular use of “they,” “them” and “their.” Another choice uses the gender-neutral singular pronouns, “person,” “per” and “pers,” which are used in Information for Maintainers of GNU Software. Other gender-neutral pronouns have also been used in English.

22 October, 2019 07:09PM by Dora Scilipoti

October 21, 2019

parallel @ Savannah

GNU Parallel 20191022 ('Driving IT') released [stable]

GNU Parallel 20191022 ('Driving IT') [stable] has been released. It is available for download at: http://ftpmirror.gnu.org/parallel/

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

GNU Parallel is 10 years old next 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:

  I've said it before: The command line program GNU Parallel is a godsend.
    -- Jo Chr. Oterhals @oterhals@twitter

New in this release:

  • --tee will use --output-error=warn-nopipe if supported by tee.
  • 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.

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

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

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

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

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

You can install GNU Parallel in just 10 seconds with:

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

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

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

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

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

If you like GNU Parallel:

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

If you use programs that use GNU Parallel for research:

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

If GNU Parallel saves you money:

About GNU SQL

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

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

When using GNU SQL for a publication please cite:

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

About GNU Niceload

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

21 October, 2019 07:08PM by Ole Tange

Applied Pokology

Styled output in Poke programs

I just committed support for styling in printf. Basically, it uses the libtextstyle approach of having styling classes that the user can customize in a .css file.

21 October, 2019 12:00AM

October 19, 2019

GNUnet News

GNUnet invited to ICANN Panel

GNUnet project invited to ICANN66

We are delighted to announce that ICANN has invited the GNUnet project to speak at the next ICANN Annual General Meeting. We have been invited to join a panel discussion on Emerging Internet Identifier Technologies in order to share our ideas and work on the GNU Name System (GNS). ICANN generously offered to cover travel and accomodation.

The meeting will take place in Montreal between 2 - 7 November. The panel will tentatively be help on November 6th.

UPDATE: The panel is on Tueday, November 5th 13:30 EDT with the possibility of remote participation: Link

19 October, 2019 10:00PM

Parabola GNU/Linux-libre

[From Arch] Required update to recent libarchive

The compression algorithm zstd brings faster compression and decompression, while maintaining a compression ratio comparable with xz. This will speed up package installation with pacman, without further drawbacks.

The imminent release of pacman 5.2 brings build tools with support for compressing packages with zstd. To install these packages you need libarchive with support for zstd, which entered the repositories in September 2018. In order for zstd compressed packages to be distributed, we require all users to have updated to at least libarchive 3.3.3-1. You have had a year, so we expect you already did update. Hurry up if you have not.

If you use custom scripts make sure these do not rely on hardcoded file extensions. The zstd package file extension will be .pkg.tar.zst.

19 October, 2019 02:27PM by David P.

remotecontrol @ Savannah

Report: Home builders ditch Nest products after Google takeover

19 October, 2019 12:28PM by Stephen H. Dawson DSL

October 18, 2019

Applied Pokology

Dealing with alternatives - Unions in Poke

The Poke type definitions can be seen as a sort of declarative specifications for decoding and encoding procedures. You specify the structure of the data you want to operate on, and poke uses that information to automatically decode and encode the data for you. Under this perspective, struct types correspond to sequences of instructions, array types to repetitions (or loops), and union types to conditionals.

18 October, 2019 12:00AM

October 15, 2019

Gary Benson

Building GDB on a freshly installed machine FAQ

So you just installed Fedora, RHEL or CentOS and now you want to build GDB from source.

  1. How do you make sure everything you need to build it is installed?
    # dnf builddep gdb
  2. Did it say, No such command: builddep? Do this, then try again:
    # dnf install dnf-plugins-core
  3. Did it say, dnf: command not found…? You’re using yum, try this:
    # yum-builddep gdb
  4. Did it say, yum-builddep: command not found…? Do this, then try again:
    # yum install yum-utils

Thank you, you’re welcome.

15 October, 2019 01:35PM by gbenson

October 11, 2019

Python hacking

Python‘s had this handy logging module since July 2003. A lot of things use it, so if you’re trying to understand or debug some Python code then a handy snippet to insert somewhere is:

import logging
logging.basicConfig(level=1)

Those two lines cause all loggers to log everything to the console. Check out the logging.basicConfig docs to see what else you could do.

11 October, 2019 12:06PM by gbenson

parted @ Savannah

parted-3.3 released [stable]

Parted 3.3 has been released.  This release includes many bug fixes and new features.

Here is Parted's home page:

    http://www.gnu.org/software/parted/

For a summary of all changes and contributors, see:
  https://git.savannah.gnu.org/cgit/parted.git/log/?h=v3.3

or run this command from a git-cloned parted directory:
  git shortlog v3.2..v3.3 (appended below)

Here are the compressed sources and a GPG detached signature[*]:
  http://ftp.gnu.org/gnu/parted/parted-3.3.tar.xz
  http://ftp.gnu.org/gnu/parted/parted-3.3.tar.xz.sig

Use a mirror for higher download bandwidth:
  http://ftpmirror.gnu.org/parted/parted-3.3.tar.xz
  http://ftpmirror.gnu.org/parted/parted-3.3.tar.xz.sig

[*] 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 parted-3.3.tar.xz.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 117E8C168EFE3A7F

and rerun the 'gpg --verify' command.

This release was bootstrapped with the following tools:
  Autoconf 2.69
  Automake 1.16.1
  Gettext 0.19.8.1
  Gnulib commit 6430babe47ece6953cf18ef07c1d8642c8588e89
  Gperf 3.1

NEWS

A considerable number of patches have been made since the last release, see the git log if you want all the gory details.

A huge thank you to everyone who has contributed to this release.

================================================================
Here is a log of the commits since parted 3.2

A. Wilcox (1):
      libparted: Fix endian bug in bsd.c

Alexander Todorov (3):
      tests: Fall back to C.UTF-8 if no en_US.utf8 available
      merge HACKING and README-hacking
      Fwd: [PATCH 2/2] add verbose test documentation

Amarnath Valluri (3):
      UI: Avoid memory leaks.
      libparted: Fix memory leaks
      libparted: Fix possible memory leaks

Arnout Vandecappelle (Essensium/Mind) (1):
      libparted/labels: link with libiconv if needed

Arvin Schnell (1):
      libparted: set swap flag on GPT partitions

Brian C. Lane (73):
      tests: Change minimum size to 256MiB
      tests: Add a test for device-mapper partition sizes
      libparted: device mapper uses 512b sectors
      Update manpage NAME so whatis will work
      doc: Fix url for LWN article
      tests: Make sure the extended partition length is correct (#1135493)
      libparted: BLKPG_RESIZE_PARTITION uses bytes, not sectors (#1135493)
      parted: Fix crash with name command and no disklabel (#1226067)
      libparted: Stop converting . in sys path to /
      libparted: Fix misspelling in hfs exception string
      libparted: Use read only when probing devices on linux (#1245144)
      tests: Use wait_for_dev_to_ functions
      Add libparted-fs-resize.pc
      docs: Add list of filesystems for fs-type (#1311596)
      parted: Display details of partition alignment failure (#726856)
      libparted: Remove fdasd geometry code from alloc_metadata (#1244833)
      libparted: Fix probing AIX disks on other arches
      tests: t3310-flags.sh skip pc98 when sector size != 512
      tests: Add udevadm settle to wait_for_ loop (#1260664)
      tests: Add wait to t9042 (#1257415)
      tests: Fix t1700 failing on a host with a 4k xfs filesystem (#1260664)
      doc: Cleanup mkpart manpage entry (#1183077)
      doc: Add information about quoting
      tests: Set optimal blocks to 64 for scsi_debug devices
      partprobe: Open the device once for probing
      tests: Stop timing t9040 (#1172675)
      tests: Update t0220 and t0280 for the swap flag.
      Increase timeout for rmmod scsi_debug and make it a framework failure
      tests/t1701-rescue-fs wait for the device to appear.
      libparted: Fix udev cookie leak in _dm_resize_partition
      libparted: Fix udev cookie leak in _dm_resize_partition
      atari.c: Drop xlocale.h (#1476934)
      Modify gpt-header-move and msdos-overlap to work with py2 or py3
      Fix the length of several strncpy calls
      parted.c: Always free peek_word
      parted.c: Make sure dev_name is freed
      t6100-mdraid-partitions: Use v0.90 metadata for the test
      Add udf to t1700-probe-fs and to the manpage
      docs: Update GNU License version in parted .text files
      parted: Remove PED_ASSERT from ped_partition_set_name
      Fix align-check help output
      README-release: Updating the release instructions
      configure.ac: Remove default -Werror flag
      Remove unnecessary if before free checks
      Remove trailing whitespace
      Fix syntax-check complaints about tests
      Update syntax-check NEWS hash to cover 3.2 release notes.
      Fix double semi-colons
      Change 'time stamp' to 'timestamp'
      atari.c: Align the AtariRawTable on a 16bit boundary
      dos.c: Fix cast alignment error in maybe_FAT
      Adjust the gcc warnings to recognize FALLTHROUGH
      dvh.c: Use memcpy instead of strncpy
      gpt.c: Align _GPTDiskData to 8 byte boundary
      gpt.c: Drop cast of efi_guid_t to unsigned char *
      sun.c: Aligned _SunRawLabel to 16bit boundary
      Add gcc malloc attribute to ped_alloc and ped_calloc
      bsd.c: Rewrite disklabel code to prevent gcc warnings
      po: Add argmatch.h
      Turn off c_prohibit_gnu_make_extensions
      dist-check.mk: Remove empty .deps directories
      doc: Create po directory if missing
      libparted: Fix bug in bsd.c alpha_bootblock_checksum
      maint: Update to latest gnulib
      maint: Update bootstrap script from latest gnulib
      maint: Bump library REVISION number for release
      maint: Update copyright statements to 2019
      maint: Move NEWS template to line 3
      version 3.2.153
      maint: post-release administrivia
      README-release: Add link to upload registration page
      NEWS: Note the fix for the s390 bug
      version 3.3

Colin Watson (2):
      parted: fix build error on s390
      build: Remove unused traces of dynamic loading

Curtis Gedak (1):
      lib-fs-resize: Fix recognition of FAT file system after resizing

David Cantrell (1):
      Use BLKSSZGET to get device sector size in _device_probe_geometry()

Felix Janda (2):
      libparted/arch/linux.c: Compile without ENABLE_DEVICE_MAPPER
      libparted/fs/xfs/platform_defs.h: Include <fcntl.h> for loff_t

Gareth Randall (1):
      docs: Improve partition description in parted.texi

Gustavo Zacarias (1):
      bug #17883: [PATCH] configure.ac: uclinux is also linux

Hans-Joachim Baader (1):
      Added support for Windows recovery partition (WINRE) on MBR

Heiko Becker (1):
      libparted: also link to UUID_LIBS

John Paul Adrian Glaubitz (2):
      libparted:tests: Move get_sector_size() to common.c
      libparted: Add support for atari partition tables

Laurent Vivier (1):
      libparted: Fix MacOS boot support

Max Staudt (1):
      libparted/fs/amiga/affs.c: Remove printf() to avoid confusion

Michael Small (2):
      Avoid sigsegv in case 2nd nilfs2 superblock magic accidently found.
      Tests case for sigsegv when false nilfs2 superblock detected.

Mike Fleetwood (13):
      lib-fs-resize: Prevent crash resizing FAT16 file systems
      tests: t3000-resize-fs.sh: Add FAT16 resizing test
      tests: t3000-resize-fs.sh: Add requirement on mkfs.vfat
      lib-fs-resize: Prevent crash resizing FAT with very deep directories
      tests: t3000-resize-fs.sh: Add very deep directory
      tests: t3310-flags.sh: Query libparted for all flags to be tested
      tests: t3310-flags.sh: Stop excluding certain flags from being tested
      tests: t3310-flags.sh: Add test for bsd table flags
      libparted: Fix to report success when setting lvm flag on bsd table
      libparted: Remove commented local variable from bsd_partition_set_flag()
      tests: t3310-flags.sh: Add test for mac table flags
      tests: t3310-flags.sh: Add test for dvh table flags
      tests: t3310-flags.sh: Add tests for remaining table types

Niklas Hambüchen (1):
      mkpart: Allow negative start value when FS-TYPE is not given

Pali Rohár (1):
      libparted: Add support for MBR id, GPT GUID and detection of UDF filesystem

Petr Uzel (3):
      Add support for NVMe devices
      libparted: only IEC units are treated as exact
      libparted: Fix starting CHS in protective MBR

Phillip Susi (11):
      maint: post-release administrivia
      parted: don't crash in disk_set when disk label not found
      parted: fix the rescue command
      Add NEWS entry for fat resize fix
      Fix crash when localized
      Fix make check
      tests: fix t6100-mdraid-partitions
      Fix set and disk_set to not crash when no flags are supported
      Fix resizepart iec unit end sector
      Lift 512 byte restriction on fat resize
      Fix atari label false positives

Richard W.M. Jones (1):
      linux: Include <sys/sysmacros.h> for major() macro.

Sebastian Parschauer (3):
      libparted: Don't warn if no HDIO_GET_IDENTITY ioctl
      Add support for RAM drives
      Add support for NVDIMM devices

Sebastian Rasmussen (1):
      libparted: Fix typo in hfs error message

Sergei Antonov (1):
      mac: copy partition type and name correctly

Shin'ichiro Kawasaki (4):
      configure.ac: Check ABI against ABI version 2
      libparted/labels/pt-tools.c: Fix gperf generated function attribute
      include/parted/unit.in.h: Specify const attribute to ped_unit_get_name()
      libparted: Replace abs() with llabs()

Simon Xu (1):
      Fix potential command line buffer overflow

Steven Lang (1):
      Use disk geometry as basis for ext2 sector sizes.

Ulrich Müller (1):
      libparted: Fix ending CHS address in PMBR.

Viktor Mihajlovski (4):
      fdasd: geometry handling updated from upstream s390-tools
      dasd: enhance device probing
      fdasd.c: Safeguard against geometry misprobing
      libparted/s390: Re-enabled virtio-attached DASD heuristics

Wang Dong (13):
      libparted/dasd: correct the offset where the first partition begins
      libparted/dasd: unify vtoc handling for cdl/ldl
      libparted/dasd: update and improve fdasd functions
      libparted/dasd: add new fdasd functions
      libparted/dasd: add test cases for the new fdasd functions
      parted: fix crash due to improper partition number input
      parted: fix wrong error label jump in mkpart
      clean the disk information when commands fail in interactive mode.
      parted: check the name of partition first when to name a partition
      parted/ui: remove unneccesary information of command line
      libpartd/dasd: improve flag processing for DASD-LDL
      libparted/dasd: add an exception for changing DASD-LDL partition table
      libparted/dasd: add test cases for the new fdasd functions

dann frazier (3):
      ped_unit_get_name: Resolve conflicting attributes 'const' and 'pure'
      Fix warnings from GCC 7's -Wimplicit-fallthrough
      Read NVMe model names from sysfs

11 October, 2019 12:18AM by Brian C. Lane

October 09, 2019

FSF Events

LibrePlanet 2020 IRC CFS Office Hours

The LibrePlanet call for sessions is open now and will be open until November 20 and we want to hear from you!

Speaking at a conference, and even submitting a proposal, can be intimidating or hard. Luckily, some great, experienced speakers are volunteering their time to help out during the CFS Office Hours.

Whether you want to propose a talk and want feedback on your idea, proposal wording, talk title, or just advice on how to deal with nerves, there is one more office hour slot scheduled over the next few weeks.

Join #libreplanet on Freenode IRC on any of the following dates:

  • Thursday, November 14th from 13:00 - 14:00 (EST)

If you do not have an IRC client, you can log onto Freenode IRC here, and connect to the channel #libreplanet.

If you can't make an office hours meeting, feel free to email campaigns@fsf.org with questions.

09 October, 2019 08:50PM

Gary Benson

“Reformat the filesystem to enable support”

Apparently it’s been a while since I ran containers on my office computer—and by a while, I mean, since November 2016—because if your initial install was RHEL or CentOS 7.2 or older then neither Docker nor Podman will work:

# yum -q -y install podman skopeo buildah
# podman pull registry.access.redhat.com/ubi7/ubi
Error: could not get runtime: kernel does not support overlay fs: overlay: the backing xfs filesystem is formatted without d_type support, which leads to incorrect behavior. Reformat the filesystem with ftype=1 to enable d_type support. Running without d_type is not supported.: driver not supported

So… ugh. I didn’t have any disks it’d work on either:

# for i in $(awk '{ if ($3 == "xfs") print $2 }' /etc/mtab); do xfs_info $i; done | grep ftype
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0

I didn’t reformat anything though. podman pull wants overlayFS on /var/run/containers/storage, and buildah bud wants it on /var/lib/containers/storage. I made loopback disks for them both:

  1. Find/make space somewhere, then create a directory to put the images in:
    # mkdir -p /store/containers
  2. Create a big file, whatever size you want, for the disk image. I made mine 20GiB. It took a couple minutes, my disks are slow:
    # dd if=/dev/zero of=/store/containers/var_lib_containers.img bs=1M count=20K
  3. Find a free loop device and associate the file to it:
    # losetup -f
    /dev/loop1
    # losetup /dev/loop1 /store/containers/var_lib_containers.img 
    
  4. Format the “device”, then detach it from the file:
    # mkfs -t xfs -n ftype=1 /dev/loop1
    # losetup -d /dev/loop1
  5. Mount the “disk”, and see if it worked:
    # mount -oloop /store/containers/var_lib_containers.img /var/lib/containers
    # df -h /var/lib/containers
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/loop1       20G   33M   20G   1% /var/lib/containers
  6. It worked? Make it permanent:
    # echo "/store/containers/var_lib_containers.img /var/lib/containers xfs defaults,loop 1 2" >> /etc/fstab

Rinse and repeat for the other drive it needed. Then try again:

# podman pull registry.access.redhat.com/ubi7/ubi
Trying to pull registry.access.redhat.com/ubi7/ubi...Getting image
source signatures
Copying blob bff3b73cbcc4 done
Copying blob 7b1c937e0f67 done
Copying config 6fecccc91c done
Writing manifest to image destination
Storing signatures
6fecccc91c83e11ae4fede6793e9410841221d4779520c2b9e9fb7f7b3830264

#victorydanceđŸ˜

09 October, 2019 12:32PM by gbenson

October 08, 2019

Andy Wingo

thoughts on rms and gnu

Yesterday, a collective of GNU maintainers publicly posted a statement advocating collective decision-making in the GNU project. I would like to expand on what that statement means to me and why I signed on.

For many years now, I have not considered Richard Stallman (RMS) to be the head of the GNU project. Yes, he created GNU, speaking it into existence via prophetic narrative and via code; yes, he inspired many people, myself included, to make the vision of a GNU system into a reality; and yes, he should be recognized for these things. But accomplishing difficult and important tasks for GNU in the past does not grant RMS perpetual sovereignty over GNU in the future.

ontological considerations

More on the motivations for the non serviam in a minute. But first, a meta-point: the GNU project does not exist, at least not in the sense that many people think it does. It is not a legal entity. It is not a charity. You cannot give money to the GNU project. Besides the manifesto, GNU has no by-laws or constitution or founding document.

One could describe GNU as a set of software packages that have been designated by RMS as forming part, in some way, of GNU. But this artifact-centered description does not capture movement: software does not, by itself, change the world; it lacks agency. It is the people that maintain, grow, adapt, and build the software that are the heart of the GNU project -- the maintainers of and contributors to the GNU packages. They are the GNU of whom I speak and of whom I form a part.

wasted youth

Richard Stallman describes himself as the leader of the GNU project -- the "chief GNUisance", he calls it -- but this position only exists in any real sense by consent of the people that make GNU. So what is he doing with this role? Does he deserve it? Should we consent?

To me it has been clear for many years that to a first approximation, the answer is that RMS does nothing for GNU. RMS does not write software. He does not design software, or systems. He does hold a role of accepting new projects into GNU; there, his primary criteria is not "does this make a better GNU system"; it is, rather, "does the new project meet the minimum requirements".

By itself, this seems to me to be a failure of leadership for a software project like GNU. But unfortunately when RMS's role in GNU isn't neglect, more often as not it's negative. RMS's interventions are generally conservative -- to assert authority over the workings of the GNU project, to preserve ways of operating that he sees as important. See for example the whole glibc abortion joke debacle as an example of how RMS acts, when he chooses to do so.

Which, fair enough, right? I can hear you saying it. RMS started GNU so RMS decides what it is and what it can be. But I don't accept that. GNU is about practical software freedom, not about RMS. GNU has long outgrown any individual contributor. I don't think RMS has the legitimacy to tell this group of largely volunteers what we should build or how we should organize ourselves. Or rather, he can say what he thinks, but he has no dominion over GNU; he does not have majority sweat equity in the project. If RMS actually wants the project to outlive him -- something that by his actions is not clear -- the best thing that he could do for GNU is to stop pretending to run things, to instead declare victory and retire to an emeritus role.

Note, however, that my personal perspective here is not a consensus position of the GNU project. There are many (most?) GNU developers that still consider RMS to be GNU's rightful leader. I think they are mistaken, but I do not repudiate them for this reason; we can work together while differing on this and other matters. I simply state that I, personally, do not serve RMS.

selective attrition

Though the "voluntary servitude" questions are at the heart of the recent joint statement, I think we all recognize that attempts at self-organization in GNU face a grave difficulty, even if RMS decided to retire tomorrow, in the way that GNU maintainers have selected themselves.

The great tragedy of RMS's tenure in the supposedly universalist FSF and GNU projects is that he behaves in a way that is particularly alienating to women. It doesn't take a genius to conclude that if you're personally driving away potential collaborators, that's a bad thing for the organization, and actively harmful to the organization's goals: software freedom is a cause that is explicitly for everyone.

We already know that software development in people's free time skews towards privilege: not everyone has the ability to devote many hours per week to what is for many people a hobby, and it follows of course that those that have more privilege in society will be more able to establish a position in the movement. And then on top of these limitations on contributors coming in, we additionally have this negative effect of a toxic culture pushing people out.

The result, sadly, is that a significant proportion of those that have stuck with GNU don't see any problems with RMS. The cause of software freedom has always run against the grain of capitalism so GNU people are used to being a bit contrarian, but it has also had the unfortunate effect of creating a cult of personality and a with-us-or-against-us mentality. For some, only a traitor would criticise the GNU project. It's laughable but it's a thing; I prefer to ignore these perspectives.

Finally, it must be said that there are a few GNU people for whom it's important to check if the microphone is on before making a joke about rape culture. (Incidentally, RMS had nothing to say on that issue; how useless.)

So I honestly am not sure if GNU as a whole effectively has the demos to make good decisions. Neglect and selective attrition have gravely weakened the project. But I stand by the principles and practice of software freedom, and by my fellow GNU maintainers who are unwilling to accept the status quo, and I consider attempts to reduce GNU to founder-loyalty to be mistaken and without legitimacy.

where we're at

Given this divided state regarding RMS, the only conclusion I can make is that for the foreseeable future, GNU is not likely to have a formal leadership. There will be affinity groups working in different ways. It's not ideal, but the differences are real and cannot be papered over. Perhaps in the medium term, GNU maintainers can reach enough consensus to establish a formal collective decision-making process; here's hoping.

In the meantime, as always, happy hacking, and: no gods! No masters! No chief!!!

08 October, 2019 03:34PM by Andy Wingo