Ereaders...not quite the death of paper
I am the proud owner of an ereader. I have had a Sony PRS-600 (Touch) for less than 24 hours. But unless something changes dramatically, I am unlikely to be an ereader user 24 hours from now. To say I am disappointed would be an understatement. For what I have paid for the unit, I almost feel taken. Before I delineate the short comings, let me tell you how I got here.
I am a reader. Ever since I was young, I have read. Books, magazines, cereal boxes, what have you. My parents fostered a love of reading in me and it took hold. I read books like Dune and the Lord of the Rings when I was 10 and to this day I have stacks of paperbacks, hardbacks and falling off backs scattered around. I have books on a variety of topics from philosophy to Cisco IOS. But I did not get an ereader for reading books. I got it for my other problem - documentation. Like most of us, I have directories of PDF files, Word documents, and raw text files full of documentation. Some of it vendor created, some of it created by luminaries in the field and some of it cobbled together by yours truly. I wanted an ereader to help manage and provide convenient access to the documentation without having to search though directories, distribution CDs and thumb drives. I also had the wild notion that I could consolidate my favorite editions of magazines, like the Linux Journal and some of the O'Reilly books I find myself using frequently, into one easy to carry device. Now I have a laptop, and a netbook, but the easy on, easy off, gentle on the wrist idea of an ereader just seemed to be the magic gizmo that would make things easier for me.
When the Kindle first appeared on the market, my interest was piqued, but I decided to wait. When my wife got an Apple Touch, I started paying attention. She downloaded the Kindle app and I took a look at it. The largest disadvantage I found was the screen size. To my mind, it was too small for concentrated reading, even something as fluffy as a novel, much less something as detailed as code in an installation document, but it gave me an idea of what I was looking for. In November, I started doing a survey of all the ereader devices on the market at the time and was surprised by the number of devices that are available if not the general lack of variation between them. They all have the same things in common. Most are between six and ten inches in visual display (my netbook is ten inches), and I was looking for something at the lower end of the scale around the size of a paperback, maybe a little larger. Most can either accept PDF formatted documents natively or through some sort of conversion process and a couple, including the Sony, could consume other file formats, like MS Word documents. All of them seem to have been built with some form of the Open Source tool sets, which is nice even though I was not about to start hacking the kernel on these devices right away. The final selling point for me was expandability: would it take more storage media easily and especially, SD RAM storage media, because I have piles of these little chips sitting around. In the end, the Sony met my technical requirements.
I picked it up on Sunday and started the process of loading it and using it.
Let me start by saying that it is a very simple device. This is both a pro and a con. It comes with a nice iTunes like interface for managing books and photos and music (yes, if you want you can put pictures and MP3 files on it. The pictures are displayed in gray scale and I found them to be less than satisfying, especially those dynamic ones of my daughter shot in 8 megapixels with full colour saturation. I haven't got to the music, but I digress). Loading books is a simple process with a number of ways to get documents onto your device, including the direct load method of dragging your file to the folder on the device itself: a very nice feature for moving large numbers of files or entire folders of documentation. Sadly, the simplicity is also a bit of disappointment. If, like me, you have your documents in folders, and you drag these folders, the reader does not recognize the hierarchy and while it reads the documents in the folders, it does not acknowledge the folders. You are instead, forced to create your own hierarchy, called Collections, in the PC interface (you cannot create it on the device itself) and move the files into the new Collections, much like making a playlist. This turned out to be another failing point.
The Collections are not user sortable. They are sorted by file name, but not the file name of the actual file as seen on the PC but the file name of the PDF as displayed in the properties of the PDF, which, depending on how much attention was being paid at the time of PDF creation, may have nothing to do with the actual title of the document the PDF is referring too. This gets frustrating very quickly when, for example, you have manuals that were generated in another country or another language. I have two radio documents that were created in Japan and the PDF title is a couple of ideograms, properly displayed by the reader, but completely meaningless to me who does not speak the language and there is no way to alter them. For me, this was annoying but not a major issue, although it could rapidly become one.
These are the major issues:
Legibility: I bought this to be able to read documentation, so it does not help that I cannot read the words or, that I cannot read the words. Let me explain. There are two aspects to legibility. The first is the font size. Most books are set in either 9 point or 11 point type, with a certain amount of space (leading) between the lines, usually 2 points. While this may seem incredibly small, especially when the average font standard for most memos created in word processors is 12 point, it is, in fact, quite comfortable and most people find that long documents in larger fonts uncomfortable to read. However, if you take the PDF for the Linux Journal and load it up, you find, immediately, that it is all most illegible at the small font setting on the ereader. In fact, to make it legible, you have to bump it almost to the large setting, but in doing so, you reduce the amount of text available to barely a paragraph at a time, which, if you read at a decent rate, say 400 words per minute, you will be frustrated with both the limited text available and the speed at which you can move to the next block (I will cover performance in an minute). The other minor annoyance is the text flow leaves some pretty interesting gaps in the text that I found to be frustrating or annoying, depending on where they fell.
The second issue of legibility is the ability to read the text on the screen. In this case I am talking about glare and lighting. The screen is a matte finish, designed to reduce glare as much as possible, but I discovered that in conditions where I could read documentation on paper, I had a hard time reading the screen. In fact, unless the light was coming exactly over my shoulder, with no shadows, I could not easily read the screen. Further, in tests on the train (fluorescent) and in the office (also fluorescent), there was enough glare that I could not read the entire screen unless I tipped and moved it to slide the glare around from the text I was reading. It is hard enough to read barely 100 words at a time, much less when you have to bob and weave to do it.
On legibility, I have a third annoyance and that is with the, oh call it microscope factor, of having to zoom in so tight to read paragraph chunks that you cannot see the overall document. I found this to be very disconcerting but that is a personal preference thing.
Performance I expected that page turns would be nearly instantaneous. OK, so, I can live with not quite counting to one as I initiate a page turn, but I cannot live with counting two, or three or putting it down to flip the pancakes and picking it back up again and finding it has just turned the page as I am watching it repixelate. Initially I thought it was the PDF, but I found this occurred on nearly all PDF files over 50 pages. This is not acceptable performance, especially when you need to flip through to say page 203 of a 900-page document. Even RTF documents, which are what MS Word documents are converted into, are slow on their page turning. To me this is a deal breaker as former boss would say.
Rendering One of things that I found odd was the inconsistent rendering of PDF documents, specifically the fonts. I suspect it has to do with what was used in the master document and how the PDF was told to manage the fonts, but in several cases, there would be a major font change within the document, and sometimes within words, where the font would shift from serif to sans serif and back again. I could find no logic behind the shifting, especially since the PDF seemed to render correctly on the PC and in print. This is incredibly distracting to read.
There is also an issue with drawings and images. Now to be fair, Sony warns you about this in tiny print, but it does not make it any easier to accept when you are experiencing it. Some images cannot be zoomed in on. This is a problem when one of those images happens to be a schematic and you really do not want to put in a resistor when you should be putting in a capacitor. It is also difficult when you are trying to determine just what that button on the front panel is supposed to be used for.
Configuration One of the first things I looked for was a contrast adjustment. It does not exist. No dial, no setting, nothing. You cannot alter the predefined contrasts. In fact, other than the date and time and the gesture you use to change the pages, you cannot alter much on the device. And while I cannot think of something beyond the contrast and brightness I would want to alter (other than encrypting it, but that is a different discussion), being able to alter the contrast might actually alleviate some of the legibility issues I experienced in some of my lighting conditions – like standing next to the stove, trying to read grandma’s pancake recipe. Fortunately, I have that printed out.
In all, I can buy a lot of paper, toner and binders for the $300 the unit cost me. Sure there is the bulk of paper. But I do not have to wait for the unit to decide to show me the page I want to read. I do not have to ramp up the magnification to be able to read the document, angle the light and wait seconds for the page to render, completely or otherwise.
Now, in the interest of fairness, I am picking on Sony because that was the device I bought, but I am not expecting I would have a much different experience with any of the devices on the market. I might not have the same legibility issues on a larger Kindle like screen from a font perspective because it has a bigger screen, but then the form factor of a Kindle comes into play, and it is too big for carrying for my requirements. None of them are backlit, making the screen glare an issue regardless. And I am not reading books. I am reading documents. So my file type of choice is going to be the standard PDF, and I do not want to have to shove it up to a converter just to load it on my reader. Again, one of the advantages of the Sony is that it consumes a variety of file types natively. I like that feature. But I cannot live with the other short comings.
Of course, your mileage and experience may vary.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide