However, as we all know, Unisys *did* change their policy, allthough the target wasn't compress (which meanwhile had lost most of its markedshare to gzip)
Actually, Unisys specifically stated that the LZW compression techniques used in compress were free for use on unix systems. Unfortunately, since Gnu is Not Unix, it wasquite possible that those license terms wouldn't apply to GNU software.
About 4 years ago, there was a long gripe session on van.general (VANcouver, Canada) about the horrors of shipping UPS across the Canada/US border. Apparently UPS Canada and UPS US are entirely different companies.
I understand that UPS US has a pretty good reputation, and UPS Canada doesn't have a bad reputation, that I know of. I'm guessing that the two companies hate each others' guts, or something.
The upshot is that I (alongg with just about anybody who read that thread) now specifically warn anybody who ships something from the states that They should not use UPS under any circumstances whatsoever.
Yep.. The data sheet crows about how the 4004 can handle what would now be called 4K of ROM and 640 bytes of RAM (though it was measured in bits back then).
and it could add two 8 digit integers in just under a second (probably stored in 32 bits as Binary Coded Decimal)
And I moan about how my secondary computer has 'only' 96meg of RAM in it....
Back in the earluy/mid 80's some friends of mine founded Myrias Computers... Proposing a 4000 processor system (68000s). I joked that the system would be able to calculate real-time holograms and pop popcorn at the same time. -- Then I did a bit of work on the kinds of CPU power it would take to do real time holograms.... I stand by the pop popcorn statement, though..
Unfortunately, the company's financing colapsed before they could build anything larger than a 256 CPU unit, so my prediction was never tested.
800,000 hours mean time between failure (MTBF) in the field
3 Year Limited Warranty
units 800000hours years
* 91.263642
If their drives have a 91 year mean time to faulure, it would be pretty cheap for them to give a 5 year warranty rather than a 3 year warranty. Even if their MTBF was off by an order of magnitude , a 5 year warranty wouldn't be that bad.
I think it's time for someone to compile some failure stats on these things.
(anecdote)
Back in the early '80s when oil sands development was starting in Northern Alberta, a friend of mine was working at the site. It was mid-winter, and starting to get pretty cold... -35C (~-30F)
-30 is cold on any scale, but the equipment that they were using was rated doen wo -40. Now in the States, +40C ~ -40C is often referred to as "Mil Spec". In Northern Alberta it's referred to as "outdoor equipment".
-35C, and this equipment freezes. My friend Dan calls the manufacturer of this stuff and he complains about it. The engineer led off with one question that told Dan all he needed to know.
With a Texan drawl he asked, incredulously: "You mean it actually gets that cold?"
I'm wondering if Maxtor's 800K Hour MTBF is kinda like that Texan Mil Spec rating.
It's the air outside the balloon that won't be dense enough to support the balloon. At some point the volume of helium needed to provide the lift is going to be so large that the weight of the envelope is going to exceed the boyancy provided by the volume it encloses.
Even though the Tic cartoon was probably child-oriented, it still had some adult-parsed humor in it. I remember being ROFL with some of the social undertones to a couple of the episodes I watched.
Don't watch enough TV to have gotten the whole series, or anything, but the ones I watched had a good bit to them... especially the earlier ones.
They move at a rate of 1 to 2 meters per day, sliding over a bed of sediment saturated with liquid water. But if the bed becomes cold enough for the water in it to start freezing, the loss of lubrication causes the ice stream to slow and eventually stop moving, Tulaczyk said.
That 1Metre/day is the movement of the whole ice chunk over lubricated ground. That sort of movement is not likely to affect the detector that much... More important is the warping of the ice block against itself which is more likely to be in the range of inches or feet/year
(as an analogy: I may be walking at 5MPH, but my backbone is relatively stable relative to itself [unless I get hit by a car going 60MPH, in which case, all bets are off])
Ice streams-large river-like currents of ice flowing through the ice sheets at speeds one to two orders of magnitude faster than the general ice flow-greatly increase the potential swiftness of ice-sheet collapse by rapidly transporting ice from the interior of the ice sheet to the margin.
Glacial movements on the Antarctic shelf can vary in the range of orders of magnitude. In other words, the movement at the place chosen for the dector are probably unlikely to be moving at the 1M/day rate.. Given that the detector is apparently at the south pole, my expectation is that that section of ice sheet is going to be relatively stable.
I remember thinking the same thing when I first saw HP calculators..."Why would you want to use that wierd notation?" Then one day I stood at a store counter and played with one for about half an hour. That was long enough to convert me to RPN. The only problem after that was that I didn't have the money for an HP. Back in 1977, $100+ for a calculator was a LOT of money.
When National Semiconductor came out with their RPN calculator in 1978, I actually remember buying 2 of them. I can't remember what happened to the first one, but I definitely remember buying the second. It probably broke... The National calculators were cheap in every sense of the word.
I don't know why it is tht RPN is so intuitive once you start using it, but I do remember that the 4-level RPN stack was enough to solve problems that taxed the nine-level algebraic stack of the TIs. I thnk that the problem with infix notation for a calculator is that you have to worry about operation precedence, and, for complicated calculationa, you sometimes have to remember to put brackets in miles ahead of where they close. Not having to remember to hit a closing bracket, instead of '=' 5 miles later
may be the problem that RPN solves.
One thing to note is that TI's were only partly algebraic, and actually partly RPN. I never saw a 'normal' calculator where you keyed in " sin 48 = " in immediate mode. It was always " 48 sin " (note the lack of an '=' whether you used an HP or a TI.
Although Infix notation (algebraic) is the standard way of documenting equations, it seems that RPN is a more natural way of doing calculations. Once the two activities are recognized as separate, the transition to RPN gets a bit easier.
Sometimes it can take me 6 montns or a year to get around to putting my negs in a proper archive neg sleve and then dump them in a binder. THe older pictures that I mentioned are mostly still in the original sleves that they came from the photo lab in -- in the boxes that my mom put them in.
(My dad was a dentist, so many pictures are in old anesthetic boxes).
Once stored, they stay there until someone asks me about "those pictures you took way back when....".
My point is that -- once stored, they're safe until there's a fire, flood, etc. I don't have to worry about transferring them to a new media every couple of years. or chose between storing old pictures, MP3s and the most recent mozilla build.
Unfortunately, when you set netscape (4) to ban all cookies, it removes the cookie file so when you get to a site where you want to use cookies, you have nothing to send.
On the other hand, if you have cookie notification set, then some sites have so many cookies that you spend 15 minutes clicking on cancel before you can get around to seeing the page (or even hitting the 'stop' button.)
I think that it may be appropriate to make it illegal to use cookies other than associated with a user making an explicit choice/setting (like cliking on a purchace, or chosing to save password settings, etc.). That's what cookies
were originally designed for.
This would, at least, get rid of all those cookies associated with images, etc. that get sent by various add sites. That, I think, is what they are really trying to ban.
$20 for a book and some slede sleeves will give you storage for hundreds of rolls of film. To do that with digital, you need to pay for tape drives, tapes and someone to run the backup software.
That's a budget item.
Add to that, the fact that it's a lot easier to flip through a 5 year old file of negatives than it is to hunt down the 5 year old tape (presuming that it's readable and you've still got a tape drive that can play it, extract the images, and then pray that you've still got the software to view them....
See a CNN Story on
the problems that Nasa is having with old data -- and that's an organization that takes it's old data seriously. Most newspapers store old negatives more as an aside than as a conscious effort. It's just easier to keep them than to destroy them. For digital images, on the other hand, it's the other way 'round.
I could take a picture of a sports game with a regular camera and think to myself "aw it's a nothing shot" and set it and it's negative on fire in an ashtray.
The point is that very few people do burn their negatives.
In my closet, I have stereo slides taken in the '50s by my dad from before he met my mother. I also have most of the negatives from my childhood, and thousands of negatives that I've shot since then. Negatives are relatively compact, and easy to store for a couple of decades (longer than that and you should be explicitly nice to them).
What we're dealing with in this digital vs film case is the default path for the 'uninteresting' pictures. With film, the photographer would drop of a bag of film rolls at the processing lab, and the editor would get a stack of negatives, chose one (or a few) and be done with it.
In this case, you now have, besides the one or two printed pictures, another dozen or hundred that didn't make the grade, today. For the most part, these pictures cannot be reused, but it is pretty easy to put the spare pictures in a book and stick it on a shelf for a few years.
With digital, a couple of 'bad' pictures (like the picturs of clinton with 'that intern chick') might get culled before it even made it to the editorial desk. The images that aren't used, on the other hand, are on a $200 hard disk that is very reusable. One click of the mouse, and you once again have space for another 300 images.
Most consumers don't realize the quantity of film that a news photographer can go through. You don't count frames. You count rolls. If a news photographer tells you that he's got 3 rolls left, he's not bragging. He's probably worrying.
BTW: At 3Meg each, someone mentioned that his camera has room for 330 images (~ 9 rolls). This is about the number of pictures that I'll take at a friend's wedding. I'm not a news photographer, but I go through film like one. (must come from volunteering for community newspapers).
A 20 GB drive wouldn't store a busy year's worth of my pictures at decent resolution. Then I would have to decide if I'm gonna try and fit another 20GB drive in my box or cull most of the pictures.
Listen to the sound of file pointers being zeroed
Having wine well-developed will encourage people to use Linux without having to worry about lack of access to the older (windows) software. This is an old trick that IBM used when they did microcode for..... eh I think it was their first 360s that emulated their predecessor.
Once the mindshare of Linux goes up, people will be more willing to develop for Linux. Until then, a good emulator means that people have to worry less about the MS F.U.D. about 'but what if you need Windows application "Y"'.
In the short term, however, it's problematic because it encourages people to just write for Windows -- however, we can encourage people to write wine-enabled extensions to their windows code which will allow them to take advantage of Linux capabilities. This may encourage a migration of users to linux/wine.
My quick guess (never having used wine) is that wine is likely to be a bit more expensive for heavily graphics intensive apps (like quake) than for more CPU intensive apps (like The Sims).
Once again it's a question of using the tool that's appropriate for the job. For those jobs where WINE does the job, it's dogmatic and counter-productive to demand a 'native' Linux port.
On the other hand, insisting on WINE, whether it works or not, is a different problem in the other direction. Granted: It'd be nice to always have a linux base port, but politics and economics often directs otherwise.
This doesn't mean you can't use them, though. What it does mean is that you'll need to select something you're pretty sure can handle what you want, and then devise procedures for calibrating the devices' output.
Note that even NASA continually re-calibrates their probes -- and I presume that Nasa doesn't use off the shelf components for most of their deep-space boxes. Units will change over time -- much less the change between units of the same model. Whatever you choose, you'll have to do calibration on an ongoing basis.
Once you figure out how to do calibration, you can compare various units (and report back!:-). If you do a good job, you might even be able to scam yourself some free units from manufacturers who are interested in the results, and having them published.
I'm not sure quite how rare it is for a CPU to be run with the heatsink off. I can easily see a naive user pulling the heatsink off "for a few seconds", to check something, or to apply new heatsink compound, or in the process of playing with an old(dead) fan and/or replacing it.
Granted -- none of us would do it, having seen the video (kof, kof), but there are a lot of people out there who, having seen it done on older (intel) CPUs, figure that it's a medium/low risk process. (oops).
It would seem to me that the most likely time for such a failure (dropped heat sinkk) wiykd be after shipping -- I can just see some poor sod in Costa Rica with his brand new 1.4GZ Athlon, pluging his box in and smelling the processor go up in smoke while the CPU heatsink fan (accidently) cools his sound card (!).
SO the good news is that AMD is now specifying a crude thermal protection for boards using their CPUs. The bad news is that
This protection doesn't exist for old (current) boards
It just shuts down the whole system (i.e. crash)
AMD didn't bother to mention that this is a patched board that they're using.
You could probably do a board design that, instead of shutting down the whole machine, switched it to 100MZ (or some other 'safe' clock speed), but AMD hasn't quite gotten around to that, (yet).
You probably want to dump the streams to disk and then copy the disks to tape. That way, when you dump from disk to tape, you can ensure enough volume to stream the tape drives. Streaming a tape drive results in
Faster throughput
Less mechanical wear on the tape
higher density on the tape
Dumping to disk first will also mean that you can use off the shelf backup software (like NetBackup, mentioned before). Given the kind of
moneyo you're going to be spending, it's probably going to be worth it.
If you can do it, alternate between dumping to one disk array and reading from another (better yet, go through three, so you have a bit of buffer) you can get an effective increase in the effeciency of drives if they're not seeking to write and read at the same time. Obviously there will be a real advantage to using RAID.
It would also be to your advantage to have multiple CPUs controlling the tape drives. Each one would have it's own small farm. You should be able to have multiple CPUs feeding the drives on one tape library.
Given that you're going to need tape monkeys feed the tape library, it may be worthwhile to not use a tape library, but I'd suggest that the drives be in at least small tape libraries. The reason for this is that a tape library can read the bar code on the back of each tape as it goes into the drive.. Otherwise you are almost sure to have errors logging which tape was where/when. With the volume of tapes you're going through it could be absolute hell trying to track down a mis-labeled tape. A small tape library would also allow you to keep drives in more constant motion.
The last thing is to make sure that you have more drives than you 'really' need. With many drives in constant use they will break down from time to time. Make sure that you keep that in mind when you design both your hardware and your software. The horrid thing is that, if they're reasonably well built, failure could be clustered (identical drives with similar usage).
For 90MB/sec Super DLT promises 10MB/sec which means you'll need at least 10 drives. I'd budget for 15 drives -- it gives you some reserve capacity, and allowance for things like non- streaming and occasional drive failure (in spite of their lofty promises) and people who want to read the tapes. It's usually easier to get the budget for the extra drives when you start the project, than after you run into the inevitable problems.
knowing that this is being used for fase recognition helps the issue a bit for two reasons:
1) knowing what sorts ofvideos are bing stored is useful to the design of the system
2) some people may not be too happy in helping to design a mass face-recognition system.
If he hadn't made the post, I would have asked a similar question, myelf.
THe cluelessness of an error response will change from programmer to programme, and even from progrm to program. Programs that I write will vary from a reasonably complete attempt to catch and explain errors to, through terse "bad stuff" messages to ignoring the error and producing (obviously?) bad results.
The more likely that I think someone other than me is going to use a program, the more likely I'm going to put work into error support. If I'm expecting really techie types to use it, I may be more oriented to super-terse responses.
For stuff that goes to the general public, I'm more likely to do nice error work, but even that may be cut short if I'm really short on time. Of course, there's the problem of systems that go are originally intended for me but then get released to an unintended audience... These are the ones most likely to have what I consider inappropriate error handling for the audience.
I think that this re-targeting of programs originally intended for internal consumption are also the source of sub-optimal error handling in some open source programs.
Some principles that I've learned for error reporting are (in roughly decresing order of importance);
it shouldn't do the unexpected in the face of the unexpected/unwanted
the response should be reasonable and predictable
error messages should indicate, as much as possible) where the error originated
recovery should be as easy as possible
Now I think that I'm going to get flamed at for putting easy recovery at the end, but that's really where I have it. I'd rather have consistent and reasonable (but cryptic) responses than reall nice messages and eratic behaviour. If it happens with any regularity, I believe that eratic behavior is going to be more off-puting to users than terse messages.
Now ideally, I'm going to achieve all of the above, but that's going to depend on how much time I have to put into the project in question.
I guess that the listing I gave is the order in which I plan for error reporting depending on the 'techiness' of the expected user.. (This may also include the techniness of my own expected mood when I'm going to be running the program).
To be honest, I believe that if other users are going to be playing with my program, it's usually worth my while to go the full gamut for error response/ recovery. I know that if I don't take the time to make error recovery as easy as possible, I'm ultimately going to end up spending more than that amount of time responding to users who don't understand/like the errors that they get out of my program.
Short term investment, long term gain
--------
Microsoft has had a history of going to extremes with their error response. The response is either laking all but (possibly) the most basic error handling that may not even achieve my first intent (e.g. BSOD) to things like the paper clip that are so damned helpful that they're annoying.
Part of the problem, I think, is that the Microsoft culture encourages it.
When program failures are cryptic and unpredictable, it encourages support calls to Microsoft that they get paid for. Microsoft actually gets paid for. The other reasonable response is to go to microsoft for training -- once again paying them for an MSIE that spends lots of time on how to placate customer dissatisfaction with Microsoft's problems.. In other words, microsoft gets paid for bad programming practices.
This seems to change, however, when Marketing decrees that problems need to be handled better. As far as I can tell, marketing seems to drive Microsoft, so when they decree that things need to change, they will.
An early example of this was when windows 95 came out and decided to check the filesystem if the system was brought down badly. This was something that Unix and MAC boxes already did, and microsoft probably wanted to jump on the "stability bandwagon". The result was the annoying wait at the "we're about to clean the filesystem, you naughty boy" prompt.
I expect that the paperclip was similarly mandated by Marketing (though I sometimes think that it may have started
out as some programmer's prank and picked up by marketing as a 'good idea'). That feature was so annoying that it was ultimately dropped -- I think because it broke the principle of 'reasonable response'.
Something that distracts the user isn't helpful. The constant (nervous) motion of the paper clip, and it's obtrusive location on top of the main screenare tricks learned by advvertisers to get peoples attention -- unfortunately, most of the time the users' attention is attempting to focus on the document being created. Had the paper clip been an unobtrusive text box in the toolbar, people probably would have welcomed it.
In any case (having rambled), I think that Microsoft error responses are more oriented towards making money for Microsoft than making life easier for the user (a common subtext on slashdot).
Slashdot Mirror
Actually, Unisys specifically stated that the LZW compression techniques used in compress were free for use on unix systems. Unfortunately, since Gnu is Not Unix, it wasquite possible that those license terms wouldn't apply to GNU software.
I understand that UPS US has a pretty good reputation, and UPS Canada doesn't have a bad reputation, that I know of. I'm guessing that the two companies hate each others' guts, or something.
The upshot is that I (alongg with just about anybody who read that thread) now specifically warn anybody who ships something from the states that They should not use UPS under any circumstances whatsoever.
and it could add two 8 digit integers in just under a second (probably stored in 32 bits as Binary Coded Decimal)
And I moan about how my secondary computer has 'only' 96meg of RAM in it....
Unfortunately, the company's financing colapsed before they could build anything larger than a 256 CPU unit, so my prediction was never tested.
- 800,000 hours mean time between failure (MTBF) in the field
- 3 Year Limited Warranty
units 800000hours years* 91.263642
If their drives have a 91 year mean time to faulure, it would be pretty cheap for them to give a 5 year warranty rather than a 3 year warranty. Even if their MTBF was off by an order of magnitude , a 5 year warranty wouldn't be that bad.
I think it's time for someone to compile some failure stats on these things.
(anecdote)
Back in the early '80s when oil sands development was starting in Northern Alberta, a friend of mine was working at the site. It was mid-winter, and starting to get pretty cold... -35C (~-30F)
-30 is cold on any scale, but the equipment that they were using was rated doen wo -40. Now in the States, +40C ~ -40C is often referred to as "Mil Spec". In Northern Alberta it's referred to as "outdoor equipment".
-35C, and this equipment freezes. My friend Dan calls the manufacturer of this stuff and he complains about it. The engineer led off with one question that told Dan all he needed to know.
With a Texan drawl he asked, incredulously: "You mean it actually gets that cold?"
I'm wondering if Maxtor's 800K Hour MTBF is kinda like that Texan Mil Spec rating.
It's the air outside the balloon that won't be dense enough to support the balloon. At some point the volume of helium needed to provide the lift is going to be so large that the weight of the envelope is going to exceed the boyancy provided by the volume it encloses.
Even though the Tic cartoon was probably child-oriented, it still had some adult-parsed humor in it. I remember being ROFL with some of the social undertones to a couple of the episodes I watched.
Don't watch enough TV to have gotten the whole series, or anything, but the ones I watched had a good bit to them... especially the earlier ones.
That 1Metre/day is the movement of the whole ice chunk over lubricated ground. That sort of movement is not likely to affect the detector that much... More important is the warping of the ice block against itself which is more likely to be in the range of inches or feet /year
(as an analogy: I may be walking at 5MPH, but my backbone is relatively stable relative to itself [unless I get hit by a car going 60MPH, in which case, all bets are off])
As noted at one Nasa glacial site,
Glacial movements on the Antarctic shelf can vary in the range of orders of magnitude. In other words, the movement at the place chosen for the dector are probably unlikely to be moving at the 1M/day rate.. Given that the detector is apparently at the south pole, my expectation is that that section of ice sheet is going to be relatively stable.oh, nevermind.
When National Semiconductor came out with their RPN calculator in 1978, I actually remember buying 2 of them. I can't remember what happened to the first one, but I definitely remember buying the second. It probably broke... The National calculators were cheap in every sense of the word.
I don't know why it is tht RPN is so intuitive once you start using it, but I do remember that the 4-level RPN stack was enough to solve problems that taxed the nine-level algebraic stack of the TIs. I thnk that the problem with infix notation for a calculator is that you have to worry about operation precedence, and, for complicated calculationa, you sometimes have to remember to put brackets in miles ahead of where they close. Not having to remember to hit a closing bracket, instead of '=' 5 miles later may be the problem that RPN solves.
One thing to note is that TI's were only partly algebraic, and actually partly RPN. I never saw a 'normal' calculator where you keyed in " sin 48 = " in immediate mode. It was always " 48 sin " (note the lack of an '=' whether you used an HP or a TI.
Although Infix notation (algebraic) is the standard way of documenting equations, it seems that RPN is a more natural way of doing calculations. Once the two activities are recognized as separate, the transition to RPN gets a bit easier.
Ah, but They do make a palmtop.
Once stored, they stay there until someone asks me about "those pictures you took way back when....". My point is that -- once stored, they're safe until there's a fire, flood, etc. I don't have to worry about transferring them to a new media every couple of years. or chose between storing old pictures, MP3s and the most recent mozilla build.
On the other hand, if you have cookie notification set, then some sites have so many cookies that you spend 15 minutes clicking on cancel before you can get around to seeing the page (or even hitting the 'stop' button.)
I think that it may be appropriate to make it illegal to use cookies other than associated with a user making an explicit choice/setting (like cliking on a purchace, or chosing to save password settings, etc.). That's what cookies were originally designed for.
This would, at least, get rid of all those cookies associated with images, etc. that get sent by various add sites. That, I think, is what they are really trying to ban.
Seven thousand images were takent today, and they chose the one wierd one to put on the front page.
That's a budget item.
Add to that, the fact that it's a lot easier to flip through a 5 year old file of negatives than it is to hunt down the 5 year old tape (presuming that it's readable and you've still got a tape drive that can play it, extract the images, and then pray that you've still got the software to view them....
See a CNN Story on the problems that Nasa is having with old data -- and that's an organization that takes it's old data seriously. Most newspapers store old negatives more as an aside than as a conscious effort. It's just easier to keep them than to destroy them. For digital images, on the other hand, it's the other way 'round.
The point is that very few people do burn their negatives.
In my closet, I have stereo slides taken in the '50s by my dad from before he met my mother. I also have most of the negatives from my childhood, and thousands of negatives that I've shot since then. Negatives are relatively compact, and easy to store for a couple of decades (longer than that and you should be explicitly nice to them).
What we're dealing with in this digital vs film case is the default path for the 'uninteresting' pictures. With film, the photographer would drop of a bag of film rolls at the processing lab, and the editor would get a stack of negatives, chose one (or a few) and be done with it.
In this case, you now have, besides the one or two printed pictures, another dozen or hundred that didn't make the grade, today. For the most part, these pictures cannot be reused, but it is pretty easy to put the spare pictures in a book and stick it on a shelf for a few years.
With digital, a couple of 'bad' pictures (like the picturs of clinton with 'that intern chick') might get culled before it even made it to the editorial desk. The images that aren't used, on the other hand, are on a $200 hard disk that is very reusable. One click of the mouse, and you once again have space for another 300 images.
Most consumers don't realize the quantity of film that a news photographer can go through. You don't count frames. You count rolls. If a news photographer tells you that he's got 3 rolls left, he's not bragging. He's probably worrying.
BTW: At 3Meg each, someone mentioned that his camera has room for 330 images (~ 9 rolls). This is about the number of pictures that I'll take at a friend's wedding. I'm not a news photographer, but I go through film like one. (must come from volunteering for community newspapers). A 20 GB drive wouldn't store a busy year's worth of my pictures at decent resolution. Then I would have to decide if I'm gonna try and fit another 20GB drive in my box or cull most of the pictures.
Listen to the sound of file pointers being zeroed
Once the mindshare of Linux goes up, people will be more willing to develop for Linux. Until then, a good emulator means that people have to worry less about the MS F.U.D. about 'but what if you need Windows application "Y"'.
In the short term, however, it's problematic because it encourages people to just write for Windows -- however, we can encourage people to write wine-enabled extensions to their windows code which will allow them to take advantage of Linux capabilities. This may encourage a migration of users to linux/wine.
My quick guess (never having used wine) is that wine is likely to be a bit more expensive for heavily graphics intensive apps (like quake) than for more CPU intensive apps (like The Sims). Once again it's a question of using the tool that's appropriate for the job. For those jobs where WINE does the job, it's dogmatic and counter-productive to demand a 'native' Linux port.
On the other hand, insisting on WINE, whether it works or not, is a different problem in the other direction. Granted: It'd be nice to always have a linux base port, but politics and economics often directs otherwise.
Note that even NASA continually re-calibrates their probes -- and I presume that Nasa doesn't use off the shelf components for most of their deep-space boxes. Units will change over time -- much less the change between units of the same model. Whatever you choose, you'll have to do calibration on an ongoing basis.
Once you figure out how to do calibration, you can compare various units (and report back! :-). If you do a good job, you might even be able to scam yourself some free units from manufacturers who are interested in the results, and having them published.
Granted -- none of us would do it, having seen the video (kof, kof), but there are a lot of people out there who, having seen it done on older (intel) CPUs, figure that it's a medium/low risk process. (oops).
It would seem to me that the most likely time for such a failure (dropped heat sinkk) wiykd be after shipping -- I can just see some poor sod in Costa Rica with his brand new 1.4GZ Athlon, pluging his box in and smelling the processor go up in smoke while the CPU heatsink fan (accidently) cools his sound card (!).
-
This protection doesn't exist for old (current) boards
- It just shuts down the whole system (i.e. crash)
- AMD didn't bother to mention that this is a patched board that they're using.
You could probably do a board design that, instead of shutting down the whole machine, switched it to 100MZ (or some other 'safe' clock speed), but AMD hasn't quite gotten around to that, (yet).-
Faster throughput
- Less mechanical wear on the tape
- higher density on the tape
Dumping to disk first will also mean that you can use off the shelf backup software (like NetBackup, mentioned before). Given the kind of moneyo you're going to be spending, it's probably going to be worth it.If you can do it, alternate between dumping to one disk array and reading from another (better yet, go through three, so you have a bit of buffer) you can get an effective increase in the effeciency of drives if they're not seeking to write and read at the same time. Obviously there will be a real advantage to using RAID.
It would also be to your advantage to have multiple CPUs controlling the tape drives. Each one would have it's own small farm. You should be able to have multiple CPUs feeding the drives on one tape library.
Given that you're going to need tape monkeys feed the tape library, it may be worthwhile to not use a tape library, but I'd suggest that the drives be in at least small tape libraries. The reason for this is that a tape library can read the bar code on the back of each tape as it goes into the drive .. Otherwise you are almost sure to have errors logging which tape was where/when. With the volume of tapes you're going through it could be absolute hell trying to track down a mis-labeled tape. A small tape library would also allow you to keep drives in more constant motion.
The last thing is to make sure that you have more drives than you 'really' need. With many drives in constant use they will break down from time to time. Make sure that you keep that in mind when you design both your hardware and your software. The horrid thing is that, if they're reasonably well built, failure could be clustered (identical drives with similar usage).
For 90MB/sec Super DLT promises 10MB/sec which means you'll need at least 10 drives. I'd budget for 15 drives -- it gives you some reserve capacity, and allowance for things like non- streaming and occasional drive failure (in spite of their lofty promises) and people who want to read the tapes. It's usually easier to get the budget for the extra drives when you start the project, than after you run into the inevitable problems.
So then, what IS the system being used for?
1) knowing what sorts ofvideos are bing stored is useful to the design of the system
2) some people may not be too happy in helping to design a mass face-recognition system.
If he hadn't made the post, I would have asked a similar question, myelf.
The more likely that I think someone other than me is going to use a program, the more likely I'm going to put work into error support. If I'm expecting really techie types to use it, I may be more oriented to super-terse responses.
For stuff that goes to the general public, I'm more likely to do nice error work, but even that may be cut short if I'm really short on time. Of course, there's the problem of systems that go are originally intended for me but then get released to an unintended audience... These are the ones most likely to have what I consider inappropriate error handling for the audience. I think that this re-targeting of programs originally intended for internal consumption are also the source of sub-optimal error handling in some open source programs.
Some principles that I've learned for error reporting are (in roughly decresing order of importance);
- it shouldn't do the unexpected in the face of the unexpected/unwanted
- the response should be reasonable and predictable
- error messages should indicate, as much as possible) where the error originated
- recovery should be as easy as possible
Now I think that I'm going to get flamed at for putting easy recovery at the end, but that's really where I have it. I'd rather have consistent and reasonable (but cryptic) responses than reall nice messages and eratic behaviour. If it happens with any regularity, I believe that eratic behavior is going to be more off-puting to users than terse messages.Now ideally, I'm going to achieve all of the above, but that's going to depend on how much time I have to put into the project in question. I guess that the listing I gave is the order in which I plan for error reporting depending on the 'techiness' of the expected user.. (This may also include the techniness of my own expected mood when I'm going to be running the program).
To be honest, I believe that if other users are going to be playing with my program, it's usually worth my while to go the full gamut for error response/ recovery. I know that if I don't take the time to make error recovery as easy as possible, I'm ultimately going to end up spending more than that amount of time responding to users who don't understand/like the errors that they get out of my program.
Short term investment, long term gain
--------
Microsoft has had a history of going to extremes with their error response. The response is either laking all but (possibly) the most basic error handling that may not even achieve my first intent (e.g. BSOD) to things like the paper clip that are so damned helpful that they're annoying. Part of the problem, I think, is that the Microsoft culture encourages it.
When program failures are cryptic and unpredictable, it encourages support calls to Microsoft that they get paid for. Microsoft actually gets paid for. The other reasonable response is to go to microsoft for training -- once again paying them for an MSIE that spends lots of time on how to placate customer dissatisfaction with Microsoft's problems.. In other words, microsoft gets paid for bad programming practices.
This seems to change, however, when Marketing decrees that problems need to be handled better. As far as I can tell, marketing seems to drive Microsoft, so when they decree that things need to change, they will.
An early example of this was when windows 95 came out and decided to check the filesystem if the system was brought down badly. This was something that Unix and MAC boxes already did, and microsoft probably wanted to jump on the "stability bandwagon". The result was the annoying wait at the "we're about to clean the filesystem, you naughty boy" prompt.
I expect that the paperclip was similarly mandated by Marketing (though I sometimes think that it may have started out as some programmer's prank and picked up by marketing as a 'good idea'). That feature was so annoying that it was ultimately dropped -- I think because it broke the principle of 'reasonable response'.
Something that distracts the user isn't helpful. The constant (nervous) motion of the paper clip, and it's obtrusive location on top of the main screenare tricks learned by advvertisers to get peoples attention -- unfortunately, most of the time the users' attention is attempting to focus on the document being created. Had the paper clip been an unobtrusive text box in the toolbar, people probably would have welcomed it.
In any case (having rambled), I think that Microsoft error responses are more oriented towards making money for Microsoft than making life easier for the user (a common subtext on slashdot).
for me (Redhat 7.1) Netscape 4,77 was allowed in, but Mozilla 0.94 wasn't....