DOCSLIB.ORG

On the Design of Reliable and Scalable Networked Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
On the Design of Reliable and Scalable Networked Systems On the Design of Reliable and Scalable Networked Systems Ph.D. Thesis Tomas Hruby VU University Amsterdam, 2014 This work was funded by European Research Council under ERC Advanced Grant 227874. Copyright © 2014 by Tomas Hruby. ISBN 978-90-5383-072-7 Printed by Wöhrmann Print Service. VRIJE UNIVERSITEIT ON THE DESIGN OF RELIABLE AND SCALABLE NETWORKED SYSTEMS ACADEMISCH PROEFSCHRIFT ter verkrijging van de graad Doctor aan de Vrije Universiteit Amsterdam, op gezag van de rector magnificus prof.dr. F.A. van der Duyn Schouten, in het openbaar te verdedigen ten overstaan van de promotiecommissie van de Faculteit der Exacte Wetenschappen op donderdag 10 april 2014 om 13.45 uur in de aula van de universiteit, De Boelelaan 1105 door TOMAS HRUBY geboren te Stod, Tsjechische Republiek promotors: prof.dr. Andrew S. Tanenbaum prof.dr. Herbert Bos Acknowledgements Tomas Hruby Amsterdam, The Netherlands, December 2013 v Contents Acknowledgements v Contents vii List of Figures xi List of Tables xiii Publications xv 1 Introduction 1 1.1 Overview of Operating System Architectures . 4 1.1.1 Monolithic Kernels . 4 1.1.2 Microkernels . 5 1.2 New Multicore Hardware . 7 1.3 Network Stack . 9 1.4 NEWTOS ............................... 11 1.5 Contributions . 12 1.6 Organization of the Dissertation . 12 2 Keep Net Working On a Dependable and Fast Networking Stack 15 2.1 Introduction . 16 2.2 Reliability, performance and multicore . 17 2.3 Rethinking the Internals . 19 2.3.1 IPC: What’s the kernel got to do with it? . 19 2.3.2 Asynchrony for Performance and Reliability . 20 vii viii 2.4 Fast-Path Channels . 21 2.4.1 Trustworthy Shared Memory Channels . 22 2.4.2 Monitoring Queues . 23 2.4.3 Channel Management . 24 2.4.4 Channels and Restarting Servers . 24 2.5 Dependable Networking Stack . 25 2.5.1 The Internals . 27 2.5.2 Combining Kernel IPC and Channels IPC . 28 2.5.3 Zero Copy . 29 2.5.4 Crash Recovery . 30 2.6 Evaluation . 32 2.6.1 TCP Performance . 32 2.6.2 Fault Injection and Crash Recovery . 33 2.6.3 High Bitrate Crashes . 35 2.7 Related work . 36 2.8 Conclusion and Future Work . 37 3 When Slower is Faster On Heterogeneous Multicores for Reliable Systems 39 3.1 Introduction . 40 3.2 Big cores, little cores and combinations . 42 3.2.1 BOCs and SICs . 42 3.2.2 Configurations of BOCs and SICs . 43 3.3 NEWTOS ............................... 44 3.3.1 The NEWTOS network stack . 45 3.3.2 Dynamic reconfiguration . 46 3.3.3 Non-overlapping ISA . 47 3.4 Evaluation on a high-performance stack . 48 3.4.1 Test configurations . 49 3.4.2 Methodology of measurements . 50 3.4.3 Frequency scaling 2267–1600 MHz . 50 3.4.4 Throttling below 1600 MHz . 51 3.4.5 Hyper-threading . 53 3.4.6 Why is slower faster? . 55 3.4.7 Stack on a single core . 57 3.5 Related work . 57 3.6 Conclusions . 59 4 Scheduling of Multiserver System Components on Over-provisioned Multicore Systems 61 4.1 Introduction . 62 4.2 NEWTOS ............................... 63 4.3 Network Traffic Indicators . 66 ix 4.4 Web Server Profiles . 67 4.5 Profile Based Scheduling . 70 4.6 Conclusions and Future Work . 71 5 On Sockets and System Calls Minimizing Context Switches for the Socket API 73 5.1 Introduction . 74 5.2 Motivation and Related Work . 76 5.3 Sockets without System Calls . 79 5.4 Socket Buffers . 81 5.4.1 Exposing the Buffers . 81 5.4.2 Socket Buffers in Practice . 82 5.5 Calls and Controls . 83 5.5.1 Notifying the System . 83 5.5.2 Notifying the Application . 84 5.5.3 Socket Management Calls . 85 5.5.4 Select in User Space . 86 5.5.5 Lazy Closing and Fast Accepts . 86 5.6 Fast Sockets in NEWTOS....................... 87 5.6.1 Polling within the Network Stack . 88 5.6.2 Reducing TX Copy Overhead . 89 5.7 Implications for Reliability . 90 5.8 Evaluation . 90 5.8.1 lighttpd . 91 5.8.2 memcached . 94 5.8.3 Scalability . 95 5.9 Conclusions . 97 6 NEAT Designing Scalable and Reliable Networked Systems 99 6.1 Introduction . 100 6.2 Background and Related Work . 102 6.2.1 Scalability of Implementation . 102 6.2.2 Reliability of Implementation . 103 6.2.3 Scalability and Reliability of Design . 104 6.3 A Scalable and Reliable Network Stack . 105 6.3.1 Overview . 106 6.3.2 Sockets . 108 6.3.3 TCP Connections . 110 6.3.4 Scaling Up and Down . 111 6.3.5 Scaling NIC Drivers . 112 6.3.6 Reliability . 113 6.3.7 Security . 113 x CONTENTS 6.3.8 Multi-component Network Stack . 114 6.4 Architectural Support . 114 6.5 Evaluation . 116 6.5.1 Scalability on a 12-core AMD . 116 6.5.2 Scalability on a 8-core Xeon . 118 6.5.3 Impact of Different Configurations . 121 6.5.4 Reliability . 122 6.6 Conclusion . 123 7 Summary and Conclusions 125 References 131 Summary 145 Samenvatting 147 List of Figures 2.1 Conceptual overview of NEWTOS. Each box represents a core. Appli- cation (APP) cores are timeshared. 18 2.2 Decomposition and isolation in multiserver systems . 26 2.3 Asynchrony in the network stack . 28 2.4 IP crash . 34 2.5 Packet filter crash . 35 3.1 Design of the NEWTOS network stack . 44 3.2 Test configurations - large squares represent the quad-core chips, small squares individual cores and ‘&’ separates processes running on differ- ent hyper-treads. 49 3.3 Throughput compared to the combined performance of the resources in use — the best combinations . 52 3.4 Configuration #1 – CPU utilization of each core throttled to % of 1600 MHz. 53 3.5 Configuration #1 – CPU utilization normalized to cores at 1600 MHz unthrottled. 53 3.6 Configuration #2 (HT) – CPU utilization of each core throttled to % of 1600 MHz. 54 3.7 Configuration #2 (HT) – CPU utilization of each core normalized to 1600 MHz. 54 3.8 Comparison of configuration #1 (no HT) and #2 (HT). Lines represent bitrate, bars represent CPU utilization normalized to 3 cores at 1600 MHz 55 3.9 Sleep overhead in different situations. The thick line represents transi- tion between execution in user space and kernel in time. Arrows mark job arrivals, loops denote execution of the main loop and spirals denote polling. 56 xi xii LIST OF FIGURES 4.1 NEWTOS- network stack and inputs of the scheduler . 64 4.2 NEWTOS vs Linux performance. Continuously requesting 10 times a 10 B file using various numbers of simultaneous persistent connections. 65 4.3 Resuts for tests requesting continuously a file of a size between 10 bytes and 10 Megabytes using 8 simultaneous connections. The dashed line in (a) and (g) connects points where all three components run with the same frequency. 10 MB case shows bitrate instead of request rate. Legend is only in (f). 68 5.1 Net stack configurations : (a) Monolithic systems (Linux, BSD, Win- dows, etc.) (b) FlexSC / IsoStack (c) Multiserver system (MINIX 3, QNX). 77 5.2 Exposed socket buffers – no need to cross the protection boundary (dashed) to access the socket buffers. 81 5.3 A socket buffer – ring queue and data buffer. White and shaded present free and used / allocated space. 82 5.4 Architecture of the network stack . 87 5.5 1 request for a 20 B file per connection . 92 5.6 10 requests-responses per connection, 20 B file . 93 5.7 1 request and a 11 kB response per connection . 94 5.8 10 requests for an 11 kB file . ..
Load more

