>thanks for your feedback. Building CryFS on Mac OS X is currently not >supported unfortunately. >Maybe I should've said that clearer from the beginning, I'm sorry this >got you so frustrated.
Thank you for the explanation. It confirms my assessment: - The idea and the filesystem architecture are interesting, well-suited for MS or better. - The implementation is fine to mark a checkbox in thesis defense (“yes it can work - here’s the proof”), but unsuitable for field deployment without significant efforts and possibly re-design. >Btw most users won't ever build CryFS themselves We differ here. But I guess, “the market” will decide. >- there are Debian >packages already, and in future there will also be RPM and (once >supported) Mac OS X installers. Sure, fine. >On 09.02.2016 05:43, Blumenthal, Uri - 0553 - MITLL wrote: >>>> OK, I got the code and took a brief look. First impression: it looks >>>> like an exercise in “how many different and complex packages I can tie >>>> together without crashing the whole thing”. Fragility of such approach >>>> are too numerous to list. ………… >>> When I started the project, I was trying out a new buildsystem called >>> biicode with a new approach to dependency management. >> Exactly what I meant. An experiment - “let’s try this... oh wow, look - >>it >> works!” Fine for a college lab, not so cool for the field. >> >> A codebase with a decent chance to become stable usually doesn't chase >>the >> newest shiny toys/tools. >> >> It is especially nice that your build system blindly overrides local >> edits. I.e., it is pointless to edit any of the CMakeLists.txt files in >> there, as it pulls the original ones from your Github regardless. What >>can >> I say? >> >> (You felt trying a new cryptographic filesystem was not exciting enough, >> had to throw new development tools in the mix?) >> >>> The stuff it >>> downloads is mostly other code modules from myself. >> As if those modules were too large to be a part of the same codebase… >> >>> Boost is downloaded in a certain version to ensure compatibility. >> Boost usually is good enough to ensure backwards compatibility on its >>own >> (as EncFS demonstrates nicely). >> >> In any case, I for one do not need to carry an old version of boost. I’m >> pretty sure many would feel the same way. I strongly suggest to drop >> boost-1.57. >> >>> Unfortunately, biicode is >>> not maintained anymore, so I'll switch to more established build >>>systems. >> Glad to hear this. Cmake alone is quite enough to annoy a person. :-) >> >>> Mac OS X is not yet supported, this is actually what I'm currently >>> working on. >> OK. >> >>> It should compile fine if you're using the latest clang (or >>> at least did for me), >> I’m using clang-3.7 (the latest *stable*), and clang that came with the >> latest (*released*) Xcode. Clang-3.9 is still beta, so I don’t use it. >>But >> the compilation seemed to work - up until it found it’s unable to find >> osxfuse. >> >>> but I couldn't get it to run with osxfuse yet. >> Parametrizing osxfuse location might help. >> >>> Sorry for that. >> ;-) >> >>> Do you have a Linux VM? There it should work fine by >>> just following the build instructions on github. >> I do, but use it for other development. So trying cryfs there is out of >> question. “CryFS = Cry For Sure” ;) >> >
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________ Encfs-users mailing list Encfs-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/encfs-users
