3 ms·

> Imagine every process having its own "non-volatile" memory area, where all persistent state is kept between restarts... I'll treat this seriously: as softwar

> Imagine every process having its own "non-volatile" memory area, where all persistent state is kept between restarts... I'll treat this seriously: as software development practices are just now beginning to mature, with more emphasis on test coverage being considered best practice, sure ... maybe. But there's still a lot of software out there for which "restart the application" (or even, "restart the stinking OS") is the only practical solution when it's behaving badly. > Every entity in the system can be identified through unique IDs which can be handed down to other processes based on different OS policies. Okay, but how do you write a process which is capable of communicating with any other process?

bluetomcat 7y ago
> But there's still a lot of software out there for which "restart the application" (or even, "restart the stinking OS") is the only practical solution when it's behaving badly. Which, in principle, doesn't prevent a program from crashing or misbehaving when it encounters a corrupted file left over from its last run. In the imagined system, the application developer would be fully aware whether he is putting a data structure in the "volatile" or in the "non-volatile" memory areas, with some safety guarantees from the OS. Restarting would zero only the volatile area, enabling a clean starting state. > Okay, but how do you write a process which is capable of communicating with any other process? Why would you need to communicate with any process? Maybe I need to communicate with the currently running instance of "HTTP Server App" or "Database Engine App", not with an unrelated process my program knows nothing about.
- thaumaturgy 7y ago
  > Which, in principle, doesn't prevent a program from crashing or misbehaving when it encounters a corrupted file left over from its last run. Of course. But saving state to nvram also has this problem, plus the additional problem of saving broken program state. Like I say, I'm not totally pessimistic on this anymore: there are some promising trends that make me think we might get there in the not distant future. But we're not there yet. Maybe supporting some way for a user to manually reset broken program state would be a good enough compromise -- as long as application developers didn't do something dumb, like store their license information in their program state. Autodesk immediately comes to mind there. > Why would you need to communicate with any process? Because some other process wants to communicate with you. Composability and common interfaces and loose coupling is a huge advantage in Unix-like operating systems or any other software architecture that embraces those principles. They mean that you can write software with a much longer lifespan, and usually for less effort. In your example, someone may come along wanting to write "Firewall App" long after you've abandoned your software. If your software is extensible and supports standardized IPC, "Firewall App" is possible. If it doesn't, then it gets thrown out and replaced with something else.
- Khoth 7y ago
  > Why would you need to communicate with any process? Maybe I need to communicate with the currently running instance of "HTTP Server App" or "Database Engine App", not with an unrelated process my program knows nothing about. Today, I piped the output of some process I was running into grep. Neither of these programs knew about the existence of the other. Later, I used an image editor to create an image, then used a web browser to upload it to a website. The web browser and image editor were unaware of each other's existence.
  - bluetomcat 7y ago
    > Today, I piped the output of some process I was running into grep. Neither of these programs knew about the existence of the other. Only because "an unstructured stream of bytes" is the way for Unix processes to communicate. It allows for composability, but a very fragile and unsafe one, requiring programs to spit out and read free text, with all the crazy filtering and guesswork needed.
    - garmaine 7y ago
      You could pipe structures data. See: PowerShell.
    - jnurmine 7y ago
      Free text? You can just as well pipe structured binary data (such as audio or images) through one or more processing elements. The processors need to understand the data, of course. There are also other IPC mechanisms, like D-Bus.
AnIdiotOnTheNet 7y ago
Plan 9 did a pretty good job.

bluetomcat 7y ago

> But there's still a lot of software out there for which "restart the application" (or even, "restart the stinking OS") is the only practical solution when it's behaving badly. Which, in principle, doesn't prevent a program from crashing or misbehaving when it encounters a corrupted file left over from its last run. In the imagined system, the application developer would be fully aware whether he is putting a data structure in the "volatile" or in the "non-volatile" memory areas, with some safety guarantees from the OS. Restarting would zero only the volatile area, enabling a clean starting state. > Okay, but how do you write a process which is capable of communicating with any other process? Why would you need to communicate with any process? Maybe I need to communicate with the currently running instance of "HTTP Server App" or "Database Engine App", not with an unrelated process my program knows nothing about.

thaumaturgy 7y ago
> Which, in principle, doesn't prevent a program from crashing or misbehaving when it encounters a corrupted file left over from its last run. Of course. But saving state to nvram also has this problem, plus the additional problem of saving broken program state. Like I say, I'm not totally pessimistic on this anymore: there are some promising trends that make me think we might get there in the not distant future. But we're not there yet. Maybe supporting some way for a user to manually reset broken program state would be a good enough compromise -- as long as application developers didn't do something dumb, like store their license information in their program state. Autodesk immediately comes to mind there. > Why would you need to communicate with any process? Because some other process wants to communicate with you. Composability and common interfaces and loose coupling is a huge advantage in Unix-like operating systems or any other software architecture that embraces those principles. They mean that you can write software with a much longer lifespan, and usually for less effort. In your example, someone may come along wanting to write "Firewall App" long after you've abandoned your software. If your software is extensible and supports standardized IPC, "Firewall App" is possible. If it doesn't, then it gets thrown out and replaced with something else.
Khoth 7y ago
> Why would you need to communicate with any process? Maybe I need to communicate with the currently running instance of "HTTP Server App" or "Database Engine App", not with an unrelated process my program knows nothing about. Today, I piped the output of some process I was running into grep. Neither of these programs knew about the existence of the other. Later, I used an image editor to create an image, then used a web browser to upload it to a website. The web browser and image editor were unaware of each other's existence.
- bluetomcat 7y ago
  > Today, I piped the output of some process I was running into grep. Neither of these programs knew about the existence of the other. Only because "an unstructured stream of bytes" is the way for Unix processes to communicate. It allows for composability, but a very fragile and unsafe one, requiring programs to spit out and read free text, with all the crazy filtering and guesswork needed.
  - garmaine 7y ago
    You could pipe structures data. See: PowerShell.
  - jnurmine 7y ago
    Free text? You can just as well pipe structured binary data (such as audio or images) through one or more processing elements. The processors need to understand the data, of course. There are also other IPC mechanisms, like D-Bus.

AnIdiotOnTheNet 7y ago

Plan 9 did a pretty good job.