為什麼不能實時修補整個核心？
在過去的幾年中，各種實時核心修補技術在系統管理員中變得流行，他們努力確保系統的最長正常執行時間。
為了使該過程成為可能，人們準備定制更新檔，然後通常將其分發給付費客戶，有時還免費分發給家庭使用者。
為什麼不能使用正在執行的核心版本的原始碼和最新可用的原始碼之間的差異自動創建這些更新檔？據我了解，可以從中獲利最多的伺服器核心通常每隔幾年才會進行一次重大更改，否則只會收到重大的錯誤修復和安全更新，這似乎使這變得更加容易。同樣，如果關注的是穩定性，那麼設置一個系統似乎很簡單，在該系統中，執行重要性相對較低的機器的志願者將首先建構他們的更新檔，並自動報告它們的工作情況。
然而，這一切都沒有發生。我在那裡缺少什麼使情況如此？
我們喜歡將執行程序想像成創建它們的靜態原始碼。但它們確實在不斷變化。同樣，記憶體中的核心與磁碟上的核心不同。
在他的信中引用 Dijkstra 的話“ goto 被認為是有害的”……
我的第一點是，雖然程序員的活動在他建構了一個正確的程序時就結束了，但在他的程序控制下發生的過程才是他活動的真正主題，因為正是這個過程必須達到預期的效果；正是這個過程在其動態行為中必須滿足所需的規範。然而，一旦製作了程序，相應過程的“製作”就會委託給機器。
我的第二個評論是，我們的智力相當適合掌握靜態關係，而我們視覺化隨時間演變的過程的能力相對較差。出於這個原因，我們應該（作為聰明的程序員意識到我們的局限性）盡最大努力縮短靜態程序和動態過程之間的概念差距，使程序（在文本空間中展開）和過程（展開及時）盡可能微不足道
由此我推斷，在記憶體中擁有一個不是從磁碟載入核心的結果的程序或核心是一個壞主意。如果沒有其他資訊，您可以重新啟動並最終使用與您現在執行的核心相同的核心。
作為一個系統管理員，你想知道你最終得到了一個真正的正常核心，而不是一些科學怪人的怪物，因為你的實時核心與他們修補的核心有細微的差別。
實時修補確實非常困難。自動生成實時更新檔在技術上是不可能的
重要的是要理解程式碼會有效地自我重寫。
int X = 10; void run(){ X=5; }在此程式碼範例
X=10中，永遠不會作為程式碼執行。該編號10由編譯器放置在位置“X”中。在執行時執行第 3 行時，它將替換位置“X”處的值。它從字面上覆蓋了該值，這意味著該數字10完全從正在執行的程式碼中消失了。現在我們嘗試使用以下方法進行實時修補：
int X = 20; void run(){ X=15; }X 應該修補到 20 還是 15？我們應該完全修補它還是留下它？我們不只是在這裡更改程式碼，我們正在更改動態生成的值。您可能會認為，因為它們是動態生成的，您可能不需要更改它們，但如果我們不更改它們，我們是否知道 5 或 10 在新程式碼中仍然是有效值？這不能自動完成！
簡而言之，有一些技術與相關工具可以創建實時更新檔，但使用它們並測試結果需要專家。發布這些工具並期望家庭使用者了解如何使用它們是許多家庭使用者搞砸系統的好方法。