I've done this for years, works great, no risk to the keyboard:
A couple of sprays (mist, not stream) of Formula 409 on the keyboard (I've found Formula 409 works the best). Let the cleaner sit for a 30 seconds to a minute or so. Then take a brush like you'd use to clean your fingernails (short, hard bristles) and use it to scrub the keys, being sure to get in-between them. Then wipe up the mess with paper towels, being sure to get as much of the cleaner out as possible. Repeat process as needed (I've had some keyboards take 3 or more tries to get really clean).
Let's say I search your database for Author = "Clemens, Samuel Langhorne"? Probably wouldn't hit anything. Now, do that search in the LOC authorities website I posted in my original post.
I see in your database that you don't support subject searching. That is another "controlled language" area that is very important. What if I wanted all items that dealt with, say, gay rights?
Like I said, cool idea, but check out some of the free librarian driven software packages that do this same thing, like www.koha.org.;)
There's a reason that professional librarians go to graduate school to learn how to do essential "librarian" things like cataloging. Any database of this nature will collapse in on itself and be completely useless without things such as language control. This is another case where a techie with a really good idea should first consult with a professional librarian before trying to re-invent the wheel.
Why don't you delete it as soon as the book is returned?
1. Troubleshooting. We circulate millions of items, and "stupid" problems occur. I keep records for this time period because most problems will crop up in that time period. Our typical item's circulation period is 2 weeks. It is much easier to fix problems with footprints.
2. Usage statistics. Libraries live and die from statistics. It is how we justify our funding, assign staff, and determine what hours we are open. We need time to extract data (yes... non-identifying data).
Is there from the server end? If so, why?
We track who uses what system. These records live the same amount of time as normal circulation records (30 days). We have people who abuse their computer privilages (we've had many cases of spam and hate mail). We use these records to determine who did what. Again, these problems usually surface in 30 days. And, again, we need usage statistics.
Not against the FBI. For them the centralization is just an added convenience.
You are sure confident in my (and my cohorts) lack of ability. It only takes about 3 keystrokes to misplace a log file. And we've been having alot of problems with those back up tapes lately.
First, I am a systems librarian. I run the central "materials management" server for a public library consortium, so I believe that I can add a few things to the discussion here.
First, it is important to mention that privacy and the right to information is very important to librarians. All professional librarians have at least a master's level degree; we receive in-depth training and education in privacy laws, ethics, and technology. Yes, slashdotters, I am a professional librarian, but I am also run an E10K.
A librarian will be the last person to give any private information of any sort. We fight internet filtering just like we fight the people who want to remove those "blasphemous" Harry Potter books from the library shelves. It's just a part of our profession.
With that said, I can tell you what we are doing, and maybe calm some of the fears of the original poster. The practices that I use in my system administration are very common, and are widely used. First, all of our "private" information is stored on the central server. We do not keep any identifying data on the server past 30 days. This is a very common practice... we've done it this way since coming off the old card catalog (as do most public and academic libraries).
As for any information stored on the public access computers-- there is no way to tell who used what computer on the client end. Again, the usage records are all centralized and secure. Furthermore, I know that most of our branches do maintenance routines to clear the workstations' cache and such. Some branches even go as far as reloading the entire hard drive each night ( actually removing the partition, and starting again from scratch from a image).
So, there is no need for an "anonymous checkout system" or anything like that. We're handling this job just like we've been handling it since Egyptian times... and John Ashcroft does not scare us. Much.
You know, instead of posting this question to slashdot, you should of consulted your friendly local reference librarian, who would of consulted your local systems librarian (who is probably chained up somewhere in the server room). That is their job, afterall.
It's good to see such a strong response from the community and we thank everyone that has given us constructive feedback. However, we feel that many of you have completely missed the purpose of the article.
The purpose of the article is NOT to compare OSs, get fast SETI@home times, or even to optimize the systems at all. We thought this was clearly stated in the abstract and methodology sections. Either we screwed up and did not make this apparent or people did not read the article. The study of optimizing systems and making SETI@home faster is already handled very well by Team Lamb Chop (if the site ever decides to come up...).
What we DID want to accomplish is to study work unit completion time VARIATION. This question was prompted by our reading of the SETI literature which had not dealt with this matter. Our research question was: on a "typical" system, how much does the completion time vary from instance to instance? If I run the same work unit over and over, how much will my completion time vary? I don't know about the rest of you, but when I run SETI@home on my systems, I do not disable all other processes (including cron or anything else). If we did disable anything out of the ordinary, then we did not accomplish our goals. As was clearly stated in the methodology section, we used the default settings for each OS.
A separate question was the method used for us to arrive at this conclusion: testing several OSs in several configurations on the same platform. At this time, this method seems a useful one for comparing configurations.
Now that we have a baseline, we are going to continue and try to figure out the questions posed in the article. Such as: why does Linux have such a high variance in comparision to the other OSs? We have collected many great suggestions and I will test all of them and post the results.
In any case, this article cannot be used to compare OS to OS performance. Not only is that not the purpose of the article, but there are too many confounding variables--many of which have been raised here.
Slashdot Mirror
One switch to rule them all...
Cannot RTFA. It hurts too bad.
Something is either unique or it is not. It cannot be /rather unique/.
I've done this for years, works great, no risk to the keyboard:
A couple of sprays (mist, not stream) of Formula 409 on the keyboard (I've found Formula 409 works the best). Let the cleaner sit for a 30 seconds to a minute or so. Then take a brush like you'd use to clean your fingernails (short, hard bristles) and use it to scrub the keys, being sure to get in-between them. Then wipe up the mess with paper towels, being sure to get as much of the cleaner out as possible. Repeat process as needed (I've had some keyboards take 3 or more tries to get really clean).
I think you missed what I was saying. :)
;)
Let's say I search your database for Author = "Clemens, Samuel Langhorne"? Probably wouldn't hit anything. Now, do that search in the LOC authorities website I posted in my original post.
I see in your database that you don't support subject searching. That is another "controlled language" area that is very important. What if I wanted all items that dealt with, say, gay rights?
Like I said, cool idea, but check out some of the free librarian driven software packages that do this same thing, like www.koha.org.
There's a reason that professional librarians go to graduate school to learn how to do essential "librarian" things like cataloging. Any database of this nature will collapse in on itself and be completely useless without things such as language control. This is another case where a techie with a really good idea should first consult with a professional librarian before trying to re-invent the wheel.
"..and all I could think about was Carolyn still had my casserole dish..." --Jeff Foxworthy, talking about rednecks and tornadoes...
Atlanta's traffic Sure it is not in pretty flash, but is is much more extensive.
1. Troubleshooting. We circulate millions of items, and "stupid" problems occur. I keep records for this time period because most problems will crop up in that time period. Our typical item's circulation period is 2 weeks. It is much easier to fix problems with footprints.
2. Usage statistics. Libraries live and die from statistics. It is how we justify our funding, assign staff, and determine what hours we are open. We need time to extract data (yes... non-identifying data).
We track who uses what system. These records live the same amount of time as normal circulation records (30 days). We have people who abuse their computer privilages (we've had many cases of spam and hate mail). We use these records to determine who did what. Again, these problems usually surface in 30 days. And, again, we need usage statistics.
You are sure confident in my (and my cohorts) lack of ability. It only takes about 3 keystrokes to misplace a log file. And we've been having alot of problems with those back up tapes lately.
*sheesh*
First, I am a systems librarian. I run the central "materials management" server for a public library consortium, so I believe that I can add a few things to the discussion here.
First, it is important to mention that privacy and the right to information is very important to librarians. All professional librarians have at least a master's level degree; we receive in-depth training and education in privacy laws, ethics, and technology. Yes, slashdotters, I am a professional librarian, but I am also run an E10K.
A librarian will be the last person to give any private information of any sort. We fight internet filtering just like we fight the people who want to remove those "blasphemous" Harry Potter books from the library shelves. It's just a part of our profession.
With that said, I can tell you what we are doing, and maybe calm some of the fears of the original poster. The practices that I use in my system administration are very common, and are widely used. First, all of our "private" information is stored on the central server. We do not keep any identifying data on the server past 30 days. This is a very common practice... we've done it this way since coming off the old card catalog (as do most public and academic libraries).
As for any information stored on the public access computers-- there is no way to tell who used what computer on the client end. Again, the usage records are all centralized and secure. Furthermore, I know that most of our branches do maintenance routines to clear the workstations' cache and such. Some branches even go as far as reloading the entire hard drive each night ( actually removing the partition, and starting again from scratch from a image).
So, there is no need for an "anonymous checkout system" or anything like that. We're handling this job just like we've been handling it since Egyptian times... and John Ashcroft does not scare us. Much.
You know, instead of posting this question to slashdot, you should of consulted your friendly local reference librarian, who would of consulted your local systems librarian (who is probably chained up somewhere in the server room). That is their job, afterall.
It's good to see such a strong response from the community and we thank everyone that has given us constructive feedback. However, we feel that many of you have completely missed the purpose of the article.
The purpose of the article is NOT to compare OSs, get fast SETI@home times, or even to optimize the systems at all. We thought this was clearly stated in the abstract and methodology sections. Either we screwed up and did not make this apparent or people did not read the article. The study of optimizing systems and making SETI@home faster is already handled very well by Team Lamb Chop (if the site ever decides to come up...).
What we DID want to accomplish is to study work unit completion time VARIATION . This question was prompted by our reading of the SETI literature which had not dealt with this matter. Our research question was: on a "typical" system, how much does the completion time vary from instance to instance? If I run the same work unit over and over, how much will my completion time vary? I don't know about the rest of you, but when I run SETI@home on my systems, I do not disable all other processes (including cron or anything else). If we did disable anything out of the ordinary, then we did not accomplish our goals. As was clearly stated in the methodology section, we used the default settings for each OS.
A separate question was the method used for us to arrive at this conclusion: testing several OSs in several configurations on the same platform. At this time, this method seems a useful one for comparing configurations.
Now that we have a baseline, we are going to continue and try to figure out the questions posed in the article. Such as: why does Linux have such a high variance in comparision to the other OSs? We have collected many great suggestions and I will test all of them and post the results.
In any case, this article cannot be used to compare OS to OS performance. Not only is that not the purpose of the article, but there are too many confounding variables--many of which have been raised here.