Probably the thing that concerns me the most here: If it is as described... turning it off and then back on again probably won't fix whatever it's doing wrong. :/
I'm very curious what troubleshooting a system like this would look like.
It really depends on how much control on the life cycle of state exists between the user, program and operating system. More to the user, easier to press reset and clear the state. More to the OS then it needs to have some clear guidelines about how to deal with bad behaving programs. If its all up to the programs then it will probably be very brittle since applications may not implement what's needed to clear state when necessary. Although if a program crashes you'd expect that the OS would clear its state.. which I assume is the case.
A button that resets an individual application’s state?
I mean this is already an issue today where people “reboot” their system which really just sleeps/wakes it and are surprised that their problems aren’t fixed.
I think it would be a good thing for UX if an OS made this explicit and had a correct “factory reset” behavior for individual apps. It would make troubleshooting a breeze.
It does kinda suck because under this model to ensure correctness apps either can’t share any state between them or the entire forest has to be reset together.
Most likely what happens when Windows can't restore state from sleep/suspend and you have to delete the state file and do a normal boot. Though hopefully with fine grain control over what you can nuke.
hopefully with fine grain control over what you can nuke.
And therein lies one of the many challenges of a system like this. It's fine as an experiment - but turning it into something usable for any serious purpose is unlikely to happen.
There are much more reliable and usable ways to implement automatically persistent systems. The way databases use transaction logs is an example.
- OO DB, like key/val storage, but with stored procedures. It's Phantom.
- Smart home UI, SCADA front - lots of METAdata about widgets, windows, screens, etc - but getting all the actual data from network. It's Phantom.
- Robotics. How long your self-driving car takes to reboot, fsck and restart all applications when it drives 100 mph?
- Medic equipment. Please do not die for five minutes, we need to reload application.
There are places that in any case need very clever and special software, would gain of fast same-state restart and need complex but more or less static configuration.
Think of partial use of Phantom nature. Be it usual Unix app, but with ability to have access to pre-built complex object structure to use.
One example: if you have 200 fonts on your PC, starting any appl that uses fonts is "wait half an hour till I rescan all these fonts for you".
Let Phantom personality to prepare persistent font data structures and Unix personality to use them.
It is really interesting even to start thinking in persistent manner. There are new worlds behind, forgive me being pathos man a bit. :)
A system like Phantom is not the best solution to any of those problems. They've already been solved in much better ways. If Phantom were developed to the point of commercial usability, it would have to reinvent the techniques that those systems use.
It's funny how all of your specific examples are already solved, many years ago.
- "fsck" is not longer required with journalling filesystems.
- For faster boot, there is "ureadahead" which requests the block from the disk in the right order -- so time to start up the system with 1GB of memory used is roughly the same as read that 1GB from the disk drive.
- For "200 fonts", there is "fc-cache" tool which keeps the font cache -- and you only run it when a new font is installed.
The robust way is to abstract control logic from the UI logic entirely. So a dedicated processor(s) running bare metal code or an RTOS with a link to a fancier HMI. The HMI can have all the ugly crash happy UI code heaped on top to display data or send changes. If the HMI crashes the controller won't notice or care. There should never be a dependency on the HMI.
Comments
Probably the thing that concerns me the most here: If it is as described... turning it off and then back on again probably won't fix whatever it's doing wrong. :/
I'm very curious what troubleshooting a system like this would look like.
It really depends on how much control on the life cycle of state exists between the user, program and operating system. More to the user, easier to press reset and clear the state. More to the OS then it needs to have some clear guidelines about how to deal with bad behaving programs. If its all up to the programs then it will probably be very brittle since applications may not implement what's needed to clear state when necessary. Although if a program crashes you'd expect that the OS would clear its state.. which I assume is the case.
A button that resets an individual application’s state?
I mean this is already an issue today where people “reboot” their system which really just sleeps/wakes it and are surprised that their problems aren’t fixed.
I think it would be a good thing for UX if an OS made this explicit and had a correct “factory reset” behavior for individual apps. It would make troubleshooting a breeze.
It does kinda suck because under this model to ensure correctness apps either can’t share any state between them or the entire forest has to be reset together.
Yes. But, really, turning off and on fixes not quite everything. I've seen Word files that can't be open and crash Word completely.
Application state can be unrecoverably wrong with any kind of storage, be it files or persistent object tree.
But only files offer fully automated backups which do not need any sort of support from application at all.
Most likely what happens when Windows can't restore state from sleep/suspend and you have to delete the state file and do a normal boot. Though hopefully with fine grain control over what you can nuke.
And therein lies one of the many challenges of a system like this. It's fine as an experiment - but turning it into something usable for any serious purpose is unlikely to happen.
There are much more reliable and usable ways to implement automatically persistent systems. The way databases use transaction logs is an example.
It depends.
Think of:
- OO DB, like key/val storage, but with stored procedures. It's Phantom.
- Smart home UI, SCADA front - lots of METAdata about widgets, windows, screens, etc - but getting all the actual data from network. It's Phantom.
- Robotics. How long your self-driving car takes to reboot, fsck and restart all applications when it drives 100 mph?
- Medic equipment. Please do not die for five minutes, we need to reload application.
There are places that in any case need very clever and special software, would gain of fast same-state restart and need complex but more or less static configuration.
Think of partial use of Phantom nature. Be it usual Unix app, but with ability to have access to pre-built complex object structure to use.
One example: if you have 200 fonts on your PC, starting any appl that uses fonts is "wait half an hour till I rescan all these fonts for you".
Let Phantom personality to prepare persistent font data structures and Unix personality to use them.
It is really interesting even to start thinking in persistent manner. There are new worlds behind, forgive me being pathos man a bit. :)
A system like Phantom is not the best solution to any of those problems. They've already been solved in much better ways. If Phantom were developed to the point of commercial usability, it would have to reinvent the techniques that those systems use.
It's funny how all of your specific examples are already solved, many years ago.
- "fsck" is not longer required with journalling filesystems.
- For faster boot, there is "ureadahead" which requests the block from the disk in the right order -- so time to start up the system with 1GB of memory used is roughly the same as read that 1GB from the disk drive.
- For "200 fonts", there is "fc-cache" tool which keeps the font cache -- and you only run it when a new font is installed.
The robust way is to abstract control logic from the UI logic entirely. So a dedicated processor(s) running bare metal code or an RTOS with a link to a fancier HMI. The HMI can have all the ugly crash happy UI code heaped on top to display data or send changes. If the HMI crashes the controller won't notice or care. There should never be a dependency on the HMI.