GNU Guix Is 4 Years Old!

Total Page:16

File Type:pdf, Size:1020Kb

GNU Guix Is 4 Years Old! GNU Guix is 4 years old! Ludovic Courtes` GNU Hackers Meeting, Rennes, August 2016 The rise and fall of distros. “Debian and other distributions are going to be that thing you run docker on, little more.” — Jos Poortvliet, ownCloud developer http://lwn.net/Articles/670566/ It’s also that thing you run inside Docker! main griefs: I distros are inflexible I distros “lag behind” I developers have to “chase distros” http://xkcd.com/1654/ ! “app bundles” Giving up? Giving up? ! “app bundles” https://imagelayers.io/ Maybe what we need is an app store that feels like apt, yum & co.? ... still too low-level ... still too low-level Maybe what we need is an app store that feels like apt, yum & co.? “There is in fact another system with very similar goals, which is now called Flatpak [...]” “This is, to put it diplomatically, a heaping pile of steaming bullshit [...] served by the Canonical press department.” — Adam Williamson (Red Hat, Fedora) https://www.happyassassin.net/ “This is, to put it diplomatically, a heaping pile of steaming bullshit [...] served by the Canonical press department.” “There is in fact another system with very similar goals, which is now called Flatpak [...]” — Adam Williamson (Red Hat, Fedora) https://www.happyassassin.net/ http://flatpak.org/ “app bundles” are headed wrong I difficulty to compose software packages I no “big picture” integration work I where’s the Corresponding Source? I “app” model/free software commons mismatch Guix 1. transactional package manager 2. software environment manager 3. APIs & tools to customize environments 4. packaging tools $ guix package -i gcc-toolchain coreutils sed grep ... $ eval `guix package --search-paths` ... $ guix package --manifest=my-software.scm ... A simple matter of installing the deps, right? Want to get started hacking on GIMP? Want to get started hacking on GIMP? A simple matter of installing the deps, right? gimp-2.8.14 python2-pygtk-2.24.0 libexif-0.6.21 librsvg-2.40.13 gegl-0.2.0 gtk+-2.24.28 libgsf-1.14.34 babl-0.1.10 pango-1.38.1 gdk-pixbuf-2.32.3 atk-2.18.0 harfbuzz-1.0.5 python2-pygobject-2.28.6 gobject-introspection-1.46.0 python2-pycairo-1.10.0 cups-2.1.0 cups-filters-1.4.0 cairo-1.14.2 python-waf-1.8.8 icu4c-55.1 poppler-0.37.0 font-dejavu-2.34 libcroco-0.6.8 cairo-1.14.2 tar-1.28 avahi-0.6.31 ijs-9.14.0 glib-2.46.1 libspectre-0.2.7 intltool-0.51.0 libdaemon-0.14 libtool-2.4.6 tzdata-2015g pixman-0.32.8 openjpeg-1.5.2 ghostscript-9.14.0 cups-minimal-2.1.0 dbus-1.10.0 perl-xml-parser-2.44 file-5.25 automake-1.15 libpng-1.5.26 qpdf-5.1.3 lcms-2.6 libpaper-1.1.24 graphite2-1.3.3 python-wrapper-3.4.3 gnutls-3.4.7 autoconf-wrapper-2.69 autoconf-wrapper-2.69 coreutils-8.24 python2-fonttools-2.5 pcre-8.38 libtiff-4.0.6 python-3.4.3 python-2.7.10 libjpeg-8d which-2.21 guile-2.0.11 nettle-3.1.1 libidn-1.32 autoconf-2.69 libcap-2.24 python2-setuptools-18.3.1 bzip2-1.0.6 libffi-3.2.1 acl-2.2.52 gdbm-1.11 tk-8.6.4 sqlite-3.10.0 libjpeg-9a bash-4.3.42 gmp-6.1.0 libgc-7.4.2 libltdl-2.4.6 libunistring-0.9.6 attr-2.4.47 tcl-8.6.4 bison-3.0.4 readline-6.3 libxft-2.3.2 libatomic-ops-7.4.2 libxinerama-1.1.3 libxrandr-1.4.2 libxcursor-1.1.14 libxi-1.7.4 libxcomposite-0.4.4 libxdamage-1.1.4 flex-2.6.0 fontconfig-2.11.94 ncurses-6.0 gettext-0.19.7 libxrender-0.9.8 libxext-1.3.3 libxfixes-5.0.1 compositeproto-0.4.2 freetype-2.6 indent-2.2.10 bison-2.7.1 gs-fonts-8.11 expat-2.1.0 libx11-1.6.2 fixesproto-5.0 m4-1.4.17 xextproto-7.3.0 libxcb-1.11 kbproto-1.0.6 inputproto-2.3.1 libxslt-1.1.28 xcb-proto-1.11 libxau-1.0.8 xtrans-1.3.5 libxdmcp-1.1.1 randrproto-1.4.0 libxml2-2.9.3 python-minimal-wrapper-3.4.3 renderproto-0.11.1 libpthread-stubs-0.3 libgcrypt-1.6.4 xproto-7.0.26 python-minimal-3.4.3 libgpg-error-1.21 xineramaproto-1.2.1 util-macros-1.19.0 damageproto-1.2.1 zlib-1.2.8 openssl-1.0.2e pkg-config-0.29 libtasn1-4.7 perl-5.22.1 $ guix environment --container gimp ... $ guix environment --container gimp \ --ad-hoc git autoconf automake gdb ... Creating package variants at the command line $ guix package -i git \ --with-input=openssl=libressl ... $ guix package -i emacs \ --with-source=./emacs-25.1rc0.tar.gz ... $ guix package -i emacs \ --with-source=./emacs-25.1rc0.tar.gz ... $ guix package -i git \ --with-input=openssl=libressl ... Your personal packages or variants in GUIX PACKAGE PATH! Security updates “grafted” onto available binaries gimp-2.8.14 python2-pygtk-2.24.0 libexif-0.6.21 librsvg-2.40.13 gegl-0.2.0 gtk+-2.24.28 libgsf-1.14.34 babl-0.1.10 pango-1.38.1 gdk-pixbuf-2.32.3 atk-2.18.0 harfbuzz-1.0.5 python2-pygobject-2.28.6 gobject-introspection-1.46.0 python2-pycairo-1.10.0 cups-2.1.0 cups-filters-1.4.0 cairo-1.14.2 python-waf-1.8.8 icu4c-55.1 poppler-0.37.0 font-dejavu-2.34 libcroco-0.6.8 cairo-1.14.2 tar-1.28 avahi-0.6.31 ijs-9.14.0 glib-2.46.1 libspectre-0.2.7 intltool-0.51.0 libdaemon-0.14 libtool-2.4.6 tzdata-2015g pixman-0.32.8 openjpeg-1.5.2 ghostscript-9.14.0 cups-minimal-2.1.0 dbus-1.10.0 perl-xml-parser-2.44 file-5.25 automake-1.15 libpng-1.5.26 qpdf-5.1.3 lcms-2.6 libpaper-1.1.24 graphite2-1.3.3 python-wrapper-3.4.3 gnutls-3.4.7 autoconf-wrapper-2.69 autoconf-wrapper-2.69 coreutils-8.24 python2-fonttools-2.5 pcre-8.38 libtiff-4.0.6 python-3.4.3 python-2.7.10 libjpeg-8d which-2.21 guile-2.0.11 nettle-3.1.1 libidn-1.32 autoconf-2.69 libcap-2.24 python2-setuptools-18.3.1 bzip2-1.0.6 libffi-3.2.1 acl-2.2.52 gdbm-1.11 tk-8.6.4 sqlite-3.10.0 libjpeg-9a bash-4.3.42 gmp-6.1.0 libgc-7.4.2 libltdl-2.4.6 libunistring-0.9.6 attr-2.4.47 tcl-8.6.4 bison-3.0.4 readline-6.3 libxft-2.3.2 libatomic-ops-7.4.2 libxinerama-1.1.3 libxrandr-1.4.2 libxcursor-1.1.14 libxi-1.7.4 libxcomposite-0.4.4 libxdamage-1.1.4 flex-2.6.0 fontconfig-2.11.94 ncurses-6.0 gettext-0.19.7 libxrender-0.9.8 libxext-1.3.3 libxfixes-5.0.1 compositeproto-0.4.2 freetype-2.6 indent-2.2.10 bison-2.7.1 gs-fonts-8.11 expat-2.1.0 libx11-1.6.2 fixesproto-5.0 m4-1.4.17 xextproto-7.3.0 libxcb-1.11 kbproto-1.0.6 inputproto-2.3.1 libxslt-1.1.28 xcb-proto-1.11 libxau-1.0.8 xtrans-1.3.5 libxdmcp-1.1.1 randrproto-1.4.0 libxml2-2.9.3 python-minimal-wrapper-3.4.3 renderproto-0.11.1 libpthread-stubs-0.3 libgcrypt-1.6.4 xproto-7.0.26 python-minimal-3.4.3 libgpg-error-1.21 xineramaproto-1.2.1 util-macros-1.19.0 damageproto-1.2.1 zlib-1.2.8 openssl-1.0.2e pkg-config-0.29 libtasn1-4.7 perl-5.22.1 GuixSD: declarative OS config Linux-libre Linux-libre initial RAM disk Linux-libre initial RAM disk Guile Linux-libre initial RAM disk Guile PID 1: GNU Shepherd services... Linux-libre initial RAM disk Guile PID 1: GNU Shepherd services... Guile Linux-libre initial RAM disk Guile PID 1: GNU Shepherd services... Guile applications Status. 4 years! I Aug. 2012 — GNU Hackers Meeting, Dusseldorf¨ I Nov. 2012 — dubbed GNU I Jan. 2013 — 0.1 I ... I July 2014 — 0.7, installable operating system I ... I Nov. 2015 — 0.9.0, new service framework, etc. I Jan. 2016 — successful fundraiser for new build farm I Mar. 2016 — 0.10.0, grafts, GNOME I Aug. 2016 — 0.11.0, system tests, more services growth! I 3,800+ packages I 4 architectures I binaries at https://hydra.gnu.org I ≈500 new packages per release Scaling up. importers & updaters I guix import I 8.5 importers: GNU, Nix, PyPI, CPAN, CRAN, Hackage, ELPA, Gem, npm (GSoC 2016) I guix refresh I 11 updaters: GNU, GNOME, KDE, Xorg, ELPA, CRAN, Bioconductor, Hackage, PyPI, Gem, GitHub I guix lint -c cve (vulnerabilities) I 30 committers, but 5–10 frequent reviewers I 50+ emails per day, hard to track patches I Patchwork? QEMU’s patches? suggestions? contributions I documented processes, code of conduct I consensus-based decision making I tools: guix lint (12 checkers!), guix build --rounds=2, etc.
Recommended publications
  • On the Impact of Exception Handling Compatibility on Binary Instrumentation†
    On the Impact of Exception Handling Compatibility on Binary Instrumentation† Soumyakant Priyadarshan Huan Nguyen R. Sekar Stony Brook University Stony Brook University Stony Brook University Stony Brook, NY, USA Stony Brook, NY, USA Stony Brook, NY, USA [email protected] [email protected] [email protected] Abstract overheads, but has been held back by challenges in accurate dis- assembly and code pointer identification. With the emergence of To support C++ exception handling, compilers generate metadata position-independent (or relocatable) binaries as the dominant for- that is a rich source of information about the code layout. On mat in recent years, researchers have been able to address these Linux, this metadata is also used to support stack tracing, thread challenges, e.g., in Egalito [41], RetroWrite [11] and SBR[28, 29] cleanup and other functions. For this reason, Linux binaries contain systems. code-layout-revealing metadata for C-code as well. Even hand- written assembly in low-level system libraries is covered by such Despite recent advances, deployability of binary instrumentation metadata. We investigate the implications of this metadata in this continues to face significant challenges. One of the major concerns paper, and show that it can be used to (a) improve accuracy of is compatibility. In particular, existing static binary instrumentation disassembly, (b) achieve significantly better accuracy at function tools tend to break stack tracing (for C and C++) as well as C++ boundary identification as compared to previous research, and(c) exception handling. While compatibility with these features may as a rich source of information for defeating fine-grained code not be important for proof-of-concept instrumentations, it is hardly randomization.
    [Show full text]
  • Designing and Packaging Printer and Scanner Drivers
    Designing and Packaging Printer and Scanner Drivers OpenPrinting MC on Linux Plumbers 2020 August 28, 2020 Till Kamppeter, OpenPrinting What we had ● Printer drivers – PPD files – Filters, perhaps also backends – All has to be in CUPS-specific directories ● Scanner drivers – Shared libraries with SANE ABI in SANE-specific directories ● Packaging – Binaries were built specific to destination distro and packaged in DEB or RPM packages – For each distro drivers need to be built, packaged, and tested separately – As files need to be in specific directories drivers cannot be installed with CUPS in a Snap or with scanning user applications in Snaps What we want ● Sandboxed packaging – Snaps – Distribution-independent: Install from Snap Store on any distro running snapd – More security: Every package with all its libraries and files in its own sandbox, fine-grained control for communication between packages – All-Snap distributions ● But – You cannot drop driver files into directories of a snapped CUPS or snapped user applications, Snaps do not see the system’s files – Snaps only communicate via IP or D-Bus, not by files ● Also – CUPS is deprecating support for PPD files, working by itself only in driverless IPP mode. The New Architecture ● Printer/Scanner Applications emulating an IPP device – Easily snappable: Communicates only via IP – Multi-function device support, Printing, Scanning, and Fax Out can be done in one Snap/Application – Web admin interface for vendor/device-specific GUI – Behaves like a network printer/scanner/multi-function
    [Show full text]
  • MASTERCLASS GNUPG MASTERCLASS You Wouldn’T Want Other People Opening Your Letters and BEN EVERARD Your Data Is No Different
    MASTERCLASS GNUPG MASTERCLASS You wouldn’t want other people opening your letters and BEN EVERARD your data is no different. Encrypt it today! SECURE EMAIL WITH GNUPG AND ENIGMAIL Send encrypted emails from your favourite email client. our typical email is about as secure as a The first thing that you need to do is create a key to JOHN LANE postcard, which is good news if you’re a represent your identity in the OpenPGP world. You’d Ygovernment agency. But you wouldn’t use a typically create one key per identity that you have. postcard for most things sent in the post; you’d use a Most people would have one identity, being sealed envelope. Email is no different; you just need themselves as a person. However, some may find an envelope – and it’s called “Encryption”. having separate personal and professional identities Since the early 1990s, the main way to encrypt useful. It’s a personal choice, but starting with a single email has been PGP, which stands for “Pretty Good key will help while you’re learning. Privacy”. It’s a protocol for the secure encryption of Launch Seahorse and click on the large plus-sign email that has since evolved into an open standard icon that’s just below the menu. Select ‘PGP Key’ and called OpenPGP. work your way through the screens that follow to supply your name and email address and then My lovely horse generate the key. The GNU Privacy Guard (GnuPG), is a free, GPL-licensed You can, optionally, use the Advanced Key Options implementation of the OpenPGP standard (there are to add a comment that can help others identify your other implementations, both free and commercial – key and to select the cipher, its strength and set when the PGP name now refers to a commercial product the key should expire.
    [Show full text]
  • Source Code Trees in the VALLEY of THE
    PROGRAMMING GNOME Source code trees IN THE VALLEY OF THE CODETHORSTEN FISCHER So you’ve just like the one in Listing 1. Not too complex, eh? written yet another Unfortunately, creating a Makefile isn’t always the terrific GNOME best solution, as assumptions on programs program. Great! But locations, path names and others things may not be does it, like so many true in all cases, forcing the user to edit the file in other great programs, order to get it to work properly. lack something in terms of ease of installation? Even the Listing 1: A simple Makefile for a GNOME 1: CC=/usr/bin/gcc best and easiest to use programs 2: CFLAGS=`gnome-config —cflags gnome gnomeui` will cause headaches if you have to 3: LDFLAGS=`gnome-config —libs gnome gnomeui` type in lines like this, 4: OBJ=example.o one.o two.o 5: BINARIES=example With the help of gcc -c sourcee.c gnome-config —libs —cflags 6: gnome gnomeui gnomecanvaspixbuf -o sourcee.o 7: all: $(BINARIES) Automake and Autoconf, 8: you can create easily perhaps repeated for each of the files, and maybe 9: example: $(OBJ) with additional compiler flags too, only to then 10: $(CC) $(LDFLAGS) -o $@ $(OBJ) installed source code demand that everything is linked. And at the end, 11: do you then also have to copy the finished binary 12: .c.o: text trees. Read on to 13: $(CC) $(CFLAGS) -c $< manually into the destination directory? Instead, 14: find out how. wouldn’t you rather have an easy, portable and 15: clean: quick installation process? Well, you can – if you 16: rm -rf $(OBJ) $(BINARIES) know how.
    [Show full text]
  • Red Hat Enterprise Linux 6 Developer Guide
    Red Hat Enterprise Linux 6 Developer Guide An introduction to application development tools in Red Hat Enterprise Linux 6 Dave Brolley William Cohen Roland Grunberg Aldy Hernandez Karsten Hopp Jakub Jelinek Developer Guide Jeff Johnston Benjamin Kosnik Aleksander Kurtakov Chris Moller Phil Muldoon Andrew Overholt Charley Wang Kent Sebastian Red Hat Enterprise Linux 6 Developer Guide An introduction to application development tools in Red Hat Enterprise Linux 6 Edition 0 Author Dave Brolley [email protected] Author William Cohen [email protected] Author Roland Grunberg [email protected] Author Aldy Hernandez [email protected] Author Karsten Hopp [email protected] Author Jakub Jelinek [email protected] Author Jeff Johnston [email protected] Author Benjamin Kosnik [email protected] Author Aleksander Kurtakov [email protected] Author Chris Moller [email protected] Author Phil Muldoon [email protected] Author Andrew Overholt [email protected] Author Charley Wang [email protected] Author Kent Sebastian [email protected] Editor Don Domingo [email protected] Editor Jacquelynn East [email protected] Copyright © 2010 Red Hat, Inc. and others. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
    [Show full text]
  • Beginning Portable Shell Scripting from Novice to Professional
    Beginning Portable Shell Scripting From Novice to Professional Peter Seebach 10436fmfinal 1 10/23/08 10:40:24 PM Beginning Portable Shell Scripting: From Novice to Professional Copyright © 2008 by Peter Seebach All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher. ISBN-13 (pbk): 978-1-4302-1043-6 ISBN-10 (pbk): 1-4302-1043-5 ISBN-13 (electronic): 978-1-4302-1044-3 ISBN-10 (electronic): 1-4302-1044-3 Printed and bound in the United States of America 9 8 7 6 5 4 3 2 1 Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. Lead Editor: Frank Pohlmann Technical Reviewer: Gary V. Vaughan Editorial Board: Clay Andres, Steve Anglin, Ewan Buckingham, Tony Campbell, Gary Cornell, Jonathan Gennick, Michelle Lowman, Matthew Moodie, Jeffrey Pepper, Frank Pohlmann, Ben Renow-Clarke, Dominic Shakeshaft, Matt Wade, Tom Welsh Project Manager: Richard Dal Porto Copy Editor: Kim Benbow Associate Production Director: Kari Brooks-Copony Production Editor: Katie Stence Compositor: Linda Weidemann, Wolf Creek Press Proofreader: Dan Shaw Indexer: Broccoli Information Management Cover Designer: Kurt Krames Manufacturing Director: Tom Debolski Distributed to the book trade worldwide by Springer-Verlag New York, Inc., 233 Spring Street, 6th Floor, New York, NY 10013.
    [Show full text]
  • Nix on SHARCNET
    Nix on SHARCNET Tyson Whitehead May 14, 2015 Nix Overview An enterprise approach to package management I a package is a specific piece of code compiled in a specific way I each package is entirely self contained and does not change I each users select what packages they want and gets a custom enviornment https://nixos.org/nix Ships with several thousand packages already created https://nixos.org/nixos/packages.html SHARCNET What this adds to SHARCNET I each user can have their own custom environments I environments should work everywhere (closed with no external dependencies) I several thousand new and newer packages Current issues (first is permanent, second will likely be resolved) I newer glibc requires kernel 2.6.32 so no requin I package can be used but not installed/removed on viz/vdi https: //sourceware.org/ml/libc-alpha/2014-01/msg00511.html Enabling Nix Nix is installed under /home/nixbld on SHARCNET. Enable for a single sessiong by running source /home/nixbld/profile.d/nix-profile.sh To always enable add this to the end of ~/.bash_profile echo source /home/nixbld/profile.d/nix-profile.sh \ >> ~/.bash_profile Reseting Nix A basic reset is done by removing all .nix* files from your home directory rm -fr ~/.nix* A complete reset done by remove your Nix per-user directories rm -fr /home/nixbld/var/nix/profile/per-user/$USER rm -fr /home/nixbld/var/nix/gcroots/per-user/$USER The nix-profile.sh script will re-create these with the defaults next time it runs. Environment The nix-env commands maintains your environments I query packages (available and installed) I create a new environment from current one by adding packages I create a new environment from current one by removing packages I switching between existing environments I delete unused environements Querying Packages The nix-env {--query | -q} ..
    [Show full text]
  • The Interplay of Compile-Time and Run-Time Options for Performance Prediction Luc Lesoil, Mathieu Acher, Xhevahire Tërnava, Arnaud Blouin, Jean-Marc Jézéquel
    The Interplay of Compile-time and Run-time Options for Performance Prediction Luc Lesoil, Mathieu Acher, Xhevahire Tërnava, Arnaud Blouin, Jean-Marc Jézéquel To cite this version: Luc Lesoil, Mathieu Acher, Xhevahire Tërnava, Arnaud Blouin, Jean-Marc Jézéquel. The Interplay of Compile-time and Run-time Options for Performance Prediction. SPLC 2021 - 25th ACM Inter- national Systems and Software Product Line Conference - Volume A, Sep 2021, Leicester, United Kingdom. pp.1-12, 10.1145/3461001.3471149. hal-03286127 HAL Id: hal-03286127 https://hal.archives-ouvertes.fr/hal-03286127 Submitted on 15 Jul 2021 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. The Interplay of Compile-time and Run-time Options for Performance Prediction Luc Lesoil, Mathieu Acher, Xhevahire Tërnava, Arnaud Blouin, Jean-Marc Jézéquel Univ Rennes, INSA Rennes, CNRS, Inria, IRISA Rennes, France [email protected] ABSTRACT Both compile-time and run-time options can be configured to reach Many software projects are configurable through compile-time op- specific functional and performance goals. tions (e.g., using ./configure) and also through run-time options (e.g., Existing studies consider either compile-time or run-time op- command-line parameters, fed to the software at execution time).
    [Show full text]
  • The GNOME Desktop Environment
    The GNOME desktop environment Miguel de Icaza ([email protected]) Instituto de Ciencias Nucleares, UNAM Elliot Lee ([email protected]) Federico Mena ([email protected]) Instituto de Ciencias Nucleares, UNAM Tom Tromey ([email protected]) April 27, 1998 Abstract We present an overview of the free GNU Network Object Model Environment (GNOME). GNOME is a suite of X11 GUI applications that provides joy to users and hackers alike. It has been designed for extensibility and automation by using CORBA and scripting languages throughout the code. GNOME is licensed under the terms of the GNU GPL and the GNU LGPL and has been developed on the Internet by a loosely-coupled team of programmers. 1 Motivation Free operating systems1 are excellent at providing server-class services, and so are often the ideal choice for a server machine. However, the lack of a consistent user interface and of consumer-targeted applications has prevented free operating systems from reaching the vast majority of users — the desktop users. As such, the benefits of free software have only been enjoyed by the technically savvy computer user community. Most users are still locked into proprietary solutions for their desktop environments. By using GNOME, free operating systems will have a complete, user-friendly desktop which will provide users with powerful and easy-to-use graphical applications. Many people have suggested that the cause for the lack of free user-oriented appli- cations is that these do not provide enough excitement to hackers, as opposed to system- level programming. Since most of the GNOME code had to be written by hackers, we kept them happy: the magic recipe here is to design GNOME around an adrenaline response by trying to use exciting models and ideas in the applications.
    [Show full text]
  • GNU Guix Cookbook Tutorials and Examples for Using the GNU Guix Functional Package Manager
    GNU Guix Cookbook Tutorials and examples for using the GNU Guix Functional Package Manager The GNU Guix Developers Copyright c 2019 Ricardo Wurmus Copyright c 2019 Efraim Flashner Copyright c 2019 Pierre Neidhardt Copyright c 2020 Oleg Pykhalov Copyright c 2020 Matthew Brooks Copyright c 2020 Marcin Karpezo Copyright c 2020 Brice Waegeneire Copyright c 2020 Andr´eBatista Copyright c 2020 Christine Lemmer-Webber Copyright c 2021 Joshua Branson Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License". i Table of Contents GNU Guix Cookbook ::::::::::::::::::::::::::::::: 1 1 Scheme tutorials ::::::::::::::::::::::::::::::::: 2 1.1 A Scheme Crash Course :::::::::::::::::::::::::::::::::::::::: 2 2 Packaging :::::::::::::::::::::::::::::::::::::::: 5 2.1 Packaging Tutorial:::::::::::::::::::::::::::::::::::::::::::::: 5 2.1.1 A \Hello World" package :::::::::::::::::::::::::::::::::: 5 2.1.2 Setup:::::::::::::::::::::::::::::::::::::::::::::::::::::: 8 2.1.2.1 Local file ::::::::::::::::::::::::::::::::::::::::::::: 8 2.1.2.2 `GUIX_PACKAGE_PATH' ::::::::::::::::::::::::::::::::: 9 2.1.2.3 Guix channels ::::::::::::::::::::::::::::::::::::::: 10 2.1.2.4 Direct checkout hacking:::::::::::::::::::::::::::::: 10 2.1.3 Extended example ::::::::::::::::::::::::::::::::::::::::
    [Show full text]
  • The Next-Gen Apertis Application Framework 1 Contents
    The next-gen Apertis application framework 1 Contents 2 Creating a vibrant ecosystem ....................... 2 3 The next-generation Apertis application framework ........... 3 4 Application runtime: Flatpak ....................... 4 5 Compositor: libweston ........................... 6 6 Audio management: PipeWire and WirePlumber ............ 7 7 Session management: systemd ....................... 7 8 Software distribution: hawkBit ...................... 8 9 Evaluation .................................. 8 10 Focus on the development user experience ................ 12 11 Legacy Apertis application framework 13 12 High level implementation plan for the next-generation Apertis 13 application framework 14 14 Flatpak on the Apertis images ...................... 15 15 The Apertis Flatpak application runtime ................. 15 16 Implement a new reference graphical shell/compositor ......... 16 17 Switch to PipeWire for audio management ................ 16 18 AppArmor support ............................. 17 19 The app-store ................................ 17 20 As a platform, Apertis needs a vibrant ecosystem to thrive, and one of the 21 foundations of such ecosystem is being friendly to application developers and 22 product teams. Product teams and application developers are more likely to 23 choose Apertis if it offers flows for building, shipping, and updating applications 24 that are convenient, cheap, and that require low maintenance. 25 To reach that goal, a key guideline is to closely align to upstream solutions 26 that address those needs and integrate them into Apertis, to provide to appli- 27 cation authors a framework that is made of proven, stable, complete, and well 28 documented components. 29 The cornerstone of this new approach is the adoption of Flatpak, the modern 30 application system already officially supported on more than 20 Linux distribu- 1 31 tions , including Ubuntu, Fedora, Red Hat Enterprise, Alpine, Arch, Debian, 32 ChromeOS, and Raspian.
    [Show full text]
  • Downloads." the Open Information Security Foundation
    Performance Testing Suricata The Effect of Configuration Variables On Offline Suricata Performance A Project Completed for CS 6266 Under Jonathon T. Giffin, Assistant Professor, Georgia Institute of Technology by Winston H Messer Project Advisor: Matt Jonkman, President, Open Information Security Foundation December 2011 Messer ii Abstract The Suricata IDS/IPS engine, a viable alternative to Snort, has a multitude of potential configurations. A simplified automated testing system was devised for the purpose of performance testing Suricata in an offline environment. Of the available configuration variables, seventeen were analyzed independently by testing in fifty-six configurations. Of these, three variables were found to have a statistically significant effect on performance: Detect Engine Profile, Multi Pattern Algorithm, and CPU affinity. Acknowledgements In writing the final report on this endeavor, I would like to start by thanking four people who made this project possible: Matt Jonkman, President, Open Information Security Foundation: For allowing me the opportunity to carry out this project under his supervision. Victor Julien, Lead Programmer, Open Information Security Foundation and Anne-Fleur Koolstra, Documentation Specialist, Open Information Security Foundation: For their willingness to share their wisdom and experience of Suricata via email for the past four months. John M. Weathersby, Jr., Executive Director, Open Source Software Institute: For allowing me the use of Institute equipment for the creation of a suitable testing
    [Show full text]