Return to Answer

added 1 character in body

Source Link

edited Jul 18, 2023 at 12:50

BoppreH

1.1k
8
9

Software updates

The environment is highly dynamic and is constantly evolving:

The schema of the data ingested.
Parameters (e.g., channel frequencies).
The communication protocol used to exchange messages.
Newer versions of their tools.
Bug fixes.
Security updates (vulnerability fixes, new certificates, virus signatures).
The way the OS notifies processes of startup/shutdown.

There's always a new version of something available.

Most of that is changed in backwards-compatible ways. Processes don't have to update right away, and everyone will understand them if they speak with a protocol that is a few versions out of date.

But every missed update takes a toll on the performance, available features, and potential compatibility issues.

The updates themselves are "complex data", and they can be optimized for the type of complex inputs the process workworks on.

Starving processes

A process that rarely updates will find that communication gets less efficient, bugs start popping up, and attacks become a real danger.

Eventually features stop working altogether: the OS notifications don't make sense anymore; other processes ignore its messages because they are signed by an old certificate authority; the input data it receives is missing important fields, and has new ones it doesn't understand.

If this goes on for too long, the steps the OS takes to start/stop processes won't work anymore with such an old interface, and the process is never activated again.

Fat processes

On the other hand, a process can spend too many resources on updates.

Continuously monitoring the repositories for new versions, downloading schemas for inputs it's unlikely to ever receive, hoarding tools. The process becomes slow and bloated.

And sometimes the new versions have bugs. By living on the bleeding edge, the process risks ingesting changes that break functions (i.e., food poisoning).

From fast food to gourmet courses

And there are loads of ways to import updates.

Fast food: updates can come as pre-packaged binaries. You throw away the old version, and replace with the new one. Quick and easy, but wasteful and not as "nutritious" (optimized).
Restaurant: a busy process can download only "deltas", that is, the difference between the current binaries and the new. Still easy and less wasteful, but takes a bit longer to coordinate.
Home-cooked meals: processes can also download only the sources, and build the new binaries themselves. By cross-referencing the functions with the data it expects to process, it can make the new version perform exactly as needed. Very slow, but infinitely customizable.
Gourmet courses: building from source is hard, and customizing flags and features is an art in and of itself. Why not delegate the task to other processes?

Because the updates are constant and affect the function of the processes themselves, it's less "reading the news" and more "eating food". You can also restrict what gets updated, by making it very broad (all the examples above) or very narrow (only data schema updates).

Software updates

The environment is highly dynamic and is constantly evolving:

The schema of the data ingested.
Parameters (e.g., channel frequencies).
The communication protocol used to exchange messages.
Newer versions of their tools.
Bug fixes.
Security updates (vulnerability fixes, new certificates, virus signatures).
The way the OS notifies processes of startup/shutdown.

There's always a new version of something available.

Most of that is changed in backwards-compatible ways. Processes don't have to update right away, and everyone will understand them if they speak with a protocol that is a few versions out of date.

But every missed update takes a toll on the performance, available features, and potential compatibility issues.

The updates themselves are "complex data", and they can be optimized for the type of complex inputs the process work on.

Starving processes

A process that rarely updates will find that communication gets less efficient, bugs start popping up, and attacks become a real danger.

If this goes on for too long, the steps the OS takes to start/stop processes won't work anymore with such an old interface, and the process is never activated again.

Fat processes

On the other hand, a process can spend too many resources on updates.

Continuously monitoring the repositories for new versions, downloading schemas for inputs it's unlikely to ever receive, hoarding tools. The process becomes slow and bloated.

And sometimes the new versions have bugs. By living on the bleeding edge, the process risks ingesting changes that break functions (i.e., food poisoning).

From fast food to gourmet courses

And there are loads of ways to import updates.

Fast food: updates can come as pre-packaged binaries. You throw away the old version, and replace with the new one. Quick and easy, but wasteful and not as "nutritious" (optimized).
Restaurant: a busy process can download only "deltas", that is, the difference between the current binaries and the new. Still easy and less wasteful, but takes a bit longer to coordinate.
Home-cooked meals: processes can also download only the sources, and build the new binaries themselves. By cross-referencing the functions with the data it expects to process, it can make the new version perform exactly as needed. Very slow, but infinitely customizable.
Gourmet courses: building from source is hard, and customizing flags and features is an art in and of itself. Why not delegate the task to other processes?

