On 01/06/2017 07:33 AM, Jonathan Wakely wrote: > On 05/01/17 14:42 -0500, Randy Barlow wrote: >> On Thu, 2017-01-05 at 17:02 +0000, Jonathan Wakely wrote: >>> Which definitely changes how software is built. >> >> Containers also change the way software must be written in some cases, >> since they expect there to be one main process and don't expect that >> main process to interact with other "main" processes on the system. >> There are some program architectures that aren't well suited to be run >> in containers since containers expect programs to work in specific >> ways. I don't think they are general enough to cover all use cases. >> >> I also expect that users will not appreciate being forced to use >> containers if they want to keep being able to do things they can do >> today. Offering it to them as an option rather than the only solution >> is probably a friendlier approach. > > > That would certainly be a problem if the proposal was to run each > 32-bit application in its own container environment, but I think the > suggestion is to have a single 32-bit container used by all 32-bit > software. With that approach all the 32-bit software would be able to > interact with the rest of the 32-bit system, there wouldn't be > segregation between them. > Yes, I was unclear about this, but that was where I was going with it. A single 32-bit container whose purpose was to share the 32-bit runtime. That being said, the counter-proposal of figuring out how to keep the layout the same as today but keeping the content in separate repositories is compelling and I'm investigating that further. > But we would need to consider how a 32-bit application starts other > programs via things like xdg-open. Would you have to have a 32-bit > browser installed so that you could click on links in 32-bit > applications? Would xdg-utils have to be installed on the system > twice, once in the 64-bit host and once in the 32-bit container? And > install things like Firefox and image viewers twice? Very good questions and I don't have all the answers right now, but again, I think the "separate repository" solution might be closer, as the end result should keep things in the same hierarchy.
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
