Étude Formelle Des Distributions De Logiciel Libre

Total Page:16

File Type:pdf, Size:1020Kb

Étude Formelle Des Distributions De Logiciel Libre Université Paris Diderot — Paris 7 École doctorale de Sciences Mathématiques de Paris Centre THÈSE pour obtenir le grade de DOCTEUR DE L’UNIVERSITÉ PARIS DIDEROT Spécialité : Informatique présentée par Jacob Pieter BOENDER Directeur : Roberto DI COSMO Étude formelle des distributions de logiciel libre A formal study of Free Software Distributions soutenue le 24 mars 2011 devant le jury composé de : M. Roberto DI COSMO directeur M. Jesús M. GONZÁLEZ-BARAHONA examinateur M. Carsten SINZ rapporteur M. Diomidis SPINELLIS examinateur M. Jean-Bernard STEFANI examinateur M. Ralf TREINEN examinateur M. Peter VAN ROY rapporteur 2 Contents C Résumé5 La théorie des paquets.............................6 Algorithmes et outils..............................8 Formalisation..................................9 Validation et analyse..............................9 Conclusions et perspectives.......................... 10 1 Introduction 11 1.1 F/OSS Software Distributions...................... 11 1.2 Contributions............................... 12 1.3 Structure.................................. 14 2 Definitions 17 2.1 Existing package formats......................... 17 2.2 Definitions................................. 28 2.3 Installability................................ 30 2.4 Dependencies............................... 32 3 Strong dependencies and conflicts 37 3.1 Strong dependencies........................... 37 3.2 Dominators................................ 39 3.3 Dominators in strong dependency graphs and control flow graphs 41 3.4 Strong conflicts.............................. 46 4 Algorithms 53 4.1 Installability................................ 53 4.2 Strong dependencies........................... 54 4.3 Dominators................................ 59 4.4 Strong conflicts.............................. 60 5 Tools 63 5.1 distcheck.................................. 63 5.2 dose..................................... 63 5.3 Ceve.................................... 65 5.4 Pkglab................................... 66 6 Formalisation 71 6.1 Repository................................. 71 6.2 Dependencies............................... 72 6.3 The dependency cone........................... 76 6.4 Repository properties........................... 78 6.5 Installability................................ 80 6.6 Strong dependencies and conflicts................... 82 3 6.7 Triangle conflicts............................. 84 7 Experimentation and validation 91 7.1 Repositories................................ 91 7.2 Run time of the installability algorithm................ 93 7.3 Run time of the strong dependency algorithm............ 95 7.4 The dominator graph........................... 96 7.5 Run time of the strong conflict algorithm............... 98 8 Graph properties of distributions 109 8.1 Small world properties.......................... 109 8.2 Distributions as small world networks................. 111 9 Conclusion 125 9.1 Summary.................................. 125 9.2 Practical usage............................... 126 9.3 Related works............................... 127 9.4 Future work................................ 130 Acknowledgements 131 4 Résumé R De quoi s’agit-il ? —FERDINAND FOCH Comme l’indique le titre, dans cette thèse, il sera beaucoup question des distributions du logiciel libre (aussi connu sous l’abréviation F/OSS, free and open source software). Ces distributions sont extrêmement hétérogènes. Elles contiennent des lo- giciels de différentes provenances ; écrits dans des langages différents, avec des calendriers de publication différents et avec des procédures différentes. Pour gérer cette hétérogénéité, et pour avoir une façon simple et unique d’installer des logiciels, les systèmes de paquetage ont été développés. Ceux-ci consistent en l’emballage d’un logiciel dans un paquet, qui contient des don- nées supplémentaires utilisées par un logiciel approprié, un gestionnaire de pa- quets. Le gestionnaire sert à installer les paquets et le logiciel qu’il contient de façon presque automatique. Les systèmes de paquetage diffèrent selon les distributions, mais les prin- cipes sont communs : une distribution a plusieurs dépôts, dont chacun contient plusieurs paquets, reliés entre eux par des relations spécifiques, notamment les dépendances et les conflits. Une dépendance d’un paquet a un autre indique que le premier paquet ne peut pas être installé sans que l’autre soit installé aussi ; un conflit entre deux paquets indique que ces deux paquets ne pourront jamais être installés en même temps. Les dépendances peuvent être disjonctives, c’est à dire qu’un paquet peut spécifier une dépendance sur plusieurs paquets, dont au moins un doit être installé pour satisfaire à la dépendance. Tout ceci fait que le problème de l’installabilité d’un paquet est d’une com- plexité comparable au problème SAT. Quand on y ajoute le fait que les distri- butions d’aujourd’hui ont une taille importante (la version la plus récente de Debian contient 22 000 paquets), il devient clair qu’il est très important d’avoir des algorithmes rapides et efficaces. Les quatre sujets principaux abordés dans cette thèse se résument comme suit : • D’abord, nous présentons un modèle formel qui réunit les propriétés principales des systèmes de paquetage les plus courantes, et nous iden- tifions des relations sémantiques entre paquets qui peuvent être utilisées pour trouver des erreurs et assurer la qualité des distributions de logiciel libre ; • Ensuite, nous présentons des algorithmes efficaces pour manipuler des dépôts de paquets et calculer les relations mentionnées ci-dessus ; tous ces algorithmes ont été implémentés dans la langage de programmation OCaml, et incorporés dans une librairie de manipulation et analyse de paquets qui s’appelle dose3 ; 5 • Nous avons encodé notre modèle dans l’assistant de preuves Coq, et uti- lisé cet encodage pour vérifier quelques-uns des théorèmes les plus im- portants qui correspondent aux étapes les plus compliquées des algo- rithmes déjà présentés ; • Finalement, nous avons validé nos algorithmes sur des distributions de logiciel libre existantes, et nous présentons une analyse extensive de la structure générale de ces distributions, notamment les caractéristiques dites «petit monde» de la structure du graphe sous-jacent. La théorie des paquets Dans cette partie de la thèse, qui correspond aux chapitres2 et3, nous com- mençons par expliquer les concepts communs entre les différents systèmes de paquetage. Systèmes de paquetage alpha echo bravo charlie delta # foxtrot (a) Dépendances et conflits (b) Paquet virtuel FIGURE 1 – Dépôts d’exemple Considérons la figure 1a. Ici, le paquet alpha a une dépendance simple sur le paquet bravo, ce qui exprime la nécessité d’installer bravo dès lors qu’on veut installer alpha. En revanche, l’autre dépendance d’alpha est disjonctive sur charlie et delta. Alors pour installer alpha il faudrait aussi installer soit charlie, soit delta, soit les deux. La situation est semblable pour echo : pour installer echo, on a besoin de delta ou foxtrot. Cependant, il n’est pas possible ici d’installer les deux en même temps, parce que delta et foxtrot sont en conflit (indiqué par le dièse). Dans la plupart des systèmes de paquetage, il existe la notion de paquets virtuels. Comme leur nom l’indique, ce sont des paquets qui n’existent pas vraiment, mais qui peuvent être fournis par des autres paquets. Considérons la figure 1b : ici, le paquet zulu est un paquet virtuel, qui est fourni par bravo, charlie et delta. Dans ce cas, alpha a une dépendance sur zulu ; une dépendance sur un paquet virtuel peut être satisfaite par n’importe quel fournisseur du paquet virtuel, et la situation revient donc à une dépendance disjonctive d’alpha sur bravo, charlie ou delta. 6 alpha echo delta charlie # zulu bravo Quant à echo, il y a un conflit entre ce paquet et zulu. Un conflit avec un paquet virtuel se traduit par un conflit avec chaque fournisseur de ce paquet virtuel : autrement dit, echo est en conflit avec à la fois bravo, charlie et delta. Il y a des différences de détail entre les systèmes de paquetage (dont les plus utilisés sont le système de Debian et RPM), mais ils sont tous conformes au schéma expliqué ci-dessus. Relations sémantiques entre paquets Les relations entre paquets qu’on a détaillées dans la section précédente ne nous donnent pas toute l’histoire. Par exemple, le simple fait qu’il y a une dé- pendance entre deux paquets ne signifie pas forcément que l’un doit être ins- tallé pour installer l’autre (la dépendance pourrait être disjonctive). Il pourrait aussi y avoir des paquets qui, sans être en conflit direct, ne sont néanmoins pas installable en même temps1. Pour pallier à ce problème, nous installons des relations sémantiques qui nous aident à voir plus clairement la structure d’un dépôt. Commençons par les dépendances. Nous définissons qu’il existe une dépen- dance forte entre un paquet p et un autre paquet q (tous les deux contenu dans un dépôt R) si et seulement si : • p est installable2 dans R ; • chaque installation de p dans R contient q. Avec cette relation de dépendance forte, on résume l’essentiel de la dépen- dance : un paquet a des dépendances fortes sur tous les paquets qui lui sont absolument indispensables. Notons aussi que la relation de dépendance forte, contrairement aux dépendances normales, est transitive. Il est également intéressant de considérer les dépendances fortes en sens inverse : un paquet dont beaucoup d’autres paquets dépendent fortement est nécessairement un paquet important dans la distribution : si ce paquet
Recommended publications
  • 2020 Spring Product Guide Final-Min
    2020 SPRING INTEGRATOR PRODUCT GUIDE COME SWIM WITH THE BIG FISH November 9 – 11, 2020 | Cleveland, OH | Huntington Convention Center Take control of your business success. Gain insights from the integration industry elite this November at Total Tech Summit. This uniquely powerful by invitation-only event drives extraordinary progress in the integration industry. Total Tech Summit is where the industry elite gather. Total Tech Summit helps to grow and improve your company through: › Educational, deep-dive sessions from the industry elite › 1-on-1 and boardroom meetings with new vendors that can take your offerings from better to best › Networking at every turn. Connect with both integrators in your industry and beyond to help give you fresh ideas and business strategies › Complimentary flights, hotel, “Gathering of professionals that registration, and meals to help you are non-competition to collaborate focus on what matters most on ideas to grow business in profits, procurement, strategies, staffing and general business practices is a wealth of knowledge at the cost of a couple days’ time and to also have the added benefit of meeting one on one with manufacturers that you may not have reached out to.” — John Rudolph, Vice President, PCD To learn more and to apply to join the best in the industry, please visit www.totaltechsummit.com Table of Contents Page 6 Audio ▶ Page 23 Control/Networking/Energy Management ▶ Page 36 Home Enhancements (central vacuum, wire and cable, tools, testers, furniture) ▶ Page 48 Security ▶ Page 53 Video ▶ Page
    [Show full text]
  • Greg Kroah-Hartman [email protected] Github.Com/Gregkh/Presentation-Kdbus
    kdbus IPC for the modern world Greg Kroah-Hartman [email protected] github.com/gregkh/presentation-kdbus Interprocess Communication ● signal ● synchronization ● communication standard signals realtime The Linux Programming Interface, Michael Kerrisk, page 878 POSIX semaphore futex synchronization named eventfd unnamed semaphore System V semaphore “record” lock file lock file lock mutex threads condition variables barrier read/write lock The Linux Programming Interface, Michael Kerrisk, page 878 data transfer pipe communication FIFO stream socket pseudoterminal POSIX message queue message System V message queue memory mapping System V shared memory POSIX shared memory shared memory memory mapping Anonymous mapping mapped file The Linux Programming Interface, Michael Kerrisk, page 878 Android ● ashmem ● pmem ● binder ashmem ● POSIX shared memory for the lazy ● Uses virtual memory ● Can discard segments under pressure ● Unknown future pmem ● shares memory between kernel and user ● uses physically contigous memory ● GPUs ● Unknown future binder ● IPC bus for Android system ● Like D-Bus, but “different” ● Came from system without SysV types ● Works on object / message level ● Needs large userspace library ● NEVER use outside an Android system binder ● File descriptor passing ● Used for Intents and application separation ● Good for small messages ● Not for streams of data ● NEVER use outside an Android system QNX message passing ● Tight coupling to microkernel ● Send message and control, to another process ● Used to build complex messages
    [Show full text]
  • Performance Tuning Guide
    Red Hat Enterprise Linux 7 Performance Tuning Guide Optimizing subsystem throughput in Red Hat Enterprise Linux 7 Red Hat Subject Matter ExpertsLaura Bailey Charlie Boyle Red Hat Enterprise Linux 7 Performance Tuning Guide Optimizing subsystem throughput in Red Hat Enterprise Linux 7 Laura Bailey Red Hat Customer Content Services Charlie Boyle Red Hat Customer Content Services Red Hat Subject Matter Experts Edited by Milan Navrátil Red Hat Customer Content Services [email protected] Legal Notice Copyright © 2016 Red Hat, Inc. and others. This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed. 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. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
    [Show full text]
  • Understanding and Improving Security of the Android Operating System
    Syracuse University SURFACE Dissertations - ALL SURFACE December 2016 Understanding and Improving Security of the Android Operating System Edward Paul Ratazzi Syracuse University Follow this and additional works at: https://surface.syr.edu/etd Part of the Engineering Commons Recommended Citation Ratazzi, Edward Paul, "Understanding and Improving Security of the Android Operating System" (2016). Dissertations - ALL. 592. https://surface.syr.edu/etd/592 This Dissertation is brought to you for free and open access by the SURFACE at SURFACE. It has been accepted for inclusion in Dissertations - ALL by an authorized administrator of SURFACE. For more information, please contact [email protected]. ABSTRACT Successful realization of practical computer security improvements requires an understanding and insight into the system’s security architecture, combined with a consideration of end-users’ needs as well as the system’s design tenets. In the case of Android, a system with an open, modular architecture that emphasizes usability and performance, acquiring this knowledge and insight can be particularly challenging for several reasons. In spite of Android’s open source philosophy, the system is extremely large and complex, documentation and reference materials are scarce, and the code base is rapidly evolving with new features and fixes. To make matters worse, the vast majority of Android devices in use do not run the open source code, but rather proprietary versions that have been heavily customized by vendors for product dierentiation. Proposing security improvements or making customizations without suicient insight into the system typically leads to less-practical, less-eicient, or even vulnerable results. Point solutions to specific problems risk leaving other similar problems in the distributed security architecture unsolved.
    [Show full text]
  • Pagedout 002 Beta2.Pdf
    It seems PO!#1 was received well. OK, that was an understatement - the download count (over 135k at the moment of writing these words) and the positive feedback we've received blew my predictions out of the water! It seems Paged Out! Institute our readers appreciated the old-school zine feel, liked the https://pagedout.institute/ experimental one-page format, and enjoyed the topic choice. Project Lead At the same time I realize we still have a long way to go on multiple fronts. To give you a glimpse of what's on my mind, here Gynvael Coldwind are three most urgent matters. Executive Assistant First of all, the print files proved to be more tricky than Arashi Coldwind expected. Thankfully the first version is being battle-tested at a printing house as we speak, so it shouldn't be long now. Once we have these, we'll claim we've reached beta2. DTP Programmer foxtrot_charlie Secondly, and even more importantly, we have even more delays with optimizing the PDFs towards screen readers (text-to- DTP Advisor speech engines and the like). This requires more work both on the process side and technical side, but we'll get there. And tusiak_charlie once we do, we'll call it the final version. Lead Reviewers And last, I'm thinking of re-working the article review process for Mateusz "j00ru" Jurczyk PO!#3 to distribute the review work more evenly both in terms of time and between reviewers, and to automate certain things we KrzaQ usually check for. So, if you've written an article for PO!#1 or PO! #2, note that there will be changes ("the only constant thing is Reviewers change" and all that).
    [Show full text]
  • Crestron 3-Series Control Systems Reference Guide
    Crestron 3-Series Control Systems Reference Guide A portion of the code in this product is covered by the Microsoft® Public License (Ms-PL), which can be found at www.microsoft.com/opensource/licenses.mspx. This device includes an aggregation of separate independent works that are each generally copyrighted by Crestron Electronics, Inc., with all rights reserved. One of those independent works, Linux Bridge Project, is copyrighted under the GNU GENERAL PUBLIC LICENSE, Version2, reproduced in “GNU General Public License” on page 78, where the corresponding source code is available at: ftp://ftp.crestron.com/gpl. The specific patents that cover Crestron products are listed at patents.crestron.com/. Crestron, the Crestron logo, 3-Series, 3-Series Control System, Core 3, Core 3 OS, Core 3 UI, Cresnet, Crestron Mobile Pro, Crestron Toolbox, e-Control, Fusion RV, VisionTools, and VT Pro-e are either trademarks or registered trademarks of Crestron Electronics, Inc. in the United States and/or other countries. BACnet is either a trademark or registered trademark of American Society of Heating, Refrigerating and Air-Conditioning Engineers, Inc. in the United States and/or other countries. iPad and iPhone are either trademarks or registered trademarks of Apple, Inc. in the United States and/or other countries. Blu-ray Disc is a trademark or registered trademark of the Blu-ray Disc Association (BDA) in the United States and/or other countries. Android is either a trademark or registered trademark of Google, Inc. in the United States and/or other countries. Microsoft and Windows are either trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries.
    [Show full text]
  • Open Source Used in Cisco Findit Network Probe, Version 1.1.0
    Open Source Used In Cisco FindIT Network Probe 1.1.0.x Cisco Systems, Inc. www.cisco.com Cisco has more than 200 offices worldwide. Addresses, phone numbers, and fax numbers are listed on the Cisco website at www.cisco.com/go/offices. Text Part Number: 78EE117C99-157639917 Open Source Used In Cisco FindIT Network Probe 1.1.0.x 1 This document contains licenses and notices for open source software used in this product. With respect to the free/open source software listed in this document, if you have any questions or wish to receive a copy of any source code to which you may be entitled under the applicable free/open source license(s) (such as the GNU Lesser/General Public License), please contact us at [email protected]. In your requests please include the following reference number 78EE117C99-157639917 En ce qui a trait au logiciel gratuit ou à exploitation libre figurant dans ce document, si vous avez des questions ou souhaitez recevoir une copie du code source, auquel vous avez droit en vertu des licences gratuites ou d'exploitation libre applicables (telles que licences GNU Lesser/General Public), veuillez communiquer avec nous à l'adresse external- [email protected]. Dans vos demandes, veuillez inclure le numéro de référence 78EE117C99-157639917 Contents 1.1 Angular Bootstrap 0.12.0 1.1.1 Available under license 1.2 Angular UI Sortable 1.1.1 1.2.1 Available under license 1.3 angular-chart.js 0.7.2 1.3.1 Available under license 1.4 Angular-dashboard-frmework 0.8.0 1.4.1 Available under license 1.5
    [Show full text]
  • The LPIC-2 Exam Prep I
    The LPIC-2 Exam Prep i The LPIC-2 Exam Prep Copyright 2013 Snow B.V. The LPIC-2 Exam Prep ii Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013 Snow B.V. Copyright 2013 Snow B.V. The LPIC-2 Exam Prep iii COLLABORATORS TITLE : The LPIC-2 Exam Prep ACTION NAME DATE SIGNATURE WRITTEN BY Heinrich W. 2010 Klöpping, Beno T.J. Mesman, Piet W. Plomp, Willem A. Schreuder, Ricky Latupeirissa, Patryck Winkelmolen, Many, many Snow B.V. colleagues for peer reviewing and authoring updates., Jos Jansen, and Joost Helberg REVISION HISTORY NUMBER DATE DESCRIPTION NAME Copyright 2013 Snow B.V. The LPIC-2 Exam Prep iv Contents 0 Capacity Planning (200) 1 0.1 Measure and Troubleshoot Resource Usage (200.1) . .1 0.1.1 iostat .....................................................2 0.1.2 vmstat ....................................................2 0.1.3 netstat ....................................................3 0.1.4 ps .......................................................4 0.1.5 pstree .....................................................5 0.1.6 w .......................................................5 0.1.7 lsof ......................................................5 0.1.8 free ......................................................6 0.1.9 top . .6 0.1.10 uptime ....................................................7 0.1.11 sar ......................................................7 0.1.12 Match / correlate system symptoms with likely problems . .8 0.1.13 Estimate throughput and identify bottlenecks in a system including networking . .8 0.2 Predict Future Resource Needs (200.2) . .8 0.2.1 ........................................................9 0.2.2 Predict future growth . .9 0.2.3 Resource Exhaustion . .9 0.3 Questions and answers . 10 1 Linux Kernel (201) 11 1.1 Kernel Components (201.1) . 11 1.1.1 Different types of kernel images .
    [Show full text]
  • Stable and Should Be Used Instead
    SIMP Documentation THE SIMP TEAM Dec 09, 2020 Contents 1 Level of Knowledge 3 1.1 Quick Start................................................4 1.2 Changelogs................................................4 1.3 SIMP Getting Started Guide....................................... 103 1.4 SIMP User Guide............................................ 119 1.5 SIMP HOWTO Guides.......................................... 208 1.6 Frequently Asked Questions....................................... 281 1.7 Contributing to SIMP.......................................... 290 1.8 SIMP Security Concepts......................................... 326 1.9 SIMP Security Control Mapping..................................... 344 1.10 Vulnerability Supplement........................................ 705 1.11 Help................................................... 707 1.12 License.................................................. 708 1.13 Contact.................................................. 709 1.14 Glossary of Terms............................................ 709 Index 725 i ii SIMP Documentation This is the documentation for the 6.5.0-1 release of SIMP, which is compatible with CentOS and Red Hat Enterprise Linux (RHEL). This guide will walk a user through the process of installing and managing a SIMP system. It also provides a mapping of security features to security requirements, which can be used to document a system’s security conformance. Warning: Be EXTREMELY CAREFUL when performing copy/paste operations from this document! Different web browsers and operating
    [Show full text]
  • An Overview of the Verification of the Sel4 Microkernel
    An Overview of the Verification of the seL4 Microkernel Lukas Stevens Seminar | Formal Proof in Mathematics and Computer Science 21st June 2018 Contents 1 What is the seL4 Microkernel? 1 1.1 A Brief History of Microkernels . .1 1.2 seL4: Putting the Security in L4 . .2 1.3 Operating System Verification: An Overview . .2 2 Engineering the seL4 Kernel 3 2.1 Design Process for Verification . .3 2.2 Formal Methods of the Correctness Proof . .5 3 Layers of the Functional Correctness Proof 6 3.1 Abstract Specification . .6 3.2 Executable Specification . .7 3.3 Low-level Implementation in C . .8 3.4 Refinement by Forward Simulation . .9 3.5 The Costs and Benefits of Verification . 11 4 Summary and Outlook 13 1 What is the seL4 Microkernel? 1.1 A Brief History of Microkernels Our interactions with computers are shaped by operating systems (OS) such as Linux, Windows and Android. Therefore, understanding the inner workings of operating systems is not only interesting, but also important. At the core of every OS resides the kernel [Lin]. The kernel is responsible for providing the necessary abstractions that are needed to run the rest of the OS and user facing applications. These abstractions include memory management, i.e. mapping of virtual addresses into physical memory, and scheduling of threads. In order to provide these services, the kernel is the first part of the OS loaded into memory at startup, and it retains complete control over the whole system after that. Owing to its critical nature, the kernel is usually loaded into a protected memory region, which can not be accessed by the rest of the OS or user applications.
    [Show full text]
  • Resource Management Guide
    Red Hat Enterprise Linux 7 Resource Management Guide Managing system resources on Red Hat Enterprise Linux 7 Milan Navrátil Eva Majoršinová Peter Ondrejka Douglas Silas Martin Prpič Rüdiger Landmann Red Hat Enterprise Linux 7 Resource Management Guide Managing system resources on Red Hat Enterprise Linux 7 Milan Navrátil Red Hat Customer Content Services [email protected] Eva Majoršinová Red Hat Customer Content Services Peter Ondrejka Red Hat Customer Content Services Douglas Silas Red Hat Customer Content Services Martin Prpič Red Hat Product Security Rüdiger Landmann Red Hat Customer Content Services Legal Notice Copyright © 2016 Red Hat, Inc. This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed. 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. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux ® is the registered trademark of Linus Torvalds in the United States and other countries. Java ® is a registered trademark of Oracle and/or its affiliates. XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
    [Show full text]
  • Lttng: the Linux Trace Toolkit Next Generation a Comprehensive User's Guide (Version 2.3 Edition)
    DRDC Document Number: DRDC-RDDC-2016-N036 LTTng: The Linux Trace Toolkit Next Generation A Comprehensive User's Guide (version 2.3 edition) Daniel U. Thibault, DRDC Valcartier Research Centre The contents are published as open-access documentation distributed under the terms of the Creative Commons Attribution 4.0 International Public License (CC-BY 4.0, http://creativecommons.org/licenses/by/4.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original author and source are credited. Defence Research and Development Canada External Literature DRDC-RDDC-2016-N036 June 2016 © Her Majesty the Queen in Right of Canada, as represented by the Minister of National Defence, 2016 © Sa Majesté la Reine (en droit du Canada), telle que représentée par le ministre de la Défense nationale, 2016 IMPORTANT INFORMATIVE STATEMENTS Work conducted for project 15bl, HeLP-CCS: Host-Level Protection of Critical Computerized Systems Template in use: SR Advanced (2010) Template_EN (2015-11-05).dotm © Her Majesty the Queen in Right of Canada, as represented by the Minister of National Defence, 2016. LTTng: The Linux Trace Toolkit Next Generation: A Comprehensivve User's Guide (version 2.3 edition) is made available under the Creative Commons Attribution 4.0 Innternational Public License (CC-BY 4.0, http://creativecommons.org/licenses/by/4.0). © Sa Majesté la Reine (en droit du Canada), telle que représentée par le ministre de la Défense nationale, 2016. LTTng: The Linux Trace Toolkit Next Generation: A Comprehensive User's Guide (version 2.3 edition) est rendu disponible sous la licence publique Creative Commons Attribution 4.0 International (CC-BY 4.0, http://creativecommons.org/licenses/by/4.0/deed.fr).
    [Show full text]