mesos probably is the beginning of that. but we'll see more and more very soon.
On Fri, Jun 13, 2014 at 8:47 PM, Andrew <mu...@mimisbrunnr.net> wrote: > Saying that docker (of all things) will produce impedance mismatches > between different components and ruin composition seems a little > premature and unfounded. > > There is some evidence for your theory at the application layer. > Consider building an application out of libraries using strong/static vs > dynamic types. If your application is using dynamic types and you have > no static type checking, you will probably have a harder time composing > modules because there is no contract in the language about the > parameters the modules consume and the values they produce. Any checking > you do will have to be with "unit tests" and be run time. > > If you use strong and static typing, as you try and compose your program > with libraries, and libraries with libraries, when the program is > compiled these "impedance mismatches" will reveal themselves as type > errors, if the mismatches are representable at the type level. Today > this would catch problems like "it returns a string when it should > return an int" and so on, but session types and possibly concurrency > types could tell you things about processing data in the wrong order, > for example. > > It seems that lacking strong and static typing when composing whole > systems together is not really Docker's problem but would be a symptom > of an engineering organization making heavy use of Docker? Frameworks to > do this kind of large-scale composition are kind of rare, the ones I can > think of are like Fabric[1] or perhaps an SDN language like Frenetic[2]. > I don't really think we have statically typed deployment languages ready > for use though. > > Do you envision checking like this being important in the future? Do you > think that we see problems today because we don't use it generally? > > 1: http://www.cs.cornell.edu/projects/fabric/ > 2: http://frenetic-lang.org/publications/overview-ieeecoms13.pdf > > On 06/14/2014 01:37 AM, d...@geer.org wrote: > > > > | On 10.06.2014 23:48, d...@geer.org wrote: > > | > > > | > Of possible interest. > > | > > > | > > | Hi, > > | > > | I fail to see where docker fits within langsec? > > | > > | Could you please explain this a bit? > > > > > > I just thought it was interesting to have yet another "write once, > > run anywhere" utopia showing up when as far as I can tell such > > utopias are guaranteed to exhibit the very problems that the LANGSEC > > mindset so aptly warns about. Quoting Docker's come-on, > > > > Docker is an open platform for developers and sysadmins to build, > > ship, and run distributed applications. Consisting of Docker > > Engine, a portable, lightweight runtime and packaging tool, and > > Docker Hub, a cloud service for sharing applications and automating > > workflows, Docker enables apps to be quickly assembled from > > components and eliminates the friction between development, QA, > > and production environments. As a result, IT can ship faster and > > run the same app, unchanged, on laptops, data center VMs, and > > any cloud. > > > > Doesn't that have to produce impedance mismatches between components > > that have been assembled with this new kind of glue (Component A > > expects sanitized input but it is getting something else from > > Component B)? In any case, the idea that the operating system has > > been abstracted away to the point of irrelevance just rubs me the > > wrong way -- me and David Wheeler: > > > > All problems in computer science can be solved by another level of > > indirection... Except for the problem of too many layers of > > indirection. > > > > In the meantime, the group of Clark, Smith, Blaze, and others at > > Penn have convinced me that application code reuse is a net negative > > for cyber security; that's a little orthogonal, but not entirely. > > > > YMMV, > > > > --dan > > > > _______________________________________________ > > langsec-discuss mailing list > > langsec-discuss@mail.langsec.org > > https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss > > > _______________________________________________ > langsec-discuss mailing list > langsec-discuss@mail.langsec.org > https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss >
_______________________________________________ langsec-discuss mailing list langsec-discuss@mail.langsec.org https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
