[轉帖]LSB

LSB 簡介

馮 銳
2006 年 8 月 07 日發佈

 

https://www.ibm.com/developerworks/cn/linux/l-lsb-intr/

學習一下 以前 不知道LSB_RELEASE 什麼意思 

原來是 linux standard base 的意思.

 

 

 

 

Unix/Linux 標準化歷史

標準化目前已經成爲 Linux 系統上的一個熱門話題。實際上，在 Linux 誕生之初，這個問題就獲得了重視。當 Linus 在開發 0.01 版本的 Linux 內核時，就開始關注 POSIX 標準的發展，他在 /include/unistd.h 文件中定義了幾個與 POSIX 有關的宏，如下內容就節選自 0.01 版本內核的 /include/unistd.h 文件：

1 2	/* ok, this may be a joke, but I'm working on it */ #define _POSIX_VERSION 198808L

下面咱們就從 POSIX入手開始介紹 Unix/Linux 方面的標準化發展歷程。

POSIX

Unix 1969 年誕生於 AT&T 貝爾實驗室，並在 1973 年使用 C 語言進行了重寫，今後就具備了很好的可移植性。可是當 AT&T 在 1984 年因爲分拆而得以進入計算機領域的市場以後，卻引起了 Unix 業界的一場大戰。當時最爲主要的兩個版本是 AT&T 的 System V 和伯克利的 BSD。兩者在技術方面（例如終端）和文化方面都存在不少分歧，致使應用程序很難在不一樣的系統上平滑地進行移植，爲了解決這個問題，IEEE（Institute of Electrical and Electronic Engineers）的 1003 委員會着手開發了一系列標準，這就是後來的 POSIX（Portable Operating System Interface for UNIX）標準。其目的是爲那些兼容各類 UNIX 變種的應用程序制定應用程序編程接口（API）規範，從而確保這些應用程序的兼容性。這些標準後來被 ISO/IEC 採納，成爲 ISO/IEC 9945 標準。

POSIX 在 15 份不一樣的文檔中對操做系統與用戶軟件的接口進行了規範，主要內容包括3個部分：

• POSIX 系統調用
• POSIX 命令和工具
• POSIX 兼容測試

同時還提供了一套 POSIX 兼容性測試工具，稱爲 PCTS（POSIX Conformance Test Suite）。

後來 POSIX 標準又進行了不少擴充，主要包括：

• POSIX.1，核心服務：主要集成了 ANSI C 標準，包括進程建立和控制、信號、浮點異常、段錯誤、非法指令、總線錯誤、定時器、文件和目錄操做、管道、C 標準庫、I/O 端口和控制
• POSIX.1b，實時擴展：包括優先級調度、實時信號、時鐘和定時器、信號量、消息傳遞、共享內存、異步和同步 I/O、內存鎖
• POSIX.1c，線程擴展：包括線程建立和控制、線程調度、線程同步、信號處理

POSIX 最初的設計目標是爲 Unix System V 和 BSD Unix 等 Unix 系統上的特性制定規範，使其能夠實現更好的可移植性。可是不少其餘系統都也兼容POSIX 標準。例如，微軟的 Windows NT 就兼容 POSIX 標準的實時部分（POSIX.1b），而 RTOS（LynxOS real-time operating system）也與 POSIX 標準兼容。Windows 上能夠經過安裝 Windows 的 Services for UNIX 或 Cygwin 來加強對 POSIX 標準的兼容度。

Open Group

Open Group 是如今 Unix 商標的擁有者，其前身是 X/Open。X/Open 是 Unix 廠商在 1984 年成立的一個聯盟，它試圖爲衆多 Unix 變種定義一個安全公共子集，所以即便在 Unix 混戰的年代，也獲得了比較好的發展。在 1993 年，包括主要 Unix 公司在內的75 家系統和軟件供應商委託 X/Open 爲 Unix 制定一個統一的規範。X/Open在現有標準基礎上，增長了對終端進行處理的 API 和 X11 API，並全面兼容 1989 ANSI C 標準，最終誕生了初版本的單一 Unix規範（Single Unix Specification，簡稱 SUS）。

X/Open在 1996 年與 OSF（開放軟件基金會）進行合併，成立了 Open Group 組織，專門從事開放標準的制定和推廣工做，並對不少領域提供了認證，包括 Unix 操做系統、Motif 和 CDE（Common Desktop Environment）用戶界面。

