Log for Ubuntu 台灣社群
interface 有改變，我記得之前 shred 可以給 device id
26.04 上的 shred 這樣用會出現錯誤訊息：
shred /dev/sdb26.04 上的 shred 這樣用會出現錯誤訊息：
shred: /dev/sdi: Not a file在 Linux 上執行 macOS 軟體 （★ 139 分）
Darling 是一套讓 Linux 執行 macOS 軟體的開放原始碼轉譯層，定位類似 Wine：Wine 讓 Linux 可執行 Windows 程式，Darling 則嘗試重建 macOS 所依賴的 Darwin 環境。它不使用硬體模擬器，而是直接在 Linux 上執行相容程式，並納入 Mach 核心機制、dyld 動態載入器與 launchd 服務管理等 Darwin 元件。專案採 GNU GPL v3 授權，主要運用 Apple 公開釋出的 Darwin 程式碼，以及 The Cocotron、GNUstep、Apportable Foundation 等開放原始碼成果。
Darling 的目標是讓 macOS 應用程式在 Linux 桌面上具備接近原生程式的外觀與操作感，但目前圖形介面程式僅有基礎實驗性成果，適用範圍以簡單應用程式為主；命令列工具則較具可用性。專案強調未違反 Apple 的終端使用者授權協議，因為只直接採用已完全開放的 Darwin 部分。長期規畫還包括在 ARM 裝置上執行 iOS App，但這需要自行實作 UIKit，難度很高；在 Windows 的 WSL 2（Windows Subsystem for Linux 2，Windows 的 Linux 子系統）環境中也可建置與使用 Darling。
討論串指出，Darling 的實際範圍遠小於「可執行 macOS 軟體」這句宣傳語：它較能處理依賴開放 Darwin 元件的程式，未公開的 macOS 圖形程式框架仍是主要障礙。AppKit（macOS 傳統圖形介面框架）、Quartz 圖形系統等內容並非完整開放，使 Logic Pro、Final Cut Pro、Photoshop 或 Xcode 圖形介面等主流商業軟體短期內難以執行。有人補充，Xcode 的 Clang、LLDB、Git、Swift 與 Metal 編譯器等命令列工具已有部分可用性，但 Xcode 圖形介面尚不可行，`xcodebuild` 也僅能處理極簡單的 XIB 介面專案。
社群普遍認為，Darling 與 Wine 的落差主要來自累積時間、人力與生態規模。Wine 自 1993 年起逐步建立 Windows API（應用程式介面）與 ABI（二進位介面）的相容層，並擁有龐大的測試套件、相容性資料庫與 Valve、Steam 等遊戲市場的實際需求；相較之下，Darling 的 AppKit 進展緩慢，近期更新也不多。部分意見認為 Apple 的軟硬體整合及專有框架讓重建難度更高；也有人反駁，Windows 同樣有龐大且複雜的圖形與系統元件，關鍵差異更在於 Wine 較早起步、取得足夠採用者與開發動能。整體而言，Darling 是具技術價值的基礎建設，但距離讓 Linux 使用者日常執行完整 macOS 商業圖形軟體，仍有很長一段路。
👥 46 則討論、評論 💬
https://news.ycombinator.com/item?id=49515830
Darling 是一套讓 Linux 執行 macOS 軟體的開放原始碼轉譯層，定位類似 Wine：Wine 讓 Linux 可執行 Windows 程式，Darling 則嘗試重建 macOS 所依賴的 Darwin 環境。它不使用硬體模擬器，而是直接在 Linux 上執行相容程式，並納入 Mach 核心機制、dyld 動態載入器與 launchd 服務管理等 Darwin 元件。專案採 GNU GPL v3 授權，主要運用 Apple 公開釋出的 Darwin 程式碼，以及 The Cocotron、GNUstep、Apportable Foundation 等開放原始碼成果。
Darling 的目標是讓 macOS 應用程式在 Linux 桌面上具備接近原生程式的外觀與操作感，但目前圖形介面程式僅有基礎實驗性成果，適用範圍以簡單應用程式為主；命令列工具則較具可用性。專案強調未違反 Apple 的終端使用者授權協議，因為只直接採用已完全開放的 Darwin 部分。長期規畫還包括在 ARM 裝置上執行 iOS App，但這需要自行實作 UIKit，難度很高；在 Windows 的 WSL 2（Windows Subsystem for Linux 2，Windows 的 Linux 子系統）環境中也可建置與使用 Darling。
討論串指出，Darling 的實際範圍遠小於「可執行 macOS 軟體」這句宣傳語：它較能處理依賴開放 Darwin 元件的程式，未公開的 macOS 圖形程式框架仍是主要障礙。AppKit（macOS 傳統圖形介面框架）、Quartz 圖形系統等內容並非完整開放，使 Logic Pro、Final Cut Pro、Photoshop 或 Xcode 圖形介面等主流商業軟體短期內難以執行。有人補充，Xcode 的 Clang、LLDB、Git、Swift 與 Metal 編譯器等命令列工具已有部分可用性，但 Xcode 圖形介面尚不可行，`xcodebuild` 也僅能處理極簡單的 XIB 介面專案。
社群普遍認為，Darling 與 Wine 的落差主要來自累積時間、人力與生態規模。Wine 自 1993 年起逐步建立 Windows API（應用程式介面）與 ABI（二進位介面）的相容層，並擁有龐大的測試套件、相容性資料庫與 Valve、Steam 等遊戲市場的實際需求；相較之下，Darling 的 AppKit 進展緩慢，近期更新也不多。部分意見認為 Apple 的軟硬體整合及專有框架讓重建難度更高；也有人反駁，Windows 同樣有龐大且複雜的圖形與系統元件，關鍵差異更在於 Wine 較早起步、取得足夠採用者與開發動能。整體而言，Darling 是具技術價值的基礎建設，但距離讓 Linux 使用者日常執行完整 macOS 商業圖形軟體，仍有很長一段路。
👥 46 則討論、評論 💬
https://news.ycombinator.com/item?id=49515830
硬碟壞軌，把資料全部清除以後才拿去回收
還是你想問的是什麼情境下只處理一個檔案的內容？
硬碟沒有故障，但是我只想想曾經用來儲存財務資料的檔案銷毀，這個時候就只會清理儲存檔案的 data block，不會處理整個硬碟
多數檔案系統 (NTFS, ext4, zfs 等) 會將檔案位置和權限放在 inode (metadata)，檔案內容則存放於 data block 區段
刪除檔案時，僅更新檔案系統的 inode，把路徑、權限、時間記錄刪除。
這個情況下找資料不會出現這個檔案，也不知道檔案的內容放在硬碟的哪個位置，但是內容還是存在。
會需要做 zero fill ，主要原因是擔心惡意人士，把整個硬碟的 block 都讀取一次，然後嘗試從不完整的資料中取得敏感字眼，像是姓名、電話等資料，再拿去利用。
另外做一次 zero fill 並不表示資料完全無法被讀取，硬碟碟片上的感磁材料有可能因為磁場強度略微減弱，或是特徵不同，逆推測出過去的狀態，進而得知檔案內容。重要資料要銷毀，通常會抹除一次以上。再嚴格一點，會加上物理性破壞 (搜尋 shredder，影片蠻舒壓的 XD)
一般資料不必搞得那麼累，自己做好風險評估即可
還是你想問的是什麼情境下只處理一個檔案的內容？
硬碟沒有故障，但是我只想想曾經用來儲存財務資料的檔案銷毀，這個時候就只會清理儲存檔案的 data block，不會處理整個硬碟
多數檔案系統 (NTFS, ext4, zfs 等) 會將檔案位置和權限放在 inode (metadata)，檔案內容則存放於 data block 區段
刪除檔案時，僅更新檔案系統的 inode，把路徑、權限、時間記錄刪除。
這個情況下找資料不會出現這個檔案，也不知道檔案的內容放在硬碟的哪個位置，但是內容還是存在。
會需要做 zero fill ，主要原因是擔心惡意人士，把整個硬碟的 block 都讀取一次，然後嘗試從不完整的資料中取得敏感字眼，像是姓名、電話等資料，再拿去利用。
另外做一次 zero fill 並不表示資料完全無法被讀取，硬碟碟片上的感磁材料有可能因為磁場強度略微減弱，或是特徵不同，逆推測出過去的狀態，進而得知檔案內容。重要資料要銷毀，通常會抹除一次以上。再嚴格一點，會加上物理性破壞 (搜尋 shredder，影片蠻舒壓的 XD)
一般資料不必搞得那麼累，自己做好風險評估即可