Mike has a working real time raytracier. The
real time raytracer is handling >5000 solids
at this time, rendering at ARL and then transmitting the results via ATM to other
research labs.
The last major milestone for the BRL-CAD was
raytracing a scene with over 3,000,000,000 solids.
Yes, that is 3 billion.
The license agreement is not "Free" as in beer or "Free" as in "Freedom." You need to sign a simple license and fax it to ARL. They send back the license agreement with a password. Download the program and have fun.
I've been writting CGI scripts from about the time HTML 1.0 was first introduced. I've written in C, C++, Perl, PHP3, sh, and in apache's SHTML languages. Each has it's good points and each has its bad points.
C - The choice of an old generation. Fast. Once you have a CGI application written in C you will know what fast is.
Downside is that the development time for the infrastructure is huge. C isn't designed for string processing. Even REs are harder to do in C. My 2nd to last choice in CGI programming.
C++ - All the hardaches of C plus the anguish of C++. My last choice for a CGI langauge.
Perl - Ah perl! Easy to write a script, nice tools built in for dealing with input streams and tainted variable detection. With the current Perl modules for CGI interfacing and HTML/HTTP output it has gotten to the point where Perl is even easy to debug.
On the downside it is a programming language first and a web design langauge 2nd. It also has a serious limit in that it often takes longer to compile to byte code for the run time engine than it takes to run the script. Startup times on largish scripts can be huge. Somewhat solved by embedding Perl into your web server. All in all, my 2nd choice for a CGI Language.
sh - Good old Bourne Shell. Just don't do anything with it and it will work fine. On the downside, security doesn't exist. On the upside, you can do something in 30seconds.
PHP3 - This IS my choice for a CGI langauge. With MOD_PHP it is very fast. Reliable, good error messages, good database interfacing, good interfacing to web object generation packages (libgd, libpdf, libmhash...) In addition, it is a language that can be embedded into your HTML document. Something powerful about <? $info = mysql_fetch_array($result);echo "His name is $info{'name'}"; > being all it takes to get the results of a SQL query into a web page.
On the downside? It is another langage, sometimes I don't have a standalone PHP interpreter to do testing with. My favorite CGI lanague.
SHTML - A very simple language addition that has almost no power and is a pain to use. Mostly used when I want to have different pages for different browsers. Not worth mucking with.
Summary: PHP for almost everything, Perl for the rest, C/C++ if you must, stay away from shells.
Chris
On the downside? It is another langage, sometimes I don't have a standalone PHP interpreter to do testing with. My favorite CGI lanague.
I am a ProAm photographer and lust after a good digital camera. The problem is one of what makes a digital camera "good"?
The criteria that are commonly used seem to be:
Number of pictures that fit on the media
The size of the captured images.
The ease of transfering images from camera to computer.
The quality of the captured Image.
The size of the captured Image.
Quality of the camera.
Quality of the Lens
Ease of control of the camera.
I have one lens for my 35mm that I payed almost 1K for. If you look at lenses for 35mm cameras you'll find the prices range from a few hundred dollars to many thousands of dollars. It is hard to look at a camera that costs less than $300.00 and even consider the lens to be reasonable.
Each person judges their needs and makes a decision based on those needs. My brother wanted "webshots." For him a Sony which compresses everything like mad and has 640x480 sizing is just fine. For me it doesn't come close.
My friend wanted a digital and used 3 before he picked his favorite. He choose the Nikon CoolPix 950. (The current Nikon is 990). For him quality was the name of the game. The size had to be 1280x1024 or larger. The compression had to allow for NO compression. I.e A raw TIFF file. And the "Hi Quality" setting is only 4:1 compression JPEG. Very usable.
The other day I took some pictures of a personal event. I ended up with about 16 pictures, all of them head shots. After the film was developped and I had scanned them for the web it turned out that we wanted some close ups of an earing. With just the original scan I was able to do a close up of the earing without upscaling or generating any data that was not already there. And my film scanner isn't the best there is. It only does 30bits of 2000+ by 3000+ pixels.
So to determine what the "best" digital camera is requires a good understanding of what the user wants to do and how they plan to use their images. If you want to be able to just move floppy disks with "Webshots" from your camera to your computer for uploading, pick a Sony digital camera. If you want higher resolution, you need something like the CoolPix 950 from Nikon. Or if you want the real thing you can pick up a Kodak DCS660 for only $20,000.00. That actually does 2k by 3K with 36 bits.
Pick what works for you, just take the list there at the top and rank those things that are important for you. "Webshots" or "Artprint" it makes a difference as to what camera features you need.
The wonders of back ups. I've been dealing with backup requirements for large and small shops for years now and it is always hateful.
In 1980 I worked for Michigan State University Computer Center. They had a backup plan that seemed to work pretty well. They did nightly change dumps. This normally took one to 5 reels of 2400ft 6250 tape. We had about 200 reels in our library and the backup system just went through the pool of tapes in a FILO order. This gave us about 2 months of partial backups. Every Monday we did a full dump which took about 20 tapes. These were kept for a year.
Now the neat thing was that at the end of each term, the computer center took that full backup and sent it offsite for storage. For 5 years. This was designed to make sure that every student's project survived if needed.
The computer science instructors knowing when the offsite back up was made worked with that knowledge in mind. They made sure that all projects were due at least a week before then. They then very carefully wrote the student files to a personal tape and then DELETED all the student files. Thus ensuring that student files never got long term backups...
When I went to work for a government site, they to did backups in a simular way (And still do). Doing full backups one a month (dump -0u), partial backups everyday (dump -2u), and weekly (dump -1u) once a week. This was done to IBM3480 tape carts.
At that time I was working on BUMP which later became Cray's Data Migration Product. This is a virtual filesystem. When a file is selected for migration, it is moved (equivelent of hardlinked) to a backup directory and from there writen to tape. The hardlink is deleted and the INODE type is changed to MIGRATED with the datapointers now holding a DB reference key. When you want the file back you just open() the file, the open blocks, the OS sends a request to a daemon which requests the tape and reloads it into the "backup directory" the hardlinks are remade and then the file in the backup dir is unlinked.
Complex but it works, the BUMP code is available for free at ftp.arl.mil. It is a set of patches to BSD 4.2. It ran on Cray's and SunOS 4.0.3(?) and one other OS. This Virtual File System was originally designed for allowing the sysadmin to free up space on the disk. When something was old and big it was migrated giving more space for current, on going work.
The thing that happens tho is that a file can be migrated and still have its data on disk. Giving the user instant access to that data. And the sysadmin instant access to that space if needed.
Shortly after this was all working reliably, they/we hooked up some tape robots to the system. With the tape robots in place even getting offline data was pretty fast. The sysadmins decided to test this. They set up a large (>20GB) filesystem, then they did dumps accross the network to this filesystem. These dumps were then migrated (each file was written to two tapes), and the disk space made available for the next set of dumps. From the point of view of the remote systems this was much faster (Dumping 70GByte filesystem across OC12 ATMs only takes a couple of hours). All automated.
To recover tape space, just reuse the file names and that space on the tapes will be freed up at some point.
Having said all that, I moved on to an ISP and had to do backups there. About a dozen machines. I ended up choosing Amanda as the method and Exabytes 8200 (2GB/2dollar tape) for the storage medium. This worked well. It took about 2 hours to configure Amanda but once done it just ran, doing a backup every night. All I had to do was change the tape in the morning. We just kept that one tape forever. Cheap backup. A tape a day, or $700/year for full backups forever (plus storage)
As long as I had no more than 2GB of data on any one filesystem, this worked well. After I left the job I found myself trying to back up my home systems to 8200s with amanda and it failed. 8GB file systems. 18 and 30 GByte file systems it doesn't work.
At this point I'm doing full backups once a month and being unhappy about it. 8 to 10 hours per filesystem. 4 or 5 tapes. It just is alot of work.
What I've started is an amanda like idea. The difference being that the 32K label on the front of each tape file is the source for a program to combine tape files into one "dump file" even across multiple tapes. With a holding disk this should work pretty well.
As a last thought, the place where the big shops win with backups isn't in the backup software. Dump/restore is every bit as good as most of the software we used in big shops. Better in somecases. Where the big iron wins is in the tape handling system. The ability to request a particular tape by label. To know which tapes are in use, to send messages to operators. To have resource allocations and tape warning/scheduleing. All these things the big iron has been doing right for 30 plus years.
If you want linux/*BSD to be as good as the big iron in backups, spend the time to write tape handlers that allow users to request tapes, release tapes and allows operators/tape robots else where to find and mount those tapes, and then answer the request.
I've used both Nokia and Motorola phones and there is one "feature" that I hate about Motorola phones. The display. My Digital StarTac has the new display and I love that. I can actually read it. But if you don't have the LCD display, they are almost imposible to read with out a cheat sheet handy.
But if you are comparing Motorola phones with LCD to Nokia phones, you quickly find that there is a major difference in feature style. Motorola focuses on "phone/call" features and Nokia focuses on "User" features.
Example 1. No games on my motorola, no repeating timers on the nokia. Repeating timer is a tone that sounds every user setable minutes. I have mine set to beep every 5 minutes. PLUS it beeps 10 seconds before the moment so that you can close the phone at the beep and not get taken for a minute of air time when you used 3 seconds.
Example 2. Multiple choices for how to answer phone. The motorola will let me choose to answer on open, answer on "send" or answer on any key. Plus it has a silence ring feature. The Nokia has only the one "big" button which is used to answer calls.
Example 3. Access to stored numbers. I can jump to names in the directory by pushing the "smart button" then the alpha digit on the keypad till I get to the "N's" for example. Or I can just press the up/down buttons till I get there. The Nokia has just up down options.
Example 4. Easy access to last 20 numbers dialed.
My wife on the other hand loves her Nokia. She plays the games when she finds herself stuck somewhere. She loves the many ring tones as well and she uses the clock/alarms all the time.
I wish my Motorola had clock/alarm as well but there doesn't seem to be anything else I really want with it. If I did, they have a PDA that clips on to the back of the phone that offers more than I want.
I've been working with Unix now for 20+ years. I've worked in the kernels of Cray Super Computers and been driven batty by a BSDish system running on a no name box for a network logger. The equipment has ranged from a 386 that took 5 minutes to boot Linux to SGI super computer cluster. And there are a few things that they all had in common. These common "features" are, in my not so humble opinion, what makes something "Unix".
A command line interpeter, and a way to get to it. Be that a TTY login, rlogin, telnet, or XDM giving me an xterm.
Pipes. The ability to trivially feed the output of one program to another. Where the default input is "stdin" and the default output is "stdout" (See IBM/CDC/Cray Not unix OSs to see how each program required you to define an input and output file)
A tools based approach to solving problems. Rather than loading a file into a spreadsheet and then clicking away for a few hours. Instead we have "sed... | awk | lpr"
File based access to devices./dev/* is a very powerful access method. No special code is required of fsck but access to the special device and a user land program can do a filesystem repair. Just think of it this way, 'dd', 'cat', 'fmt', 'awk', 'sed' all can write tapes.
For that matter, the user can't tell the difference between an IDE cdrom and a SCSI cdrom.
A method of attaching extra storage as part of the existing filesystem. "mount/dev/da7s1/usr/homes/diskhog" vs "Yo, Mr Hog, please use g: for your files now"
While API is important, and I wouldn't want to give up my X windows, or bash/tcsh I've run on Unix boxes where those are different or missing. In some cases my tools of choice were missing and I had to bootstrap 'gcc' into place and from there I added the extra tools (sed/awk/tcsh/bash) that made my life comfortable.
Unix is a style. A way of solving problems. We don't think in terms of "monolithic (Office)" programs that do almost what we want, but instead we think in terms of solving a piece of the problem, chipping away till there is nothing left. And in the process we find that we have a dozen new tools that people will use in ways we never considered.
PERL was never intended to be a webserver, but the tool is so powerful that it now is. That and much more. Every tool that Unix has is used in ways that its creator never intended. Microsoft Office will never be more than what it is, What You See Is ALL You Get.
I leave you with this quote then: "Like a precious metal, UNIX is being beaten and molded into whatever forms are most pleasing to the owners." -- Lee A Butler
This is not a new problem. People have been dealing with the question of recovering data from old media for years. As a first data point, a number of years ago, about 5 IIRC, some people finally decided that some old music tapes had to be rescued.
The method used was to find this old RCA gentleman how had retired more than a few years before then. They then went to the Smithsonian and got the last remaining version of the tape recording/play back device that had been used to make the original master tapes. The RCA guy used the specs and his knowledge to tune the tape deck to perfection. They then put a high quality amp and spliter down stream of the tape deck to feed 2 digital tape decks (The professional version, not DAT, more bits and a bit faster sampling rate) and a couple of analog tape decks as well.
After testing, they carefully placed one of the Master tapes on the deck, started all the recorders and press "play". As the Master tape played it just came apart. They had to keep the heads clean but this was a one time, one chance thing. They succeeded.
From the recordings they made some wonderful CDs. Amazingly enough, the Master tape had almost no "hiss" in it.
Data point two. MIT I believe it was, decided to move some of their older theises to CDROM for easier online access. The first thing they noticed is that many of the data tapes they had stored things on were 7 track tapes, and of course they had no 7 track tape drives any more. Again people went to the museums got out a 7 track drive, spent the time to fix it and make it work, then built an interface box to connect it all up and away they went.
3rd data point. Somebody sent out to a mailing list that they were looking for some old code to run on a mulator for a PDP11(?). We ended up going into our machine room and found some old release tapes. This included a copy of BRLUNIX (Based on a BSD release) and I think, an AT&T Sixth addition. These were 9 track reel to reel tapes. We went into the machine room, powered up the tape drive, copied the tapes verbatium to disk. We set it up to do the least amount of reading. These tapes were around 15 or 20 years old.
Because of this rescue which happened late last year, we saved the tape drive when the machine was tossed due to "Inability to prove Y2K compliance". So the tape drive still sits on the machineroom floor. The operators turn it on and clean it once a week. But it isn't currently hooked up to anything, but we expect it to be hooked up to something again in the next year or two. Just to be able to read all those old tapes we still have.
At home I use EXABYTE-8200s for my back ups. I have 3 drives and you can still get them referbished. While each tape only holds 2GB (Compared to a max of 150MB for a 9 track tape). The media is small and low cost. The exabyte encoding also has a great deal of redundency in it making it an exclent choice for long term storage.
At work they do much of their backups EXABYTE 8500s. For the Crays, they use to use IBM 3480 tape cartrages, when they changed tape formats, they spent a few weeks moving all the data from the older format to the new format.
Of course our most reliable storage medium to date has been our paper tape and punch cards. While they maybe low density and sometimes we've had to make readers for them (Auto feed to a flat bed scanner which scanned the card. Process the card for holes and voloa).
CDROMs have the problem of decaying do to light contamination. If you want to keep them for years and years and years, they have to be kept out of sunlight. And because our long term, low cost, storage methods keeps dropping in cost and increasing in size, I suspect that what we will find in 3 years is that everybody is carefully copying all their data from CDROM to DVDs which will have a twenty year life span.
The basic rules on saving your data for the long term are:
Have more than one copy
Copy from older media to newer media when density more than tripples and the safty/economy matches.
Yes, SANE does support the Coolscan III that I have. it just doesn't have some of the features that I use most often.
I'm looking forward to the day when SANE has better, interactive curves and levels, ICC capabilities and a few other things. As it is, I scan on the windows box and save to a samba partition then run GIMP for all my image work.
Truely, I run games, QuickTime and the scanner software on the widnows box. Nothing more.
There are two major camps today in the computer world. Windows and unix. Anybody asking why we should run Windows over anyother OS is trolling and it isn't worth responding to. Of the Unix offereings there are two main varients: SVR4 and BSD.
The Linux kernel was built by a DOS programmer according to the specifications and papers he had read from POSIX and SVR4 (yeah, I know there is more to it then that). So much of Linux feels like a SVR4 box. SVR4 is the "One True Unix" as defined by AT&T Bell Labs or whoever owns UNIX now. From this you get a certain set of administrative functions in a particular style.
BSD Unixes are mostly ports. They started as a System X release, then some bright folks at Berekely add some extra stuff (like TCP/IP) and pretty soon there was BSD. This version was then ported to different chipsets. Including the Intel x86 set. Because it is a port and not a new product, most BSD based OSes have a style that has much history behind it.
One major difference between BSD and Linux is the question of where things end up. Because Linux is a "kernel" plus distribution, everything but the kernel is an add on. You need to decide if "tcl" is part of the "system" or an add on. In most Linux distributions, everything is considered a part of the "system" so "tcl" ends up in/usr/bin and "gs" (ghostscript) ends up in/usr/bin and so on and so on.
With the BSD Unixes, you get many base parts. Generaly they have a history leading back to the original Unixes at BSD. For example, there is "cc". While we don't run the portable C compiler on any of the Free Unixes but instead one of the GNU compilers. That means that our "cc" is really "gcc" but it lives in/usr/bin. But those extras... Thats where the big difference is. The extras endup over in/usr/local or/usr/X11R6.
If I was to remove/usr/local and/usr/X11R6 from my system the base system would be unaffected but i would lose "gs" and "tcl" and "apsfilter" and "kde" and all the other neat extras I've added to my system.
As to why somebody might choose a BSD system over a Linux distribution.
Upgrades: Last night I went from FreeBSD 3.4 to FreeBSD 4.0-CURRENT. This happened to be my personal box but the total time for the upgrade was about an hour and that upgraded every piece of software on the system. Every configuration script every added package. Everything. And when I say upgrade, I don't mean replacing configuration scripts. I mean merging them or using the ones that I have from 3.4. All and all for an unpleasent upgrade, it didn't take to long.
Stability. The BSD and Linux camps both have excelent stability but in my experence and opinion, FreeBSD has been a little more stable than Linux.
Security. Linux boxes have software from everywhere and as such the security is only as good as the weakest link. While it is still MUCH better than most commerical OSes (Win95/winNT/Irix/Soloris) it still a bit weaker than then Free BSD Unixes.
Patches. Somebody finds something wrong with some software, how do you get the patch and get it installed? With Linux this can mean anything from a full kernel upgrade including upgrading libc and half your system to a simple patch file and recompile. But YOU have to figure out what it is going to take and how this patch will interact with the rest of your system. In BSD, there is one stop shopping in the form of the "STABLE" tree. You can pull the stable tree, build and install and your entire system gets the latest STABLE version of the OS. And you know that all the parts are designed to interact with each other correctly and will not break (for the most part) any extras that you have added.
announcements. FreeBSD has a number of very low bandwidth mailing lists that you can subscribe to (freebsd-announc@freebsd.org) which will keep you up-to-date on the OS with out flooding your mailbox. (Yes, I'm sure there are lists like that for Linux, but finding them can be difficult)
Emulations. With the FreeBSD 4.0 most Linux programs run under the FreeBSD emulation system. The new Heros III runs fine under 4.0 and linux emulation. So does StarOffice 5.1 and vmware. All of this is way good.
I have a windows box just to play games and run my scanner, I don't use it for any real work. I use FreeBSD for all of the house servers and house computers. The exception being the one MacIntosh my wife uses (besides her FreeBSD box which is what she uses most of the time). I ran Linux for 3 or 4 years before switching to FreeBSD. I don't think I'll go back but every once in a while, when the Linux people announce another cool game that runs under linux but not FBSD I get tempted. With this release of FBSD 4.0, I don't see myself as going back to Linux ever.
Let's face it, the DVD CCA isn't really worried about the guy with the ability to bit copy one DVD and make/press thousands of exact copies for resale. They've always known that this is possable. If you do a search for cable box instructions you'll find loads of information from crackers on how they use electron microscopes and other fairly high tech equipment to crack the cable scrambling.
But this isn't what the DVDCCA is afraid of, what they are afraid of is you snagging a copy of the DVD you rented last night because it is so good that you want to watch it again this weekend but don't want to rent it again. Or you wanted to give a copy to Uncle Jimmy because it just happens to exactly express your political opinion.
Those are the "pirates" that DVDCAA is worried about.
How many of us have borrowed a friends ablum and cut your own tape of it. Or maybe even made an MP3 for your own personal use. According to the MPAA and DVDCCA that's piracy. The big pirates are pretty easy to catch. The FBI goes after them and there are lots of foot prints all over the place. Relativly easy to find and relatively easy to prosicute.
But the FBI just isn't going to want to spend a few grand just to prove that you made a copy of the Matrix and handed it to your brother. Its just to small to bother with.
DVDCCA came up with a technical solution. They hid some bits and then did a simple encrypt on the data, no big deal. But what it did was it made it difficult for you and me to make those single copies. Of course it also ment that anybody using a real OS got screwed. No DVDs for us FreeBSD users or IRIX or BeOs, or oh yea, Linux. We just got left out.
DVDCCA and MPAA isn't nearly as worried about 10 people stealing 10,000 copies each as they are of 1,000,000 people stealling 2 or 3 copies each.
All that aside, I got my builitin from the EFF and sent them a check to help fight this and I hope that the good guys, that's us, win.
The problem isn't in getting people to encrypt when sending e-mail or other point to point communications, the problem is in everything else we do. Notice that slashdot.org is not offered over a secure channel. (No https)
I do have https available for my primary domain but I didn't offer that to my customers accept at additional cost. When was the last time you did random browsing using Secure Sockets instead of HTTP?
Personally I use SSH for all interactive connections and file transfers, but that doesn't help me when I'm reading news, or surfing the web.
The big win in the decision to not include wiretap friendly additions to IPV6 is that we don't have to worry about things such as "has this been recorded yet?" and "User level sender authentication." Think of a protocol where each packet had a "Law enforcement has copy" flag and that flag was a cryptographic checksum of the contents of the packet plus some enforcement "cookie". When that packet arrives at a "tap" point it would be recorded and the field filled in. If the field is not properly set, the packet is first sent to a "tap point" to be recorded. In other words, the talk session that I run between two local machines in the clear might suddenly become tapped. Not because Johnny Law produced a warrent and physically tapped my home lan, but because the protocol suddenly says "Send a copy of this to the tap point."
Or think of each packet sent having an authentication requirement. I.e. Every single packet sent via IPV6 belonging to some one person. It is pretty easy to see where that might generate targetted taps, or it might just generate lists of "suspects". Think about what happens if getting packets from a "rape victem support site" would mean that some where, somebody knows that you went to that site. The privacy issues are huge.
So what happened is that the IETF has made a decision that says "We aren't going to allow the protocol to have these types of things." That doesn't mean that Fore doesn't put an option in thier ATM switch that says "send a copy of every packet recieved down this pipe." It just means that at the protocol level we don't have to directly worry about tapping.
Slashdot Mirror
Mike has a working real time raytracier. The real time raytracer is handling >5000 solids at this time, rendering at ARL and then transmitting the results via ATM to other research labs.
The last major milestone for the BRL-CAD was raytracing a scene with over 3,000,000,000 solids. Yes, that is 3 billion.
The license agreement is not "Free" as in beer or "Free" as in "Freedom." You need to sign a simple license and fax it to ARL. They send back the license agreement with a password. Download the program and have fun.
His work site will remain up because it has so much information that is off interest to the world. There is no need for it to ever go off line.
His personal server is still up and will remain up for as long as I can keep it running.
I've been writting CGI scripts from about the time HTML 1.0 was first introduced. I've written in C, C++, Perl, PHP3, sh, and in apache's SHTML languages. Each has it's good points and each has its bad points.
Downside is that the development time for the infrastructure is huge. C isn't designed for string processing. Even REs are harder to do in C. My 2nd to last choice in CGI programming.
On the downside it is a programming language first and a web design langauge 2nd. It also has a serious limit in that it often takes longer to compile to byte code for the run time engine than it takes to run the script. Startup times on largish scripts can be huge. Somewhat solved by embedding Perl into your web server. All in all, my 2nd choice for a CGI Language.
On the downside? It is another langage, sometimes I don't have a standalone PHP interpreter to do testing with. My favorite CGI lanague.
Summary: PHP for almost everything, Perl for the rest, C/C++ if you must, stay away from shells.
Chris
On the downside? It is another langage, sometimes I don't have a standalone PHP interpreter to do testing with. My favorite CGI lanague.
I am a ProAm photographer and lust after a good digital camera. The problem is one of what makes a digital camera "good"?
The criteria that are commonly used seem to be:
I have one lens for my 35mm that I payed almost 1K for. If you look at lenses for 35mm cameras you'll find the prices range from a few hundred dollars to many thousands of dollars. It is hard to look at a camera that costs less than $300.00 and even consider the lens to be reasonable.
Each person judges their needs and makes a decision based on those needs. My brother wanted "webshots." For him a Sony which compresses everything like mad and has 640x480 sizing is just fine. For me it doesn't come close.
My friend wanted a digital and used 3 before he picked his favorite. He choose the Nikon CoolPix 950. (The current Nikon is 990). For him quality was the name of the game. The size had to be 1280x1024 or larger. The compression had to allow for NO compression. I.e A raw TIFF file. And the "Hi Quality" setting is only 4:1 compression JPEG. Very usable.
The other day I took some pictures of a personal event. I ended up with about 16 pictures, all of them head shots. After the film was developped and I had scanned them for the web it turned out that we wanted some close ups of an earing. With just the original scan I was able to do a close up of the earing without upscaling or generating any data that was not already there. And my film scanner isn't the best there is. It only does 30bits of 2000+ by 3000+ pixels.
So to determine what the "best" digital camera is requires a good understanding of what the user wants to do and how they plan to use their images. If you want to be able to just move floppy disks with "Webshots" from your camera to your computer for uploading, pick a Sony digital camera. If you want higher resolution, you need something like the CoolPix 950 from Nikon. Or if you want the real thing you can pick up a Kodak DCS660 for only $20,000.00. That actually does 2k by 3K with 36 bits.
Pick what works for you, just take the list there at the top and rank those things that are important for you. "Webshots" or "Artprint" it makes a difference as to what camera features you need.
Chris
The wonders of back ups. I've been dealing with backup requirements for large and small shops for years now and it is always hateful.
In 1980 I worked for Michigan State University Computer Center. They had a backup plan that seemed to work pretty well. They did nightly change dumps. This normally took one to 5 reels of 2400ft 6250 tape. We had about 200 reels in our library and the backup system just went through the pool of tapes in a FILO order. This gave us about 2 months of partial backups. Every Monday we did a full dump which took about 20 tapes. These were kept for a year.
Now the neat thing was that at the end of each term, the computer center took that full backup and sent it offsite for storage. For 5 years. This was designed to make sure that every student's project survived if needed.
The computer science instructors knowing when the offsite back up was made worked with that knowledge in mind. They made sure that all projects were due at least a week before then. They then very carefully wrote the student files to a personal tape and then DELETED all the student files. Thus ensuring that student files never got long term backups...
When I went to work for a government site, they to did backups in a simular way (And still do). Doing full backups one a month (dump -0u), partial backups everyday (dump -2u), and weekly (dump -1u) once a week. This was done to IBM3480 tape carts.
At that time I was working on BUMP which later became Cray's Data Migration Product. This is a virtual filesystem. When a file is selected for migration, it is moved (equivelent of hardlinked) to a backup directory and from there writen to tape. The hardlink is deleted and the INODE type is changed to MIGRATED with the datapointers now holding a DB reference key. When you want the file back you just open() the file, the open blocks, the OS sends a request to a daemon which requests the tape and reloads it into the "backup directory" the hardlinks are remade and then the file in the backup dir is unlinked.
Complex but it works, the BUMP code is available for free at ftp.arl.mil. It is a set of patches to BSD 4.2. It ran on Cray's and SunOS 4.0.3(?) and one other OS. This Virtual File System was originally designed for allowing the sysadmin to free up space on the disk. When something was old and big it was migrated giving more space for current, on going work.
The thing that happens tho is that a file can be migrated and still have its data on disk. Giving the user instant access to that data. And the sysadmin instant access to that space if needed.
Shortly after this was all working reliably, they/we hooked up some tape robots to the system. With the tape robots in place even getting offline data was pretty fast. The sysadmins decided to test this. They set up a large (>20GB) filesystem, then they did dumps accross the network to this filesystem. These dumps were then migrated (each file was written to two tapes), and the disk space made available for the next set of dumps. From the point of view of the remote systems this was much faster (Dumping 70GByte filesystem across OC12 ATMs only takes a couple of hours). All automated.
To recover tape space, just reuse the file names and that space on the tapes will be freed up at some point.
Having said all that, I moved on to an ISP and had to do backups there. About a dozen machines. I ended up choosing Amanda as the method and Exabytes 8200 (2GB/2dollar tape) for the storage medium. This worked well. It took about 2 hours to configure Amanda but once done it just ran, doing a backup every night. All I had to do was change the tape in the morning. We just kept that one tape forever. Cheap backup. A tape a day, or $700/year for full backups forever (plus storage)
As long as I had no more than 2GB of data on any one filesystem, this worked well. After I left the job I found myself trying to back up my home systems to 8200s with amanda and it failed. 8GB file systems. 18 and 30 GByte file systems it doesn't work.
At this point I'm doing full backups once a month and being unhappy about it. 8 to 10 hours per filesystem. 4 or 5 tapes. It just is alot of work.
What I've started is an amanda like idea. The difference being that the 32K label on the front of each tape file is the source for a program to combine tape files into one "dump file" even across multiple tapes. With a holding disk this should work pretty well.
As a last thought, the place where the big shops win with backups isn't in the backup software. Dump/restore is every bit as good as most of the software we used in big shops. Better in somecases. Where the big iron wins is in the tape handling system. The ability to request a particular tape by label. To know which tapes are in use, to send messages to operators. To have resource allocations and tape warning/scheduleing. All these things the big iron has been doing right for 30 plus years.
If you want linux/*BSD to be as good as the big iron in backups, spend the time to write tape handlers that allow users to request tapes, release tapes and allows operators/tape robots else where to find and mount those tapes, and then answer the request.
Chris
I've used both Nokia and Motorola phones and there is one "feature" that I hate about Motorola phones. The display. My Digital StarTac has the new display and I love that. I can actually read it. But if you don't have the LCD display, they are almost imposible to read with out a cheat sheet handy.
But if you are comparing Motorola phones with LCD to Nokia phones, you quickly find that there is a major difference in feature style. Motorola focuses on "phone/call" features and Nokia focuses on "User" features.
Example 1. No games on my motorola, no repeating timers on the nokia. Repeating timer is a tone that sounds every user setable minutes. I have mine set to beep every 5 minutes. PLUS it beeps 10 seconds before the moment so that you can close the phone at the beep and not get taken for a minute of air time when you used 3 seconds.
Example 2. Multiple choices for how to answer phone. The motorola will let me choose to answer on open, answer on "send" or answer on any key. Plus it has a silence ring feature. The Nokia has only the one "big" button which is used to answer calls.
Example 3. Access to stored numbers. I can jump to names in the directory by pushing the "smart button" then the alpha digit on the keypad till I get to the "N's" for example. Or I can just press the up/down buttons till I get there. The Nokia has just up down options.
Example 4. Easy access to last 20 numbers dialed.
My wife on the other hand loves her Nokia. She plays the games when she finds herself stuck somewhere. She loves the many ring tones as well and she uses the clock/alarms all the time.
I wish my Motorola had clock/alarm as well but there doesn't seem to be anything else I really want with it. If I did, they have a PDA that clips on to the back of the phone that offers more than I want.
I've been working with Unix now for 20+ years. I've worked in the kernels of Cray Super Computers and been driven batty by a BSDish system running on a no name box for a network logger. The equipment has ranged from a 386 that took 5 minutes to boot Linux to SGI super computer cluster. And there are a few things that they all had in common. These common "features" are, in my not so humble opinion, what makes something "Unix".
For that matter, the user can't tell the difference between an IDE cdrom and a SCSI cdrom.
While API is important, and I wouldn't want to give up my X windows, or bash/tcsh I've run on Unix boxes where those are different or missing. In some cases my tools of choice were missing and I had to bootstrap 'gcc' into place and from there I added the extra tools (sed/awk/tcsh/bash) that made my life comfortable.
Unix is a style. A way of solving problems. We don't think in terms of "monolithic (Office)" programs that do almost what we want, but instead we think in terms of solving a piece of the problem, chipping away till there is nothing left. And in the process we find that we have a dozen new tools that people will use in ways we never considered.
PERL was never intended to be a webserver, but the tool is so powerful that it now is. That and much more. Every tool that Unix has is used in ways that its creator never intended. Microsoft Office will never be more than what it is, What You See Is ALL You Get.
I leave you with this quote then: "Like a precious metal, UNIX is being beaten and molded into whatever forms are most pleasing to the owners." -- Lee A Butler
This is not a new problem. People have been dealing with the question of recovering data from old media for years. As a first data point, a number of years ago, about 5 IIRC, some people finally decided that some old music tapes had to be rescued.
The method used was to find this old RCA gentleman how had retired more than a few years before then. They then went to the Smithsonian and got the last remaining version of the tape recording/play back device that had been used to make the original master tapes. The RCA guy used the specs and his knowledge to tune the tape deck to perfection. They then put a high quality amp and spliter down stream of the tape deck to feed 2 digital tape decks (The professional version, not DAT, more bits and a bit faster sampling rate) and a couple of analog tape decks as well.
After testing, they carefully placed one of the Master tapes on the deck, started all the recorders and press "play". As the Master tape played it just came apart. They had to keep the heads clean but this was a one time, one chance thing. They succeeded.
From the recordings they made some wonderful CDs. Amazingly enough, the Master tape had almost no "hiss" in it.
Data point two. MIT I believe it was, decided to move some of their older theises to CDROM for easier online access. The first thing they noticed is that many of the data tapes they had stored things on were 7 track tapes, and of course they had no 7 track tape drives any more. Again people went to the museums got out a 7 track drive, spent the time to fix it and make it work, then built an interface box to connect it all up and away they went.
3rd data point. Somebody sent out to a mailing list that they were looking for some old code to run on a mulator for a PDP11(?). We ended up going into our machine room and found some old release tapes. This included a copy of BRLUNIX (Based on a BSD release) and I think, an AT&T Sixth addition. These were 9 track reel to reel tapes. We went into the machine room, powered up the tape drive, copied the tapes verbatium to disk. We set it up to do the least amount of reading. These tapes were around 15 or 20 years old.
Because of this rescue which happened late last year, we saved the tape drive when the machine was tossed due to "Inability to prove Y2K compliance". So the tape drive still sits on the machineroom floor. The operators turn it on and clean it once a week. But it isn't currently hooked up to anything, but we expect it to be hooked up to something again in the next year or two. Just to be able to read all those old tapes we still have.
At home I use EXABYTE-8200s for my back ups. I have 3 drives and you can still get them referbished. While each tape only holds 2GB (Compared to a max of 150MB for a 9 track tape). The media is small and low cost. The exabyte encoding also has a great deal of redundency in it making it an exclent choice for long term storage.
At work they do much of their backups EXABYTE 8500s. For the Crays, they use to use IBM 3480 tape cartrages, when they changed tape formats, they spent a few weeks moving all the data from the older format to the new format.
Of course our most reliable storage medium to date has been our paper tape and punch cards. While they maybe low density and sometimes we've had to make readers for them (Auto feed to a flat bed scanner which scanned the card. Process the card for holes and voloa).
CDROMs have the problem of decaying do to light contamination. If you want to keep them for years and years and years, they have to be kept out of sunlight. And because our long term, low cost, storage methods keeps dropping in cost and increasing in size, I suspect that what we will find in 3 years is that everybody is carefully copying all their data from CDROM to DVDs which will have a twenty year life span.
The basic rules on saving your data for the long term are:
Chris
Yes, SANE does support the Coolscan III that I have. it just doesn't have some of the features that I use most often.
I'm looking forward to the day when SANE has better, interactive curves and levels, ICC capabilities and a few other things. As it is, I scan on the windows box and save to a samba partition then run GIMP for all my image work.
Truely, I run games, QuickTime and the scanner software on the widnows box. Nothing more.
Chris
Uh, you know, it is funny. Yes, I run the Linux emulation to run the VMWare emulator so that I can run Windows which emulates an Operating system.
There are two major camps today in the computer world. Windows and unix. Anybody asking why we should run Windows over anyother OS is trolling and it isn't worth responding to. Of the Unix offereings there are two main varients: SVR4 and BSD.
The Linux kernel was built by a DOS programmer according to the specifications and papers he had read from POSIX and SVR4 (yeah, I know there is more to it then that). So much of Linux feels like a SVR4 box. SVR4 is the "One True Unix" as defined by AT&T Bell Labs or whoever owns UNIX now. From this you get a certain set of administrative functions in a particular style.
BSD Unixes are mostly ports. They started as a System X release, then some bright folks at Berekely add some extra stuff (like TCP/IP) and pretty soon there was BSD. This version was then ported to different chipsets. Including the Intel x86 set. Because it is a port and not a new product, most BSD based OSes have a style that has much history behind it.
One major difference between BSD and Linux is the question of where things end up. Because Linux is a "kernel" plus distribution, everything but the kernel is an add on. You need to decide if "tcl" is part of the "system" or an add on. In most Linux distributions, everything is considered a part of the "system" so "tcl" ends up in /usr/bin and "gs" (ghostscript) ends up in /usr/bin and so on and so on.
With the BSD Unixes, you get many base parts. Generaly they have a history leading back to the original Unixes at BSD. For example, there is "cc". While we don't run the portable C compiler on any of the Free Unixes but instead one of the GNU compilers. That means that our "cc" is really "gcc" but it lives in /usr/bin. But those extras... Thats where the big difference is. The extras endup over in /usr/local or /usr/X11R6.
If I was to remove /usr/local and /usr/X11R6 from my system the base system would be unaffected but i would lose "gs" and "tcl" and "apsfilter" and "kde" and all the other neat extras I've added to my system.
As to why somebody might choose a BSD system over a Linux distribution.
I have a windows box just to play games and run my scanner, I don't use it for any real work. I use FreeBSD for all of the house servers and house computers. The exception being the one MacIntosh my wife uses (besides her FreeBSD box which is what she uses most of the time). I ran Linux for 3 or 4 years before switching to FreeBSD. I don't think I'll go back but every once in a while, when the Linux people announce another cool game that runs under linux but not FBSD I get tempted. With this release of FBSD 4.0, I don't see myself as going back to Linux ever.
Chris
Let's face it, the DVD CCA isn't really worried about the guy with the ability to bit copy one DVD and make/press thousands of exact copies for resale. They've always known that this is possable. If you do a search for cable box instructions you'll find loads of information from crackers on how they use electron microscopes and other fairly high tech equipment to crack the cable scrambling.
But this isn't what the DVDCCA is afraid of, what they are afraid of is you snagging a copy of the DVD you rented last night because it is so good that you want to watch it again this weekend but don't want to rent it again. Or you wanted to give a copy to Uncle Jimmy because it just happens to exactly express your political opinion.
Those are the "pirates" that DVDCAA is worried about.
How many of us have borrowed a friends ablum and cut your own tape of it. Or maybe even made an MP3 for your own personal use. According to the MPAA and DVDCCA that's piracy. The big pirates are pretty easy to catch. The FBI goes after them and there are lots of foot prints all over the place. Relativly easy to find and relatively easy to prosicute.
But the FBI just isn't going to want to spend a few grand just to prove that you made a copy of the Matrix and handed it to your brother. Its just to small to bother with.
DVDCCA came up with a technical solution. They hid some bits and then did a simple encrypt on the data, no big deal. But what it did was it made it difficult for you and me to make those single copies. Of course it also ment that anybody using a real OS got screwed. No DVDs for us FreeBSD users or IRIX or BeOs, or oh yea, Linux. We just got left out.
DVDCCA and MPAA isn't nearly as worried about 10 people stealing 10,000 copies each as they are of 1,000,000 people stealling 2 or 3 copies each.
All that aside, I got my builitin from the EFF and sent them a check to help fight this and I hope that the good guys, that's us, win.
I do have https available for my primary domain but I didn't offer that to my customers accept at additional cost. When was the last time you did random browsing using Secure Sockets instead of HTTP?
Personally I use SSH for all interactive connections and file transfers, but that doesn't help me when I'm reading news, or surfing the web.
The big win in the decision to not include wiretap friendly additions to IPV6 is that we don't have to worry about things such as "has this been recorded yet?" and "User level sender authentication." Think of a protocol where each packet had a "Law enforcement has copy" flag and that flag was a cryptographic checksum of the contents of the packet plus some enforcement "cookie". When that packet arrives at a "tap" point it would be recorded and the field filled in. If the field is not properly set, the packet is first sent to a "tap point" to be recorded. In other words, the talk session that I run between two local machines in the clear might suddenly become tapped. Not because Johnny Law produced a warrent and physically tapped my home lan, but because the protocol suddenly says "Send a copy of this to the tap point."
Or think of each packet sent having an authentication requirement. I.e. Every single packet sent via IPV6 belonging to some one person. It is pretty easy to see where that might generate targetted taps, or it might just generate lists of "suspects". Think about what happens if getting packets from a "rape victem support site" would mean that some where, somebody knows that you went to that site. The privacy issues are huge.
So what happened is that the IETF has made a decision that says "We aren't going to allow the protocol to have these types of things." That doesn't mean that Fore doesn't put an option in thier ATM switch that says "send a copy of every packet recieved down this pipe." It just means that at the protocol level we don't have to directly worry about tapping.