Austin Group

Austin Group 是在 1998 年成立的一個合做技術工做組，其使命是開發並維護 POSIX.1 和 SUS 規範。Austin Group 開發規範的方法是"write once, adopt everywhere"，即由 Austin Group 制定的規範既會成爲 IEEE POSIX 規範，又會成爲 Open Group 的 技術標準規範，之後又會被採納爲 ISO/IEC 的標準。新開發的規範後來就被標準化爲 ISO/IEC 9945 和IEEE Std 1003.1，併成爲 SUSV3 的核心部分。

這種獨特的開發模式最大限度地利用了業界領先的工做成果，將正式的標準化工做轉化成了一個惟一的行爲，而且吸引了普遍的參與者。Austin Group 目前有 500 多個參與者，工做組的主席是 Open Group 的 Andrew Josey。

LSB

在90 年代中期，Linux 也開始了本身的標準化努力。實際上，Linux 一直都試圖遵照 POSIX 標準，所以在源代碼級上具備很好的兼容性，然而對於 Linux 來講，僅僅保證源碼級的兼容性還不能徹底知足要求：在 Unix 時代，大部分系統都使用的是專有的硬件，軟件開發商必須負責將本身的應用程序從一個平臺移植到其餘平臺上；每一個系統的生命週期也很長，軟件開發商能夠投入足夠的資源爲各個平臺發佈二進制文件。然而 Linux 使用的最普遍的 x86 通用平臺，其發行版是如此衆多，而發展卻如此之快，軟件開發商不可能爲每一個發行版都發佈一個二進制文件，所以就爲 Linux 上的標準化提出了一個新的要求：二進制兼容性，即二進制程序不須要從新編譯，就能夠在其餘發行版上運行。

實際上，在 Linux 社區中第一個標準化努力是文件系統層次標準（Filesystem Hierarchy Standard，FHS），用來規範系統文件、工具和程序的存放位置和系統中的目錄層次結構，例如 ifconfig 命令應該放在 /usr/bin 仍是 /usr/sbin 目錄中，光驅應該掛載到 /mnt/cdrom 中仍是 /media/cdrom 中。這些需求最終共同促進了 Linux Standard Base（LSB）項目的誕生。

LSB目前是 FSG（Free Standards Group）中最爲活躍的一個工做組，其使命是開發一系列標準來加強 Linux 發行版的兼容性，使各類軟件能夠很好地在兼容 LSB 標準的系統上運行，從而能夠幫助軟件供應商更好地在 Linux 系統上開發產品，或將已有的產品移植到 Linux 系統上。

LSB 以 POSIX 和 SUS 標準爲基礎，並對其餘領域（例如圖形）中源代碼的一些標準進行了擴充，還增長了對二進制可執行文件格式規範的定義，從而試圖確保 Linux 上應用程序源碼和二進制文件的兼容性。

LSB 簡介

LSB 是 Linux 標準化領域中事實上的標準，它的圖標（請參看圖 1）很是形象地闡述了本身的使命：對錶明自由的企鵝（Linux）制定標準。給定企鵝的體形和三維標準以後，軟件開發者就能夠設計並裁減出各色花樣的衣服（應用程序），這樣無論穿在哪隻企鵝身上，都會很是合身。

圖1. LSB圖標

在現有標準基礎上，LSB 制定了應用程序與運行環境之間的二進制接口，這主要是基於如下標準：

• Single UNIX Specification（SUS）
• System V Interface Definition（SVID）
• compilers for the Intel Itanium processor
• C++ ABI
• System V Application Binary Interface（ABI）

同時，LSB 充分吸收了 UNIX 標準化努力所取得經驗和教訓，迴避了這些標準的一些問題。例如，POSIX 僅僅定義了編程接口的標準，可是它卻沒法保證二進制的兼容性。而諸如 OSF/1 之類的標準雖然試圖解決二進制兼容性的問題，可是限制卻太爲嚴格。LSB 在兩者之間達成了一個平衡，它包含了一個二進制兼容層，同時消除了 POSIX 與 OSF/1 之間存在分歧的地方。

