DOCSLIB.ORG

07.Standards Reports

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
07.Standards Reports Standards Reports Linux Gets a Boost - The Linux Our Standard Report Editor, Standards David Blackwood, welcomes dialogue between EPORTS R Standard Base: Linux has the fastest market growth rate this column and you, the readers. Please send of any operating system (OS) in the your comments to [email protected]. world, and it is being developed faster How Will It Benefit TANDARDS than any OS in history. However, for S Linux to move into the enterprise and Linux? serve as the host for enterprise applica- tions, a set of common standards is by Bill Claybrook needed. Without standards and com- Aberdeen Group mon application programming inter- [email protected] faces (APIs), independent software vendors (ISVs) and other developers [Editor’s Note: This is the kind of docu- must decide which of the more than 250 ment that IT VP’s in large corporations Linux distributions to target for hosting read all the time. It’s interesting to see how their applications. On the upside, stan- it’s written and how it asserts various dards will bring a greater market share points of view in a persuasive way. It for Linux, allowing for its continuing reminds me ever-so-slightly of the old growth. Developers, distributors, ISVs, /usr/group standardization process. systems vendors, and especially users It is also interesting to try to discern where will surely benefit. money is moving and to notice the In response to the need for Linux stan- reliance on brand names, logos, and dards, the Free Standards Group (FSG) trademarks. A huge part of the IT world has initiated two key projects – the relies on these sorts of assurances rather Linux Standard Base (LSB) and the than employing their own technical gurus. Linux Internationalization Standard Enjoy!] (Li18nux). This article is reprinted with the permis- The LSB provides binary and behavioral sion of Aberdeen Group, and is the intel- protocols that increase compatibility lectual property of Aberdeen Group. among Linux distributions; it also enables LSB-compliant applications to Linux is knocking on the enterprise run on any LSB-compliant Linux distri- door – and quickly making inroads. bution. Li18nux is a standard for creat- The speed with which Linux enters ing a foundation for language the enterprise depends to a large globalization of Linux-compliant distri- extent on the availability of enter- butions and applications. prise applications running on Linux. Note that LSB 1.1 compliance and The Free Standards Group is help- Li18nux 1.0 compliance are two separate ing to accelerate this effort via its concepts. Thus, a distribution can be Linux Standard Base (LSB) and LSB 1.1 compliant without being Li18nux 1.0 compliant – and vice versa. Li18nux initiatives. This InSight (The focus in this article is LSB 1.1.) gives a preview of the LSB and out- The FSG Workgroups for LSB 1.1 and lines the benefits associated with Li18nux 1.0 will deliver complete, writ- deploying LSB-compliant software. ten documentation articulating what is needed to make Linux distributions and other Linux-based software compliant. In addition, they will deliver compliance June 2002 ;login: THE LINUX STANDARD BASE 59 test suites for each standard. For addi- also contains some hardware-specific system call that opens a pipe to a tional LSB and Li18nux information, see code. The LSB component is expected to process). http://www.freestandards.org. grow over time with the addition of Outside the bounds of the Linux distri- libraries, e.g., C++, but only those that The FSG is an independent, non-profit bution, but with direct access to the are stable (subject to infrequent change) organization dedicated to accelerating LSB-specified ABI, are the development will be added to the LSB component. the use and acceptance of open source tool kit, commercial applications, etc. technologies through the development One of the features of compliant devel- and promotion of standards. The FSG is opment tools is that they will restrict backed by important industry leaders potential missteps in developing com- including Caldera, Compaq, Debian, pliant applications. Dell, Hewlett-Packard (HP), Hitachi, Today, the GNU tool kit, which includes IBM, Intel, Oracle, Red Hat, Sun, SuSE, the gcc compiler, is the only tool kit that Turbolinux, and key members of the has been adopted for the development open source development community. of compliant applications and middle- Motivation for Linux ware. In the future, however, other tool Standards kits could be shown to be compatible for developing compliant applications. For the past several years, ISVs have struggled with the task of porting their Any software package or library that is applications to multiple OS platforms not specifically included in the LSB 1.1 including several Unix/RISC platforms. specification is considered to be outside Porting efforts are often time-consum- the scope of the standard. Adding a ing and costly. Once a port is completed, nonconforming package to an otherwise the ISV must support it. conforming Linux distribution does not prevent the distribution from conform- ISVs want access to as many markets as ing, unless the package removes or possible, but they do not want to repeat replaces a conforming part of the distri- the Unix/RISC phenomena – making bution. multiple ports to Linux. ISVs want to do a single port to Linux that will run on If an application developer goes outside many Linux distributions. Red Hat is the the LSB ABI, there are special rules to largest Linux distributor by far, but Figure 1: LSB View of Linux follow. These rules may require the other distributions find significant favor Distribution application developer to static-link in many geographical sectors around the Source: Aberdeen Group, March 2002 modules or bundle them with the appli- world. The LSB may be interpreted by cation to attain compliance. LSB 1.1 defines an Application Binary some as a way to “level the playing field” Interface (ABI), which is very similar to for distributors, but the real significance LSB Certification the POSIX.1 and POSIX.2 source speci- of the LSB rests in making long-term The LSB certification program is cur- fications. The LSBís ABI defines the API enterprise Linux deployments possible. rently under development; therefore, for developers to program to, and it some of the information provided Linux Standard Base 1.1 includes runtime definitions for binary below may differ slightly from the final LSB 1.1 standardizes the core function- compatibility. published details. LSB 1.1 specifies sepa- ality of Linux and core/primary Presently, an LSB-compliant Linux dis- rate sets of compliance test suites for libraries. Figure 1 depicts how a Linux tribution must supply 15 specific Linux distributions, Linux applications, distribution will be viewed post-LSB 1.1. libraries that define the ABIs. What LSB and Linux build environments. The LSB At the lowest level are the Linux kernel, 1.1 does not define, applications must Workgroup is responsible for develop- drivers, and hardware (architecture)- not use. For example, the vi (1) editor is ing the test suites and making them specific code. None of this code is not LSB-defined or LSB-compliant; available. directly affected by LSB 1.1. Above the therefore, it should not be called, via Linux kernel is the LSB component. It popen, by an application (popen is a 60 Vol. 27, No. 3 ;login: For application testing, the LSB checks pliant logo on their products, indicating LSB 1.1 software after the end of 2002. to determine if the applications are that they have been certified. However, According to our research, any Linux EPORTS using only LSB-specified ABIs and other companies could be required to distributor or Linux-based software R libraries, the LSB runtime linker, and use independent third-party companies supplier that wants to do enterprise executable and linking format (ELF). In to obtain the logo. business will have to produce LSB 1.1- addition, a set of Filesystem Hierarchy compliant products. LSB 1.1 and TANDARDS Linux distributors, such as Red Hat, S Standard (FHS) questions is asked about Li18nux 1.0 are good starts by the FSG SuSE, etc., are responsible for certifying the installation of the application. Lastly, to produce standard interfaces for the their distributions on the various hard- the application is required to be tested to development of software for Linux. ware architectures – such as IA-32, Ita- work on the LSB Sample Implementa- Standards make the long-term deploy- nium, and RISC – that they support. tion (a minimal Linux system that con- ment of Linux in the enterprise more Systems vendors like HP, IBM, Compaq, tains mostly just what is specified by the attractive and less costly for suppliers Dell, etc., will “trust” that Linux distrib- LSB) and two LSB-compliant distribu- and users. utors have certified these distributions tions. ISVs and other application devel- on the architectures that they (the dis- opers can get a preview of the types of tributors) support. IBM, for example, problems that they may encounter in will not need to repeat the SuSE Linux becoming LSB-compliant by running certification process when it ships (or their application(s) on an LSB-compli- supports) SuSE Linux on IBM servers. ant distribution (or the LSB Sample Implementation) and examining the There are two levels of certification. error reports. First-level certification involves, for example, an ISV like Oracle running the To successfully qualify as an LSB-com- LSB-compliant application test suites pliant Linux distribution, a distribution against one of its applications on two must supply the 15 libraries that define LSB-compliant Linux distributions, reg- the ABIs, adhere to the FHS, successfully istering the results with the LSB, and run a set of test applications, etc.
Load more

