Contrary to any bitching you may hear from me, I actually like PDF's.
Adobe Reader is a different matter though. I dispise Adobe Reader. I
despise it with a passion I normally hold for people trying to sell
jewelry by informing me my wife will love me more if I spend more money
on jewelery (and how they will be happy to explain their financing
options). Today I bring up the first of what I expect to be many
pieces on user abusive decisions made by Adobe in Adobe Reader 7.
This version added Javascript as a scripting language. The
scripting and programming available in previous version of Reader
weren't easy enough for value
added
enterprise solution providers apparently (more on them here). I have a great dislike
and distrust for
javascript.
This is of course because of the evils that have been perpetrated upon
webusers by any number of websites. As such I have Javascript disabled by
default in Firefox and Internet Explorer. Following that trend, I simply
disabled Javascript within the Preferences.
I did this immediately after turning off automatic updates, which is
something I do immediately after installation of Adobe Reader. Upon
closing the program I was greeted with
Figuring this was a one time warning I ignored it. But no, I get this
message each and every time I close Reader. If I open a document that I
know to not have javascript I get this message upon exiting the
program. Even if I open the program, don't open a pdf, and close the
program, I am still informed that "This Document contains Javascripts".
The correct thing to do would have of course been to warn the user on
load that a PDF had Javascript in it (and not present any warning if the
document didn't have Javascript in it) and advise that it might be needed
to view the document "properly" (where properly means according to the
ways set forth and desired by the document creator). Or maybe they can
learn from the mistakes made by Microsoft with macros in Office and warn
users to not enable Macros (Javascript in this case) unless the document
came from a trusted source. Whether or not that would be worthwhile is a
discussion for another time.
Part of my job entails making sure that we are in compliance with the
licenses for the software we use. While not a difficult task, it is
tedious and quite dull at times. Reading that much leagelese when one
is not employeed as a lawyer or paralegal can not possibly be good for
one's sanity. .
In most instances the issue for us has to do with us what is required
to allow us to have concurrent licenses. Usually it is simply a matter
of running a license server. Some involve stipulations that require the
software run off of a file server. Those are hurdles that can be
overcome without too much difficulty.
We use a good number of free (as in beer) programs, including a
handful from Sysinternals.
Most free software has limitations such as; a license is required for
commercial use or the software is free for instructional use but not
research use. Sysinternals however has some very interesting
restrictions for their software.
The license
from Sysinternals starts off saying anyone can use Sysinterals tools for
home or work so long as the user downloads it from the Sysinternals
website. This sounds like you aren't supposed to provide a mirror of
their installers. It goes on to state quite explicitly " A commercial
license is required to redistribute any of these utilities directly
(whether by computer media, a file server, an email attachment, etc.)".
I guess that means I shouldn't have it on our administrative file
server.
A quick email to the supplied licensing address came back with a
response that I almost couldn't believe. Their response was quite
clear; (paraphrased) "We aren't interested in the hassle for licenses of
less than $1000."
A thousand dollars is quite alot of money for my lab. I sent a reply
to the email clarifying the conditions we wished to use the software; We
wanted to keep copies of the programs on a file server for use by three
staff members to be used in troubleshooting and debugging. The answer
to that email was again quite clear in stating that we would require a
license for this suggested use and that the minimum license is $1000.
Instead of having the programs on our file server, I have a series of
scripts that when run will download the software, install it, run it,
and once exited delete the software. I wouldn't have blinked had they
asked for a one time license fee of $150. I would have blinked but not
really hesitated had they asked for a one time license fee of $250.
They probably could have gotten away with asking $400 even. Their tools
really are that useful to us. This way however instead of getting some
money from us they got none.
How many times have you rebooted a server thinking you were on one machine when in reality you were on another? Or have you ever been looking for something that you just know is on the server, but you can't find, only to find you are not on the server you think you are on. This is actually a problem when you are connected to servers remotely, or are working through a kvm.
Under unix, I rarely had this problem as I set my prompt to include the hostname (Checkout the Bash Prompt HOWTO for more than you probably want to know about prompts and bash). This unfortunately doesn't help me under Windows, which most of my servers are.
My first thought was to simply use a different background on each system. With just different pictures or patterns it wouldn't scale well. I clearly needed to create a custom bitmap with the name of the computer and set it as the background. I never did get around to doing anything about that.
This morning, while at a VMWareUsers Group Meeting, I saw what looked like a perfect solution to my problem. A program that displayed basic system information on the background. It turns out the program is cooler than I had thought.
BgInfo provides a simple way to autogenerate a custom background image. By default, it runs once and creates a custom image that is than set for the background. What is displayed in the image is highly customizable. There are a bunch of default options like cpu type, hostname, ip address, but it can also display information from a script, a text file, or the registry.
I was lucky to be shown in college how important documentation is to a project. The course was on operating system design, the project involved writing a simplistic operating system. The real challenge came from the fact that we would be working with code that had been created and worked upon for over 3 years by students in past iterations of the class.
The first year I was in the job, I learned a good deal about how well I document things. Which is to say, I learned that when making small changes and doing systems maintance it is really hard to take good notes and make proper documentation. In a class where the documentation was part of the grade it wasn't very difficult to make the time to do it. In the real world I found that unless documentation is really easy to add/update it won't be done. Conversely if the documentation that is not readily available may not be consulted until one's head has met the desk at least once. I needed to do something that would encourage me to use and write and update documentation more frequently.
What we had: When I started, all of the records were in a file cabinet. It was pretty cool actually. There were several hundred files in three drawers. There was a folder for each server, hardware purchase, software package, and such. I could often be experiencing a problem with a software package or a server or a piece of hardware, pull the folder for it and find hints about my immediate issue.
Goal: I needed a consistent and easy to follow procedure that would enable me to write how-tos, working notes, change logs, and whatever other documentation was needed. It would need to be viewable by others (limited by user or group permissions) and if possible edited by others as well. It needed to be searchable. It would need to be able to handle images. Perference would be given to a solution that didn't use a database and wasn't difficult to setup.
Implementation: It didn't take long for me to decide that this was an obvious candidate for a wiki was the way to go for this. Perusing a fewlists of Wiki Engines, I settled on PodWiki. It had user and group permissions with which I could restrict view and editing access to sections, didn't use a database, had revision control built in, could handle images easily, and it had a simple install. It was installed an up and running within an hour.
Actual results: Having used my little wiki (which others at my job don't actually know about yet) for nearly three months no, I can say I am quite happy with the results.