LSB 對各個庫提供的接口以及與每一個接口相關的數據結構和常量進行了定義，圖2給出了 LSB 3.1 環境中所包含的組件。這些組件包括開發者所須要的共享庫（包括 C++），文件系統層次結構（FHS）、對象文件格式、命令和工具、應用程序包、用戶和組、系統初始化等所採用的規範：

圖2. LSB 規範包含的組件

組織架構

爲了保證 LSB 項目的良好運行，LSB 採用了本身的完整組織架構來負責整個項目的運行，包括主席、選舉委員會、執行委員會：

• 主席：由選舉委員會選舉產生，任期兩年，負責 LSB 項目的總體運做，並對 FSG 和社區表明 LSB項目。目前的主席是 Debian 的創始人 Ian Murdock.。
• 選舉委員會：由全部對 LSB 做出貢獻的人組成，負責在主席任期期滿時選舉下一任主席。
• 執行委員會：由主席和各個子項目的領導人以及對 LSB
• 項目有重大貢獻的人組成，能夠對外做爲 LSB 項目的發言人。

工做組

LSB 項目包含幾個子項目（也稱爲工做組），分別負責不一樣的職責範圍，簡介以下：

• Specification SubGroup：負責開 LSB 規範的開發與維護，還要負責 ISO/IEC 23360（即 ISO LSB 標準的維護）。具體職責以下：
  • 維護 LSB 規範數據庫
  • 編寫 LSB 規範
  • 開發並維護生成規範文檔所須要的工具
• LSB Tools SubGroup：負責如下子項目的開發和實現：
  • SI（Sample Implementation）：遵照 LSB 規範的一個參考實現
  • Development Environment：開發符合 LSB 規範的應用程序的開發環境
  • Application Battery：符合 LSB 規範的樣例應用程序，例如 lsb-apache
• LSB Test SubGroup：負責按照 LSB 規範的定義，開發一些測試套件，來驗證用戶環境和應用程序是否符合 LSB 規範，主要包括：
  • LSB Runtime Tests：包括ANSI、POSIX、LSB-OS、線程、用戶和組、FHS、國際化、PAM（可插入認證模塊）等測試套件
  • LSB VSW4/XTS5 Test：Xlib11及其擴展庫的測試套件
  • LSB C++ Test：C++ 測試套件
• LSB Desktop SubGroup：負責開發與桌面有關的規範的測試套件，用來驗證用戶環境和應用程序是否符合 LSB 規範，主要包括：
  • GTK 庫
  • OpenGL 庫
  • PNG12庫
  • JPEG 庫
  • Fontconfig 庫
  • GTK+ Stack 庫
  • QT3/4 庫
  • XML2 庫
• LSB Future SubGroup：負載開拓 LSB 的新領域，將已經發展比較成熟能夠進行標準化但 LSB 還沒有涉及的領域歸入 LSB 標準範圍內

LSB 的標準化流程

LSB 對於標準的制定和推廣遵循務實的原則，它本身不會自行制定標準而後強行要求業界接受，而是把業界中已經成熟的技術和規範採用標準化的形式固定下來，而後大力加以推廣，這樣能夠更普遍地爲軟件供應商和用戶接受。

一個新領域要想歸入 LSB 標準的範疇，必須通過如下 3 個步驟：

1. 鑑定：確認這個領域是否已經足夠成熟，是否具備穩定的 ABI/API，是否須要進行標準化，以及是否依賴於還沒有標準化的領域。

2. 調研：調查上游軟件維護者是否還在積極維護，軟件是否穩定，是否具備很好的向後兼容性。

3. 實現：將該領域加入 LSB 數據庫、編寫規範、編寫測試套件、並將其加入開發環境、SI 和 APPBAT。

通過這 3 個步驟以後，LSB Future SubGroup 就會將其提交給 LSB 工做組，將其包含到 LSB 的下一個版本中進行發佈，並對外提供認證服務。

認證

在制定好標準並開發出測試套件以後，爲了區分系統或應用程序是否兼容 LSB 標準， FSG 提供了 LSB 標準認證服務。任何 Linux 發行版廠商和應用程序開發商均可以進行 Linux 認證，目前提供的認證有兩種：

• LSB 運行環境：爲平臺供應商提供的 LSB 標準認證
• LSB 應用程序：爲應用程序開發商提供的 LSB 標準認證

