41–50 of 69 posts
I like the ideas in Phantom, even considering the negative comments, it is refreshing to see people having a go at OS design that isn't just blindly making yet another UNIX clone, because apparently we can't get enough of them.
[0] By which of course we mean Linux.
This kind of system will suffer from the ratchet problem. A single bug that negatively impacts state is no longer fixable by rebooting. Instead, you have to format/reinstall. Unintended state becomes permanent, and upgrade paths constrained to the point where you must do intentional damage. I'd also be leery of fragmentation. The project is falling into the "simplification trap", where all it's doing is moving inhere…
You could base such system on software transactional memory and persistent data structures (like in Clojure) and in case of a bug just revert the state to any particular point in time by changing one pointer. Your app crashed? No problem - Rewind 5 minutes earlier and don't do the thing that crashed it. There's whole unexplored universe of possibilities when we do away with traditional OS design. I'm especially inter…
“The software rebooted and reinitialized the computer, and then restarted selected programs at a point in their execution flow near where they had been when the restart occurred.” [0]
Not related to Phantom OS, but the OS running the Apollo 11 guidance computers had this same feature. In fact, the famous 1202 program alarms right before landing are related: a low priority task was overwhelming the system and the OS restarted to get a clean slate, continuing the high priority tasks where they left off: “The software rebooted and reinitialized the computer, and then restarted selected programs at a…
(more details on Apollo 11 problem: https://www.doneyles.com/LM/Tales.html)
I'm not sure this actually solves the real problem that people have. Sure, reboots are annoying and pretty much all current OSes could be improved in this regard. Back in the 90s, it's interesting that SunOS supported live kernel upgrades, so at the same time the kernel on disk was updated, the running system was also patched so it would act the same way as-if rebooted, but without any disruption to the live system.…
This kind of system will suffer from the ratchet problem. A single bug that negatively impacts state is no longer fixable by rebooting. Instead, you have to format/reinstall. Unintended state becomes permanent, and upgrade paths constrained to the point where you must do intentional damage. I'd also be leery of fragmentation. The project is falling into the "simplification trap", where all it's doing is moving inhere…
On rooted Android I could clear corrupted app data.
This kind of system will suffer from the ratchet problem. A single bug that negatively impacts state is no longer fixable by rebooting. Instead, you have to format/reinstall. Unintended state becomes permanent, and upgrade paths constrained to the point where you must do intentional damage. I'd also be leery of fragmentation. The project is falling into the "simplification trap", where all it's doing is moving inhere…
Rebooting does not fix any bugs, it just resets the state. I'm not sure this is really the better solution because many bugs never get fixed because "Have you tried turning it off and on, again?"
Yes, a lot of bugs are never going to be fixed, and we'll have to restart the machine occasionally... but Phantom's alternative is forcing machine reformat on any bug.
You can do this today: just add a crash handler that will erase your entire hard disk. Do you think this will make software less buggy?
Earlier quoted context omitted.
Couldn't there be a middle ground that allows you to restart/reset a single application?
The FAQ calls this out as a way to recover from a bad state. It seems to already be implemented in the OS.
So if your text processor crashes, your documents go bye-bye.