DOCSLIB.ORG

Governance in Collaborative Open Source Software Development Organizations: a Comparative Analysis of Two Case Studies

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Governance in Collaborative Open Source Software Development Organizations: a Comparative Analysis of Two Case Studies Governance in Collaborative Open Source Software Development Organizations: A Comparative Analysis of two Case Studies Master’s thesis Faculty of Business, Economics and Social Sciences University of Bern submitted to Dr. Matthias Stürmer Research Center for Digital Sustainability Institute of Information Systems by Winkelmann, Rahel from Siselen 11th semester Matriculation nr.: 09-127-788 Study address: Huberstrasse 22 3008 Bern (Tel. 078 758 58 96) (e-Mail: [email protected]) Bern, 20.01.2015 Abstract While loose cooperation among several actors is common in the open source sector, companies merging into a professionally governed collaborative open source software development organization across industries is an emerging phenomenon. The purpose of this thesis is to shed light on this new approach of software development by creating a framework for building a collaborative open source software development organization. A comparative analysis examines the governance models of two different collaborative open source software development organizations from the organizational, financial and legal perspective and reveals the autonomous and the affiliated organization type and their key characteristics. Based on these findings and by means of four expert interviews a framework consisting of eight criteria that need to be considered in order to build a collaborative open source software development organization is created. Zusammenfassung In der Open Source Branche ist es gängig, dass sich verschiedene Akteure zur Softwareentwicklung zu losen Konsortien zusammenschliessen. Unternehmen, welche sich im professionellen Rahmen zu einer Organisation zusammenschliessen um gemeinsam Open Source Software zu entwickeln, sind jedoch ein neues Phänomen. Der Zweck dieser Arbeit ist es Aufschluss über diesen neuen Ansatz von Softwareentwicklung zu geben. Dies geschieht anhand der Entwicklung eines Rahmenkonzeptes über die Bildung einer Organisation, deren Mitglieder gemeinsam Open Source Software entwickeln. Eine vergleichende Analyse untersucht die Governance Modelle von zwei unterschiedlichen solchen Organisationen von der organisationalen, finanziellen und rechtlichen Perspektive und erläutert den autonomen und den angegliederten Organisationstyp mit den jeweiligen Kerncharakteristiken genauer. Basierend auf diesen Forschungsergebnissen und mit Hilfe von vier Experteninterviews wird ein Rahmenkonzept mit acht Kriterien, welche es zur Bildung einer solchen Organisation zu berücksichtigen gibt, erstellt. Acknowledgement • Dr. Matthias Stürmer for his support, motivation and for sharing his open source knowledge and experience. • Steve Crumb (Executive Director, GENIVI Alliance), Ralph Mueller (Managing Director Eclipse Foundation Europe GmbH), Jeremiah Foster (Community Manager, GENIVI Alliance) and Claus-Peter Wiedemann (Lead License Review Team, GENIVI Alliance) for four interesting conversations and sharing their knowledge and experience. • Gabriela Gnägi and Nicole Perreten for revising the thesis. Table of Contents I Table of Contents ABSTRACT III ACKNOWLEDGEMENT IV 1 INTRODUCTION 1 1.1 Background 1 1.2 Problem Description 1 1.3 Aim of the Thesis 3 1.4 Structure of the Thesis 4 2 RESEARCH APPROACH 5 2.1 Secondary Data Collection 5 2.1.1 Literature and Online Research 5 2.1.2 Selection of Cases 7 2.2 Primary Data Collection: Qualitative Expert Interviews 10 3 INTRODUCTION TO COLLABORATION IN OPEN SOURCE SOFTWARE DEVELOPMENT ORGANIZATIONS 12 3.1 Open Source Software (OSS) 12 3.2 The Open Source Initiative (OSI) 13 3.3 Legal Aspect of Open Source: Intellectual Property Rights and Licensing 13 3.4 Open Innovation 15 3.5 Collaborative Open Source Software Development 17 3.5.1 Open Source Software Platform (OSS Platform) 17 3.5.2 Open Source Software Community (OSS Community) 18 3.5.3 Open Source Software Project (OSS Project) 21 3.5.4 Open Source Software Foundation (OSS Foundation) 22 3.5.5 Open Source Software Ecosystem (OSS Ecosystem) 22 3.5.6 Adapted Onion Model 23 4 ANALYSIS OF THE GENIVI ALLIANCE AND THE POLARSYS WORKING GROUP 26 4.1 The GENIVI Alliance (GA) 26 4.1.1 Introduction to the GENIVI Alliance 26 Table of Contents II 4.1.2 Organizational Perspective 29 4.1.2.1 Organizational Structure 29 4.1.2.2 GENIVI Members 33 4.1.3 Legal Perspective 36 4.1.4 Financial Perspective 39 4.1.5 Adapted Onion Model 39 4.2 Eclipse Foundation (EF): The Case of the Polarsys Working Group 41 4.2.1 Introduction to the Eclipse Foundation and the Polarsys Working Group 41 4.2.2 Organizational Perspective 43 4.2.2.1 Organizational Structure 43 4.2.2.2 Polarsys Members 46 4.2.3 Legal Perspective 51 4.2.4 Financial Perspective 54 4.2.5 Adapted Onion Model 54 5 FINDINGS AND IMPLICATIONS 56 5.1 Comparative Analysis of the GENIVI Alliance and the Polarsys Working Group 56 5.1.1 Overall Aim 58 5.1.2 Organizational Perspective 58 5.1.2.1 Organizational Structure 59 5.1.2.2 Application Process 61 5.1.2.3 Membership Classification 62 5.1.3 Financial Perspective 65 5.1.4 Legal Perspective 66 5.2 Types of Collaborative Open Source Software Development Organizations 67 5.2.1 Autonomous Collaborative Open Source Software Development Organization 68 5.2.2 Affiliated Collaborative Open Source Software Development Organization 71 5.3 Framework for Building a Collaborative Software Development Organization 77 Table of Contents III 6 CONCLUSION 84 6.1 Future of Collaborative Open Source Software Development 84 6.2 Limitations and Suggestions for Further Research 87 APPENDIX 89 LIST OF FIGURES 111 LIST OF TABLES 112 LIST OF ABBREVIATIONS 113 REFERENCES 114 STATEMENT OF AUTONOMOUS AND INDEPENDENT WORK 122 PUBLICATION OF THE THESIS 123 Chapter 1: Introduction 1 1 Introduction 1.1 Background In recent years, software companies discovered a need to expand their research and development outside their organizational boundaries. Due to rapidly changing technology and the continually growing customer needs software companies were no longer able to provide the required functionalities and to remain competitive without external support. As a consequence of this trend, software companies started to cooperate and to build up networks for software development and software-based services, so called software ecosystems (Bosch 2009; Tiwana, Konsynsik and Busch 2010; Van den Berk, Jansen and Luinenburg 2010). Along with this movement the advancement of Linux and open source software experienced a boom and gained more and more significance (Linux Foundation 2014). Since it is nearly inevitable to encourage software development without making the software at least partially accessible to others, the software companies had to face the emergence of commercially used open source software. Open source software had no longer the reputation of a hacker- software but rather of a serious alternative to proprietary software. As a consequence of these two developments more and more proprietary software companies engaged in software ecosystems that were based on open source software (Benkler 2002; Fitzgerald 2006). 1.2 Problem Description With the commercialization of open source in the last decade (00s), research has paid growing attention to this arising phenomenon. The causes, incentives, advantages and objectives of open source software have been dealt with in many publications (Kogut and Metiu 2001; Raymond 2001; Lerner and Tirole 2002; Bonaccorsi and Rossi 2003; von Hippel and von Krogh 2003; Fitzgerald 2006; West and O’Mahony 2008). Despite the fact that all these papers, theses and journal articles agree on the collaborative approach of the open source movement, they are divided over the exact Chapter 1: Introduction 2 denotation of this collaboration in the open source domain. Researchers either create their own term in order to describe the collaborative phenomenon or use the already existing notations arbitrarily. So far, these collaborative software development constructs are usually initiated by software companies, thus from the perspective of the developers. Hence the companies whose core business is software development are building the corresponding platforms intending to save costs in the software development process (Riehle 2010). However, a new phenomenon concerning companies that are not positioned in the software development industry has emerged recently. An increasing number of companies, whose core business is not software development but are reliant upon the latest findings regarding their applied software pursue a collaborative software development approach through merging their resources across industries on an open source base. The joining together across industries means that software users in terms of companies as well as software developers are part of these collaborations in order to collectively develop software (Linux Foundation 2014). Considering the fact, that these collaborative software development constructs initiated by software users and not by software developers are only on the rise since a few years, there was little evidence that this phenomenon is relevant and part of the future software development. In 2014, however, the Linux Foundation published a trend report, which is based on a survey conducted with 686 software developers and business managers. Aside a few studies (Machbarkeitsstudie 2013; Liu, Hansen and Tu 2014) this report is one of the first that provides evidence of the practical relevance of collaborative software development on an open source base among commercially organized enterprises. The report (2014) reveals three
Load more