對於平臺供應商來講，通過 LSB 認證以後，就能夠確保本身的系統所提供的服務都是標準的，任何遵照 LSB 標準的應用程序均可以很好地在本身的系統上運行；而對於應用程序開發商來講，其意義則恰好相反：不須要擔憂本身的應用程序在遵照 LSB 標準的系統上的可移植性問題。

LSB 認證過程包含如下步驟：

• 註冊：要進行 LSB 認證的第一個步驟是在 https://www.freestandards.org/index.php?title=Special:Userlogin 上先建立一個賬號，並註冊您的公司和產品。
• 測試和驗證：使用 LSB 提供的測試工具，在您的測試系統上運行，並對結果進行分析（詳細內容請參看本系列的下一篇文章），確保您的系統或應用程序遵照 LSB 規範。
• 最終審計：在準備好正式提交測試結果以後，須要先簽署 LSB 認證協議和 LSB 商標許可協議，並向 FSG 支付認證所須要的費用。而後 FSG 會有專人對測試結果進行審計，若是一切正常，就經過了 LSB 認證。經過 LSB 認證的產品都會在 http://www.freestandards.org/en/Products 公開發布。目前已經 Redhat、Suse、RedFlag 等公司都已經經過了 LSB 3.0 的認證，對於 LSB 3.1 的認證正在進展中。

經過 LSB 認證以後，所認證的產品能夠貼上 "LSB Certified" 的標籤進行銷售了。

認證問題報告

在運行 LSB 所提供的測試工具時可能會出現部分測試用例失敗的狀況，其緣由多是產品自己的問題，例如 FHS 標準要求系統中必須存在 /media/ 目錄，而在某些系統中，這個目錄可能並不存在，此時就可能會致使相應的測試套件失敗，錯誤信息以下：

1 2 3 4 5 6 7 8 9

10|715 /tset/LSB.fhs/root/media/media-tc 00:55:04|TC Start, scenario ref 720-0 15|715 3.7 5|TCM Start 400|715 1 1 00:55:04|IC Start 200|715 1 00:55:04|TP Start 520|715 1 30056 1 1|Reference 3.11-1(A) 520|715 1 30056 1 2|The /media directory exists and is searchable 520|715 1 30056 1 3|/media: directory not found 520|715 1 30056 1 4|exit code 1 returned, expected 0 220|715 1 1 00:55:04|FAIL

可是有時可能並不是是測試環境的問題，而是測試套件自己的問題，或者是因爲系統中存在一個公認但卻暫時沒法修復的問題，此時並不影響 LSB 的認證的結果。若是出現這種問題，測試人員能夠將這個問題反饋給 LSB（http://www.freestandards.org/cert/prsubmit.php），通過確認以後，LSB 會在一個 waiver 文件中列出這種狀況，並將對應的測試套件暫時剔除，並嘗試在下一個版本中進行修復。咱們也能夠從 http://www.freestandards.org/cert/pr.php 上查看已經發現的問題。

LSB 的歷史、現狀和未來

LSB 項目最初發起於 1998 年 5 月，其項目啓動宣言獲得了 Linus Torvalds、Bruce Perens、Eric Raymond 等人的簽名支持，當時的目標是創建一系列構建 Linux 發行版所採用的源代碼應該遵循的標準，並提供一個參考平臺。2000 年 5 月，LSB 成爲 Free Standards Group（FSG） 的一個工做組。FSG 是一個獨立的非盈利組織，專一於經過開發和促進標準來加速開源軟件的發展。

從 2001 年 6 月發佈第一個正式版本的規範之後，LSB 規範幾乎每 6 個月都會進行一次更新。截止到 2005 年 7 月發佈的 3.0 版本爲止，LSB 重點關注的是服務器端的使用，這與 Linux 在服務器端獲得了普遍的應用是一致的。這個規範已經被 ISO 採納爲國際標準 23360。

目前最新的版本規範是 2005 年 10 月發佈的 LSB 3.1，目前它能夠支持 7 種體系結構：

• IA32
• IA64
• X86_64
• PPC32
• PPC64
• S390
• S390x

因爲平臺的差別，全部的規範除了有一個通用的版本以外，還都存在一個適用於特定平臺的版本，其中的內容是徹底適用於這個平臺的。

