VeraCrypt on linux uses the linux kernel infrastructure for user data encryption/decryption and hence its performance will be on par with LUKS because it uses the same infrastructure also.
Performance of a VeraCrypt volume will degrade only if you use multiple ciphers.
First a big thank you for your fantastic efforts and for letting the world participate by open sourcing all that stuff!
But one thing: Please make it easy to generate VIDEO OUTPUT with your libraries!
This is an artificial limitation that I hit with many charting libraries - output generation is html (js) only and people who would like to create moving images have unnecessary problems shoehorning that nice chart library into outputting to a high resolution video.
Please do not limit your designs to one output medium.
Have you tried using Julia? Tom Breloff's Plots.jl[0] package has a built-in @gif macro, which already relies on ImageMagick and/or FFmpeg (depending on which one of them is present). So it shouldn't be too hard to extend that to mp4 (just pass different output parameters to FFmpeg). In fact, he has an issue open for it[1] so he appears to be working on that.
what events? It would be great if he spoke openly, so people not following tor very intensively would know what is so concerning. Yes, I am living under a rock.
The Appelbaum crisis is the most recent public drama, but that's mostly a settled matter and a fall has already been taken for it. It would be fairly strange to do this now over that incident.
Given which, it looks like someone involved with a privacy project is refusing to disclose their motives for shutdown, but also shutting down slowly and openly, the way you wouldn't if someone was knocking on your door. This is an ambiguous outcome to almost everyone.
That's an interesting point - it hadn't actually occurred to me that this could be a reaction to the reaction. That would fit the timing (and maybe the ambiguity) much better than reacting to the original topic.
May I ask you for some little thing that might change the (development) world? Would you please like to introduce a folder, where people might put their dependency.yml file - this is an effort to finally stop the spreading cancer of "put one more config file into the project root".
I would like to suggest to call that folder simply "config" - all the projects and tools out there should have no problem with that. Optionally there could be one top level config file called "config.rc" - this file points to the actual config dir if it is not "config".
It would be verrry nice if one service just starts with that and hopefully all the others will follow and it will become a defacto standard. The pollution of the top level project directories really must stop.
I've thought of the same thing, but I feel that the horse has well and truly bolted, run back through the barn a few times, kicked some shelving over and then continued out the front and over the horizon at a brisk pace.
beefsack is right, please do NOT make it a github specific thing. Just one config folder. All config files for services, integration, etc. should go there.
In the config.rc file you could call that folder however you want.
I personally do not like ".meta", because it is not clear what kind of information it may contain. "Meta" might be anything, documentation, description, website, design papers, everything is meta. It is a bit like using "Information" as a menu entry for a website.
How about we put each individual config file in its own individual directory? We could name the directory after the file too, so that it is clear where each file is ;)
No but seriously, I don't think this mess of config files in the project root is really a big deal. I already grouped the interesting stuff under /src. If it is a big deal, then lets hash out an RFC that covers the general concept of "configuration" once and for all and be done with it.
Especially Bookie looks good and would be a preferred candidate to transition to if you are still using the very old 'Sitebar', 'Scuttle' or the interesting 'Semantic Scuttle'.
Well, a note-taking solution (be it a plaintext file or a simple database) can perfectly handle the task of keeping URLs, but I think the point of bookmarking service are social aspects and/or content archival and indexing. Otherwise there's no reason to just not stick to what browsers have built-in for ages.
Sadly, Bookie seems to be somewhat dated and not actively maintained. I've thought of trying it out, and now have hard time packaging it.
By default, it won't even start on modern distributions because of incompatibility with Python >=2.7.11 ("cannot import name _uuid_generate_random"). The requirements.txt file require a few version bumps. I haven't tested whenever the project actually works correctly with those yet, but it seems to at least start with kombu==3.0.35, celery==3.1.23, billiard==3.3.0.23, amqp==2.0.2, redis==2.10.5.
(I'm lazily toying with it remotely, setting it up on a small ARMv7 host, wrapping it with Docker+honcho+gunicorn, and rebuilding the image when I update requirements takes long time...)
consul and vault are very nice for devops.