Everest發行版從何構建而來?(轉)
Everest發行版從何構建而來?(轉)[@more@]問題由來
-----------
血脈傳承 寫道:
everest是怎樣的linux?
他是在什麼基礎上的版本?Dedian? 紅帽? Usue? 紅旗? gentoo?
迷茫
好像主要紅旗贊助的因該是紅旗基礎上的?
但是,好像在那篇文章(關於那些BUG是有效的,標題忘了)裡提到gentoo?
然後再找關於everest的介紹發現怎麼也找不到?除了五個目標之外
那個大俠給俺介紹下everest啊?
回答
------------------------
推理過程:
1,everest使用rpm,因此可以排除everest跟gentoo/arch/debian/ubuntu等非rpm系linux發行版本的關係。
2,everest是標準的rh體系特徵,可以排除everest跟非rh系的關係,也就是排除跟SuSe的關係。
3,everest是國內社群產物,由紅旗公司sponsor,我們不可能基於共創/中軟之類的版本,因此可以排除與國內其他發行版本的關係。
4,everest開發者並沒有安裝使用fedora任何一個版本的經歷(我最後使用的一個版本是redhat 8,接下來是magiclinux,然後就一直使用紅旗linux,從來沒有安裝使用或者感受過fedora的任何一個版本-從core 1到要釋出的core 6),所以,可以排除everest跟fedora系的關係。
總結:everest基於紅旗5.0,不論同志們說紅旗5好還是不好,開發庫全還是不全,everest卻完全在紅旗5.0平臺上搭建編譯和升級完成(或許這也是給那些說rf5.0不全的人一個說法:整個系統從核心到kde都可以在上面編譯的出來)。然後,借鑑了其他系統的一些優點(包括fedora,suse,magic,debian,ubuntu......,以前有帖子說明)。
因此,可以說:everest從紅旗5.0構建,完成第一個版本後,everest從自身升級構建。
從kernel-2.6.16開始到現在的kernel-2.6.18.x,以及gcc升級,glibc升級,kde的升級等等,everest所有軟體包均在自身系統構建,這也就是我常說的“自包含體系”,自己的軟體包不能在自己的平臺編譯算什麼事。
================轉自論壇=======================
-----------
血脈傳承 寫道:
everest是怎樣的linux?
他是在什麼基礎上的版本?Dedian? 紅帽? Usue? 紅旗? gentoo?
迷茫
好像主要紅旗贊助的因該是紅旗基礎上的?
但是,好像在那篇文章(關於那些BUG是有效的,標題忘了)裡提到gentoo?
然後再找關於everest的介紹發現怎麼也找不到?除了五個目標之外
那個大俠給俺介紹下everest啊?
回答
------------------------
推理過程:
1,everest使用rpm,因此可以排除everest跟gentoo/arch/debian/ubuntu等非rpm系linux發行版本的關係。
2,everest是標準的rh體系特徵,可以排除everest跟非rh系的關係,也就是排除跟SuSe的關係。
3,everest是國內社群產物,由紅旗公司sponsor,我們不可能基於共創/中軟之類的版本,因此可以排除與國內其他發行版本的關係。
4,everest開發者並沒有安裝使用fedora任何一個版本的經歷(我最後使用的一個版本是redhat 8,接下來是magiclinux,然後就一直使用紅旗linux,從來沒有安裝使用或者感受過fedora的任何一個版本-從core 1到要釋出的core 6),所以,可以排除everest跟fedora系的關係。
總結:everest基於紅旗5.0,不論同志們說紅旗5好還是不好,開發庫全還是不全,everest卻完全在紅旗5.0平臺上搭建編譯和升級完成(或許這也是給那些說rf5.0不全的人一個說法:整個系統從核心到kde都可以在上面編譯的出來)。然後,借鑑了其他系統的一些優點(包括fedora,suse,magic,debian,ubuntu......,以前有帖子說明)。
因此,可以說:everest從紅旗5.0構建,完成第一個版本後,everest從自身升級構建。
從kernel-2.6.16開始到現在的kernel-2.6.18.x,以及gcc升級,glibc升級,kde的升級等等,everest所有軟體包均在自身系統構建,這也就是我常說的“自包含體系”,自己的軟體包不能在自己的平臺編譯算什麼事。
================轉自論壇=======================
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10617542/viewspace-961969/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 資料中臺從何而來
- Android 事件分發完全解析之事件從何而來Android事件
- C++函式呼叫棧從何而來C++函式
- 製造業核心競爭力從何而來
- 使用者介面設計準則從何而來
- 病毒從何而來?AlphaFold等AI正在尋找答案AI
- 前端程式設計師的焦慮感從何而來?前端程式設計師
- 市面上的低價伺服器從何而來伺服器
- 邊緣計算和5G:我們從何而來?
- BEAM和JVM虛擬機器對比:JVM是為並行而構建的,而BEAM是為併發構建的 | ErlangJVM虛擬機並行
- 構建屬於自己的 Linux 發行版Linux
- [提問交流]Article控制器下的category函式從何而來?Go函式
- 內卷下的智慧投影行業,未來何去何從?行業
- 馬化騰深夜發問 網際網路未來何去何從
- 資料中心從何而來?華為雲學院帶你一探究竟!
- SIE VP 專訪:PS5 的 UI 設計靈感從何而來?UI
- 專訪《節奏醫生》開發團隊:悅耳的 BGM 和魔性的玩法從何而來
- 從何而選:從程式設計菜鳥到“牛人”之路程式設計
- SQL Server 觸發器中的兩個臨時表inserted及deleted,其資料從何而來?SQLServer觸發器delete
- iOS開發何去何從iOS
- 動作遊戲打擊感到底從何而來?(上):幀與動作屬性遊戲
- 大資料如何採集資料?大資料的資料從何而來?大資料
- 從 流行linux發行版 看 發行版引數Linux
- 為何而跑?
- GitHub破例接受投資,未來何去何從?Github
- 構建Java Agent,而不是使用框架Java框架
- 遊戲的打擊感從何而來? 打擊感的意識形態原理分析遊戲
- 動作遊戲打擊感到底從何而來?(下):鏡頭藝術與輔助演出遊戲
- 重新認識下JVM級別的本地快取框架Guava Cache——優秀從何而來JVM快取框架Guava
- web前端開發前景何去何從Web前端
- 未來展望:計算機世界即將何去何從計算機
- 根據意圖而不是架構構建程式 - Janos Pasztor架構
- JAVA中使用最廣泛的本地快取?Ehcache的自信從何而來 —— 感受來自Ehcache的強大實力Java快取
- 40歲大齡失業程式猿,未來該何去何從
- 想在JBoss上構建OA系統,各位有何建議?
- GraphQL是為聚合統一而構建的 - thenewstack
- 為建設而建設 ,為系統而系統
- 呼叫建構函式進行型別轉換函式型別