If we had not systemd and had kept it simple stupid, there would be no need for snap:
- you compile the application in static (à la windows)
- and you do a chroot (or as they call it a namespace).
Ksss, I am wrong, I see it.
But then, when you make a multi-tiers architecture, how do you make stuff communicate? Well, easy, web services.
But how do you know where they are? How do you print? How do you register PlayMediaKey as a way to start your application? How do you make sure the «right application» can set the time (ntp/system preferences) while other applications are kept away?
Guh ....
registry base?
Autodiscovery?
You need a bus?
An IPC?
And what of the mess of Xorg? How do I prevent applications to see or intercept informations they should not see?
Most engineers have troubles with a basic group/permission model already and OSX/AD have proven that a more complex schema based on a complex namespace often in practice results to poorer results.... how do we make access secured?
Oh! you still have the "one application in foreground has all rights"... the kind of tablet model à la iOS. But then, we are losing the advantage of multitasking... like listening to music while writing or playing games.
So back again in square one of being confined BUT able to cooperate.
JAVA and its JVM was a way to answer this problem: let's forget all of this and control at the application layer of the JVM.
But then, how do you talk to hardware?
java or not, application needs to know about the hardware, but we have no fixed address for HW devices (minor/major nodes are long gone, and PCI/USB vendor id are not pointing to a single HW target since long)
So maybe we could have a virtual HW that talks to the real HW with a translation in the middle ?
(VMware, Xen...)
Ho! But I want to make sure I develop for a single target!
Well, good luck unifying games dev in a single image while making sure the screensaver don't override it, while not preventing security applications to do emergency locks... and still having the right level of acceleration...
And then, the world of confinment is biting his tails always asking itself the same questions.
For the old persons, let's just accept that easy image deployment could be like on Amiga/C64/amstrad &al: a unique HW, with a single application. You jump to org and execute the ASM in single mode. Problem solved.
But the more we expect from easy to code with cooperation (wouldn't it be ridiculous to put printer/HD/SD driver in a text application, network/audio/video driver in a browser) the more our apps are dependent from an ecosystem that is a moving target.
Basically there can be no easy confinement (application snapshot) without a unified abstraction of HW and services as well of their properties whereas the complexity of OS is growing (more HW, more protocols, more "required dependencies" à la systemd).
Basically confined image deployment on heterogeneous system/HW is a chimera unless you confine yourself to very basic tasks that requires no dependencies (like mono post calculus in FORTRAN using stdin/stdout).
We are just in the hell of the dependencies. And I don't think there is any silver bullet for this situation. This problem grows more than linearly in complexity as a cross product of all the potential differences in the configuration space.
Let's forget about chimeras.
The complexity is dooming the costs model of application development. As the HW/OS landscape is splitting in different direction with legacy systems still needing updates, development has to face the world of a constant progress/obsolescence where devs are told to forget about past platforms to be hype, and customers have the need to keep their legacy systems in production.
Guh.
If we had not systemd and had kept it simple stupid, there would be no need for snap: - you compile the application in static (à la windows) - and you do a chroot (or as they call it a namespace).
Ksss, I am wrong, I see it.
But then, when you make a multi-tiers architecture, how do you make stuff communicate? Well, easy, web services.
But how do you know where they are? How do you print? How do you register PlayMediaKey as a way to start your application? How do you make sure the «right application» can set the time (ntp/system preferences) while other applications are kept away?
Guh ....
registry base? Autodiscovery? You need a bus? An IPC?
And what of the mess of Xorg? How do I prevent applications to see or intercept informations they should not see?
Most engineers have troubles with a basic group/permission model already and OSX/AD have proven that a more complex schema based on a complex namespace often in practice results to poorer results.... how do we make access secured?
Oh! you still have the "one application in foreground has all rights"... the kind of tablet model à la iOS. But then, we are losing the advantage of multitasking... like listening to music while writing or playing games.
So back again in square one of being confined BUT able to cooperate.
JAVA and its JVM was a way to answer this problem: let's forget all of this and control at the application layer of the JVM.
But then, how do you talk to hardware?
java or not, application needs to know about the hardware, but we have no fixed address for HW devices (minor/major nodes are long gone, and PCI/USB vendor id are not pointing to a single HW target since long)
So maybe we could have a virtual HW that talks to the real HW with a translation in the middle ? (VMware, Xen...)
Ho! But I want to make sure I develop for a single target!
Well, good luck unifying games dev in a single image while making sure the screensaver don't override it, while not preventing security applications to do emergency locks... and still having the right level of acceleration...
And then, the world of confinment is biting his tails always asking itself the same questions.
For the old persons, let's just accept that easy image deployment could be like on Amiga/C64/amstrad &al: a unique HW, with a single application. You jump to org and execute the ASM in single mode. Problem solved.
But the more we expect from easy to code with cooperation (wouldn't it be ridiculous to put printer/HD/SD driver in a text application, network/audio/video driver in a browser) the more our apps are dependent from an ecosystem that is a moving target.
Basically there can be no easy confinement (application snapshot) without a unified abstraction of HW and services as well of their properties whereas the complexity of OS is growing (more HW, more protocols, more "required dependencies" à la systemd).
Basically confined image deployment on heterogeneous system/HW is a chimera unless you confine yourself to very basic tasks that requires no dependencies (like mono post calculus in FORTRAN using stdin/stdout).
We are just in the hell of the dependencies. And I don't think there is any silver bullet for this situation. This problem grows more than linearly in complexity as a cross product of all the potential differences in the configuration space.
Let's forget about chimeras.
The complexity is dooming the costs model of application development. As the HW/OS landscape is splitting in different direction with legacy systems still needing updates, development has to face the world of a constant progress/obsolescence where devs are told to forget about past platforms to be hype, and customers have the need to keep their legacy systems in production.
Sometimes there is no solutions to a problem.