Preserving Permissions on USB Flash Drives

If you run a Linux/UNIX-like operating system, you will no doubt like the file-level security that exists. If you save files on a USB Flash Drive, then you will probably want to make it more difficult for you to change by accident certain files that are on a USB Flash Drive and this is where UNIX-like file system permissions come in to play.

Taking into account that the files can always be copied, if you want to make it effectively impossible for people to read files that are on there, you should also use some form of encryption.

By default, these drives come formatted with one of the FAT file systems. This means that they can be read and written to on virtually any Personal Computer, whether it is a PC running Windows, a PC running any of the flavours of Linux/BSD/UNIX or even a Mac. However, there are several subtle disadvantages:

• FAT doesn't know what permissions are so you can find that some users have ownership rights assigned to them as in the screenshot above-right ('gecko' owns the files but under the FAT partitions, 'paul' has become the owner because 'paul' is the current user - just unplugging the drive, opening up another account and reinserting the drive is guaranteed to change things like this and you might find that you don't even have to take out the drive to achieve this on some systems);
• FAT doesn't know which files are executable so, you could end up with a program that you don't want to run being run, because all files under FAT are marked as executable by the system (Windows goes on the file extension which is completely insane); and,
• With FAT, there are only 26 letters of the alphabet. Therefore, if you have two files: one called 'Index.html' and the other called 'index.html', the later one that is written to the directory will overwrite the former one (theoretically, there are 512 possible index.html file names with capitalisation in all of the variations such as 'index.html', 'inDEX.hTMl' or 'InDex.HTMl' which FAT sees only as one file name).

So, how do we get around these inflexibilities? The answer is that we can format the USB Flash Drive with a UNIX-like file system such as ReiserFS (this also has the advantage that it is a proper journalling file system).

Our USB Flash Drive - being a serial device - is in '/dev/sdc' and has a FAT32 partition in '/dev/sdc1'.

We need to get rid of this, replacing it - for the purposes of this tutorial - with a Fat32 partition and a ReiserFS partition.

So, make sure that the existing Fat32 partition is highlighted and then click on 'Delete'.

If you are sure that you have selected the correct partition, click on 'Yes'.

Next, we have to put some partitions on it.

In this case, it is '/dev/sdc'.

In the 'Format' frame, we need to select our file system - as there are no file systems on the partition yet, the 'Format' radio button is already set.

Select 'FAT' from the list - you can see that there are a number of file systems that you can choose from: some journalling and some not.

Again, we select no mount point.

Light-weight Paper

Cheap, supermarket paper is a God-send if you have children using your printer all of the time but its quality can vary between 'very good' and 'execrable': sometimes it feeds and prints beautifully and other times ... well ... forget the ink bleeding through it, you can read a newspaper through it (yes, you really can).

By definition, a sheet of DIN A4 paper is 1/16^th of a square metre. The standard is that A0 has an area of 1m² and has a ratio of short to long side lengths of 1 to the square root of 2 (1:1.414). If you then slice an A0 sheet in half, it now has a ratio of 1:0.7071. If you invert it and multiply it by 1.414, you get 1:1.414 again. This means that you can slice it in half any number of times and you always get the same aspect ratio.

To find the area (in square metres) of a sheet of DIN A paper, the area = ¹/₂x where x is the number of the paper so, for A4, ¹/₂x is the same as ¹/₂4 or ¹/₁₆m².

Paper is sold as a certain weight per unit area - usually 80GSM which means that one square metre weighs 80 grammes. So, if we know the weight per unit area of the paper and the area, we can work out how much it should weigh.

Nowadays, a ream is 500 sheets so ⁵⁰⁰/₁₆ = 31.25 m². If you multiply this by the weight for a square metre (80 grammes), you get the weight of a ream which is, for 80GSM, 2.5kg. For 70GSM, it is just under 2.2kg.

Normally, you would find 80GSM but card is usually 120GSM (or even heavier, depending upon your intended purpose) and 'Bank' paper is 40GSM (this is really light and used for typing records on where you have a lot of records to keep using as little weight of paper as you can get away with). You can also get 75GSM and 70GSM which have advantages if you are putting manuscripts through the post as every gramme saved works out cheaper in postage.

So, when is 80GSM paper not 80GSM? Arguably, you could claim that if it worked out at 75GSM, it wasn't within the 80GSM range any more but quite a lot of the weight of paper is actually water and if you keep paper badly - in too dry an environment for too long - it can lose water and therefore weight. As an experienced paper purchaser myself, I would argue that if a ream of 80GSM clocked in at 2.2kg, it was well out of range and should be called 70GSM.