與上一個版本相比，LSB 3.1 版本的規範主要是加強了對桌面系統的標準化支持，增長了對 GTK 和 QT GUI 工具包的標準化。另外，LSB 還調整了本身的路線圖，以即可以與主流的 Linux 發行商（Redhat、Novell、Asianux、Debian 等）的發行計劃更好地吻合，並吸引了更多 Linux 發行商的參與，對開發工具和文檔進行了改進，還與各個國家的組織（例如中國電子技術標準化研究所，CESI）進行認證方面的合做。

下一個版本 LSB 3.2 將在 2007 年第二季度發佈，將主要增長 freedesktop.org 的標準和跨桌面的交互操做性。

LSB 4.0 將在 2008 年發佈，它將實現更好的二進制兼容性，並增長對 Perl、Python、LAMP、Java 等語言的標準化支持。詳細路線圖及各個主要版本的特性如圖 3 所示：

圖3. LSB 主要版本的路線圖

實例：lsb_release 的規範定義和實現

咱們知道，在 /etc 目錄中有一個文件能夠查看當前系統的版本信息，在 RHEL4U3（Red Hat Enterprise Linux 4 Update 3）上這個文件是 /etc/redhat-release：

1 2	# cat /etc/redhat-release Red Hat Enterprise Linux ES release 4 (Nahant Update 3)

在 SLES9SP3（SUSE LINUX Enterprise Server 9 Service Pack 3）上這個文件是 /etc/SuSE-release：

1 2 3 4

# cat /etc/SuSE-release SUSE LINUX Enterprise Server 9 (i586) VERSION = 9 PATCHLEVEL = 3

咱們能夠看出，在這兩個發行版上，不但使用的文件不一樣，文件的內容和格式也徹底不一樣。若是開發人員在本身的程序中使用這些信息，他們就很難使用一個統一的接口來獲取發行版本的信息，所以必須爲每種平臺都定製一個腳本或開發一個程序才能實現這種功能，這無疑會增長不少工做量，並且所生成的程序的可移植性也會不好。

爲了解決這個問題，LSB 規範中增長了對 lsb_release 接口及其輸出格式的定義：lsb_release 的功能是打印與發行版本相關的信息，必須實現如下選項（詳細規範的定義請參考http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html）：

表1. LSB對lsb_release 接口定義

咱們前面已經介紹過，經過 LSB 認證發行版或軟件能夠獲得 FSG/LSB 的受權，貼上 "LSB Certified"的標籤進行銷售。實際上，在經過 LSB 認證的系統上，咱們能夠看到一個與 LSB 有關的包，其中包含了 LSB 規範中對 lsb_release 接口規範的實現。lsb_release 是 LSB-Core-generic 規範中要求的一個接口，各類平臺（目前能夠支持的 7 種平臺： IA3二、IA6四、X86_6四、PPC3二、PPC6四、S390 和 S390x）上都應該提供這個接口的實現。在 RHEL4U3 上，咱們能夠找到一個名爲 redhat-lsb 的包（RHEL4U3 遵照的是 LSB 3.0 版本的規範，所以這個包的版本是 redhat-lsb-3.0-8.EL），該包的內容以下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

# rpm -ql redhat-lsb /bin/mailx /etc/lsb-release.d /etc/lsb-release.d/core-3.0-ia32 /etc/lsb-release.d/core-3.0-noarch /etc/lsb-release.d/graphics-3.0-ia32 /etc/lsb-release.d/graphics-3.0-noarch /etc/redhat-lsb /etc/redhat-lsb/lsb_killproc /etc/redhat-lsb/lsb_log_message /etc/redhat-lsb/lsb_pidofproc /etc/redhat-lsb/lsb_start_daemon /lib/ld-lsb.so.3 /lib/lsb /lib/lsb/init-functions /usr/bin/lsb_release /usr/lib/lsb /usr/lib/lsb/install_initd /usr/lib/lsb/remove_initd /usr/sbin/redhat_lsb_trigger.i386 /usr/share/man/man1/lsb_release.1.gz

而在 SLES9SP3 中，這個包的名字是 lsb（lsb-3.0-4.8），它包含的內容以下：

1 2 3 4 5 6 7 8 9 10 11

