I have been a Linux user for almost two decades, but it was a good idea to subscribe to LJ more than a year ago. I keep finding lots of good articles in every issue.
In your July 2014 issue in the “Remote System Administration with Android” article, Federico Kereki suggests ConnectBot for SSH on Android, although as far as I know, it is no longer maintained. There is a better alternative called JuiceSSH.
Although it's not completely free (but neither do we work for free, right?), it is well worth the money for the features it supports—for example, Mosh (https://mosh.mit.edu), which comes in handy over slow mobile connections, dynamic resize of the screen area and so on.
I also have a foldable full-sized QWERTY keyboard and a micro USB to USB
female OTG adapter cable so I do not have to use the onscreen keyboard
if I know I will have to type a lot, but rather a proper keyboard.
—
Balazs
Federico Kereki replies: Mr Kinszler is almost right as to ConnectBot. Although there were no updates for a long time, work on it has seemingly restarted, a pre-release version is available at https://github.com/connectbot/connectbot/releases, and a new release may be available soon. As to his suggestion regarding JuiceSSH, I haven't tried it out, but I will; it seems to be a valid alternative. Finally, I also agree with him that a external keyboard is best. Personally, I own a rollable Bluetooth keyboard that does the job well.
Regarding Doc Searls' “Stuff That Matters” article in the September 2014 issue: isn't it possible that the word “extremist(s)” in the NSA's surveillance system XKEYSCORE is ambiguous? Isn't it possible, or even likely, that the word “some” is implied in the phrase “advocated by extremists”, as in “advocated by some extremists?” To me, it seems far more likely that the phrase is an example of the logical argument “All bad-guys are extremists, but not all extremists are bad-guys”, than it is leap to the nefarious conclusion that Cory Doctorow describes in his article as “nothing short of bizarre”.
Kyle Rankin's own article affirms that being flagged as “extremist” targets you for further surveillance. This implies that the system is in a narrowing down phase and hasn't yet concluded you're a bad guy. For example, the September 11th hijackers were identified from a set of all airline passengers. Indeed, all the September 11th hijackers were airline passengers, but not all airline passengers were hijackers.
I believe this
article is premature in its conclusions and is out of character for the
intellectually honest work I've come to expect from Doc. So much so, that I
believe this conclusion was probably reached to generate letters to the
editor. I do freely admit however, that mine is probably an extremist
opinion.
—
Jon Redinger
For Dave Taylor, here's yet another approach. Just implement the basic rule: a leap year is any year divisible by four, except that divisible by 100 is not, except that divisible by 400 is:
$ cat leapyear
yr=$1
if [ "$yr" -le 0 ]
then echo "usage: leapyear year"
exit 1
fi
if [ $yr -eq $(expr $yr / 4 '*' 4) ]
then if [ $yr -eq $(expr $yr / 100 '*' 100) ]
then if [ $yr -eq $(expr $yr / 400 '*' 400) ]
then echo $yr is a leap year
else echo $yr is not a leap year
fi
else echo $yr is a leap year
fi
else echo $yr is not a leap year
fi
Dave Taylor replies: Nice, simple straightforward code. Thanks for sending that in, Bill!
Calculating days between dates is more complicated than you would expect at first sight. First, you must ask yourself the question: “Where am I? Europe, Asia, America....”
Second, “which country?” Because all of this has an influence on the date.
Third, “which calendar am I using?”
The most accurate calendar is the Mayan calendar, not the Gregorian or western-known types of time tracking. So I suggest you start from this calendar and first convert the date to the Mayan calendar, and then calculate these days between dates, and then convert to normal dates. This will avoid a lot of mistakes due to “modern calendars”.
For example, the Thai calendar is, for us, in the future.
In Europe, we have known a lot of calendars in different periods and places.
—
Patrick Op de Beeck
I am not sure if anyone at LJ or any of your readers can answer this.
When I try to go to the www.kernel.org Web site using Win XP and IE 8, it
says the page can't be displayed. I tried to find something in XP that
would block the site, but had no luck. I can access the site from all
other systems on my network, so I know it is not a connection problem.
Have any of your readers reported this before? Does anyone know how to fix
this? Is Microsoft deliberately blocking the kernel.org site because it is
a competing OS?
—
Mike
I suspect it's not an intentional blocking of the kernel.org Web site, but probably some outdated implementation of something (DNS? SSL cert?) that makes the sites inaccessible. Since it's XP, and it's Microsoft, I would be shocked if it was something that ever gets fixed. I don't have XP to test it, but it wouldn't surprise me if it failed on every XP install. If you're stuck using that computer, maybe try a different browser? Or a proxy? Otherwise, I do know a pretty awesome operating system you could try.—Shawn Powers
Do not believe everything you read in the papers—ref: “you could be
fingerprinted”. I would almost guarantee there are NSA employees
(*nix sysadmins, security managers, etc.) who subscribe to this journal because it is
a quality source of information. They are not “extremist”, and I can only
assume that they are not forbidden from reading this journal. Perhaps the
NSA may contain some people like you and me.
—
Jon
Oh, I'm sure there are some fellow Linux nerds that work for the NSA, and most likely, some read Linux Journal. Being flagged as possible extremists was likely either automated based on our encryption articles, or manually due to the same sort of thing. Although I find it frustrating to be considered a potential threat, I'm trying to take it as a compliment. Open-source ideals are radical, and we are a passionate bunch. Does that make us suspect? Even if it does, I have no desire to change!—Shawn Powers
Thanks for Shawn Powers' excellent article on DNSMasq in the September 2014 issue. I have a couple small
networks where bind has always been an overkill. DNSMasq is great, as is
loading data directly from /etc/hosts.
—
Richard Ruth
Thanks Richard! I was surprised just how powerful it can be. I don't know why I never considered it outside of an embedded router, but I've been incredibly impressed with it. I'm glad you find it useful as well.—Shawn Powers
I would like to connect a USB digital microscope to my Linux laptop to show my children all the tiny life that is in pond water.
Do you have any ideas?
—
Pat
I think many USB microscopes function like a Webcam, so if you can figure out whether it's UVC-compatible, you should be able to tell if it will work with Linux. I think model numbers and Google will be your best friends in this endeavor.—Shawn Powers
I have two items to mention regarding Dave Taylor's article on calculating days between dates.
1) There is a bug in the code found within the “Days Left in Year” section. The output of the date command pads the results with zeros by default. In bash, a numeric value that begins with a zero is evaluated as an octal (base 8) number. This is demonstrated by the script output:
Calculating 366 - 035 There were 337 days left in the starting year
366 – 35 = 331—not 337.
If 035 is treated as octal, 035 = 29 (base 10), 366 – 29 = 337 (as reported by the script output quoted above).
The leading zeros can be removed by using a “-” in the output specification for the date command. For instance:
$ date -d '01/01/2010' +%-j 1
2) I would suggest an alternate approach to the entire script. Please ignore this if you have considered and rejected this approach for some reason. I saw this article alone and no prior articles in the series.
Use the seconds-since-epoch output format. For instance:
#!/bin/bash
# daysbetween.bash
dateEnd=${1}
dateStart=${2}
echo ${dateEnd} through ${dateStart}
epochSecondsEnd=$( date -d "${dateEnd}" +%s )
epochSecondsStart=$( date -d "${dateStart}" +%s )
let elapsedSeconds=${epochSecondsEnd}-${epochSecondsStart}
echo elapsed seconds: ${elapsedSeconds}
let elapsedDays=${elapsedSeconds}/60/60/24
echo elapsed days: ${elapsedDays}
let doubleCheck=${elapsedSeconds}-${elapsedDays}*60*60*24
if [ "${doubleCheck}x" != "0x" ] ; then
echo "double check failed: ${doubleCheck}"
fi
The +%s format gives a positive value for dates after Jan 1, 1970, and a negative value for dates prior to Jan 1, 1970.
Using this approach, there is no need to calculate any “from beginning” or “to end” of year blocks nor worry about leap years.
However, there is an issue. In a normal day, there are 24*60*60 seconds. The date command reports that March 9, 2014, has only 23 hours. From my shell:
$ ./daysbetween.bash 2014-03-10 2014-03-09 2014-03-10 through 2014-03-09 elapsed seconds: 82800 elapsed days: 0 double check failed: 82800 $ date --version date (GNU coreutils) 8.23 ...
A 24-hour day contains: 24*60*60 = 86400 seconds. A 23-hour day contains: 23*60*60 = 82800 seconds.
As you can see from the output, the date command reports that March 9 had 82800 seconds, or 23 hours.
I do not know if this is a bug in the date command, or if it's intentional because of some date-adjusting convention (such as an hour equivalent of a leap year), or something else.
All other tests I performed raised no errors.
Addendum to the seconds-since-epoch approach:
The 23-hour day corresponds with daylight-savings time. “Spring forward” gives a 23-hour day, and “fall back” gives a 25-hour day.
This problem can be avoided by switching to GMT. A modified script is presented below:
#!/bin/bash
# daysbetween.bash
dateEnd=${1}
dateStart=${2}
echo ${dateStart} through ${dateEnd}
epochSecondsEnd=$( date -d "TZ=\"GMT\" ${dateEnd}" +%s )
echo "${epochSecondsEnd}"
read epochSecondsStart startTZ <
↪<(date -d "TZ=\"GMT\" ${dateStart}" +%s)
echo "${epochSecondsStart}"
let elapsedSeconds=${epochSecondsEnd}-${epochSecondsStart}
echo elapsed seconds: ${elapsedSeconds}
let elapsedDays=${elapsedSeconds}/60/60/24
echo elapsed days: ${elapsedDays}
let doubleCheck=${elapsedSeconds}-${elapsedDays}*24*60*60
if [ "${doubleCheck}x" != "0x" ] ; then
echo "double check failed: ${doubleCheck}" >&2
fi
Doc Searls' article in the September 2014 issue about privacy on the Net and targeting by government's security agencies is interesting, but it seems to be a bit naive, especially compared to what the author actually writes about, giving the examples of Israel and London's effective security systems.
The author doesn't seem to understand that such privacy protector systems like
TOR can be used not only to protect the privacy of normal and perfectly
honest citizens but also by terrorist and criminal organizations around the
world, so I guess that's perfectly understandable that a security agency
would be interested in monitoring and tracking them and their users.
At least, if someone has nothing to hide, he's not in danger; security
operators are experienced enough to understand whether they are tracking an
employee who protects his privacy or a terrorist who wants to blow up a
building.
—
Walter
Doc Searls replies: I think you missed my point, which is that we are in the earliest days of personal privacy technology development in the on-line world. To get to that point, I borrowed interest in actual attacks going on in the real world at the time, including rockets pointed at my head in Israel and the NSA flagging Linux Journal readers as terrorism suspects.
If we all had “nothing to hide”, we wouldn't wear clothing. And really, how many of us trust the world's “security operators” to protect our privacy? The ones at the NSA sure failed in our own case.