Software updates

The environment is highly dynamic and is constantly evolving:

The schema of the data ingested.
Parameters (e.g., channel frequencies).
The communication protocol used to exchange messages.
Newer versions of their tools.
Bug fixes.
Security updates (vulnerability fixes, new certificates, virus signatures).
The way the OS notifies processes of startup/shutdown.

There's always a new version of something available.

Most of that is changed in backwards-compatible ways. Processes don't have to update right away, and everyone will understand them if they speak with a protocol that is a few versions out of date.

But every missed update takes a toll on the performance, available features, and potential compatibility issues.

The updates themselves are "complex data", and they can be optimized for the type of complex inputs the process works on.

Starving processes

A process that rarely updates will find that communication gets less efficient, bugs start popping up, and attacks become a real danger.

If this goes on for too long, the steps the OS takes to start/stop processes won't work anymore with such an old interface, and the process is never activated again.

Fat processes

On the other hand, a process can spend too many resources on updates.

Continuously monitoring the repositories for new versions, downloading schemas for inputs it's unlikely to ever receive, hoarding tools. The process becomes slow and bloated.

And sometimes the new versions have bugs. By living on the bleeding edge, the process risks ingesting changes that break functions (i.e., food poisoning).

From fast food to gourmet courses

And there are loads of ways to import updates.

Fast food: updates can come as pre-packaged binaries. You throw away the old version, and replace with the new one. Quick and easy, but wasteful and not as "nutritious" (optimized).
Restaurant: a busy process can download only "deltas", that is, the difference between the current binaries and the new. Still easy and less wasteful, but takes a bit longer to coordinate.
Home-cooked meals: processes can also download only the sources, and build the new binaries themselves. By cross-referencing the functions with the data it expects to process, it can make the new version perform exactly as needed. Very slow, but infinitely customizable.
Gourmet courses: building from source is hard, and customizing flags and features is an art in and of itself. Why not delegate the task to other processes?

Source Link

created Jul 18, 2023 at 11:53

BoppreH

1.1k
8
9

Software updates

The environment is highly dynamic and is constantly evolving:

The schema of the data ingested.
Parameters (e.g., channel frequencies).
The communication protocol used to exchange messages.
Newer versions of their tools.
Bug fixes.
Security updates (vulnerability fixes, new certificates, virus signatures).
The way the OS notifies processes of startup/shutdown.

There's always a new version of something available.

Most of that is changed in backwards-compatible ways. Processes don't have to update right away, and everyone will understand them if they speak with a protocol that is a few versions out of date.

But every missed update takes a toll on the performance, available features, and potential compatibility issues.

The updates themselves are "complex data", and they can be optimized for the type of complex inputs the process work on.

Starving processes

A process that rarely updates will find that communication gets less efficient, bugs start popping up, and attacks become a real danger.

If this goes on for too long, the steps the OS takes to start/stop processes won't work anymore with such an old interface, and the process is never activated again.

Fat processes

On the other hand, a process can spend too many resources on updates.

Continuously monitoring the repositories for new versions, downloading schemas for inputs it's unlikely to ever receive, hoarding tools. The process becomes slow and bloated.

And sometimes the new versions have bugs. By living on the bleeding edge, the process risks ingesting changes that break functions (i.e., food poisoning).

From fast food to gourmet courses

And there are loads of ways to import updates.

Fast food: updates can come as pre-packaged binaries. You throw away the old version, and replace with the new one. Quick and easy, but wasteful and not as "nutritious" (optimized).
Restaurant: a busy process can download only "deltas", that is, the difference between the current binaries and the new. Still easy and less wasteful, but takes a bit longer to coordinate.
Home-cooked meals: processes can also download only the sources, and build the new binaries themselves. By cross-referencing the functions with the data it expects to process, it can make the new version perform exactly as needed. Very slow, but infinitely customizable.
Gourmet courses: building from source is hard, and customizing flags and features is an art in and of itself. Why not delegate the task to other processes?