# rpm -ql lsb /etc/lsb-release /etc/lsb-release.d /etc/lsb-release.d/graphics-2.0-ia32 /etc/lsb-release.d/graphics-2.0-noarch /etc/lsb-release.d/graphics-3.0-ia32 /etc/lsb-release.d/graphics-3.0-noarch /lib/ld-lsb.so.2 /lib/ld-lsb.so.3 /usr/bin/lsb_release /usr/share/man/man1/lsb_release.1.gz

咱們能夠看出，在這兩個發行版上的兩個包中存在一些共同的文件：

• /usr/bin/lsb_release
• /lib/ld-lsb.so.3

其中 /lib/ld-lsb.so.3 在兩個系統上都是一個符號連接：

1 2	# ls -l /lib/ld-lsb.so.3 lrwxrwxrwx  1 root root 13 Apr 20 03:04 /lib/ld-lsb.so.3 -> ld-linux.so.2

系統中提供的大部分應用程序都是連接到了 ld-linux.so.2 上，可是兼容 LSB 標準的應用程序均可以連接到 ld-lsb.so.3 上（因爲 SLES9SP3 還兼容 LSB 2.0 的規範，所以系統中還存在一個 /lib/ld-lsb.so.2 庫，也是指向 ld-linux.so.2 的符號連接；而 RHEL4U3 不兼容 LSB 2.0 的規範，所以沒有這個庫）。

而 /usr/bin/lsb_release 就是對 lsb_release 接口的具體實現，在這兩個系統上都是一個 shell 腳本。下面咱們分別在這兩個系統上執行 lsb_release -a 命令，在 RHEL4U3 上的結果以下：

1 2 3 4 5 6 7

# /usr/bin/lsb_release -a LSB Version:   :core-3.0-ia32:core-3.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch:log Distributor ID: RedHatEnterpriseES Description:    Red Hat Enterprise Linux ES release 4 (Nahant Update 3) Release:        4 Codename:       NahantUpdate3

在 SLES9SP3 上的結果以下：

1 2 3 4 5 6 7 8

# /usr/bin/lsb_release -a LSB Version:   core-2.0-noarch:core-3.0-noarch:core-2.0-ia32:core-3.0-ia32:graphics-2.0-ia32: graphics-2.0-noarch:graphics-3.0-ia32:graphics-3.0-noarch Distributor ID: SUSE LINUX Description:    SUSE LINUX Enterprise Server 9 (i586) Release:        9 Codename:       n/a

咱們能夠看出，在這兩個系統上，lsb_release 命令的位置、用法、輸出格式都是相同的，所以開發人員可使用它編寫兼容性很是好的程序。

再看一下在這兩個系統上與 lsb_release 有關的包，咱們會發現兩者之間有一些區別，例如在 SLES9SP3 上存在一個 /etc/lsb-release 文件，其中存放的是所遵循的 LSB 標準的版本，內容以下：

1 2	# cat /etc/lsb-release LSB_VERSION="core-2.0-noarch:core-3.0-noarch:core-2.0-ia32:core-3.0-ia32"

而在 RHEL4U3 上並無這個文件，可是在 /etc/lsb-release.d 目錄中的文件卻比 SLES9SP3 上多：

• /etc/lsb-release.d/core-3.0-ia32
• /etc/lsb-release.d/core-3.0-noarch
• /etc/lsb-release.d/graphics-3.0-ia32
• /etc/lsb-release.d/graphics-3.0-noarch

而在 SLES9SP3 上只有以 graphics 開頭的文件。仔細查看一下 /usr/bin/lsb_release的實現咱們就會發現，所遵照的 LSB 規範的列表既能夠保存在 /etc/lsb-release 文件中，也能夠以文件的形式放到 /etc/lsb-release.d 目錄中。所以 LSB 只是對接口定義進行了規範，但卻沒有限定具體的實現，這樣既能夠爲發行版供應商提供充分的自由，又爲應用程序開發人員提供了一致的接口，能夠獲得最大限度的推廣和應用。

結束語

標準化的 Linux 操做系統能夠爲應用程序開發者提供一個開發應用程序的良好平臺，使他們開發的應用程序能夠很是平滑地移植到其餘發行版本上。LSB 經過定義一系列規範，並提供標準測試套件和開發環境，能夠幫助開發人員更容易地開發遵照規範的應用程序，輔助供應商構建更標準的系統。在本系列的下一篇文章中，咱們將介紹如何使用 LSB 標準提供的測試工具來驗證系統和應用程序是否遵照 LSB 規範。