taiwan2008 wrote:
Debian 能使用 wine + win10 app 嗎?
foobar2000 X64 版, Acrobat reader X64 版可以
聽說蠻多game也可以
個人積分：2318分
文章編號：92546818
個人積分：2318分
文章編號：92547392
GailLim wrote:
所以我才用Lubuntu啊！Debian的穩定基底，Ubuntu頻繁更新和龐大社群，LXQT的輕量加上QT的現代化。
debain + lxqt 4.78GB
debian + xfce 4.08GB
在上面跑浮點運算沒有什麼差別 lxqt 沒有感覺比 xfce 輕量 反而有點不夠 polished 的感覺
pcmanfm.qt 有 themes 可以點綴比較花俏 pcman最大的致命傷 emblem 無法顯示version control 的 status
我反而比較喜歡 thunar in xfce dark theme debian + xfce 仍然是不錯的組合 穩定+輕量
個人積分：2318分
文章編號：92554997
選舉 wrote:
使用LINUX就是要穩定
如果要新鮮亮點
那今天如果又跑出另一個作業系統
你的個性一定是又跳到那邊去了
說到底你其實不是一個在使用LINUX的人
像我在使用LINUX前，就先比較各個套件的優缺點
人家都說DEBIAN穩，我就安裝 一直用到現在
沒用過其他套件
Google's main internal desktop Linux, gLinux, is indeed based on Debian Testing (now called Rodete - Rolling Debian Testing) and replaced their older Ubuntu-based system (Goobuntu) for smoother, rolling updates, offering faster security fixes and avoiding large, disruptive OS upgrades. They build gLinux from Debian's source, adding their own customizations, and contribute changes back upstream, utilizing Debian's package system for efficiency.
谷歌的主要內部桌面 Linux 發行版gLinux是基於Debian Testing 的。（現名為 Rodete - Rolling Debian Testing）並取代了他們之前基於 Ubuntu 的系統（Goobuntu），以實現更流暢的滾動更新，從而更快地修復安全問題，並避免大規模、破壞性的作業系統升級。他們基於 Debian 原始碼建立 gLinux，並添加了自己的客製化功能，然後將變更貢獻回上游，同時利用 Debian 的軟體包系統來提高效率。
個人積分：2318分
文章編號：92555198
在谷歌，我們運行著龐大的生產環境，為 YouTube 和 Gmail 等谷歌產品提供服務。為了支援包括工程師在內的所有員工，我們也經營著規模龐大的企業級設備群，涵蓋數十萬台設備，分佈在多個平台、型號和地點。為了讓每位Google員工都能在最適合自己的環境中有效運作，我們運行多種作業系統平台，包括 Linux 系統。長期以來，我們內部使用的 Linux 發行版 Goobuntu 一直是基於 Ubuntu LTS 版本。 2018 年，我們完成了向基於 Debian 的滾動發布模式的遷移。
升級苦力
十五多年前，Ubuntu 被選為公司內部 Linux 發行版的基礎，因為它用戶友好、易於使用，並且擁有許多高級功能。之所以選擇長期支援 (LTS) 版本，是因為 Canonical 提供的兩年以上的安全性更新非常值得信賴。
然而，LTS 版本兩年的發布週期也意味著，在作業系統生命週期結束前，我們必須升級超過 10 萬台裝置中的所有機器。企業機器上運行的工作負載非常複雜，因此重新安裝和完全客製化機器可能是一項既困難又耗時的操作。每兩年就讓所有工程師從頭開始配置工作區，這會嚴重影響生產力，從經濟角度來看，這顯然不是明智的選擇。
每個作業系統週期，主要軟體包的版本都會有相當大的躍升，這可能需要對軟體配置進行重大更改。為了實現這個過程的自動化，我們編寫了一個無人值守的就地升級工具，它可以處理許多常見問題。這種以自動化為中心的方法意味著大多數Google員工無需手動升級他們的機器，也無需重新安裝系統並重新建立所有配置。然而，為了實現這一點，我們需要對升級過程進行全面的測試，並確保所有已更改的主要軟體包都能正常運作（在 Ubuntu 系統中，主版本之間可能需要升級多達數千個軟體包）。有時，當出現棄用情況時，很難實現自動化，工程師必須決定如何繼續前進。
升級我們的 Goobuntu 系統通常需要近一年的時間。由於支援週期為兩年，這意味著距離下一個 LTS 版本發布只剩一年時間，我們必須再次經歷相同的流程。整個過程給我們的團隊帶來了巨大的壓力，因為我們收到了數百個 bug 報告，以及針對各種特殊情況的求助。每次升級完成後，團隊都會普遍感到“接近精疲力竭”，這種狀態幾乎無法恢復，直到下一輪更新到來。此外，使用 LTS 版本也意味著，我們發行版用戶遇到的一些 bug 可能已經在上游修復，但這些改進可能從未移植到 LTS 版本中。
此外，還有大量特殊情況的升級需要處理，有時甚至會持續數年之久。如何讓工程師升級那些無法透過自動升級流程完成的機器，是變更管理方面的巨大挑戰。為了激勵用戶升級機器，我們採取了多種創新方法，包括在使用者介面上顯示提醒訊息、發送郵件、安排重啟，甚至強制關機，以提高用戶對某些機器亟需升級的認識。有時，這些措施甚至能發現一些使用者完全遺忘的機器，例如桌子底下那台運行著重要係統關鍵管道的機器。
滾動發行
我們在設計 gLinux Rodete（滾動 Debian 測試版）時，旨在取消兩年一次的升級週期，並將團隊的工作量分散到更長的時間跨度內。業界普遍採用 CI/CD 的趨勢表明，較小的增量變更更容易控制和回滾。如今，Linux 發行版採用滾動式發布模式（例如 Arch Linux 和 NixOS）的情況越來越普遍。
我們曾考慮過其他 Linux 發行版，但最終還是選擇了 Debian，因為我們仍然希望提供平滑的就地遷移。這其中考慮了 Debian 軟體包的可用性、龐大的 Debian 社區，以及使用 Debian 格式的現有內部軟體包和工具。 Debian 穩定版的發布週期大約為兩年，而 Debian 測試版則採用滾動發布模式，因為它匯集了所有從上游獲取和構建的軟體包，等待下一個穩定版的發布。
從上游發佈到測試版上線通常只需幾天時間（儘管在 Debian 穩定版發布前的凍結期內，有時會延遲幾個月）。這意味著我們通常可以獲得更精細的變更，並能及時向 Google 的工程師提供最新軟體，而無需等待更長時間。
如此頻繁的更新迫使我們重新設計了許多系統和流程。雖然最初計劃更頻繁地發布，但我們發現，每週發布對我們來說是一個最佳平衡點，既能保證快速迭代，又能確保發布流程的完整性，同時還能最大限度地減少對開發人員生產力的影響。
每當我們啟動一個新版本發佈時，我們會對當時從 Debian 匯入的所有軟體包進行快照。經過一些驗收測試後，新的封閉式候選版本會謹慎地部署到專用的測試集群，以及一個覆蓋 1% 伺服器的「金絲雀」版本。 「金絲雀」版本會刻意保留幾天時間，以便在正式發佈到整個叢集之前，檢測 Debian 軟體包或 Google 內部軟體包是否有任何問題。
篩分簡介
為了管理從原始碼建立所有上游軟體包的所有這些複雜任務，我們建立了一個名為 Sieve 的工作流程系統。每當我們發現 Debian 軟體包的新版本時，我們都會啟動一個新的建置。我們以軟體包組的形式建立軟體包，以便將需要一起升級的獨立軟體包考慮在內。一旦整個軟體包組建置完成，我們會執行一個虛擬化的測試套件，以確保我們的核心元件和開發人員工作流程沒有受到任何影響。每個軟體包組都會單獨進行測試，測試內容包括完整的系統安裝、啟動以及在該作業系統版本上執行本機測試套件。雖然單一軟體包的建置通常只需幾分鐘即可完成，但考慮到軟體包組的複雜性，這些測試可能需要長達一小時的時間。
軟體包建置完成並通過所有測試後，我們會將所有新軟體包合併到最新的軟體包池中。發布新版本時，我們會為該軟體包池建立一個快照，其中每個軟體包的版本都已鎖定到該版本中。然後，我們會運用 SRE 原則（例如增量發布和監控部署環境健康狀況）謹慎地引導該版本部署到整個部署環境。
但並非所有建置都能一次成功。如果軟體包建置失敗，我們通常會在 Debian 的 bug 追蹤系統中尋找已知 bug，如果尚未發現，我們會將其提交上報。有時，我們的發布工程師需要發揮創造力，應用本地的變通方案/補丁來使軟體包在我們的生態系統中能夠構建，並在上游發布修復程序後棄用這些變通方案。
例如，我們遇到過幾次這樣的問題：在上游 Debian 系統中，軟體包通常是在 Debian unstable 版本中建構的。幾天后，這些已建置的軟體包會遷移到 Debian testing 版本。然而，在某些情況下，建置依賴項可能仍然停留在 unstable 版本中，因此在 testing 版本中建立軟體包可能（暫時）不可行。在這種情況下，我們通常會先嘗試在上游進行修復，這既可以降低維護這些本地補丁的複雜性和負擔，又能為社區做出貢獻。
如果任何步驟失敗，Sieve 提供了一系列工具來重試建置。例如，當它開始建立一組軟體包時，系統會根據經驗猜測哪些依賴項需要一起建構。但有時 Debian 原始碼包中提供的版本資訊可能不完整，導致這種猜測出錯。因此，Sieve 會定期重試建置失敗的軟體包組。由於我們軟體包的最新快照會不斷變化，因此可能會出現這樣的情況：在將看似獨立的軟體包組添加到快照後，之前構建失敗的軟體包組卻意外地成功構建並通過了測試。所有這些工作流程大多是自動化的，這也凸顯了在這個領域中以 SRE 的視角思考的重要性。當遇到故障時，通常看起來只需修復一次失敗的建置似乎更容易，但如果我們需要反覆應用相同的解決方法，那麼將解決方法寫入程式碼將減輕工程師的整體負擔。
從原始程式碼建立所有二進位檔案並擁有額外的原始碼溯源資訊來驗證運行二進位檔案的來源，這在安全性方面也具有一些優勢。例如，在發生安全事件時，我們可以快速重建，並且由於我們之前已經建立了所有最終發佈到發行版中的軟體包，因此我們能夠使用臨時修補程式確保建置版本正常運作。此外，我們也降低了對上游 Debian 及其基礎設施產生的二進位建置工件的信任度。相反，一旦原始碼被接收並且二進位檔案建置成功，我們就可以透過加密技術證明運行的二進位檔案正是源自該原始程式碼。
升級到羅德特
上一個 Goobuntu 版本是基於 Ubuntu 14.04 LTS（代號 Trusty）。 Rodete 的開發始於 2015 年，我們很快就意識到不能直接放棄對 Trusty 的支持，並要求所有工程師安裝一個全新的發行版。憑藉著之前 LTS 版本間原地升級的經驗，我們對這次遷移已經有所了解。由於 Ubuntu 是 Debian 的衍生版本，並且使用了許多相同的軟體包基礎設施/格式（apt），因此將 Goobuntu 14.04 原地升級到 Debian 並非異想天開。我們重複使用了先前原地升級工具的部分功能，並透過增加自動化程度和進行更多測試來提高其可靠性。
為了方便建立、測試和維護此類工具，我們選擇將 gLinux Rodete 暫時凍結為 Debian 測試版在特定日期的快照，我們稱之為基準。我們可以根據需要調整此基線，以平衡 Sieve 匯入的軟體包。為了減少摩擦，我們特意將 Rodete 的基線設定為 2016 年的 Debian 穩定版，該版本與 Ubuntu Trusty 的整體狀態更為接近。這樣，我們就可以將 Trusty 到 Debian 的原地升級與 Debian 之後發生的重大軟體包版本變更區分開來。
2017 年，我們開始將機器遷移到 Rodete，並在 2018 年底完成了最後的就地遷移。然而，我們當時仍然保留著一套基線軟體包，其版本已經過時近兩年。為了趕上 Debian Testing 的步伐，我們團隊發起了一項全員參與的工作，專注於優化 Sieve 的行為，並加快軟體包的建置/測試速度。這種增量式的升級方式，以及我們可控的滾動發布目標，減輕了 Google 工程師和我們團隊的工作量。
2019年初，我們開始關閉最後幾台運行Goobuntu的機器。我們的基準版本也已更新至僅落後約250天，這意味著當時我們使用的軟體包版本大多與Buster版本相同。到了2020年年中，我們終於完全趕上Debian Bullseye的發佈時間。我們將繼續推進基準版本的更新，並可能在2023年中Debian穩定版發布之前，就已經開始使用與其版本類似的Debian穩定版。
達到禪境
如今，gLinux 團隊成員的工作方式已截然不同。我們大幅減少了版本發布所需的工程時間和精力，只需一名值班發布工程師在團隊成員間輪調即可。我們不再需要大力升級所有系統。新的 LTS 版本也不再需要經歷多階段的 alpha、beta 和 GA 測試，同時也要費力地維護那些仍在運行 Ubuntu Precise 或 Lucid 的舊機器。
我們還透過使我們的系統更緊密地與上游版本同步運行，顯著提升了安全性。雖然 Debian 為穩定版和舊穩定版提供了豐富的安全補丁，但我們意識到，並非所有獲得補丁的安全漏洞都一定有 Debian 安全公告 (DSA) 或 CVE 編號。我們的滾動發布計畫確保我們能夠快速修復整個系統上的安全漏洞，同時又不影響系統穩定性。而此前，安全工程師必須仔細審查每個 DSA，並確保修復程序已應用到我們的系統中。
我們改進了測試套件，並與運行關鍵開發系統的重要合作夥伴團隊進行了整合測試，這使得使用提供最新版 Linux 核心的 Linux 發行版時，體驗更加穩定。我們一直致力於實現管線中所有環節的自動化，這顯著減輕了團隊的工作量和壓力。現在，我們還可以報告錯誤以及與其他程式庫版本的不相容性，同時確保 Google 工具在 Linux 生態系統中更好地運作。
如果您希望在公司成功推行滾動發布，那麼請考慮平衡公司需求與升級敏捷性。掌控我們自身的動態目標和基線，有助於我們在遇到過多問題或違反團隊服務等級目標 (SLO) 時放慢速度。我們的實踐最終強化了我們的信念：漸進式變更比大規模發布更容易管理。
如果能夠控制新工作的湧入量並保持其可預測性，我們的工程師就能保持更高的工作滿意度，壓力也會更小。這最終降低了團隊的人員流動率，確保我們能夠專注於提升專業技能，而不是同時應對多個棘手的問題。
未來，我們計劃與上游 Debian 更緊密地合作，並貢獻更多內部修補程式來維護 Debian 軟體包生態系統。
個人積分：562分
文章編號：92555635
cdma2k wrote:「然而，LTS 版本兩年的發布週期也意味著，在作業系統生命週期結束前，我們必須升級超過 10 萬台裝置中的所有機器。企業機器上運行的工作負載非常複雜，因此重新安裝和完全客製化機器可能是一項既困難又耗時的操作。每兩年就讓所有工程師從頭開始配置工作區，這會嚴重影響生產力，從經濟角度來看，這顯然不是明智的選擇。」
Google 為何最...(恕刪)
簡單地說，作為伺服器，兩年一次升級它們覺得耗時耗力，所以「基於Debian」打造gLinux，讓谷歌自行決定何時升級、要不要升級。
他們責怪的不是Ubuntu不好，而是Ubuntu常常有新的發行版，這是伺服器不要的，卻是桌機要的！！
gLinux加入滾動式更新，但
AI 摘要
Ubuntu 官方是固定版本發行 (Fixed Release)，但也有接近滾動更新的方式，主要透過設定讓系統更新到最新軟體，或是在特定非官方版本 (如 Ubuntu Server 的 rolling kernel 概念) 體驗，核心差異在於固定版是定期大版本升級，滾動版是持續不斷更新最新軟體。要在 Ubuntu 體驗滾動更新感，可利用 PPA、apt 追蹤 testing 來源，或使用 Ubuntu Mainline Kernel PPA 獲得最新內核，但需注意穩定性風險。
也就是說，谷歌工程師「基於Debain」的gLinux可能有PPA那樣的滾動式更新，避免一次性大規模更新帶來的控制風險。
找不到Debain原生版可以滾動式更新，Debain建立PPA討論倒是不少。
個人積分：562分
文章編號：92556768
個人積分：562分
文章編號：92556916
個人積分：562分
文章編號：92557038
個人積分：2318分
文章編號：92565098
說真的，為什麼要把這麼爛的遙測軟體做成硬體元件，而且還能在 Windows 更新後強制重新安裝並啟用自身？ ！我花錢買的東西，就不能照自己的方式用嗎？答案是 Debian 13。去他媽的惠普，CEO 應該好好學「使用者同意」是什麼意思。
我真希望一開始就這麼做，這真是一次很棒的體驗。令我驚訝的是，我的所有硬體都能正常使用，而且運行速度比在 Windows 系統下還要流暢。最重要的是，我喜歡可以自由選擇系統安裝哪些軟體！指紋辨識器也能正常運作，而且螢幕可以像折疊蓋一樣翻轉。
我唯一建議的是，即使是 CLI 使用，也應該增加一種安全的方式，允許使用指紋而不是帳戶密碼登入。
Forced HP telemetry made me mad enough to delete Windows 11 and install Debian 13. Couldn't be happier.
r/debian - Forced HP telemetry made me mad enough to delete Windows 11 and install Debian 13. Couldn't be happier.
Seriously, why make crappy telemetry software a hardware component that can forcibly reinstall & enable itself after a Windows update!? Can I just use what I BOUGHT WITH MY OWN MONEY the way I want? The answer is Debian 13. F--k HP, the CEO should learn what "consent" is.
I wish I just did this at the beginning, its been a great experience. I am surprised that all my hardware is usable, and it runs better than it did on Windows. Most of all, I like choosing what is installed on my system! The finger print scanner works, and the screen flips when I fold it back.
I think the only thing I would suggest is adding a secure way to enable logging in with the finger print over the account password, even for CLI usage.
個人積分：2753分
文章編號：92565111
cdma2k wrote:
惠普強制收集遙測資料的行為讓我非常生氣，我卸載了 Windows 11，安裝了 Debian 13。我簡直太高興了。 r/debian -惠普強制收集遙測資料讓我非常生氣，於是我刪除了 Windows 11 並安裝了 Debian 13。我簡直太高興了。
說真的，為什麼要把這麼爛的遙測軟體做成硬體元件，而且還能在 Windows 更新後強制重新安裝並啟用自身？ ！我花錢買的東西，就不能照自己的方式用嗎？答案是 Debian 13。去他媽的惠普，CEO 應該好好學「使用者同意」是什麼意思。
我真希望一開始就這麼做，這真是一次很棒的體驗。令我驚訝的是，我的所有硬體都能正常使用，而且運行速度比在 Windows 系統下還要流暢。最重要的是，我喜歡可以自由選擇系統安裝哪些軟體！指紋辨識器也能正常運作，而且螢幕可以像折疊蓋一樣翻轉。
我唯一建議的是，即使是 CLI 使用，也應該增加一種安全的方式，允許使用指紋而不是帳戶密碼登入。
Forced HP teleme
網友 BCMM 解釋 4h ago
Fun fact: it's actually Windows reinstalling the OEM crap. The "hardware component" is really just an instruction to Windows, which Windows is designed to carry out.
There are these things called ACPI tables. On every boot, the system firmware places them in RAM before it hands over to the OS. They contain various information about the hardware which may be useful to the operating system. (It's a hideously over-complex system, designed by Microsoft and seldom implemented correctly, but I digress.)
One such table is called the "Windows Platform Binary Table". If a WPBT is present when Windows boots, Windows copies whatever data it contains to a file in system32, and then executes it. Windows does not offer any way to disable this "feature".
有趣的事實：實際上是 Windows 重新安裝了 OEM 的垃圾軟體。 「硬體元件」其實只是給 Windows 的一條指令，而 Windows 的設計初衷就是執行這條指令。
有一種叫做 ACPI 表的東西。每次啟動時，系統韌體都會在將控制權交給作業系統之前，將它們放入 RAM 中。它們包含各種可能對作業系統有用的硬體資訊。 （這是一個極為複雜的系統，由微軟設計，但很少能正確實現，不過我離題了。）
其中一個表格叫做「Windows 平台二進位表」（WPBT）。如果 Windows 啟動時存在 WPBT，Windows 會將其包含的所有資料複製到 system32 目錄下的一個檔案中，然後執行該檔案。 Windows 沒有提供任何停用此「功能」的方法。
==
所以這並不是硬體 (一般指晶片)
覺得很嚴重的話查查 firewall logs 把他擋下就好
==
停用 WPBT 的方法
https://github.com/Jamesits/dropWPBT
==
相關訊息
https://github.com/xsh3llsh0ck/Calamity
谷歌大神:
Major PC and motherboard manufacturers have used the Windows Platform Binary Table (WPBT) to automatically install software (often referred to as "bloatware" or "crapware") from the system's firmware.
Some of the OEMs that have been identified as using WPBT include:
Lenovo: Used it for their "Lenovo Service Engine" (LSE) to ensure an updater would "respawn" even after a clean OS install.
ASUS: Has been observed using WPBT to forcibly install and reinstall their software.
Dell: Indicated in some sources as potentially using this method for driver injection.
HP: Also mentioned as using the feature for similar purposes (injecting drivers or other software).
Gigabyte: Security researchers found that Gigabyte motherboards use this to install their update service, though it may be an optional setting in the BIOS/UEFI.
Huawei: Historically used WPBT for legitimate purposes.
The functionality allows these manufacturers to embed an executable file in the UEFI/BIOS firmware, which Windows then extracts and runs automatically under SYSTEM privileges every time the system boots, even after a fresh installation of the operating system from official Microsoft media.
