I really enjoyed the new layout of the March issue. It was much more readable on my tiny netbook screen.
Maybe a font that is a bit bolder also would increase the readability,
especially on low-res screens?
(I know the epub edition doesn't have this limitation; however, I still
prefer the PDF layout.)
—
Adrien
Shawn Powers replies: Thanks for the feedback! As with most changes, I'd expect a few tweaks here and there before we settle on a happy compromise between everyone's preferences.
I have been an LJ subscriber for many years and a Linux fan since 1994. I still remember downloading the 70+ floppy disks that comprised my very first Linux distro. I have always been an early adopter of the latest technologies, and e-readers were not an exception. These days, I have a tablet and an e-reader. Five years ago, at the time I moved from Spain to Ireland, I decided to stop buying paper books and magazines and switch to all digital, which better suited my roaming lifestyle. However, for some reason that I did not know at the time, it kept being extremely difficult to concentrate when reading certain types of content on digital formats, basically the ones that were more study-focused, such as technical articles and books, language study material and, in general, anything that required memorization and comprehension.
Recently, I read that some research studies have found that this is a general issue that happens to (almost) everyone and that has to do with losing “context”. Our brains are still pretty much shaped for the hunter-gatherer lifestyle, which we abandoned very recently from a biological and evolutionary perspective, and writing and reading is an invention that hasn't been with us long enough to make a mark in our brain. So we have incorporated the reading experience in one part of our brain that was used for geo-location in our hunting excursions, and that is why we use the context to remember what we read. In this particular case, context means how thick each side of the book was when we were reading a passage, how things looked on the page and on the opposite one, and so on.
In digital formats, we lose context because small things, like the frame, look the same on each page, and we do not have a physical feeling about how far we are in the book nor how much it is left to finish it.
After reading this study, I decided to stop forcing myself against my own nature and started to buy technical stuff again on paper and leave the e-reader and tablet for fiction and other non-study content. And, this is where LJ comes to the fore: I always have considered LJ one of my sources of new technical knowledge, and I use it as a way to stay connected to what's happening out there and a first pointer to things I should take a look at and study in more detail. But since LJ switched to all-digital, I am reading it less and less, and there are months when I do not even browse it at all.
I think that in light of this new scientific evidence, I would like to propose that LJ once again (as some other readers have asked in the past) switch back to paper format.
I cannot provide the original source where I read about the
scientific study I mention, but I think it was in the science section
of The Economist sometime in 2014, which normally does summaries of
prestigious publications, such as Science magazine.
Nevertheless, there are
other sources I can provide, such as these two:
www.theguardian.com/books/2014/aug/19/readers-absorb-less-kindles-paper-study-plot-ereader-digitisation
and
www.pri.org/stories/2014-09-18/your-paper-brain-and-your-kindle-brain-arent-same-thing.
—
Juan J. Olmedilla Arregui
Shawn Powers replies: It's an odd transitional period we're in, that's for certain. I also struggle with technical material on a tablet. The strange thing is, I don't seem to have any problem absorbing information from a Web browser on a computer. I don't have any explanation for why that's the case.
As far as moving back to a paper format, I don't think that's a financially feasible option at the publishing level. Not only is the process expensive, but advertisers have moved to digital expectations in their purchases. Thankfully, it's a fairly easy process to get a digital issue onto paper. I used to print every issue of TUX magazine, and then use a comb binder to make my own magazine. Some other folks are printing Linux Journal using on-line printing companies (for their own use, of course).
Your rationale is the same reason I still haven't purchased a Safari subscription and keep buying technical books. I'm curious to see what the future holds as the “digital generations” grow up. Thanks for the links as well, I appreciate it.
After using Ubuntu/Lubuntu and more recently Mint/LXDE during the past eight years, I switched to OpenSUSE/LXDE, and it has been outstandingly better and should be noted as such.
I don't mean how “pretty” it is or how easy it is to install, but as far as system performance, stability of apps (turned some from being nearly unusable to perfect) and speed.
I've got more detailed information on how it overcame some serious problems I had
with Mint, which I can let you have if you're interested. I'm not a
journalist, but I think anyone who is contemplating venturing into Linux or
has considered the OpenSUSE option, should be encouraged to try it out.
There is, as always, a downside, but the negatives are far outweighed by
many positives.
—
Nigel Hinton
Shawn Powers replies: Thanks Nigel. Some of the folks here at Linux Journal are die-hard OpenSUSE fans. For me, I usually consider ease of use as one of my most important aspects when choosing a distro. Unfortunately, that typically means what I'm most familiar with (Debian/Ubuntu, in my case). Thanks for the info on LXDE and OpenSUSE; I wouldn't have given it a try otherwise!
This short video explains how biomerics make a backdoor to password-protected personal secrets: https://youtu.be/5e2oHZccMe4.
Many citizens are being misguided collectively by the media and get trapped in a false sense of improved security generated by the addition of biometric functions to smartphones, tablets and PCs, while many criminals presumably understand what this situation means.
The role of leading media like you is very obvious. I hope that you will
not hesitate to play that role.
—
Hitoshi Kokumai
Shawn Powers replies: I think it's important for folks to realize that biometrics can add a layer of security to existing technologies, but replacing existing models with biometrics only is definitely a risk. That said, as long as an understanding of those concerns exists, there are some viable reasons for using biometrics only. (Securing my home gaming laptop, for instance, if I'm not concerned about it being compromised.) I share your concern, however, that biometrics might seem more secure than they really are. Thanks for the reminder.
In my previous article on ciphers in TLS and SSH [“Cipher Security” in the September 2015 issue], there was no detailed discussion of Elliptic Curve (EC). The default settings are considered safe, but considerable suspicion of tampering exists for the standard curves. Stronger EC settings are available, and what follows is a short guide to enable them.
OpenSSL on Oracle Linux V7 supports three Elliptic Curves:
$ openssl ecparam -list_curves secp384r1 : NIST/SECG curve over a 384 bit prime field secp521r1 : NIST/SECG curve over a 521 bit prime field prime256v1: X9.62/SECG curve over a 256 bit prime field
All of these curves are endorsed and supported as safe for financial transactions, government data and other sensitive content. The default curve used in TLS for EC is prime256v1.
However, both the 256 and the 384 curves come under heavy criticism from multiple sources for unexplained constants used in the formulas.
The prime256v1 curve has received particular sentiments of alarm: https://github.com/nodejs/node/issues/1495.
Daniel J. Bernstein, well-known in both cryptography and software development, dismisses both the 256 and 384 curves as tainted (safecurves.cr.yp.to):
| NIST P-256 | manipulatable | Coefficients generated by hashing the unexplained seed c49d3608 86e70493 6a6678e1 139d26b7 819f7e90. |
| NIST P-384 | manipulatable | Coefficients generated by hashing the unexplained seed a335926a a319a27a 1d00896a 6773a482 7acdac73. |
Recent research on TLS acknowledges concern for the mysterious constants in the 256 and 384 curves (https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf): “Unfortunately, the most widely supported ECDH parameters, those specified by NIST, are now viewed with suspicion due to NSA influence on their design, despite no known or suspected weaknesses.”
However, the secp521r1 curve appears to be more forthrightly designed, and has received praise instead of distrust (blog.cr.yp.to/20140323-ecdsa.html): “To be fair I should mention that there's one standard NIST curve using a nice prime, namely 2521–1; but the sheer size of this prime makes it much slower than NIST P-256.”
For non-HTTPS EC applications not involving a Web browser, especially where both endpoints are implemented with modern OpenSSL, prefer secp521r1. For the highest quality EC within HTTPS, prefer secp384r1, since secp521r1 support is not consistent between Chrome, Firefox and IE. The prime256v1 curve should be avoided, unless speed is preferred to quality.
The stunnel utility makes it easy to select alternate curves. Pass the curve=secp521r1 option in the configuration file, with the exact name as listed in the previous “ecparam” example. Otherwise, just append the output of openssl ecparam -name secp521r1 to your certificate file.
There are more reasons to avoid Elliptic Curve in TLS. In addition to the hints of subterfuge, there are software patent questions within the US that have come before courts of law, some by holders of significant intellectual property: security.stackexchange.com/questions/3519/can-ecc-be-used-without-infringing-on-patents.
Recent rapid-fire lawsuits have seen settlements from major corporations over patents on Elliptic Curve: www.theregister.co.uk/2015/12/01/cryptopeak_sues_.
If you have chosen to forego Elliptic Curve for any of these reasons, be aware that there is a small security ratings boost on the ssllabs.com scanner for using 4096-bit Diffie-Hellman primes in situations not involving EC, although this also imposes a heavy speed penalty.