Recommended publications
  • The Next Generation Cloud: the Rise of the Unikernel
    The Next Generation Cloud: The Rise of the Unikernel A Xen Project publication April 2015 xenproject.org Docker and Linux container technologies dominate headlines today as a powerful, easy way to package applications, especially as cloud computing becomes more mainstream. While still a work-in-progress, they offer a simple, clean and lean way to distribute application workloads. With enthusiasm continuing to grow for container innovations, a related technology called unikernels is also beginning to attract attention. Known also for their ability to cleanly separate functionality at the component level, unikernels are developing a variety of new approaches to deploy cloud services. Traditional operating systems run multiple applications on a single machine, managing resources and isolating applications from one another. A unikernel runs a single application on a single virtual machine, relying instead on the hypervisor to isolate those virtual machines. Unikernels are constructed by using “library operating systems,” from which the developer selects only the minimal set of services required for an application to run. These sealed, fixed-purpose images run directly on a hypervisor without an intervening guest OS such as Linux. As well as improving upon container technologies, unikernels are also able to deliver impressive flexibility, speed and versatility for cross-platform environments, big data analytics and scale-out cloud computing. Like container-based solutions, this technology fulfills the promise of easy deployment, but unikernels also offer an extremely tiny, specialized runtime footprint that is much less vulnerable to attack. There are several up-and-coming open source projects to watch this year, including ClickOS, Clive, HaLVM, LING, MirageOS, Rump Kernels and OSv among others, with each of them placing emphasis on a different aspect of the unikernel approach.
    [Show full text]
  • A Linux in Unikernel Clothing Lupine
    A Linux in Unikernel Clothing Hsuan-Chi Kuo+, Dan Williams*, Ricardo Koller* and Sibin Mohan+ +University of Illinois at Urbana-Champaign *IBM Research Lupine Unikernels are great BUT: Unikernels lack full Linux Support App ● Hermitux: supports only 97 system calls Kernel LibOS + App ● OSv: ○ Fork() , execve() are not supported Hypervisor Hypervisor ○ Special files are not supported such as /proc ○ Signal mechanism is not complete ● Small kernel size ● Rumprun: only 37 curated applications ● Heavy ● Fast boot time ● Community is too small to keep it rolling ● Inefficient ● Improved performance ● Better security 2 Can Linux behave like a unikernel? 3 Lupine Linux 4 Lupine Linux ● Kernel mode Linux (KML) ○ Enables normal user process to run in kernel mode ○ Processes can still use system services such as paging and scheduling ○ App calls kernel routines directly without privilege transition costs ● Minimal patch to libc ○ Replace syscall instruction to call ○ The address of the called function is exported by the patched KML kernel using the vsyscall ○ No application changes/recompilation required 5 Boot time Evaluation Metrics Image size Based on: Unikernel benefits Memory footprint Application performance Syscall overhead 6 Configuration diversity ● 20 top apps on Docker hub (83% of all downloads) ● Only 19 configuration options required to run all 20 applications: lupine-general 7 Evaluation - Comparison configurations Lupine Cloud Operating Systems [Lupine-base + app-specific options] OSv general Linux-based Unikernels Kernel for 20 apps
    [Show full text]
  • Erlang on Physical Machine
    on $ whoami Name: Zvi Avraham E-mail: [email protected] /ˈkɒm. pɑː(ɹ)t. mɛntl̩. aɪˌzeɪ. ʃən/ Physicalization • The opposite of Virtualization • dedicated machines • no virtualization overhead • no noisy neighbors – nobody stealing your CPU cycles, IOPS or bandwidth – your EC2 instance may have a Netflix “roommate” ;) • Mostly used by ARM-based public clouds • also called Bare Metal or HPC clouds Sandbox – a virtual container in which untrusted code can be safely run Sandbox examples: ZeroVM & AWS Lambda based on Google Native Client: A Sandbox for Portable, Untrusted x86 Native Code Compartmentalization in terms of Virtualization Physicalization No Virtualization Virtualization HW-level Virtualization Containerization OS-level Virtualization Sandboxing Userspace-level Virtualization* Cloud runs on virtual HW HARDWARE Does the OS on your Cloud instance still supports floppy drive? $ ls /dev on Ubuntu 14.04 AWS EC2 instance • 64 teletype devices? • Sound? • 32 serial ports? • VGA? “It’s DUPLICATED on so many LAYERS” Application + Configuration process* OS Middleware (Spring/OTP) Container Managed Runtime (JVM/BEAM) VM Guest Container OS Container Guest OS Hypervisor Hardware We run Single App per VM APPS We run in Single User mode USERS Minimalistic Linux OSes • Embedded Linux versions • DamnSmall Linux • Linux with BusyBox Min. Linux OSes for Containers JeOS – “Just Enough OS” • CoreOS • RancherOS • RedHat Project Atomic • VMware Photon • Intel Clear Linux • Hyper # of Processes and Threads per OS OSv + CLI RancherOS processes CoreOS threads
    [Show full text]
  • A Comprehensive Overview Last Updated: January
    Project ACRN: A Comprehensive Overview Last updated: January 19, 2021 Content ❖ Introduction ❖ Architecture ❖ Value Proposition ❖ Key Capabilities ❖ Scenarios Introduction ACRN™ is a flexible, lightweight reference hypervisor, built with real-time and safety-criticality in mind, optimized to streamline embedded development through an open source platform. - A Linux Foundation Project Launched in March 2018 - Version 1.0 released in May 2019 - Version 2.0 released in June 2020 Overallarchitecture ACRN is a registered trademark of the Linux Foundation. *Other names and brands may be claimed as the property of others. Value Proposition - ACRN Small Footprint • Optimized for resource-constrained devices • Small codebase: less than 40,000 vs. >156,000 lines of code for datacenter-centric hypervisors Functional Safety & Hard Real-time • Heterogeneous Workloads Consolidation • Supports also the most demanding workloads: safety-critical and real- time Open-source with Flexible License • Permissive BSD license enables proprietary Guest OS • Business-friendly to adopt, modify and integrate • True open source with a vibrant Community ACRN reduces system deployment complexity, enables heterogeneous architectures, and provide TCO advantages Key Capabilities Functional Safety Hard Real-time MISRA-C Compliance Support hard or soft RT VM FuSa certification targeted Optimized for RT, e.g. no VMExit*, cache isolation Security & Isolation Rich I/O Mediation Full isolation for mixed criticality workloads Graphics, Audio, USB… Intel VT backed isolation Industry
    [Show full text]
  • Vms, Unikernels and Containers: Experiences on the Performance of VirtualizaOn Technologies
    VMs, Unikernels and Containers: Experiences on the Performance of Virtualizaon Technologies Felipe Huici, Filipe Manco, Jose Mendes, Simon Kuenzer NEC Europe Ltd. (Heidelberg) In the Beginning… VM In the Beginning… “Tinyfied VMs” VM In the Beginning… “Tinyfied VMs” unikernels VM In the Beginning… “Tinyfied VMs” containers unikernels VM In the Beginning… “Tinyfied VMs” containers unikernels VM Virt. Technology Benchmarking • Metrics: – VM Image and memory consump=on – VM creaon =me – Delay – Throughput Virt. Technology Benchmarking • Metrics: – VM Image and memory consump=on – VM creaon =me – Delay – Throughput higher lower overhead overhead Virt. Technology Benchmarking • Metrics: – VM Image and memory consump=on – VM creaon =me – Delay – Throughput higher lower overhead overhead Virt. Technology Benchmarking • Metrics: – VM Image and memory consump=on – VM creaon =me – Delay – Throughput higher lower overhead overhead Virt. Technology Benchmarking • Metrics: – VM Image and memory consump=on – VM creaon =me – Delay – Throughput higher lower overhead overhead Virt. Technology Benchmarking • Metrics: – VM Image and memory consump=on – VM creaon =me – Delay – Throughput higher lower overhead overhead Virt. Technology Benchmarking • Metrics: – VM Image and memory consump=on – VM creaon =me – Delay – Throughput ? higher lower overhead overhead Virt. Technology Benchmarking • Metrics: – VM Image and memory consump=on – VM creaon =me – Delay – Throughput higher lower overhead overhead Virt. Technology Benchmarking • Metrics: – VM Image and memory consump=on – VM creaon =me – Delay – Throughput ? higher lower overhead overhead Virtualizaon Technology Benchmarking • Metrics: – VM image and memory consump=on: ls, top, xl – VM creaon =me: SYN flood + RST detec=on – Throughput: iperf, guest to host (TCP traffic) – RTT: ping flood • VM-based tests run on both Xen and KVM • Hardware: x86_64 server with an Intel Xeon E5-1630 v3 3.7GHz CPU (4 cores), 32GB RAM.
    [Show full text]
  • Design a System That “Just Works” the Arm Serverready Program and Beyond
    Design a System that “Just Works” The Arm ServerReady Program and Beyond November 2019 White Paper 1 Contents Page Topic 3 Executive Summary 3 1. Introduction 3 2. Arm ServerReady Program 3 2.1 Background and History 4 2.2 Arm Standards-Based Approach 6 3. Arm Server Advisory Committee (ServerAC) 6 3.1 ServerAC Development Process 8 4. Arm Server Standards 8 4.1 Server Base System Architecture (SBSA) 8 4.2 Server Base Boot Requirements (SBBR) 9 4.3 Server Base Security Guide (SBSG) 10 4.4 Server Base Manageability Requirements (SBMR) 11 5. Architectural Compliance Suites 12 5.1 Arm ServerReady Players and Responsibilities 15 6. Conclusion 16 7. Glossary 2 Executive Summary This whitepaper describes the ServerReady program, certification process, and Arm’s standards-based approach to system development. This approach is not limited to servers, it is suitable for other use cases, including edge and client devices, if standard operating systems are used. The intended audience is Arm-based processors and systems developers and integrators. By reading this paper, you will learn about Arm’s standards- based approach for development, and how to design and certify systems with the Arm ServerReady program. 1. Introduction In order to design a system that “just works” for the end user, with the ability to install and run standard operating systems (e.g. Windows, RHEL, VMWare, etc…) out-of-the-box, a set of minimum hardware and firmware requirements must be followed. For the Arm Ecosystem, such a need first surfaced in the server segment. The Arm ServerReady compliance program provides this “just works” solution for servers, enabling partners to deploy Arm servers with confidence.
    [Show full text]
  • Operator and Service Manual Standard 30 MF
    Standard 30 MF 110-700 Operator and Service Manual Raytheon Anschütz GmbH Postfach 11 66 D-24100 Kiel Germany Tel +49-4 31-30 19-0 Fax +49-4 31-30 19 464 Email [email protected] Edition: 01 www.raytheon-anschuetz.com 10000000756 Dieses Dokument sowie dessen Inhalt sind This document and its content are copyright urheberrechtlich geschützt. Die Weitergabe, protected. Distribution, reproduction and Vervielfältigung und Speicherung sowie die storage as well as translation and exploitation Übersetzung wie auch Verwendung dieses of this document and its content, in whole or Dokuments oder dessen Inhalts, als Ganzes in parts and regardless of what form, are oder in Teilen und egal in welcher Form, ist prohibited without prior express written ohne vorherige ausdrückliche schriftliche permission. Offenders will be held liable for Genehmigung nicht gestattet. the payment of damages. Zuwiderhandlungen verpflichten zu Schadenersatz. Änderungen dieses Dokuments und dessen Changes and modification to this document Inhalt bleiben vorbehalten. and its content reserved. Standard 30 MF 110-700 Operator and Service Manual This manual has been drawn up as a description and reference work. It will help answer questions and will solve problems in the quickest possible manner. Before operating the equipment read and follow the instructions and hints provided in this manual. For this purpose refer to the table of contents and read the corresponding chapters thoroughly. If you have any further questions, please contact us at the following address: RAYTHEON ANSCHÜTZ GMBH Tel. +49 431 / 3019 - 0 Zeyestr. 16 - 24 Fax +49 431 / 3019 - 291 D-24106 Kiel Germany All rights reserved.
    [Show full text]
  • User Manual Piezo Positioning Electronic ANC300
    Version: 3. 1 Modified: January 2014 Products: ANC300, ANM150, ANM200, ANM300 Firmware: 18 -04 -2012 User Manual Piezo Positioning Electronic ANC300 Open source software notice The ANC300 and its modules (ANM150, ANM200, and ANM300) include certain open source or other software originating from third parties that is subject to the GNU General Public License (GPL), GNU Library/Lesser General Public License (LGPL) and different and/or additional copyright licenses, disclaimers and notices. You may obtain a complete corresponding machine-readable copy of the source code of such software under the GPL or LGPL from attocube systems. attocube sys- tems offers to provide such source code to you on CD-ROM for a charge covering the cost of performing such distribution, such as the cost of media, shipping and handling, upon written request to: attocube systems AG Königinstrasse 11a RGB D-80539 München Germany This offer is valid for a period of three (3) years from the date of the distribution of this product by attocube. ATTOCUBE SYSTEMS AG MAKES NO REPRESENTATION ABOUT THE SUITABILITY OF THIS SOURCE CODE FOR ANY PURPOSE. IT IS PROVIDED "AS IS" WITHOUT EXPRESS OR IMPLIED WARRANTY OF ANY KIND. ATTOCUBE SYSTEMS AG DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOURCE CODE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL ATTOCUBE SYSTEMS AG BE LIABLE FOR ANY SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE, OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOURCE CODE.
    [Show full text]
  • Software Just Works on Arm-Based Devices
    Software Just Works on Arm-based Devices White paper - Version 2 Contents 1 Glossary 5 2 Executive Summary 7 3 Introduction 8 4 Arm System Architecture 10 4.1 Arm standards-based approach 10 4.2 Base System Architecture and its supplements 11 4.3 Base Boot Requirements 13 5 Architectural Compliance Suite 14 5.1 SBSA Architecture Compliance Suite 14 5.2 Enterprise Architecture Compliance Suite 14 6 Arm SystemReady Program 15 6.1 Arm SystemReady Program 15 6.2 Arm SystemReady Certification Process 17 7 Pre-Silicon Compliance Testing 18 8 Security Extension 19 9 SystemReady Compliance 20 9.1 BSA Compliance 20 9.2 BBR Compliance 20 10 Use Cases 22 11 Conclusion 23 1 Arm Non-Confidential Document Licence (“Licence”) This Licence is a legal agreement between you and Arm Limited (“Arm”) for the use of Arm’s intellectual property (including, without limitation, any copyright) embodied in the document accompanying this Licence (“Document”). Arm licenses its intellectual property in the Document to you on condition that you agree to the terms of this Licence. By using or copying the Document you indicate that you agree to be bound by the terms of this Licence. “Subsidiary” means any company the majority of whose voting shares is now or hereafter owner or controlled, directly or indirectly, by you. A company shall be a Subsidiary only for the period during which such control exists. This Document is NON-CONFIDENTIAL and any use by you and your Subsidiaries (“Licensee”) is subject to the terms of this Licence between you and Arm.
    [Show full text]
  • A Performance Benchmarking Analysis of Hypervisors, Containers and Unikernels on Armv8 and X86 Cpus Eucnc 2018, Ljubljana, Slovenia June 18-21
    A performance benchmarking analysis of Hypervisors, Containers and Unikernels on ARMv8 and x86 CPUs EuCNC 2018, Ljubljana, Slovenia June 18-21 [email protected] www.virtualopensystems.com Authorship and sponsorship Virtual Open Systems is a high-tech software company active in open source virtualization solutions and custom services for complex mixed-criticality automotive systems, NFV networking infrastructures, mobile devices and in general for embedded heterogeneous multicore systems around new generation processor architectures. This work is done in the context of the H2020 “Next Generation Platform as a Service” project (www.ngpaas.eu). 2 Virtual Open Systems Confidential & Proprietary Agenda Objectives Evaluated Solutions – Virtual Machines – Containers – Unikernels Benchmark configuration Benchmark results Conclusion 3 Virtual Open Systems Confidential & Proprietary Agenda Objectives Evaluated Solutions – Virtual Machines – Containers – Unikernels Benchmark configuration Benchmark results Conclusion 4 Virtual Open Systems Confidential & Proprietary Objectives Software Defined Network (SDN) and Network Function Virtualization (NFV) technologies are emerging in the Edge Computing Efficient virtualization technologies are becoming crucial New lightweight techniques (Containers, Unikernels) have emerged This work focuses on comparing the performance of open- source virtualization technologies on X86 and ARMv8 5 Virtual Open Systems Confidential & Proprietary Agenda Objectives Evaluated Solutions – Virtual
    [Show full text]
  • 55Hfl6014u 12 Dfu Swe.Pdf
    Användarhandbok 32HFL5014 43HFL5014 43HFL6014U 50HFL5014 50HFL6014U 55HFL6014U 65HFL6014U Innehåll 10.8 Mer 26 1 TV-pres. 3 10.9 Professionella inställningar 27 1.1 Professionellt läge 3 10.10 Google-konto 28 2 Installation 4 11 Android TV-hemskärm 29 2.1 Läs säkerhetsinstruktionerna 4 11.1 Om Android TV-hemskärmen 29 2.2 TV-stativ eller väggmontering 4 11.2 Öppna Android TV-hemskärmen 29 2.3 Tips om placering 4 11.3 Android TV-inställningar 29 2.4 Nätkabel 4 11.4 Anslut din Android TV 32 2.5 Antennkabel 5 11.5 Kanaler 35 11.6 Kanalinstallation 36 3 Fjärrkontroll 6 11.7 Internet 37 3.1 Knappöversikt 6 11.8 Smarttelefoner och surfplattor 38 3.2 IR-sensor 6 11.9 Programvara 38 3.3 Batterier 7 3.4 Rengöring 7 12 Programvara med öppen källkod 40 12.1 Öppen källkod-licens 40 4 Slå på och av 8 4.1 På eller standby 8 13 Hjälp och support 128 4.2 Knappar på TV:n 8 13.1 Felsökning 128 13.2 Onlinehjälp 129 5 Specifikationer 9 13.3 Support och reparation 130 5.1 Miljö 9 5.2 Effekt 10 14 Säkerhet och skötsel 131 5.3 Operativsystem 10 14.1 Säkerhet 131 5.4 Mottagning 10 14.2 Skötsel av bildskärmen 132 5.5 Visningstyp (6014U) 10 14.3 Radiation Exposure Statement 132 5.6 Visningstyp (5014) 10 5.7 Ingångsupplösning för skärm 10 15 Användningsvillkor 133 5.8 Ingångsupplösning för skärm (5014) 10 15.1 Användningsvillkor – TV 133 5.9 Anslutning (6014U) 11 5.10 Anslutning (5014) 11 16 Copyrights 134 5.11 Mått och vikt 11 16.1 MHL 134 5.12 Ljud 11 16.2 HDMI 134 16.3 Dolby-ljud 134 6 Ansluta enheter 13 16.4 DTS-HD Premium Sound ™ 134 6.1 Ansluta enheter 13
    [Show full text]
  • X-Containers: Breaking Down Barriers to Improve
    Session: Cloud II ASPLOS’19, April 13–17, 2019, Providence, RI, USA X-Containers: Breaking Down Barriers to Improve Performance and Isolation of Cloud-Native Containers Zhiming Shen Zhen Sun Gur-Eyal Sela∗ Cornell University Cornell University University of California, Berkeley Eugene Bagdasaryan Christina Delimitrou Robbert Van Renesse Cornell University Cornell University Cornell University Hakim Weatherspoon Cornell University Abstract CCS Concepts • Security and privacy → Virtualiza- “Cloud-native” container platforms, such as Kubernetes, have tion and security; • Software and its engineering → become an integral part of production cloud environments. Operating systems. One of the principles in designing cloud-native applica- Keywords Containers; X-Containers; Cloud-Native; Li- tions is called Single Concern Principle, which suggests that brary OS; exokernel each container should handle a single responsibility well. In this paper, we propose X-Containers as a new security ACM Reference Format: paradigm for isolating single-concerned cloud-native con- Zhiming Shen, Zhen Sun, Gur-Eyal Sela, Eugene Bagdasaryan, tainers. Each container is run with a Library OS (LibOS) Christina Delimitrou, Robbert Van Renesse, and Hakim Weath- that supports multi-processing for concurrency and compat- erspoon. 2019. X-Containers: Breaking Down Barriers to Improve Performance and Isolation of Cloud-Native Containers. In 2019 Ar- ibility. A minimal exokernel ensures strong isolation with chitectural Support for Programming Languages and Operating Sys- small kernel attack surface. We show an implementation tems (ASPLOS ’19), April 13–17, 2019, Providence, RI, USA. ACM, New of the X-Containers architecture that leverages Xen para- York, NY, USA, 15 pages. https://doi.org/10.1145/3297858.3304016 virtualization (PV) to turn Linux kernel into a LibOS.
    [Show full text]