Recommended publications
  • Report Received March 2006
    2005 was a busy year for me as of POSIX was published (the the USENIX standards represen- Shell and Utilities volume), and tative. There are three major it became a second ISO standard. NICHOLAS M. STOUGHTON standards that I watch carefully: Amendments to these standards I POSIX, which also incorpo- were also under development, USENIX rates the Single UNIX Specifi- and led to the addition of real- cation time interfaces, including Standards I ISO-C pthreads, to the core system call I The Linux Standard Base (LSB) set. Many of the other projects Activities died away as the people involved In order to do that, USENIX lost interest or hit political road- funds my participation in the blocks (most of which were Nick is the USENIX Standards committees that develop and reported in ;login: at the time). Liaison and represents the maintain these standards. Association in the POSIX, ISO C, Throughout 2005, the Free Until the end of the twentieth and LSB working groups. He is century, POSIX was developed the ISO organizational repre- Standards Group (FSG) also sentative to the Austin Group, helped fund these activities. For and maintained by IEEE exclu- a member of INCITS commit- each of these, let’s look at the his- sively. At the same time, the tees J11 and CT22, and the Open Group (also known as Specification Authority sub- tory of the standards, then at group leader for the LSB. what has happened over the past X/Open) had an entirely separate but 100% overlapping standard, [email protected] 12 months or so, and, finally, what is on the agenda for this known as the Single UNIX year.
    [Show full text]
  • Titans and Trolls of the Open Source Arena
    Titans and Trolls Enter the Open-Source Arena * by DEBRA BRUBAKER BURNS I. Introduction .................................................................................... 34 II. Legal Theories for Open Source Software License Enforcement ................................................................................... 38 A. OSS Licensing .......................................................................... 38 B. Legal Theories and Remedies for OSS Claims .................... 40 1. Legal Protections for OSS under Copyright and Contract Law ..................................................................... 40 Stronger Protections for OSS License under Copyright Law ................................................................... 40 2. Copyright-Ownership Challenges in OSS ....................... 42 3. Potential Legal Minefields for OSS under Patent Law ...................................................................................... 45 4. Added Legal Protection for OSS under Trademark Law ...................................................................................... 46 5. ITC 337 Action as Uncommon Legal Protection for OSS ..................................................................................... 49 III. Enforcement Within the OSS Community .................................. 49 A. Software Freedom Law Center Enforces OSS Licenses .... 50 B. Federal Circuit Finds OSS License Enforceable Under Copyright Law ......................................................................... 53 C. Commercial OSS
    [Show full text]
  • IT Acronyms.Docx
    List of computing and IT abbreviations /.—Slashdot 1GL—First-Generation Programming Language 1NF—First Normal Form 10B2—10BASE-2 10B5—10BASE-5 10B-F—10BASE-F 10B-FB—10BASE-FB 10B-FL—10BASE-FL 10B-FP—10BASE-FP 10B-T—10BASE-T 100B-FX—100BASE-FX 100B-T—100BASE-T 100B-TX—100BASE-TX 100BVG—100BASE-VG 286—Intel 80286 processor 2B1Q—2 Binary 1 Quaternary 2GL—Second-Generation Programming Language 2NF—Second Normal Form 3GL—Third-Generation Programming Language 3NF—Third Normal Form 386—Intel 80386 processor 1 486—Intel 80486 processor 4B5BLF—4 Byte 5 Byte Local Fiber 4GL—Fourth-Generation Programming Language 4NF—Fourth Normal Form 5GL—Fifth-Generation Programming Language 5NF—Fifth Normal Form 6NF—Sixth Normal Form 8B10BLF—8 Byte 10 Byte Local Fiber A AAT—Average Access Time AA—Anti-Aliasing AAA—Authentication Authorization, Accounting AABB—Axis Aligned Bounding Box AAC—Advanced Audio Coding AAL—ATM Adaptation Layer AALC—ATM Adaptation Layer Connection AARP—AppleTalk Address Resolution Protocol ABCL—Actor-Based Concurrent Language ABI—Application Binary Interface ABM—Asynchronous Balanced Mode ABR—Area Border Router ABR—Auto Baud-Rate detection ABR—Available Bitrate 2 ABR—Average Bitrate AC—Acoustic Coupler AC—Alternating Current ACD—Automatic Call Distributor ACE—Advanced Computing Environment ACF NCP—Advanced Communications Function—Network Control Program ACID—Atomicity Consistency Isolation Durability ACK—ACKnowledgement ACK—Amsterdam Compiler Kit ACL—Access Control List ACL—Active Current
    [Show full text]
  • Safeguarding the Future of Linux Through Standards
    Safeguarding the Future of Linux Through Standards “ Through the defi nition and testing of operating system interfaces, the LSB creates a stable platform that benefi ts Safeguarding Key Facts the Future of bo th developers and users.” - Linus Torvalds Linux Through Standards • The FSG is a non-profi t organization devoted to the ongoing success of Linux The Free Standards Group is an independent nonprofi t organization dedicated to accelerating the use and acceptance of free and open source • Growing membership includes all leading Linux vendors software by developing and promoting standards. Supported by leaders and many infl uential non-profi ts in the IT industry as well as the open source development community, the in the Linux community Free Standards Group fulfi lls a critical need to have common behavioral • Workgroups cover key specifi cations, tools and ABIs across Linux platforms. The Linux Standard Base Linux standards issues such as a binary standard and offers an answer to the most pressing issue facing Linux today: fragmentation. internationalization • Board members include an A well supported standard for Linux is the neccesary component to Linux’s assortment of Linux experts continued success. Without a commonly adopted standard, Linux will fragment, and senior representatives of the Linux community thus proving costly for ISVs to port their applications to the operating system and making it diffi cult for end users and Linux vendors alike. By adopting the • Headquartered in San Francisco Linux Standard Base, the Linux community provides this crucial portability so that applications can be used on more than one distribution of Linux with little or no change.
    [Show full text]
  • Carrier Grade Linux Requirements Definition
    Carrier Grade Linux Requirements Definition The Linux Foundation Version 5.0 1796 18th Street S u i t e C Prepared by the Carrier Grade Linux Working Group San Francisco CA 94107, USA Copyright (c) 2005, 2006, 2007, 2011 by The Linux +1 (415) 723 - 9 7 0 9 Foundation. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is available at http://www.opencontent.org/opl.shtml/). Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder. Linux is a Registered Trademark of Linus Torvalds. Other company, product, or service names may be the trademarks of others. CONTRIBUTORS TO THE CGL 5.0 REQUIREMENTS DEFINITION INCLUDE (IN ALPHABETICAL ORDER): Last Name First Name Company Anderson Matt HP Anderson Tim MontaVista Software Awad Majid Intel Aziz Khalid HP Badovinatz Peter IBM Bozarth Brad Cisco Cauchy Dan MontaVista Software Chacron Eric Alcatel Chen Terence Intel Cherry John OSDL Christopher Johnson Sun Microsystems Cihula Jospeh Intel Cress Andrew Intel Dague Sean IBM Dake Steven MontaVista Software Flaxa Ralf Novell Fleischer Julie Intel Fleischer Julie OSDL Fox Kevin Sun Microsystems Gross Mark Intel Haddad Ibrahim Ericsson Heber Troy HP Howell David P. Intel Hu Michael Radisys Ikebe Takashi NTT Ishitsuka Seiichi NEC Jagana Venkata IBM Johnson Christopher P. Sun Microsystems Kevin Fox Sun Microsystems Kimura Masato NTT Comware Krauska Joel Cisco Kukkonen Mika Nokia La Monte.H.P Yarrol Timesys Lavonius Ville Nokia Liu Bing Wei Intel Lynch Rusty Intel * MacDonald Joe Wind River Systems Manas Saksena Timesys Nakayama Mitsuo NEC Peter-Gonzalez Inaky Intel Pourzandi Makan Ericsson Rossi Frederic Eicsson Saksena Manas Timesys Sakuma Junichi OSDL Saskena Manas Timesys Seiler Glenn Wind River Systems Smarduch Mario Motorola Takamiya Noriaki NTT Software Weijers Gé Witham Timothy D.
    [Show full text]
  • Linux Standard Base Development Kit for Application Building/Porting
    Linux Standard Base Development Kit for application building/porting Rajesh Banginwar Nilesh Jain Intel Corporation Intel Corporation [email protected] [email protected] Abstract validating binaries and RPM packages for LSB conformance. We conclude with a couple of case studies that demonstrate usage of the build The Linux Standard Base (LSB) specifies the environment as well as the associated tools de- binary interface between an application and a scribed in the paper. runtime environment. This paper discusses the LSB Development Kit (LDK) consisting of a build environment and associated tools to assist software developers in building/porting their applications to the LSB interface. Developers 1 Linux Standard Base Overview will be able to use the build environment on their development machines, catching the LSB porting issues early in the development cycle The Linux* Standard Base (LSB)[1] specifies and reducing overall LSB conformance testing the binary interface between an application and time and cost. Associated tools include appli- a runtime environment. The LSB Specifica- cation and package checkers to test for LSB tion consists of a generic portion, gLSB, and conformance of application binaries and RPM an architecture-specific portion, archLSB. As packages. the names suggest, gLSB contains everything that is common across all architectures, and This paper starts with the discussion of ad- archLSBs contain the things that are specific vantages the build environment provides by to each processor architecture, such as the ma- showing how it simplifies application develop- chine instruction set and C library symbol ver- ment/porting for LSB conformance. With the sions. availability of this additional build environment from LSB working group, the application de- As much as possible, the LSB builds on ex- velopers will find the task of porting applica- isting standards, including the Single UNIX tions to LSB much easier.
    [Show full text]
  • Open Source Software: Risks and Rewards V2.0, 03 August 2005
    Open Source Software: Risks and Rewards v2.0, 03 August 2005 Author(s)Gary Hein Conclusion Open source software (OSS) brings new opportunities and risks to information technology (IT) vendors and customers. Software commoditization is being profoundly affected from the infrastructure layer and moving up to the application layer. As a result, OSS is changing the strategies and business models of hardware and software vendors and system integrators. Customers should understand the risks and rewards of OSS, and should formulate strategies that bring OSS benefits to their IT departments while mitigating the business and legal risks. Synopsis Open source software (OSS) is more than just free software. It’s a development process, a distribution model, and a set of new software licenses. And, as characterized by OSS proponents, it’s a movement. OSS projects, such as Linux and Apache HTTP server, are commoditizing enterprise and Internet infrastructure, and thus pose threats for some vendors while creating new market opportunities for others. OSS brings more to information technology (IT) than just free software. It grants freedom from vendor lock-in and application churn, freedom to inspect, modify, and improve source code, and the freedom to influence or contribute to projects key to a company’s survival. But these freedoms come at a price. Although OSS is free, it isn’t always less expensive to implement due to migration, support, training, and maintenance costs. OSS projects add new twists to business risks such as vendor viability and stability, and legal issues remain uncertain as many popular licenses have yet to be tested in a court of law.
    [Show full text]
  • Application Binary Interface for the ARM Architecture
    ABI for the ARM Architecture (Base Standard) Application Binary Interface for the ARM® Architecture The Base Standard Document number: ARM IHI 0036B, current through ABI release 2.10 Date of Issue: 10th October 2008, reissued 24th November 2015 Abstract This document describes the structure of the Application Binary Interface (ABI) for the ARM architecture, and links to the documents that define the base standard for the ABI for the ARM Architecture. The base standard governs inter-operation between independently generated binary files and sets standards common to ARM- based execution environments. Keywords ABI for the ARM architecture, ABI base standard, embedded ABI How to find the latest release of this specification or report a defect in it Please check the ARM Information Center (http://infocenter.arm.com/) for a later release if your copy is more than one year old (navigate to the ARM Software development tools section, ABI for the ARM Architecture subsection). Please report defects in this specification to arm dot eabi at arm dot com. Licence THE TERMS OF YOUR ROYALTY FREE LIMITED LICENCE TO USE THIS ABI SPECIFICATION ARE GIVEN IN SECTION 1.4, Your licence to use this specification (ARM contract reference LEC-ELA-00081 V2.0). PLEASE READ THEM CAREFULLY. BY DOWNLOADING OR OTHERWISE USING THIS SPECIFICATION, YOU AGREE TO BE BOUND BY ALL OF ITS TERMS. IF YOU DO NOT AGREE TO THIS, DO NOT DOWNLOAD OR USE THIS SPECIFICATION. THIS ABI SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES (SEE SECTION 1.4 FOR DETAILS). Proprietary notice ARM, Thumb, RealView, ARM7TDMI and ARM9TDMI are registered trademarks of ARM Limited.
    [Show full text]
  • Eb-2015-00549 Document Date: 08/27/2015 To: INCITS Members
    InterNational Committee for Information Technology Standards (INCITS) Secretariat: Information Technology Industry Council (ITI) 1101 K Street NW, Suite 610, Washington, DC 20005 www.INCITS.org eb-2015-00549 Document Date: 08/27/2015 To: INCITS Members Reply To: Deborah J. Spittle Subject: Public Review and Comments Register for the Reaffirmations of: Due Date: The public review is from August 28, 2015 to October 27, 2015. The InterNational Committee for Information Technology Standards (INCITS) announces Action: that the subject-referenced document(s) is being circulated for a 60-day public review and comment period. Comments received during this period will be considered and answered. Commenters who have objections/suggestions to this document should so indicate and include their reasons. All comments should be forwarded not later than the date noted above to the following address: INCITS Secretariat/ITI 1101 K Street NW - Suite 610 Washington DC 20005-3922 Email: [email protected] (preferred) This public review also serves as a call for patents and any other pertinent issues (copyrights, trademarks). Correspondence regarding intellectual property rights may be emailed to the INCITS Secretariat at [email protected]. INCITS/ISO/IEC 14443- Identification cards - Contactless Integrated Circuit Cards (CICCs) - Proximity integrated circuit9s0 1:2008[2010] cards Part 1: physical characteristics INCITS/ISO/IEC 19785- Information technology - Common Biometric Exchange File Formats Framework (CBEFF) - Part 3: 3:2007/AM 1:2010[2010]
    [Show full text]
  • ISO/IEC JTC 1 N8426 2006-11-28 Replaces
    ISO/IEC JTC 1 N8426 2006-11-28 Replaces: ISO/IEC JTC 1 Information Technology Document Type: Resolutions Document Title: Final Resolutions Adopted at the 21st Meeting of ISO/IEC JTC 1 13-17 November 2006 in South Africa Document Source: JTC 1 Secretary Project Number: Document Status: This document is circulated to JTC 1 National Bodies for information. Action ID: FYI Due Date: Distribution: Medium: No. of Pages: 20 Secretariat, ISO/IEC JTC 1, American National Standards Institute, 25 West 43rd Street, New York, NY 10036; Telephone: 1 212 642 4932; Facsimile: 1 212 840 2298; Email: [email protected] FINAL Resolutions Adopted at the 21st Meeting of ISO/IEC JTC 1 13-17 November 2006 in South Africa Resolution 1 - JTC 1 Business Plan JTC 1 approves document JTC 1 N 8352, as the current JTC 1 Business Plan. Unanimous Resolution 2 – JTC 1 Long Term Business Plan and Long Term Business Plan Implementation Plan JTC 1 approves document JTC 1 N 7974 as the Long Term Business Plan and document JTC 1 N 7975 as the Long Term Business Plan Implementation Plan. JTC 1 further instructs the JTC 1 Chairman to review these documents and to submit proposals for change to the plans to keep them current. Unanimous Resolution 3 – Approved Criteria for Free Availability of JTC 1 Standards JTC 1 instructs its Secretariat to redistribute the Approved Criteria for Free Availability of JTC 1 Standards (JTC 1 N 7604) to its National Bodies and Subcommittees in order to remind them of what ISO Council and IEC Council Board have agreed.
    [Show full text]
  • Linux Standard Base Core Specification for IA32 4.1
    Linux Standard Base Core Specification for IA32 4.1 Linux Standard Base Core Specification for IA32 4.1 ISO/IEC 23360 Part 2:2010(E) Copyright © 2010 Linux Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1; with no Invariant Sections, with no Front-Cover Texts, and with no Back- Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". Portions of the text may be copyrighted by the following parties: • The Regents of the University of California • Free Software Foundation • Ian F. Darwin • Paul Vixie • BSDI (now Wind River) • Andrew G Morgan • Jean-loup Gailly and Mark Adler • Massachusetts Institute of Technology • Apple Inc. • Easy Software Products • artofcode LLC • Till Kamppeter • Manfred Wassman • Python Software Foundation These excerpts are being used in accordance with their respective licenses. Linux is the registered trademark of Linus Torvalds in the U.S. and other countries. UNIX is a registered trademark of The Open Group. LSB is a trademark of the Linux Foundation in the United States and other countries. AMD is a trademark of Advanced Micro Devices, Inc. Intel and Itanium are registered trademarks and Intel386 is a trademark of Intel Corporation. PowerPC is a registered trademark and PowerPC Architecture is a trademark of the IBM Corporation. S/390 is a registered trademark of the IBM Corporation. OpenGL is a registered trademark of Silicon Graphics, Inc. ISO/IEC 23360 Part 2:2010(E)
    [Show full text]
  • Linux Standard Base Core Specification 2.0.1
    Linux Standard Base Core Specification 2.0 .1 Linux Standard Base Core Specification 2.0 .1 Copyright © 2004 Free Standards Group Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". Portions of the text are copyrighted by the following parties: • The Regents of the University of California • Free Software Foundation • Ian F. Darwin • Paul Vixie • BSDI (now Wind River) • Andrew G Morgan • Jean-loup Gailly and Mark Adler • Massachusetts Institute of Technology These excerpts are being used in accordance with their respective licenses. Linux is a trademark of Linus Torvalds. UNIX a registered trademark of the Open Group in the United States and other countries. LSB is a trademark of the Free Standards Group in the USA and other countries. AMD is a trademark of Advanced Micro Devices, Inc. Intel and Itanium are registered trademarks and Intel386 is a trademarks of Intel Corporation. OpenGL is a registered trademark of Silicon Graphics, Inc. Specification Introduction Specification Introduction Table of Contents Foreword .......................................................................................................................................................................i Introduction ...............................................................................................................................................................
    [Show full text]