【免費(fèi)下載鏈接】tty7The terminal that outlives its window. Shells survive quitting the app, agents can drive other agents, and remote machines work the same way. Pure Rust, GPU-rendered.項(xiàng)目地址https://gitcode.com/gh_mirrors/tty/tty7點(diǎn)擊查看免費(fèi)下載tty7 是一款純 Rust、GPU 渲染的現(xiàn)代終端它的核心承諾是窗口死了終端不死。普通終端里關(guān)掉窗口等于殺掉所有 shell而 tty7 把 shell 交給一個(gè)后臺(tái)守護(hù)進(jìn)程daemon持有并為每個(gè)面板維護(hù)兩級(jí)回放緩沖——內(nèi)存中的 8 MiB 環(huán)形緩沖 磁盤上的 256 KiB 周期性快照。正因如此無論是誤關(guān)窗口、進(jìn)程崩潰、kill -9還是整臺(tái)機(jī)器重啟重新打開 tty7 后你都能看到崩潰前屏幕上的內(nèi)容。本文帶你深析這套回放緩沖與會(huì)話恢復(fù)機(jī)制的設(shè)計(jì)取舍。tty7 的架構(gòu)基石窗口不擁有你的 shell理解崩潰后屏幕還能回來先要理解 tty7 的分層結(jié)構(gòu)窗口Window只是 GUI 客戶端負(fù)責(zé)顯示和輸入守護(hù)進(jìn)程daemon后臺(tái)服務(wù)器真正持有每個(gè) pane 的 PTY 文件描述符Pane一個(gè)終端實(shí)例擁有穩(wěn)定 id如%42這個(gè) id 是 CLI 和恢復(fù)機(jī)制尋址的關(guān)鍵。關(guān)閉 tty7 窗口只是斷開了一條 socket 連接守護(hù)進(jìn)程繼續(xù)存活你的構(gòu)建繼續(xù)跑、agent 繼續(xù)工作、SSH 會(huì)話不斷開。再次打開時(shí)客戶端按 pane id 重新 attach看到的正是離開時(shí)的屏幕。這套守護(hù)進(jìn)程擁有會(huì)話的模型也是遠(yuǎn)程機(jī)器上體驗(yàn)一致的原因架構(gòu)說明詳見官方文檔docs/getting-started/concepts.mdx。第一級(jí)緩沖內(nèi)存中的 8 MiB 回放環(huán)每個(gè) pane 的輸出字節(jié)都會(huì)進(jìn)入守護(hù)進(jìn)程內(nèi)存里的一個(gè)環(huán)形緩沖區(qū)replay ring上限由 pane.rs 中的RING_CAP定義const RING_CAP: usize 8 * 1024 * 1024; // 8 MiB回放環(huán)按幾何同構(gòu)段Segment切分一段輸出記錄了它寫入時(shí)的窗口尺寸cols/rows/字號(hào)重放時(shí)客戶端按原始寬度解包字節(jié)不會(huì)把舊輸出按當(dāng)前寬度錯(cuò)誤折行。窗口沒死、只是斷連的場景——比如手機(jī)連回來、CLI 重新 attach——全靠這塊環(huán)。但環(huán)也有致命弱點(diǎn)它只活在守護(hù)進(jìn)程自己的進(jìn)程里。一次崩潰、kill -9或重啟環(huán)和進(jìn)程一起消失窗口回來時(shí)只剩一排空白 shell。這正是第二級(jí)緩沖登場的地方。第二級(jí)緩沖磁盤快照——只存 256 KiB每 30 秒一次磁盤快照的實(shí)現(xiàn)集中在 scrollback.rs設(shè)計(jì)思路寫在了模塊注釋里值得細(xì)看定時(shí)而非逐字節(jié)寫盤見 SNAPSHOT_INTERVAL每個(gè) pty 字節(jié)都落盤會(huì)帶來巨大的寫放大只為換取崩潰前最后幾秒的新鮮度不劃算。寫入器跑在一個(gè) 30 秒周期的線程tty7-scrollback上server.rs且跳過環(huán)形緩沖沒變化的 pane——空閑機(jī)器零 IO忙碌的 pane 反而得到最新拷貝只存 256 KiBSNAPSHOT_CAP遠(yuǎn)小于 8 MiB 的內(nèi)存環(huán)。滾動(dòng)內(nèi)容的價(jià)值隨距離屏幕底部的距離陡降最后幾屏就夠用了從頭部裁剪trim_to終端輸出只能向前解釋尾部獨(dú)立成立、頭部不行所以超限時(shí)永遠(yuǎn)吃掉最老的部分原子寫 嚴(yán)格權(quán)限快照先寫入臨時(shí)文件再rename就位讀者永遠(yuǎn)不會(huì)看到寫一半的文件文件從創(chuàng)建起就是0600權(quán)限write_private——因?yàn)樗赡馨阍?pane 里 echo 過的 token、env輸出和 agent 對(duì)話記錄絕不能讓其他用戶讀走。文件格式以魔術(shù)數(shù)TTY7SB\x01\x00開頭MAGIC每段記錄寫入時(shí)的窗口幾何信息尾部可攜帶 pane 標(biāo)題。解碼是全有或全無截?cái)辔募?、外部文件一律拒絕讀取此時(shí) pane 回落到空白屏——這正是模塊出現(xiàn)之前的行為沒有任何損失?？煺沾娣旁谂渲媚夸浀膕crollback/{pane_id}.bin通常在~/.config/tty7/scrollback/。恢復(fù)流程RestoreFrom 請(qǐng)求與消費(fèi)一次語義守護(hù)進(jìn)程崩潰后重新啟動(dòng)它本身不記得任何 pane——但磁盤快照記得?；謴?fù)由客戶端發(fā)起打開一個(gè)頂替已死 pane的新 pane 時(shí)spawn 請(qǐng)求里攜帶一個(gè)RestoreFrom結(jié)構(gòu)protocol.rspub struct RestoreFrom { pub pane_id: u64, // 頂替哪個(gè)死去的 pane pub banner: OptionString, // 畫在舊屏幕與新 shell 之間的一行說明 }守護(hù)進(jìn)程隨后執(zhí)行 restored_screen讀取該 pane 的最后快照 → 丟棄文件forget→ 把字節(jié)流種進(jìn)新 pane 的播放環(huán)。于是窗口顯示出的就是崩潰前屏幕上那些輸出滾動(dòng)進(jìn) scrollback 一行橫幅說明 一個(gè)明顯是新的 shell。兩個(gè)細(xì)節(jié)很有講究橫幅文案來自客戶端而非守護(hù)進(jìn)程因?yàn)槭刈o(hù)進(jìn)程沒有 locale——它同時(shí)服務(wù)任意語言的 GUI 和永遠(yuǎn)說英文的 CLI快照只消費(fèi)一次?；謴?fù)過一次、pane 又被關(guān)閉、再重新打開時(shí)就沒有東西可恢復(fù)了。這是刻意設(shè)計(jì)按相關(guān)性保留而非按時(shí)間保留無人再會(huì)請(qǐng)求恢復(fù)的快照會(huì)由 sweep 定期清掃避免終端輸出無限期留在磁盤上。反過來可預(yù)見的退出會(huì)寫得更精確store_scrollback_now 在收到正常關(guān)閉通知時(shí)把每個(gè) pane 的屏幕最后一寫此時(shí)拷貝是精確的而非最多滯后 30 秒。而用戶主動(dòng)關(guān)閉的 pane 走 kill_pane快照直接刪除——你親手關(guān)掉的終端不值得留尸。崩潰之外的死亡execve 原地?fù)Q芯與 Windows 的例外快照解決不了進(jìn)程還活著但二進(jìn)制要換的場景——升級(jí)。pty master 是本進(jìn)程持有的文件描述符進(jìn)程一換、描述符一關(guān)slave 端就收到SIGHUPpane 里的一切陪葬。tty7 的解法在 handoff.rs利用 Unix 的execve替換鏡像而保留進(jìn)程——同一個(gè) pid、同一批子進(jìn)程、同一批沒有FD_CLOEXEC的打開描述符。于是 pty 保持打開shell 完全感知不到換芯只有描述符另一端的代碼變了。交接清單Manifest記錄每個(gè) pane 的 master fd、子進(jìn)程 pid、工作目錄、OSC 標(biāo)題、agent 狀態(tài)以及環(huán)形緩沖的完整長度所有需要跨execve存活的描述符先解除 close-on-exec失敗則整體回滾舊守護(hù)進(jìn)程繼續(xù)服務(wù)。三樣?xùn)|西過不去設(shè)計(jì)上也坦然處理過不去的東西處理方式原生 SSH pane加密狀態(tài)在本進(jìn)程內(nèi)存里exec 前主動(dòng)掛斷遠(yuǎn)端看到的是干凈斷開客戶端連接窗口持有的 socket 隨舊鏡像死亡客戶端按原有路徑重連、按 pane id 重掛Windows沒有execveConPTY 句柄也無法跨進(jìn)程移交——守護(hù)進(jìn)程照常停啟靠 scrollback 快照兜底升級(jí)時(shí)shells survive the update的行為平臺(tái)差異說明見 docs/reference/updates.mdx。什么能活過什么一圖看懂恢復(fù)矩陣官方文檔 docs/getting-started/concepts.mdx 用一張矩陣總結(jié)了 tty7 的持久性承諾關(guān)閉標(biāo)簽頁退出 tty7停止服務(wù)器重啟機(jī)器shell 繼續(xù)運(yùn)行????布局恢復(fù)????屏幕內(nèi)容恢復(fù)????一次截?cái)辔膊渴苤С值?agent 會(huì)話恢復(fù)????注意停止服務(wù)器那一列重啟服務(wù)器會(huì)結(jié)束該機(jī)器上所有pane 里的進(jìn)程布局保留、屏幕靠快照恢復(fù)。這也是官方反復(fù)提醒別替別人順手重啟服務(wù)器的原因。排障視角下Panes came back empty256 KiB 尾部、消費(fèi)一次的完整解釋在 docs/reference/troubleshooting.mdx。值得借鑒的三個(gè)設(shè)計(jì)取舍新鮮度與寫放大的平衡30 秒周期 只寫變化的 pane把崩潰前最后幾秒的損失換成了幾乎為零的常態(tài) IO按相關(guān)性保留快照的存留條件是還有哪個(gè)工作空間會(huì)請(qǐng)求它而不是它寫了多久隱私面磁盤上的終端輸出被壓到最小優(yōu)雅退出的降級(jí)路徑清晰handoff 覆蓋升級(jí)、快照覆蓋崩潰與重啟、Windows 無 execve 時(shí)快照就是唯一防線——每一層都知道自己的邊界。核心源碼索引磁盤快照格式與存儲(chǔ)crates/tty7-core/src/daemon/scrollback.rs快照寫入線程與恢復(fù)請(qǐng)求處理crates/tty7-core/src/daemon/server.rs內(nèi)存回放環(huán)與 8 MiB 上限crates/tty7-core/src/daemon/pane.rsexecve 原地升級(jí)crates/tty7-core/src/daemon/handoff.rs持久性矩陣文檔docs/getting-started/concepts.mdx所以為什么崩潰后屏幕還能回來的答案可以濃縮成一句話窗口死得起是因?yàn)?pane 從來不歸窗口管屏幕回得來是因?yàn)槭刈o(hù)進(jìn)程在死之前把每塊屏幕的最后幾屏悄悄寫進(jìn)了只有你自己能讀的文件里。贊分享【免費(fèi)下載鏈接】tty7The terminal that outlives its window. Shells survive quitting the app, agents can drive other agents, and remote machines work the same way. Pure Rust, GPU-rendered.項(xiàng)目地址https://gitcode.com/gh_mirrors/tty/tty7點(diǎn)擊查看免費(fèi)下載相關(guān)推薦Upterm錯(cuò)誤恢復(fù)機(jī)制進(jìn)程崩潰與會(huì)話重建策略Upterm錯(cuò)誤恢復(fù)機(jī)制進(jìn)程崩潰與會(huì)話重建策略 你是否經(jīng)歷過終端進(jìn)程意外崩潰導(dǎo)致工作成果丟失的情況在服務(wù)器管理、長時(shí)間腳本運(yùn)行或復(fù)雜命令執(zhí)行過程中會(huì)話中斷開發(fā)工具桌面應(yīng)用Nativefier崩潰恢復(fù)機(jī)制自動(dòng)保存與會(huì)話恢復(fù)Nativefier崩潰恢復(fù)機(jī)制自動(dòng)保存與會(huì)話恢復(fù) 你是否曾遇到過這樣的情況正在使用Nativefier將網(wǎng)頁轉(zhuǎn)換為桌面應(yīng)用時(shí)突然程序崩潰所有設(shè)置和登錄CLI桌面應(yīng)用開發(fā)工具Captura崩潰恢復(fù)機(jī)制自動(dòng)保存與會(huì)話恢復(fù)設(shè)計(jì)Captura崩潰恢復(fù)機(jī)制自動(dòng)保存與會(huì)話恢復(fù)設(shè)計(jì) 引言錄屏工作者的噩夢與解決方案 你是否經(jīng)歷過這樣的場景花費(fèi)數(shù)小時(shí)錄制教程或直播內(nèi)容突然軟件崩潰所有未桌面應(yīng)用屏幕錄制音視頻創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考