So, if you are thinking of buying some cheap, supermarket paper, get a ream of it and weigh it on one of the sets of scales in the fresh veg section or get one of the cashiers to weigh it at a spare checkout.

Paper is effectively sold by weight so if your ream of 80GSM paper weighs in closer to 70GSM, it is a Weights and Measures issue that needs to be addressed as it could be construed as 'passing off'.

Sendmail in programs - Sending mail from programs

The screenshot on the right shows a typical session. First of all, you call it using its full path (which is normally /usr/lib although it can be in other places) and then, use the 'From:', 'To:', 'Subject:' and any other lines you need ('Cc:' and 'Bcc:' for instance) and then, leave a blank line (if you use the '-t' switch: see 'man sendmail' on the command line or click here man://sendmail for more details).

Next, you type in your message and then, when you have finished, you put a full stop on a line on its own (nothing before or after it) and then press [Enter]. Sendmail then sends the email for you.

You can see that exactly the same thing happens.

So, we know that we can send emails using it and that it is interactive but how do we send an email from within a program?

#!/usr/bin/perl
use warnings;

# This demonstrates how to get one of the methods of how to get your
# programs to send emails to you. You might want to do this if you
# have a daemon that monitors something and needs to get in touch
# with you - perhaps sending a report automatically on a daily basis.

# Let us assume that we already have the message that we want to send
# from the rest of your program in the following scalar:

$content = "Put the text from your program in here - you could just
have this string end here and then concatenate your report 
or message to it in another line of code. There is more 
than one way of doing it.\n";

# The rest of this program should be static as the only thing you are
# going to get the program to do is to change the above message.
#
# Start off by creating the message in the $msg scalar.
#
# Note that you need to have a 'From:', a 'To:' and a 'Subject:' line.
# You can also use 'Cc:' and 'Bcc:'
# Next, you need to leave a blank line and then your message.
# With sendmail, you can use the '-i' switch when inputting from a
# program because sendmail will know when the end of the file is. Otherwise,
# you need to have a dot on its own as the only character on the line to
# signify the end of the message (in the same way that you would if you
# were using sendmail from the command line.
# 
# Note that we are using 'EOF' to terminate the string. You can use
# anything - especially if it is likely to crop up in your string
# anyway. Remember that this will be computer generated so you don't
# need to interact with it once you have written it - you just need
# to be able to make sense of it when you need to edit it - such as
# if you change your configuration.
# Note that the @ characters have to be escaped because this is
# equivalent of using "" rather than ''

$msg = << "EOF";
From: Monitoring daemon <yourname\@yourisp.com>
To: your name <yourname\@yourotherisp.com>
Subject: daemon daily report

EOF

# Next, add the message to the header
$msg .= $content;
# Unremark the following two lines if you want to check that the
# string that the program is producing is working all right.

#print $msg;
#exit;

# next, open up sendmail and send it the string. Note that you might have to
# change the location of sendmail if it is in a different place.
# If you want to change the options that you send to it, look them up on your
# system by using 'man sendmail'.

open (SM, "|/usr/lib/sendmail -t -i");
  print SM $msg;
close (SM) or warn "Sendmail sent a warning.";

# and that is it. If you take out all of the comments, you have a nice
# little program fragment that you can add to your own work and increase
# its functionality.

open (SM, "|/usr/lib/sendmail -t -i");
  print SM $msg;
close (SM) or warn "Sendmail sent a warning.";

By opening sendmail - complete with any command line arguments that it needs such as -i so that it looks for an EOF rather than a '.' - as a pipe, we can print to it and when we close it, we effectively send it the EOF that it is looking for.

Although this is in Perl, it is easy enough to translate it to any other programming language.

Sub-Pixel Hinting a.k.a. Cleartype(tm)

Sub-pixel hinting has been around for a while but only recently has the price of flat-screen monitors come down so that a substantial proportion of the user population can enjoy them.

So, how good is it really? In Microsoft's press release (Autumn 1998), it stated 'ClearType improves display resolution by as much as 300 percent and works especially well on existing LCD devices, including desktop flat panels, laptops and smaller devices such as Handheld and Palm-size PCs.'

Okay, so Microsoft's PR people don't know how to do the maths because a 300 per cent improvement would mean it was 4 times as good but, as you will see below, it could, at the most be only 3 times as good, hence an improvement of resolution by 200 per cent. So, taking that into account, can it be three times as good?

• One problem is the fact that the red and the blue are not perceived as being as bright by the eye which means that they cannot produce a sub-pixel effect that is as good as the green sub-pixel. Very roughly, the perceived brightness of red added to that of blue is around that of green so there goes another 100 per cent.
• Often, you'll see sub-pixel hinting examples where the lines in the original are all 1 pixel wide so that there is no colour cast added to the line when the line is hinted. In reality, one-pixel-wide lines do not happen with any great frequency - especially with fonts - so you will most likely see added colour casts to your letters. Vertical lines such as those in 'l's, 'I's and 'T's, and even the shorter lines in 'm's, 'n's and 'p's will generate a cast that is uniform along their length so you might end up with a 'T' with a red or blue vertical line.
• Also, even on a flat-panel monitor, the text is quite often blurry when it is sub-pixel hinted.
• In addition, your graphics card is now processing three times as many 'pixels' as it was - a 1024x768 display now has the dimensions 3072x768 pixels so it is more processor intensive (even if it is your graphics processor, it is still your electricity bill).
• As straight characters often fall foul of sub-pixel hinting casts, italics are where sub-pixel hinting really works well. If you only view italic print then this is for you.
• The Windows version only supports (on XP Home) horizontal sub-pixel hinting so if you are using a TFT monitor that you can rotate through 90 degrees so that you can do DTP more efficiently, you are not supported.

So, does it provide a '300 percent increase in image resolution'? in a real life environment, 100 percent is probably as much of an improvement as you will see and then only if you are completely colour blind (so that the colour fringes don't irritate you).

Look at these two examples...

How Sub-Pixel Hinting Works

The cells are so tiny that you would be convinced that they were square.

This is, in effect, an example of sub-pixel hinting (well, shifting stuff around the screen by amounts smaller than a pixel) because the red displays a third of a pixel to the left and the blue displays a third of a pixel to the right, hence the gap being smaller.

You can see that it mimics the real screen that is shown above.

You can see that we are asking for a hopelessly large amount of detail to put in there but in reality, you wouldn't expect much from a small letter like this as long as the shape made sense in context - a lot of reading is recognising the overall shape of a word rather than identifying each letter individually.

Whilst the colours in the image on the right might seem to be utterly wild, a blue next to an orange will, at the pixel level cancel out to make a grey average over two pixels. However, on the sub-pixel level they are two dark sides of adjacent pixels.

If you look at the actual-scale image of the 'y' below, you can see that the colours have largely disappeared.

It is when they do not disappear that they can be an annoyance.

If you compare the two, side by side, they look like this (pixel, then sub-pixel) - .

If you have a TFT monitor, you will be able to see that the sub-pixel hinting version is a lot clearer if you ignore the peculiar colours that you sometimes get.

Adding/Removing Sub-Pixel Hinting - Windows

This is done on the default (SP2) installation of Windows XP home without any plug-ins or toys.

If you want to try out sub-pixel hinting on a Windows XP machine, this is what you need to do...

If you had the other type of Control Panel display, you could have got to this stage just by clicking on Display.

Next, select the 'Appearance' tab and then, click on 'Effects...'.

Next, click on OK

Before (without)...

You can see that the contrast is greatly reduced and that there are some chromatic aberrations around the letters. It's a bit like looking at it through a dirty lens.

You can see that just about every vertical has been extended into the pixel on the left (the red line of pixels up the left) and is an example of poor font placement. This has the effect of smudging it.

Adding/Removing Sub-Pixel Hinting - Linux/KDE

Like Windows XP above, this is done on the default installation of KDE without any plug-ins or toys.

(Yes, this is on KDE 3.1 (this was part of the default installation at least that long ago) and we are now on 3.5.2.)

Note that you have four types:

• RGB and BGR cater for normal flat panel screens; and,
• Vertical RGB and Vertical BGR cater for vertical screens so that: if you are using either a flat-panel monitor for DTP and have turned the screen round by 90 degrees (to the left or the right - it doesn't matter as you have RGB and BGR in the vertical option); or, if you are using a small computer with a vertically oriented screen - say for reading an electronic book, you can do so.

You can see that the font placement is a lot better than in Microsoft's version. The contrast between the vertical bars and any adjacent smudging is far greater so any smudging is only minimal - this is largely down to the choice of a better font and better font placement to start with.

With other fonts at the right (wrong) size, the effect is just as psychedelic as in the Microsoft version. However, if you do want it, you can - with the KDE version - use it with any flat-panel display regardless of orientation.