sbrass

Numberphile did cover this some years ago, see for example: https://www.youtube.com/watch?v=AxJubaijQbI

The author suggests that security has to be enforced by the system itself, i.e. by the usage of an appropriate programming language, security tools (e.g. sand-boxing, ...) and other. However, the author's comment fell short to honor the history of the kernel development, specify user applicability and discuss any improvements. I partly agree with the author, but "default" settings are a very sensitive topic (why he doesn't provide any suggestions?) and hardly to answer for every application scope.

I don't think that Linux is more secure "than any other OS". First, we have a wide variety of Linux desktops. Second, when required, experienced (!) system administrators/business vendors invest a lot of time in order to get their system secure. However, (unexperienced) "home users" are at disadvantage, because of lack of knowledge. They would/will suffer from the perception of an superior security notion of Linux. We have to get that right. That's it.

As already stated by the other commenters, the author had already submitted the paper to arXiv in mid of March. So, I don't think that it falls in anyway under April's fool (and I don't think that in this serious situation any researcher should do a April's fool paper).

Back to its contents, the authors describe the potential destructive action of alcohol on SARS-CoV-2 and its possible application in the respiratory tract, thus, nose, nasal cavity and further. He bases his ansatz on a theoretical approach on diffusing the alcohol from a alcoholic vapor in to the respiratory system. However, as theoretical it may sound, I think it could prove usable, if it is done in a controlled way and may deliver a simple approach to help infected people and saving those.

Thanks for your interesting insight in your projects.

I'm using org-mode profoundly since 2015 for a lot of my daily note taking routines. Additionally, I've started two years ago to work some of my readmes/tutorials with org-mode. It provides a fantastic way of helping to write, where I find it much more graceful than RST (or Markdown at all).

One of the reason of change to org-mode, however, was its excellent code blocks and noweb-like feature - as you told residing in org-babel. However, that is not what org-mode was buying for me, but the sheer extensibility and that you can use it now everywhere (e.g. for static page builder like Jekyll or wiki-pages based on Gollum).

I recommend everyone to peek at the excellent Spacemacs project, https://www.spacemacs.org, for an org-mode experience out-of-the-box.

I would have agreed then, in 2014, maybe, one or two years later, completely with GnuPG's statement on ECC support. I cannot state whether any of the other open-source and free projects on encryption have advanced to ECC, however, I would expect most of them have so far. Independent of the ECC support in other programs than GnuPG, I think to advance to the newest, but stable and well-tested, security measures (ECC), would be a good idea and will pay of in the future? I expect, of course, to advance to the newest stable versions will, at some point, introduce regressions with older versions (or platforms). But I think that is a price we should be willing to pay.

Thanks for the great post! However, I discourage the usage of RSA with 4096 bit as it does not offer any substantial security over RSA with 2048 bit. The mean idea behind the "No-4096-bit" is nicely explained by GnuPG people themselves, https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa40....

Therefore, wouldn't it be more efficient to use elliptic curve cryptography, i.e. ED25519, if you want that extra bit of security? It's included in GnuPG since version 2.1.0 released in November 2014 - at least in an experimental state.