Recommended publications
  • The Politics of Roman Memory in the Age of Justinian DISSERTATION Presented in Partial Fulfillment of the Requirements for the D
    The Politics of Roman Memory in the Age of Justinian DISSERTATION Presented in Partial Fulfillment of the Requirements for the Degree Doctor of Philosophy in the Graduate School of The Ohio State University By Marion Woodrow Kruse, III Graduate Program in Greek and Latin The Ohio State University 2015 Dissertation Committee: Anthony Kaldellis, Advisor; Benjamin Acosta-Hughes; Nathan Rosenstein Copyright by Marion Woodrow Kruse, III 2015 ABSTRACT This dissertation explores the use of Roman historical memory from the late fifth century through the middle of the sixth century AD. The collapse of Roman government in the western Roman empire in the late fifth century inspired a crisis of identity and political messaging in the eastern Roman empire of the same period. I argue that the Romans of the eastern empire, in particular those who lived in Constantinople and worked in or around the imperial administration, responded to the challenge posed by the loss of Rome by rewriting the history of the Roman empire. The new historical narratives that arose during this period were initially concerned with Roman identity and fixated on urban space (in particular the cities of Rome and Constantinople) and Roman mythistory. By the sixth century, however, the debate over Roman history had begun to infuse all levels of Roman political discourse and became a major component of the emperor Justinian’s imperial messaging and propaganda, especially in his Novels. The imperial history proposed by the Novels was aggressivley challenged by other writers of the period, creating a clear historical and political conflict over the role and import of Roman history as a model or justification for Roman politics in the sixth century.
    [Show full text]
  • Hyper-V Performance Comparison: Microsoft Windows Server 2008 SP2 and R2 with Intel Xeon Processor X5570
    TEST REPORT JULY 2009 Hyper-V performance comparison: Microsoft Windows Server 2008 SP2 and R2 with Intel Xeon processor X5570- and E5450-based servers Executive summary KEY FINDINGS Microsoft® Corporation (Microsoft) and Intel® Corporation (Intel) commissioned Principled z The Intel Xeon processor X5570-based server with Technologies® (PT) to measure Hyper-V R2 the optimum number of CSUs delivered 37.1 percent virtualization performance improvements using more vConsolidate performance when running vConsolidate on the following Microsoft operating Microsoft Windows Server 2008 Enterprise Edition systems and Intel processors: R2 than when runningTEST Microsoft REPORT Windows Server 2008 EnterpriseFEBRUARY Edition SP2. (See 2006 Figure 1.) • Microsoft Windows Server® 2008 z Microsoft Windows Server 2008 Enterprise Edition Enterprise Edition SP2 with Hyper-V on SP2 running on the Intel Xeon processor X5570- Intel® Xeon® processor E5450 based server with the optimum number of CSUs • Microsoft Windows Server 2008 Enterprise delivered 98.7 percent more vConsolidate Edition SP2 with Hyper-V on Intel Xeon performance than it did running on the Intel Xeon processor X5570 processor E5450-based server with the optimum • Microsoft Windows Server 2008 Enterprise number of CSUs. (See Figure 1.) Edition R2 with Hyper-V on Intel Xeon processor X5570 Figure 1 shows the vConsolidate results for all three configurations with the optimum number of vConsolidate work units, consolidation stack units (CSUs). The Intel Xeon processor X5570-based server with the optimum number of CSUs (eight) delivered 37.1 percent more vConsolidate performance when running Microsoft Windows Server 2008 Enterprise Edition R2 than when running Microsoft Windows Server 2008 Enterprise Edition SP2.
    [Show full text]
  • Intel X86 Considered Harmful
    Intel x86 considered harmful Joanna Rutkowska October 2015 Intel x86 considered harmful Version: 1.0 1 Contents 1 Introduction5 Trusted, Trustworthy, Secure?......................6 2 The BIOS and boot security8 BIOS as the root of trust. For everything................8 Bad SMM vs. Tails...........................9 How can the BIOS become malicious?.................9 Write-Protecting the flash chip..................... 10 Measuring the firmware: TPM and Static Root of Trust........ 11 A forgotten element: an immutable CRTM............... 12 Intel Boot Guard............................. 13 Problems maintaining long chains of trust............... 14 UEFI Secure Boot?........................... 15 Intel TXT to the rescue!......................... 15 The broken promise of Intel TXT.................... 16 Rescuing TXT: SMM sandboxing with STM.............. 18 The broken promise of an STM?.................... 19 Intel SGX: a next generation TXT?................... 20 Summary of x86 boot (in)security.................... 21 2 Intel x86 considered harmful Contents 3 The peripherals 23 Networking devices & subsystem as attack vectors........... 23 Networking devices as leaking apparatus................ 24 Sandboxing the networking devices................... 24 Keeping networking devices outside of the TCB............ 25 Preventing networking from leaking out data.............. 25 The USB as an attack vector...................... 26 The graphics subsystem......................... 29 The disk controller and storage subsystem............... 30 The audio
    [Show full text]
  • Performance Best Practices for Vmware Workstation Vmware Workstation 7.0
    Performance Best Practices for VMware Workstation VMware Workstation 7.0 This document supports the version of each product listed and supports all subsequent versions until the document is replaced by a new edition. To check for more recent editions of this document, see http://www.vmware.com/support/pubs. EN-000294-00 Performance Best Practices for VMware Workstation You can find the most up-to-date technical documentation on the VMware Web site at: http://www.vmware.com/support/ The VMware Web site also provides the latest product updates. If you have comments about this documentation, submit your feedback to: [email protected] Copyright © 2007–2009 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. VMware products are covered by one or more patents listed at http://www.vmware.com/go/patents. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies. VMware, Inc. 3401 Hillview Ave. Palo Alto, CA 94304 www.vmware.com 2 VMware, Inc. Contents About This Book 5 Terminology 5 Intended Audience 5 Document Feedback 5 Technical Support and Education Resources 5 Online and Telephone Support 5 Support Offerings 5 VMware Professional Services 6 1 Hardware for VMware Workstation 7 CPUs for VMware Workstation 7 Hyperthreading 7 Hardware-Assisted Virtualization 7 Hardware-Assisted CPU Virtualization (Intel VT-x and AMD AMD-V)
    [Show full text]
  • TVS-Ecx80+ Edge Cloud Turbo Vnas Series the Best Storage Solution for Edge Cloud Use Your Turbo Vnas As a PC
    TVS-ECx80+ Edge Cloud Turbo vNAS Series The Best Storage Solution for Edge Cloud Use your Turbo vNAS as a PC 1 2 3 Keys to Super Boost 3 System Performance Flagship model 1 2 3 TVS-EC1080+ Intel® Quad-Core Xeon® E3-1245 v3 3.4GHz and 32GB RAM Built-in dual-port 10GbE and 256GB mSATA modules 10GbE Network Adapter DDR3 Memory mSATA Module MAX 32GB 4K 2K RAM • Supports Intel® Quad-Core Xeon® E3-1245 v3 3.4GHz / Intel® Core™ i3 Dual-Core processors integrated with Intel HD Graphics P4600 • Inbuilt two 10GbE ports reaching over 2000 MB/s throughput and 223,000 IOPs • Scale-up storage to 400 TB raw capacity • Powered by QTS 4.1.2 with new HD Station 2.0 for 4K/2K video TＶS-ECx80+ Turbo vNAS Series transcoding and playback • Q’center centralized management system for managing multiple QNAP Turbo vNAS units • Use the NAS as a PC with exclusive QvPC Technology • Designed for file management, backup and disaster recovery TVS-EC1080+-E3 TVS-EC1080-E3 TVS-EC880-E3 • NAS and iSCSI-SAN unified storage solution for server virtualization TVS-EC1080-i3 Hybrid Enterprise Cloud Storage Architecture With the advent of cloud computing, it is inevitable for enterprises to increase their investments in cloud services. However, enterprises are reducing IT expenses to maximize the return on investment (ROI). In addition to controlling rising costs, IT administrators must take many considerations when facilitating cloud environment. They need to incorporate new technology into existing systems without impacting the stability and performance of the system and user experience.
    [Show full text]
  • Operating System Support for Redundant Multithreading
    Operating System Support for Redundant Multithreading Dissertation zur Erlangung des akademischen Grades Doktoringenieur (Dr.-Ing.) Vorgelegt an der Technischen Universität Dresden Fakultät Informatik Eingereicht von Dipl.-Inf. Björn Döbel geboren am 17. Dezember 1980 in Lauchhammer Betreuender Hochschullehrer: Prof. Dr. Hermann Härtig Technische Universität Dresden Gutachter: Prof. Frank Mueller, Ph.D. North Carolina State University Fachreferent: Prof. Dr. Christof Fetzer Technische Universität Dresden Statusvortrag: 29.02.2012 Eingereicht am: 21.08.2014 Verteidigt am: 25.11.2014 FÜR JAKOB *† 15. Februar 2013 Contents 1 Introduction 7 1.1 Hardware meets Soft Errors 8 1.2 An Operating System for Tolerating Soft Errors 9 1.3 Whom can you Rely on? 12 2 Why Do Transistors Fail And What Can Be Done About It? 15 2.1 Hardware Faults at the Transistor Level 15 2.2 Faults, Errors, and Failures – A Taxonomy 18 2.3 Manifestation of Hardware Faults 20 2.4 Existing Approaches to Tolerating Faults 25 2.5 Thesis Goals and Design Decisions 36 3 Redundant Multithreading as an Operating System Service 39 3.1 Architectural Overview 39 3.2 Process Replication 41 3.3 Tracking Externalization Events 42 3.4 Handling Replica System Calls 45 3.5 Managing Replica Memory 49 3.6 Managing Memory Shared with External Applications 57 3.7 Hardware-Induced Non-Determinism 63 3.8 Error Detection and Recovery 65 4 Can We Put the Concurrency Back Into Redundant Multithreading? 71 4.1 What is the Problem with Multithreaded Replication? 71 4.2 Can we make Multithreading
    [Show full text]
  • Oracle Databases on Vmware Best Practices Guide Provides Best Practice Guidelines for Deploying Oracle Databases on Vmware Vsphere®
    VMware Hybrid Cloud Best Practices Guide for Oracle Workloads Version 1.0 May 2016 © 2016 VMware, Inc. All rights reserved. Page 1 of 81 © 2016 VMware, Inc. All rights reserved. This product is protected by U.S. and international copyright and intellectual property laws. This product is covered by one or more patents listed at http://www.vmware.com/download/patents.html. VMware is a registered trademark or trademark of VMware, Inc. in the United States and/or other jurisdictions. All other marks and names mentioned herein may be trademarks of their respective companies. VMware, Inc. 3401 Hillview Ave Palo Alto, CA 94304 www.vmware.com © 2016 VMware, Inc. All rights reserved. Page 2 of 81 VMware Hybrid Cloud Best Practices Guide for Oracle Workloads Contents 1. Introduction ...................................................................................... 9 2. vSphere ......................................................................................... 10 3. VMware Support for Oracle Databases on vSphere ....................... 11 3.1 VMware Oracle Support Policy .................................................................................... 11 3.2 VMware Oracle Support Process................................................................................. 12 4. Server Guidelines .......................................................................... 13 4.1 General Guidelines ...................................................................................................... 13 4.2 Hardware Assisted Virtualization ................................................................................
    [Show full text]
  • Linux Performance Tools
    Linux Performance Tools Brendan Gregg Senior Performance Architect Performance Engineering Team [email protected] @brendangregg This Tutorial • A tour of many Linux performance tools – To show you what can be done – With guidance for how to do it • This includes objectives, discussion, live demos – See the video of this tutorial Observability Benchmarking Tuning Stac Tuning • Massive AWS EC2 Linux cloud – 10s of thousands of cloud instances • FreeBSD for content delivery – ~33% of US Internet traffic at night • Over 50M subscribers – Recently launched in ANZ • Use Linux server tools as needed – After cloud monitoring (Atlas, etc.) and instance monitoring (Vector) tools Agenda • Methodologies • Tools • Tool Types: – Observability – Benchmarking – Tuning – Static • Profiling • Tracing Methodologies Methodologies • Objectives: – Recognize the Streetlight Anti-Method – Perform the Workload Characterization Method – Perform the USE Method – Learn how to start with the questions, before using tools – Be aware of other methodologies My system is slow… DEMO & DISCUSSION Methodologies • There are dozens of performance tools for Linux – Packages: sysstat, procps, coreutils, … – Commercial products • Methodologies can provide guidance for choosing and using tools effectively • A starting point, a process, and an ending point An#-Methodologies • The lack of a deliberate methodology… Street Light An<-Method 1. Pick observability tools that are: – Familiar – Found on the Internet – Found at random 2. Run tools 3. Look for obvious issues Drunk Man An<-Method • Tune things at random until the problem goes away Blame Someone Else An<-Method 1. Find a system or environment component you are not responsible for 2. Hypothesize that the issue is with that component 3. Redirect the issue to the responsible team 4.
    [Show full text]
  • Perceptions of the Ancient Jews As a Nation in the Greek and Roman Worlds
    Perceptions of the Ancient Jews as a Nation in the Greek and Roman Worlds By Keaton Arksey A Thesis submitted to the Faculty of Graduate Studies of The University of Manitoba In partial fulfilment of the requirements of the degree of MASTER OF ARTS Department of Classics University of Manitoba Winnipeg Copyright © 2016 by Keaton Arksey Abstract The question of what made one Jewish in the ancient world remains a fraught topic for scholars. The current communis opinio is that Jewish communities had more in common with the Greeks and Romans than previously thought. Throughout the Diaspora, Jewish communities struggled with how to live amongst their Greco-Roman majority while continuing to practise their faith and thereby remain identifiably ‘Jewish’. To describe a unified Jewish identity in the Mediterranean in the period between 200 BCE and 200 CE is incorrect, since each Jewish community approached its identity in unique ways. These varied on the basis of time, place, and how the non-Jewish population reacted to the Jews and interpreted Judaism. This thesis examines the three major centres of Jewish life in the ancient world - Rome, Alexandria in Egypt, and Judaea - demonstrate that Jewish identity was remarkably and surprisingly fluid. By examining the available Jewish, Roman, and Greek literary and archaeological sources, one can learn how Jewish identity evolved in the Greco-Roman world. The Jews interacted with non-Jews daily, and adapted their neighbours’ practices while retaining what they considered a distinctive Jewish identity. Each chapter of this thesis examines a Jewish community in a different region of the ancient Mediterranean.
    [Show full text]
  • Cisco Telepresence Server 4.4(1.16) MR1 Open Source Documentation
    Open Source Used In Cisco TelePresence Server 4.4(1.16) MR1 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-139358573 Open Source Used In Cisco TelePresence Server 4.4(1.16) MR1 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-139358573 Contents 1.1 Brian Gladman's AES Implementation 11-01-11 1.1.1 Available under license 1.2 busybox 1.15.1 :15.el6 1.2.1 Available under license 1.3 Coreboot d9b5d897d7f05d0ee8f9411628b757beea990b4b 1.3.1 Available under license 1.4 curl and libcurl 7.44.0 :7.44.0 1.4.1 Available under license 1.5 dhcp 4.1.1-P1 1.5.1 Available under license 1.6 expat 2.2.0 1.6.1 Available under license 1.7 FatFS R0.05 1.7.1 Available under license 1.8 freetype 2.5.3 1.8.1 Available under license 1.9 fribidi 0.19.6 :1 1.9.1 Available under license 1.10 G.722 2.00 1.10.1 Available under license 1.11 HMAC n/a 1.11.1 Available under license 1.12 icelib f50dffe9820bb7e32ac7b9b1b1d19aa3431227a2 1.12.1 Available under license 1.13
    [Show full text]
  • Why Open Source Software?
    Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers! David A. Wheeler http://www.dwheeler.com/contactme.html Revised as of November 7, 2004 This paper provides quantitative data that, in many cases, using open source software / free software is a reasonable or even superior approach to using their proprietary competition according to various measures. This paper’s goal is to show that you should consider using OSS/FS when acquiring software. This paper examines market share, reliability, performance, scalability, security, and total cost of ownership. It also has sections on non- quantitative issues, unnecessary fears, OSS/FS on the desktop, usage reports, governments and OSS/FS, other sites providing related information, and ends with some conclusions. An appendix gives more background information about OSS/FS. You can view this paper at http://www.dwheeler.com/oss_fs_why.html (HTML format). Palm PDA users may wish to use Plucker to view this. A short briefing based on this paper is also available in PDF and Open Office Impress formats (for the latter, use Open Office Impress). Old archived copies and a list of changes are also available. 1. Introduction Open Source Software / Free Software (OSS/FS) has risen to great prominence. Briefly, OSS/FS programs are programs whose licenses give users the freedom to run the program for any purpose, to study and modify the program, and to redistribute copies of either the original or modified program (without having to pay royalties to previous developers). This goal of this paper is to show that you should consider using OSS/FS when you’re looking for software, based on quantitative measures.
    [Show full text]
  • Project-Team REGAL
    IN PARTNERSHIP WITH: CNRS Université Pierre et Marie Curie (Paris 6) Activity Report 2013 Project-Team REGAL Large-Scale Distributed Systems and Applications IN COLLABORATION WITH: Laboratoire d’informatique de Paris 6 (LIP6) RESEARCH CENTER Paris - Rocquencourt THEME Distributed Systems and middleware Table of contents 1. Members :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 1 2. Overall Objectives :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 2 2.1. Overall Objectives2 2.2. Highlights of the Year2 3. Research Program :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 3 3.1.1. Modern computer systems are increasingly parallel and distributed.3 3.1.2. Multicore architectures are everywhere.3 4. Software and Platforms ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 4 4.1. Coccinelle 4 4.2. SwiftCloud 4 4.3. JESSY 4 4.4. Java and .Net runtimes for LLVM5 5. New Results :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: 5 5.1. Introduction 5 5.2. Distributed algorithms for dynamic networks5 5.2.1. Mutual Exclusion and Failure Detection.6 5.2.2. Self-Stabilization and Self-* Services.6 5.2.3. Dissemination and Data Finding in Large Scale Systems.6 5.2.4. Peer certification.7 5.3. Management of distributed data7 5.3.1. Long term durability7 5.3.2. Adaptative replication8 5.3.3. Strong consistency8 5.3.4. Distributed Transaction Scheduling9 5.3.5. Eventual consistency9 5.3.6. Mixing commutative and non-commutative updates: reservations9 5.4. Performance and Robustness of Systems Software in Multicore Architectures 10 5.4.1. Managed Runtime Environments 10 5.4.2. System software robustness 10 5.4.3. Domain-specific languages for systems software 11 6. Bilateral Contracts and Grants with Industry ::::::::::::::::::::::::::::::::::::::::::::: 11 6.1. Bilateral Contracts with Industry 11 6.2. Bilateral Grants with Industry 11 7.
    [Show full text]