More Zonkyness

Author: Mike Meredith

  • The Future Of Printed Newspapers

    There seems to be an impression amongst fans of digital media that printed newspapers are on the slow decline on the way to oblivion, and they could well be right. Without some radical changes, printed newspapers could be going the way of the town crier – around only as a historical oddity.

    But what about radical change ? There are certainly possibilities there. The key is to look at the weaknesses of digital news :-

    1. Authority. Whilst some digital media news sources have some credibility, much of the time when you bump across some random blogger (like me!), you will have no idea on how credible they are – do they know what they are talking about ? I certainly don’t!
    2. Location. There are zillions (well a large number anyway) of places you can find digital news and it can take time to look for the news you are interested in. That is fine for a number of specialised areas – for instance my job includes an unwritten requirement to keep up to speed with what is happening in the IT industry, so I’ll spend a few hours a week searching. But for something less important to me – such as general European news, I’ll pass.
    3. Photography. Funnily enough given the quality of photo printing in most newspapers, this actually a weakness of digital news – whilst they all do photographs, they don’t do them well. Some of the most dramatic moments in history have had their stories told in newspapers with just a photo printed large. This does not happen often, but when it does it is a very powerful way of telling a news story (or starting off the story).
    4. You can’t read digital media in the bath. In the past, Sundays would often include a period of an hour or two sitting quietly reading the newspaper; whilst we can do that on the computer screen, this is rarely as relaxing as reading in the bath, at a quiet spot in the garden (or the local park), etc.

    But what are the weaknesses of the printed newspaper ? Here we also have many :-

    1. You pay for the whole paper. Out of an ordinary newspaper, I am probably interested in at most 50% of it, and it seems rather irritating paying for that sports journalist who puts in some long story about a hockey tournament that I have never heard of, do not care about, and will not take the time to read even if you pay me for it. On the other hand, I might be interested in some random articles on things I would otherwise not read – for instance I am completely uninterested in car reviews, but there has been a recent review of a car “made” by Top Gear that I wouldn’t mind reading (for humour if nothing else).
    2. If you are lucky the newspaper you buy was put together by an editor whose interests closely match your own. Far more likely however is that there are news stories that did not get in (because you have “oddball” interests) because they are not seen as popular. I want to see news stories on what is happening in Europe, and local interest stories for Portsmouth, Winchester, Bangkok, and Sangüesa – a rather eclectic set of locations it may seem, but what they really are is individual.
    3. The quality of news photograph prints needs to be improved on. If you can print fashion photographs in a supplement properly why cannot the news stories also be printed properly ? Maybe that would cost more but I for one would be willing to pay extra for it.
    4. Some people want a daily newspaper and some want a weekly one. Actually some of us probably want a newspaper on some Sundays.

    What we are looking at here is a newspaper suited to the individual requirements. Conventional newspaper printing and distribution won’t cope with that, but that does not mean it is impossible to provide. After all we have printing on demand for books, so why not newspapers ?

    What I envisage is a web site where you start off by choosing something very conventional … “I want a copy of the Sunday Times delivered every Sunday”. From this unpromising start (and a start that is probably more expensive than the current way of getting the Sunday Times), you can add customisations :-

    • Print on quality paper for extra cost.
    • Remove any articles relating to Sport.
    • Add articles relating to this set of locations.
    • Add articles relating to IT, astrophysics, and archaeology.
    • Reset the formatting to use body text font as “Liberation Serif” at 12 points, headlines as “Verdana” at 14 points, and make the pages four columns wide.

    From there, you could add additional customisations to the point where the newspaper has little or no relation to the real world “Sunday Times”. Whilst the default preference would be to pay for a printed copy, you could opt for downloading a PDF (or any other suitable eBook format) at a cheaper cost if you wished.

    I am sure that if some newspaper magnate were to read this, they would think “hell no, that’s just too expensive” or some other reason for not doing it. That is probably more an indication that their imagination is too limited.

  • Rockbox and the 240Gbyte iPod

    So in the interests of science (ok, I wanted a new toy with a large amount of storage for music), I bought a pre-upgraded iPod 5.5 with a 240Gbyte hard disk in it. Loaded up Rockbox as soon as it arrived with the special version for upgraded iPods and everything was working …

    Well … sort of. I could copy most of my music onto it, but nothing with a filename that broke the rules of pure FAT … no long extensions (so no FLAC files!!), no UTF-8 filenames (and “f#a#oo” isn’t quite a catchy a name as “f♯a♯∞”). So I rebuild the filesystem with the standard Linux tool mkfs.vfat

    Bad move! Whilst all the files now copied onto the iPod, the Rockbox bootloader was now unable to load the main rockbox binary (“rockbox.ipod”). Seems that Rockbox’s idea of FAT32 on large disks isn’t quite the same as Linux’s version (or to be fair OSX either). So I spend ages hunting around to see how to create an appropriate filesystem on the iPod to allow things to work, without success.

    Thus this page.

    First of all, connect up the iPod and determine what device it is (mine showed up as /dev/sdh). The command fdisk -l is quite helpful here particularly as we use that next.

    Once you find the iPod’s device, use that to display the partition table using fdisk :-

    # fdisk /dev/sdh
# fdisk /dev/sdh
Note: sector size is 2048 (not 512)

The number of cylinders for this disk is set to 22506.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
 (e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/sdh: 240.1 GB, 240057409536 bytes
84 heads, 62 sectors/track, 22506 cylinders
Units = cylinders of 5208 * 2048 = 10665984 bytes
Disk identifier: 0x20202020

 Device Boot      Start         End      Blocks   Id  System
/dev/sdh1               1          13      128394    0  Empty
Partition 1 does not end on cylinder boundary.
/dev/sdh2              13       22507   234302542    b  W95 FAT32

Command (m for help): q

    Here we use the “p” command to list the partition table, and “q” to quit. The key bit of information we are looking for are the number of cylinders, heads and sectors per track (22506, 84, 62). For the number of cylinders, we need to subtract the number of cylinders used by the first partition … or perhaps easier the value of the cylinder that the second partition starts on (13). This gives the values we use for mformat to format the filesystem.

    Next we need to create a “drive letter” (!! – why doesn’t mtools allow you to specify a device to work with in the proper Unix fashion?) by editing /etc/mtools.conf and adding a line at the end like “drive z: file=”/dev/sdh2″”.

    Finally we need to use mformat to create the filesystem :-

    mformat -t 22493 -h 84 -n 62 -S 4 -M 2048 -F -v FATBOX -N deadcafe z:

    The “-v” and “-N” options are unnecessary, but at least the “-v” option is kind of handy to allow the iPod to be automatically mounted in an appropriate place. And I usually take every opportunity to assign some funky hex value 🙂

  • Gender Differences In Photography

    I have just read this article on whether men and women take different photograph. Without going into too much detail, the overall impression is of confusion with some people saying yes and others no.

    This is going to be very short. Whilst there may be gender-based differences in the way that we make photographs, these are likely to be overwhelmed by the simple differences between us that are down to us all being individuals. Most of us are far too keen to jump on the obvious differences (gender) and assume that these explain everything.

    Or to put it another way, why did Robert Capa and Henri Cartier-Bresson make images that were so different when they are both men ? That’s right, because they were individuals and so was Gerda Taro. That she was a woman adds to her individuality, but being a woman didn’t make her any more of an individual or any less of an individual than Robert Capa was.

  • MSN Robot Has A Bug ??

    So a few days ago I was idly looking at the “StatPress” page on my site to look how few people were visiting to see something rather surprising :-

    Graph of accesses

    What was happening here ? Have I been slashdotted ? Is my income from those silly ads down the side going to shoot through the roof to a level worth letting a certain company send me the payments ?

    No. Nothing so exciting. All (well, the overwhelming majority) were from an MSN robot – presumably indexing this site. Well fair enough, but why so many accesses ? It is not as if my site has much on it – nowhere near the nearly 100,000 page fetches they tried. A closer look at the Apache logs shows that the msn robot repeatedly fetched many pages including one page 1,300 times!

    Sounds like Microsoft has a bug somewhere.

  • Creating A Date-Based Photo Repository & Examining Results

    Because of a little “issue” with Bibble which causes that software to cease responding when navigating the browser whilst it is updating the icons, I had to come up with a different way of storing my raw images. Or at least a different “shadow view” that would allow Bibble to work more reliably. I had been thinking on what would be the best way (for me!) of doing this for a while now, and this morning spent about 45minutes knocking up some code to do what I wanted.

    I chose to use the “date” contained within the Exif information within each file to produce a directory structure along the lines of “/some/place/YYYY-MM-DD/original-name-of-file” with the file at the bottom level being a symlink back to the original file. I chose not to move any files around as I could more easily fix things if the code I had written did Something Stupid. I chose not to copy any files, as I did not want to duplicate some 100Gbytes of RAW files if I did not need to — and I did not as symlinks can do the job perfectly well.

    As for the choice of the date format, well I have long preferred the ISO date format in places where a conventionally human readable date was not necessary or would be inconvenient. The ISO date format is useful in that it is not subject to misinterpretation as date formats such as “DD-MM-YY” and “MM-DD-YY” are, and it happens to sort easily with the ls command – which is much more useful than you would think. If it looks a little odd, just start using it and get used to it.

    The code itself is available here if you really want to get hold of it (I wouldn’t bother if I were you – it’s just something knocked up in a rush that works ok for me).

    The interesting thing about the new “repository” was that it was easy to produce a table of dates and the number of photos taken on those dates :-

    cd /media/photos/raw.dated
for i in $(echo *)                        
do
  echo -n "$i "; ls $i/* | wc -l
done

    The output is long enough and boring enough (for anyone other than me) that I will not include it here. But it is relatively easy to turn this into a graph using ploticus :-

    ploticus -prefab chron \
  -o photos.png \
  -png \
  data=dates.dat x=1 y=2 \
  datefmt=yyyy-mm-dd \
  color=blue \
  echodata=no \
  xinc='1 year' \
  stubfmt='MMM YY'

    This produced a graph similar to :-

    Photo Frequency

    I seem to be taking more photos over time.