I'm considering renewing my subscription. My main problem with the magazine
is that the digital format is not set up for digital devices. Digital
devices do not have letter page size and do not have 600dpi resolution,
and many laptops do not have a portrait aspect ratio. What does this mean?
Well, in order to view a page, you have to zoom in. Once zoomed in, you
have to scroll up and down to view a single page. That is annoying. Compare
it with the Web. You start at the top and scroll down because most Web
pages are single-column text. They are digitally ergonomic, whereas your
magazine's
PDF is not. Please, I beg you, fix it by going to a single-column PDF or,
better yet a, downloadable HTML .tgz. HTML would allow readers to set the
single-column size to what works best for their devices.
—
Mark Ramsell
The main PDF has changed slightly since the digital transition. It “fits” on a tablet-size screen better. Laptops, I agree, don't lend themselves to reading a portrait document very well. In that case, I recommend using an EPUB reader, which allows for flowing text (a couple issues ago I wrote about a great Firefox plugin that does it). Otherwise, the interactive on-line version of the magazine formats as a two-page spread, which looks good on a computer screen. Hopefully, one of those formats will work well for you. The good news is they're all included with your subscription!—Ed.
I have to admit, I am quite messy at keeping track of stuff, and things that have been added to my list of untrackable stuff are e-books. I have an old Android tablet, a new Android phone, a laptop with Windows 7/OpenSUSE 12.1 and three more PCs that I usually work on. That's a lot of devices, and because of this, except for my work PC, I don't spend a lot of time at any given device. I think the PDF and .mobi formats are great for e-books like the magazine; however, it takes precious time to find the last page that I read. I am currently using Dropbox to share the files between all the computers, but I can't help wondering if there is a better way to do it and keep the reading progress tracked.
I like to read on my regular
PC because of the bigger monitor, but I rarely have time at work (I read
when I need to wind down), but when I am waiting for something, I can read
on my phone. Before going to bed, the tablet is great. At the moment, I am
reading different things in each device, because I don't feel like wasting
time searching for the last spot that I was on.
I figure I am not the only one; other people must have encountered this
problem.
Keep up the good job!
—
David
David, I have the same issue with e-books—not just Linux Journal, but my entire collection. For something I want to read cover to cover (and keep my place), I find the Kindle reader to do a nice job. You can upload the .mobi version of Linux Journal to your Kindle account as a personal document, and it will use WhisperSync to keep your spot on multiple devices. The only thing that frustrates me is that personal documents can't be read with the cloud reader, so reading on my screen isn't possible yet. Hopefully Amazon will lift that restriction!—Ed.
Thanks for the digital edition of Linux Journal! It's really nice to have full-text search on all the issues, thanks to our usual desktop search tools.
The other day I wanted to download all the back issues for my archives on a new PC, so got an old Python script and edited it to download them, as an alternative to wget's black magic. Also, it's easy to edit it to get only the latest issue and run in a cron job.
You can get it here, if you want; it's far from perfect, but it works:
gerlos.altervista.org/files/dljget.py.
Obviously, it needs to be edited: you need to put your download
page link and the download path in the script.
—
gerlos
Thanks gerlos! This is exactly what many of us have been hoping for. The script works well, and it's easily modifiable for .epub or .mobi. gerlos is officially hero of the day! (Note: you need to make sure you have the python-bs4 package installed. Also, to find your variables, click through to your download page and look in the address field. You'll find your personal link information to put into the script.)—Ed.
I'm finding all of Dave Taylor's shell scripts for cheating at Scrabble, Words with Friends and so on to be tiresome. Normally I'd be interested, but he's gone on about this ever since I renewed my subscription a few months ago!
I must admit, part of my blasé stems from the fact that I solved this problem more than five years ago for a different word game: Jumble, a syndicated newspaper word/riddle game I loved to play as a child. I was bored at my tech support job (with restricted Internet access), and someone gave me an entire illustrated book of Jumble. Rather than work the entire book manually, I wrote a series of Bourne shell scripts to solve it on a SCO UNIX system. All I had was SCO's man pages, aspell and a very limited vi. It took me a few weeks, but I was able to get it to the point where I could solve the entire book in about ten minutes.
So when reading Dave's column, I see that he's gone deeper than I did (granted, I had a much simpler, one-player game). In my case, I don't call it cheating. Scripting the problem means you never have to solve it again!
Will we see a different topic next month?
—
Trey Blancher
Dave Taylor replies: ayup. I was ready to move on too and have done so (starting with my column in the July 2012 issue).
I will say this, however. If you have some great ideas about big, complex scripts I could work on, I'd be very interested in hearing about them. Sometimes I can rather get at a loss for a topic when my column's due, so if you've got ideas or problems you face, do share!
To Dave Heebner [see Dave's letter regarding downloading issues on his NOOK in
the June 2012 issue]:
after I download an issue of LJ, I open “My
Stuff” in NOOK for PCs and use
the “add new item” at the top of the page to copy the item from downloads.
—
Ray Cleveland
Awesome! It's nice when things “just work” like they're supposed to.—Ed.
Greg commented in the June 2012 issue that Linux Journal had become a bit
esoteric with the subjects covered recently. I'm a very recent two-year
subscriber, and I must say that I echoed Greg's impression when I previewed
a few past issues. I made a two-year subscription in spite of my initial
impression because I was certain that it was a passing thing and that
LJ
eventually would cover more general and practical topics. A Bluetooth
proximity device that locks and unlocks my computer when I leave and return
is pretty incredibly cool, I admit, but not too practical. A wall-mounted,
dual-monitor PC is also pretty cool. But practical? Don't get me wrong,
there is nothing at all wrong with the esoteric, but let's not exclude the
more common—something for the intermediate reader: an article on Udev and the
many gotchas involved in manual configuration; Calibre, and what it can do;
using notify-send to set up your own notifications; Flexget for automating
torrent downloads. There is a trove of topics that would be beneficial to
a very broad slice of your readership. I'd even be willing to write a few
articles myself, if that would help. Love the magazine as a whole, just hoping
for something a notch or two closer to home.
—
Slurry
It's an admittedly strange game trying to get just the right balance of articles to make everyone equally happy (or equally frustrated I suppose). We have a group of Linux Journal readers on our advisory board, and we run ideas past them every issue. We are always up for new writers, so if you'd like to send an article idea, we'd love to hear it. See www.linuxjournal.com/author for more information.
Dave Taylor's Work the Shell column is far less useful than it could be. This is not UNIX Journal. This is Linux Journal. As such, the shell that people use is bash, not the Bourne shell. I just don't understand why every example is based on a 20-year-old shell that requires that every single thing can occur only by running external processes. Let's look at a few examples from the current issue:
if [ ! -z "$2" ] ...
vs.:
if [[ -n "$2" ]] ...
vs.:
[[ -z "$2" ]] || targetLength="$2"
For the record, I'd rather see people getting educated on what the difference is between use of single vs. double square brackets.
Here's another:
for word in $(cat $possibilities) do length=$(echo $word | wc --c) length="$(( $length - 1 ))" # Why the dbl quotes?
vs.:
for word in $(< $possibilities)
do
length=$(( ${#word} - 1 ))
A few processes were saved. Who cares? The people who go into a job interview and demonstrate how little they know and how sloppy they are at not bothering to learn properly the language in which they are being paid to write. Besides that, there are lots of bad >10K LOC scripts out there that get buried under the sheer weight of the excess processes.
One last one:
uword=$(echo $word | tr '[[:lower:]]' '[[:upper:]]')
Sure, using a bash4 feature might be pushing my luck because of all those people out there who are still(?) using an antique copy of bash. Maybe they can't use:
uword="${word^^}"
But, at the very least, they could use:
uword=$(tr '[[:lower:]]' '[[:upper:]]' <<<$word)
I won't even go into why a while loop is being used that has a start, a termination value and an increment, when a for loop would be perfectly lovely.
I do hope that this problem can be rectified since I see no reason why it
shouldn't.
—
Steven W. Orr
Dave Taylor replies: Thanks for your interesting note, Steve. I have old dog/new tricks syndrome with the scripting I work off, so I have to say that I haven't seen the [[ ]] notation before. I'm curious. I tend to work off the reference materials I have on hand and the man pages: where are some of these newer scripting capabilities documented so I can catch up on things?
I'll definitely hit on these topics in my next column, due July 1, so stay tuned for it, and thanks again for taking the time to write.
And, Steven replies to Dave: You have to read the bash man page about 200 times.
There used to be a program in /bin or /usr/bin called test. For a while, that program used to link to a file called [. After that, the test became built in, and you'd have to go out of your way to invoke the external test program. The [[ ]] construct is relatively new, around 20 years old or so. It started with ksh88, and bash has had it for a very long time.
The differences are quite important:
if [ -z "$foo" ] && [ $(xxx; echo $?) -eq 0 ] || ↪[ $(yyy; echo $?) -eq 0 ]
will not do what you expect. It will test to see if $foo is null, and if it is, it will then run the xxx test and not the yyy test. If the foo test is false, it will run the yyy test and not the xxx test.
The correct approach is:
if [[ -z "$foo" ]] && {
xxx || yyy
}
Note that double square brackets are not a built-in; they are a keyword.
Another example that will demonstrate things:
if [[ t1 && t2 && t3 ]]
is not the same as:
if [ t1 -a t2 -a t3 ]
I am a long-term subscriber to Linux Journal, and I have recently posted the source code of two of my projects on GitHub. One is a lattice simulation and the other an N-body simulation: https://github.com/fhstoica/AbelianHiggs and https://github.com/fhstoica/N_Body_Simulation.
The code gives a good real-world example of highly parallelizable computations making use of barrier synchronization and CPU affinity (Linux-specific) to improve performance. The visualization code implements the rendering of an isosurface using the Mesa and GLUT libraries.
I would have liked to see such examples when I was learning multithreaded
and OpenGL programming, so I am trying to make them available to anyone
interested.
—
Horace Stoica
Here's a picture of myself as Tux for Halloween.
—
Joey Bartlett
Joey Bartlett, 13 Years Old