Panasonic may still make some stuff in.jp, but the last few things I've bought from them have been made Elsewhere(tm).
You can't trust any major name any more. But Panasonic does still wind up as my "default" choice most of the time.
OTOH, Sony has been on (and occasionally off) my Must Not Buy list for 20 years. I've been having problems with cheap non-Sony parts in Sony gear for a while now... started with a TC-FX-44A tape deck, with Sharp VU meters that blew up (literally).
The annoying thing about Sony stuff is that you get some cheap Achillie's heel part in an otherwise nice piece of gear.
Plus, let's say you're a site like eBay and your customers can't use it for several hours.
The money they would have spent is still there. People still want to sell stuff through eBay. Other people still want to buy stuff through eBay.
A large site, or a unique site, is only "losing money" to the extent that they are having to pay staff to repair or harden systems while transactions aren't happening, rather than the day-to-day maintenance.
The people who will not make money because their site is down are the people who offer the same thing as the guy with the next site over. Even then, customers who've bought from you before (and whom you didn't screw over like by shipping via UPS to Canada or something), they'll probably just wait.
Now, if you're consistently down for many hours or days, people will start looking for something else. But people don't like changing things once they know hwo something works.
eBay was at risk several years back, when they were having major crashes because of stuff on their end. It got so bad, that they finally said, "Our SUN SERVERS are crashing and THE VENDOR CAN'T FIX THEM." Prior to that, they never said just what database and operating system they were running. (This was... oh... 1998, 1999 time frame. A while back.)
At that point, given that eBay was bouncing up and down for almost a month, there was a good chance for someone to put together a competing auction site and take over the market from people frustated by eBay's crashes.
Except... it's hard to put a whole site together in a month. You'd have needed to already have a robust site, and just take advantage of the marketing opportunity.
Except... if you're a young site, where do you get the money for a quick market blitz like that? Assuming that spamming is out....
failing to mention that you can use upgrade on a fresh install with an old windows CD.
You do mean that all you have to do is show the upgrade your old windows CD, right? You don't even have to have the old windows installed.
Though, people should try out that "system inspector" thingie that XP Upgrade provides that critiques your drivers and applications. I kept uninstalling stuff until it was happy, and upgrade went great. Mostly you get rid of unneeded USB drivers, since the generic bulk storage driver handles everything now. Oh yeah, and that Trend anti-virus thing that comes free with a new mobo purchase...
The only strange thing is, my XP install lives in a directory called "WIN98" now... oh well, malware looking for C:\WINDOWS is going to have fun.
I even converted all the FAT32 drives to NTFS. To my shock, it all worked--I had planned my time expecting to have to wipe the whole system and do a clean insatll of XP.
Yes/no; OS flaws provide opportunity, and the architecture guides the implementation.
If you're relying on a stack smash or heap overflow to write machine code, you need to write the appropriate code for the machine. You can't exploit an IA32 box with PPC code and vice versa.
And as someone else said, different architectures afford different security measures in the OS, like allowable page protection modes. (No-Execute being fairly new to IA32, but old hat to most other CPU architectures. Cache implementations can make getting code from a data page into the execution unit "interesting", also.)
Apple's viewer (Preview.app) doesn't handle some PDF constructs; though some of that might have been resolved in Tiger.
Adobe Reader has better zoom modes and stuff like that; I use "Fit Width" a lot, and Preview.app just doesn't cut the mustard.
PDF Forms don't work in Preview.app either. Not that they work all that well in Reader for Macintosh. Some PDFs don't render correctly in Preview, but they're fine in Adobe Reader, and so on. (Shading and blending I think were the main areas of trouble.)
On the generation side, Save As PDF doesn't do anywhere near as much as Acrobat. If you don't need it, you don't need it--Save As PDF will keep you happy for years. (I'm happy with it, but all I do is save order confirmation pages from on-line retailers.) But if you need some of the stuff Acrobat does, like indexing, you can't just use Save As PDF. (Not the same as saying that Acrobat is the only program that can do those things.)
If you're using the UCM in ClearCase, I've got some scripts to export integration stream changes and import them into CVS.
I'm sure my company would be happy to sell them to you for a "reasonable" fee.
(And to save your Linux machines: Kick MVFS the fsck off the system and go with snapshot views only. That MVFS thing is the dumbest thing I've ever seen in a revision control program. Obviously written by someone who liked VMS but didn't understand it.)
You know you're in trouble with a revision control system which says you can't use regular Make, you have to use their Seekrit Make That Is Almost, But Not Quite, Compatible With GNU Make, Except That You Modified GNU Make To Have New Features Because That's What OSS Is All About So You Really Can't Use The Stupid Seekrit Make From The Rat Company.
We hates them. We hates their lying salespeople. Sure, they got fired for lying, but we were still stuck with the bill for the software.
Yup; I've got a Microtek X6USB that only works in MacOS 8.6... if you use Microtek's alledged drivers and scanning software.
SANE (Linux) and VueScan (Mac), on the other hand, will drive it just fine.
OTOH, the stepper motors are making some really, really odd noises these days... so I'll be watching the recommendations this topic pulls out with interest.
My general rule of hardware: If it only works with the manufacturer's software, it's crap. The number of times I've had manufacturers just stop supporting stuff--and not even all-that-old stuff, is... well, not too many because I lerned from both Microtek and Microtech (both make cheap hardware and incredibly bad software drivers).
So TWAIN for scanners, Hayes AT commands for modems, generic protocol drivers for USB, SCSI and FireWire things, PostScript for printers... though I can't seem to find a $100 PostScript inkjet printer for some reason.
It does mean that attacking the machine without knowing the user's names is that much more complicated--you have to guess 2 pieces of ID, rather than keep feeding passwords into the root account.
I don't give "guests" admin access on my Macs, and they never have reason to complain. You can install something from within their account, since the "Please Authenticate..." dialogs let you specify a username as well as a password. There's just much less incentive to make everyone admin. (And Fast User Switching means you've got two ways of doing installs as an admin.) (Yes, I know about Run As... on Windows.)
Still, if someone has a null or obvious password and is in sudoers and downloads a malicious.app that does sudo with a pseudo-TTY feeding it the guessable password, it'll be on the system in no time flat.
ignoring the trash cans that are usually inside or immediately outside the room.
The main-stream theatres I've been to, if you can even FIND a trashcan, it has a tiny hole on the top that is smaller than the "medium" soda cup, has been full since the first afternoon matinee finished, and shows no sign of being emptied any time soon, either.
Whereas the guys that are supposed to pick up the trash after the screening have a commercial-size trash-bin-on-wheels without a lid, so they can stuff everything right in. If I see them waiting when it's time to leave, I'll put my trash in their bin. But otherwise, I'll leave it for them.
The repertory and art-house theatres, on the other hand, charge reasonable prices for soda and popcorn, and has great big trash bins where you can easily find them and they're set up so you can put stuff in them.
Everyone knows backups are important, right? Well, pretend you do if you don't....
So, my first full-time job, I wound up being de facto system operator of the department's AIX machines, since I'd learned the Magic Incantations necessary to upgrade AIX 3.2.3 to 3.2.4 or 3.2.5... or even, this was really great, install AIX on a new computer!
After my first 6 months in that group, the guy who had been doing the backups left for hopefully-greener pastures. No big deal, you just had to run this program which told you which tape numbers to load in to which drives, and printed out the label sheet for the previous night's backups. Everything was done with the standard dump command, which is a nice and robust way to back up.
Everything seemed good; every now and then, a few nodes would fail to back up, but no big deal, they were done on an earlier night, and the tape selection program made sure that a "recent" backup was available for each node before it allowed a tape to be re-used.
If only I had noticed that it was always 3 machines in a row that had backup failures....
So, the inevitable happens... we need to restore an important filesystem. (Anyone who worked with IBM 857mb SCSI drives knows that the inevitable happened about once every 6 months. Per drive.)
Pulled the latest tape, seeked to the right record... funny, this looks like a different filesystem, but that should be a much later record on the tape.
Try the next-earlier one, same thing.
One before that... found the right filesystem. Restore went good, fortunately it was a read-mostly system, and we didn't lose any important changes since that dump.
But having filesystems in the wrong place... I couldn't figure that one out. I went through the backup script (which had been adapted from a magazine article...). Added a whole pile of logging and tracing, especially putting stderr somewhere where it could be read back (it had been sent to/dev/null... of course.)
So those three failures in a row? The went something like this:
DUMP: Backing up/dev/hd9var... DUMP: No space left on device. DUMP: DUMP ABORTED DUMP: Backing up/dev/hd1 DUMP: I/O ERROR DUMP: DUMP ABORTED DUMP: Backing up/dev/hd2 DUMP: Device not ready DUMP: DUMP ABORTED DUMP: Backing up/dev/hd3 DUMP: Dump complete!
What the error messages didn't explain, but some experimenting found, the operation that hit end-of-tape returned end-of-tape, as expected. The next operation got an I/O error, because the last operation resulted in an I/O error, and the tape had not been rewound or ejected.
The thing is, these tape drives would automatically re-wind when you read back an I/O error from them...
So device not ready was obtained while the drive was rewinding. (Normally, it should just block until the rewind is complete. In this case, the NEXT command after it started rewinding would block.)
Then the remaining backups would go fine... overstriking the eariler ones on the same tape.
I've had a fetish for proper error-checking in scripts ever since... and I don't accept scripts written by others unless they will run with #!/bin/sh -e or equivelent.
If you're a cheap bastard, the gallon jug of methyl hydrate (or methanol or methyl alcohol) from the hardware store is the way to go--any alcohol will do the job. But save the ethanol products for the system operator!
How is "programmer failing to check error status" or "protect arguments" a sign of bad platform design?
Especially when UNIX shells provide paranoia flags for preventing exactly this kind of disaster:
#!/bin/sh -e
Now any failing command in a script started like that will cause the script to bail. This should be your standard way of writing a shell script.
The only commands allowed to fail will be those that are the condition of an if or while statement, or are part of a command-chain using the short-circuit operators && or ||.
Further, any POSIX-compliant command has an "end of options" indicator, --. Sure, it's annoying to type on the command line, but when you're writing a script to run unattended, you need to protect it against anticipated situations.
It's not as if having the "remove" command be called "rm" was the cause of this problem.
Really, the use of wildcards in script that run unattended is just dangerous... if you're doing it, re-code.
Like this:
find "${DATADIR}" -type f -exec rm {} \;
If you need to nuke subdirs too, that's easy--if you do it separately:
Anyone who doesn't get heart palpitations when writing rm commands to be run by a script as root is either inexperienced or unimaginative.
Ask the guys at Apple who had to pay for forensic recovery of customer's hard drives when a badly-written rm command in an early iTunes update clobbered hard drives because it didn't handle spaces-in-filenames.
Target Disk Mode (hold down "T" during power-on) turns the iBook into a very, very expensive, self-powered FireWire hard-disk. When is very handy when it blows its logic board for the Nth time and you want to make a backup before taking it in for Yet Another Repair Extension replacement. (But I'm not bitter.)
You can boot another machine from it, but you cannot boot the iBook.
You can, however, boot the iBook from an external FireWire disk. Hold down "Option" during power-on for a clickable menu of detected bootable devices. Or hold down "C" during power-on to boot from CD-ROM. I believe it will try FireWire-attached CD-ROMs (and DVD-ROMs) as well as the built-in drive.
Of course, they may have set an OpenFirmware password to prevent this.
NTP will basically build a new calibration map for your system's time-of-day clock. Many operating systems allow the clock ratio, that of clock ticks to seconds, to be adjusted. This helps compensate for characteristic error in the oscillator.
All your left with is temperature-induced drift, as machine load and ambient air affects the oscillator's frequency.
NTP adjusts the drift parameters much more frequently than once a day, so machines maintain very, very close time. It's easy to get within 100 msec from a stratum 3 server.
Basically, consistent clock gain or loss, like you described, will be compensated for by re-calibrating the system clock against the NTP servers. (Where Facilities Exist... if your system can't do that, well, you should ask your vendor to fix it because the free ones can.)
Monitors on the CBM and PET machines could also be very vigorously abused via software.
Although they were single-scan, single-resolution monitors, they were very closely linked to the video drive chips in the computers. It's not like there was a virtual "video out" port connected to "video in"--the video chip directly controlled the monitor deflection circuits.
By putting non-standard values in the video chip control registers, you could get all sorts of neat effects--the screen apparently wrapped onto a cylinder, compressed into a single line, compressed into a small square.
And it was really changing the drive currents running through the deflector yokes--you'd see the image get much, much, much brighter when it was displaying a small square, as the whole screen worth of electrons hit that smaller bit of phosphor.
The only monitor I've had catch on fire was a TTL RGB set (like CGA, but different) that was simply defective.
Once they finally do, they are thrilled to discover that it's like having a new laptop again, with nice long battery life.
The trigger, for me, was that my iBook G3 would no longer run off battery for an entire feature-length DVD movie.
That just won't do, the whole reason for having a laptop is to have a portable DVD player that can also do e-mail and Web.
But it seems Apple improved the batteries between then and now... the runtime on the new battery is better than it was on the original battery when it was new. The case on the new battery is better manufactured as well: no gaps in the joins.
It just looks a little weird, because the older iBooks were slightly grey compared to the new models. So there's this Bright! Shiny! battery on a dull iBook.
The article does not state that information was transmitted to the off-site servers in order to trigger the "gotcha".
There is also no evidence, from the article, that information was NOT transmitted off-site.
It's easy enough to set up a "trap" to test your users.
For the fake web-form, put the input boxes in a form element without a submit button. Then, put the submit button in a second form element that contains only information that YOU sent to the "victim"--other than "address exists" confirmation, this does not leak any further information.
For the password checker, it sounded like people were alerted that it was a test before the user provided their password.
A classic, and often Career Limiting, move is to send out an e-mail with a link or attachment. When clicked, it runs a script that brings up a big flashing box saying, "Your IT Department Reminds You Never Click On Links In E-Mail."
You can do the same sort of thing by sending a harmless trojan executable, one that just brings up a "Had this been a real virus your computer would be hosed by now" message.
You've still got the misrepresentation aspect to deal with, but you don't have to have an information leak to do this kind of "education" program.
I have Mozilla set to delete cookies every day, which seems to be the best balance. (Firefox unfortunately does not have this option).
Don't be too sure it doesn't; Firefox has almost every pref that Mozilla has.
What it often lacks is a user-interface for setting that preference. You can either frob user.js by hand, or use about:config. In this case, I believe you're after network.cookie.lifetime.days.
only to be saved from the vast insansity of netspace by a few hundred doubleclick cookies..
Yeah... I have no sympathy for cookies set in response to IMG requests (typically, cross-site tracking cookies). And I got fairly tired of Certain Ad Servers taking forever to cough up the ad, that my nameserver grew a few new entries like this:
zone "doubleclick.net" IN { type master; file "master.d/null"; allow-update { none; }; };
Any site which results in the browser "barberpole" running for ages after page load appears complete gets their whole domain taken out that way. Especially if it is a file called "blank.gif" that is reported to be "1px x 1px". That's there for nothing but cross-site tracking.
minor degredation on some arbitrary older browser (I'm looking at you, Netscape 4).
Thanks, that's the funniest thing I've read all day.
Minor degradation in Netscape 4... that's a good one.
Let's try "major weirdness" in Netscape 4, as it renders color = inherit as #00e000 and other fun tricks.
The thing about Netscape 4 isn't that it doesn't handle modern standards like CSS and HTML. It's that it tries, but gets it completely and utterly wrong. In fact, on a page rich in CSS, you're better with Netscape 3 than Netscape 4... I tried it. (And Netscape 3 is amazingly fast on a 1 GHz Pentium III....) OK, disabling CSS in Netscape 4 works pretty good, too.
Slashdot Mirror
You can't trust any major name any more. But Panasonic does still wind up as my "default" choice most of the time.
OTOH, Sony has been on (and occasionally off) my Must Not Buy list for 20 years. I've been having problems with cheap non-Sony parts in Sony gear for a while now... started with a TC-FX-44A tape deck, with Sharp VU meters that blew up (literally).
The annoying thing about Sony stuff is that you get some cheap Achillie's heel part in an otherwise nice piece of gear.
Plus, let's say you're a site like eBay and your customers can't use it for several hours.
The money they would have spent is still there. People still want to sell stuff through eBay. Other people still want to buy stuff through eBay.
A large site, or a unique site, is only "losing money" to the extent that they are having to pay staff to repair or harden systems while transactions aren't happening, rather than the day-to-day maintenance.
The people who will not make money because their site is down are the people who offer the same thing as the guy with the next site over. Even then, customers who've bought from you before (and whom you didn't screw over like by shipping via UPS to Canada or something), they'll probably just wait.
Now, if you're consistently down for many hours or days, people will start looking for something else. But people don't like changing things once they know hwo something works.
eBay was at risk several years back, when they were having major crashes because of stuff on their end. It got so bad, that they finally said, "Our SUN SERVERS are crashing and THE VENDOR CAN'T FIX THEM." Prior to that, they never said just what database and operating system they were running. (This was... oh... 1998, 1999 time frame. A while back.)
At that point, given that eBay was bouncing up and down for almost a month, there was a good chance for someone to put together a competing auction site and take over the market from people frustated by eBay's crashes.
Except... it's hard to put a whole site together in a month. You'd have needed to already have a robust site, and just take advantage of the marketing opportunity.
Except... if you're a young site, where do you get the money for a quick market blitz like that? Assuming that spamming is out....
You do mean that all you have to do is show the upgrade your old windows CD, right? You don't even have to have the old windows installed.
Though, people should try out that "system inspector" thingie that XP Upgrade provides that critiques your drivers and applications. I kept uninstalling stuff until it was happy, and upgrade went great. Mostly you get rid of unneeded USB drivers, since the generic bulk storage driver handles everything now. Oh yeah, and that Trend anti-virus thing that comes free with a new mobo purchase...
The only strange thing is, my XP install lives in a directory called "WIN98" now... oh well, malware looking for C:\WINDOWS is going to have fun.
I even converted all the FAT32 drives to NTFS. To my shock, it all worked--I had planned my time expecting to have to wipe the whole system and do a clean insatll of XP.
If you're relying on a stack smash or heap overflow to write machine code, you need to write the appropriate code for the machine. You can't exploit an IA32 box with PPC code and vice versa.
And as someone else said, different architectures afford different security measures in the OS, like allowable page protection modes. (No-Execute being fairly new to IA32, but old hat to most other CPU architectures. Cache implementations can make getting code from a data page into the execution unit "interesting", also.)
Apple's viewer (Preview.app) doesn't handle some PDF constructs; though some of that might have been resolved in Tiger.
Adobe Reader has better zoom modes and stuff like that; I use "Fit Width" a lot, and Preview.app just doesn't cut the mustard.
PDF Forms don't work in Preview.app either. Not that they work all that well in Reader for Macintosh. Some PDFs don't render correctly in Preview, but they're fine in Adobe Reader, and so on. (Shading and blending I think were the main areas of trouble.)
On the generation side, Save As PDF doesn't do anywhere near as much as Acrobat. If you don't need it, you don't need it--Save As PDF will keep you happy for years. (I'm happy with it, but all I do is save order confirmation pages from on-line retailers.) But if you need some of the stuff Acrobat does, like indexing, you can't just use Save As PDF. (Not the same as saying that Acrobat is the only program that can do those things.)
I'm sure my company would be happy to sell them to you for a "reasonable" fee.
(And to save your Linux machines: Kick MVFS the fsck off the system and go with snapshot views only. That MVFS thing is the dumbest thing I've ever seen in a revision control program. Obviously written by someone who liked VMS but didn't understand it.)
You know you're in trouble with a revision control system which says you can't use regular Make, you have to use their Seekrit Make That Is Almost, But Not Quite, Compatible With GNU Make, Except That You Modified GNU Make To Have New Features Because That's What OSS Is All About So You Really Can't Use The Stupid Seekrit Make From The Rat Company.
We hates them. We hates their lying salespeople. Sure, they got fired for lying, but we were still stuck with the bill for the software.
Given how hot cars get inside when they're sitting in the sun, I think that's a worthwhile feature.
SANE (Linux) and VueScan (Mac), on the other hand, will drive it just fine.
OTOH, the stepper motors are making some really, really odd noises these days... so I'll be watching the recommendations this topic pulls out with interest.
My general rule of hardware: If it only works with the manufacturer's software, it's crap. The number of times I've had manufacturers just stop supporting stuff--and not even all-that-old stuff, is... well, not too many because I lerned from both Microtek and Microtech (both make cheap hardware and incredibly bad software drivers).
So TWAIN for scanners, Hayes AT commands for modems, generic protocol drivers for USB, SCSI and FireWire things, PostScript for printers... though I can't seem to find a $100 PostScript inkjet printer for some reason.
It does mean that attacking the machine without knowing the user's names is that much more complicated--you have to guess 2 pieces of ID, rather than keep feeding passwords into the root account.
I don't give "guests" admin access on my Macs, and they never have reason to complain. You can install something from within their account, since the "Please Authenticate..." dialogs let you specify a username as well as a password. There's just much less incentive to make everyone admin. (And Fast User Switching means you've got two ways of doing installs as an admin.) (Yes, I know about Run As... on Windows.)
Still, if someone has a null or obvious password and is in sudoers and downloads a malicious .app that does sudo with a pseudo-TTY feeding it the guessable password, it'll be on the system in no time flat.
Woohoo! I've been patented!
But I'd like a cut of the royalties at least....
The main-stream theatres I've been to, if you can even FIND a trashcan, it has a tiny hole on the top that is smaller than the "medium" soda cup, has been full since the first afternoon matinee finished, and shows no sign of being emptied any time soon, either.
Whereas the guys that are supposed to pick up the trash after the screening have a commercial-size trash-bin-on-wheels without a lid, so they can stuff everything right in. If I see them waiting when it's time to leave, I'll put my trash in their bin. But otherwise, I'll leave it for them.
The repertory and art-house theatres, on the other hand, charge reasonable prices for soda and popcorn, and has great big trash bins where you can easily find them and they're set up so you can put stuff in them.
Until you pointed it out, I hadn't figured out what that image was supposed to be....
Without colour, he just isn't the same.
Fortunately.
That was modded funny, but look at the history of successful media formats, and those which... flopped.
Everyone knows backups are important, right? Well, pretend you do if you don't....
So, my first full-time job, I wound up being de facto system operator of the department's AIX machines, since I'd learned the Magic Incantations necessary to upgrade AIX 3.2.3 to 3.2.4 or 3.2.5... or even, this was really great, install AIX on a new computer!
After my first 6 months in that group, the guy who had been doing the backups left for hopefully-greener pastures. No big deal, you just had to run this program which told you which tape numbers to load in to which drives, and printed out the label sheet for the previous night's backups. Everything was done with the standard dump command, which is a nice and robust way to back up.
Everything seemed good; every now and then, a few nodes would fail to back up, but no big deal, they were done on an earlier night, and the tape selection program made sure that a "recent" backup was available for each node before it allowed a tape to be re-used.
If only I had noticed that it was always 3 machines in a row that had backup failures....
So, the inevitable happens... we need to restore an important filesystem. (Anyone who worked with IBM 857mb SCSI drives knows that the inevitable happened about once every 6 months. Per drive.)
Pulled the latest tape, seeked to the right record... funny, this looks like a different filesystem, but that should be a much later record on the tape.
Try the next-earlier one, same thing.
One before that... found the right filesystem. Restore went good, fortunately it was a read-mostly system, and we didn't lose any important changes since that dump.
But having filesystems in the wrong place... I couldn't figure that one out. I went through the backup script (which had been adapted from a magazine article...). Added a whole pile of logging and tracing, especially putting stderr somewhere where it could be read back (it had been sent to /dev/null... of course.)
So those three failures in a row? The went something like this:
What the error messages didn't explain, but some experimenting found, the operation that hit end-of-tape returned end-of-tape, as expected. The next operation got an I/O error, because the last operation resulted in an I/O error, and the tape had not been rewound or ejected.
The thing is, these tape drives would automatically re-wind when you read back an I/O error from them...
So device not ready was obtained while the drive was rewinding. (Normally, it should just block until the rewind is complete. In this case, the NEXT command after it started rewinding would block.)
Then the remaining backups would go fine... overstriking the eariler ones on the same tape.
I've had a fetish for proper error-checking in scripts ever since... and I don't accept scripts written by others unless they will run with #!/bin/sh -e or equivelent.
Except they always ask me about things first, so the book still isn't perfect.
I don't need no stinkin' book. I learned UNIX the old-fashioned way; by having to restore from backup when I got things wrong.
If you're a cheap bastard, the gallon jug of methyl hydrate (or methanol or methyl alcohol) from the hardware store is the way to go--any alcohol will do the job. But save the ethanol products for the system operator!
Especially when UNIX shells provide paranoia flags for preventing exactly this kind of disaster:
Now any failing command in a script started like that will cause the script to bail. This should be your standard way of writing a shell script.
The only commands allowed to fail will be those that are the condition of an if or while statement, or are part of a command-chain using the short-circuit operators && or ||.
Further, any POSIX-compliant command has an "end of options" indicator, --. Sure, it's annoying to type on the command line, but when you're writing a script to run unattended, you need to protect it against anticipated situations.
It's not as if having the "remove" command be called "rm" was the cause of this problem.
Really, the use of wildcards in script that run unattended is just dangerous... if you're doing it, re-code.
Like this:
If you need to nuke subdirs too, that's easy--if you do it separately:
Anyone who doesn't get heart palpitations when writing rm commands to be run by a script as root is either inexperienced or unimaginative.
Ask the guys at Apple who had to pay for forensic recovery of customer's hard drives when a badly-written rm command in an early iTunes update clobbered hard drives because it didn't handle spaces-in-filenames.
You can boot another machine from it, but you cannot boot the iBook.
You can, however, boot the iBook from an external FireWire disk. Hold down "Option" during power-on for a clickable menu of detected bootable devices. Or hold down "C" during power-on to boot from CD-ROM. I believe it will try FireWire-attached CD-ROMs (and DVD-ROMs) as well as the built-in drive.
Of course, they may have set an OpenFirmware password to prevent this.
NTP will basically build a new calibration map for your system's time-of-day clock. Many operating systems allow the clock ratio, that of clock ticks to seconds, to be adjusted. This helps compensate for characteristic error in the oscillator.
All your left with is temperature-induced drift, as machine load and ambient air affects the oscillator's frequency.
NTP adjusts the drift parameters much more frequently than once a day, so machines maintain very, very close time. It's easy to get within 100 msec from a stratum 3 server.
Basically, consistent clock gain or loss, like you described, will be compensated for by re-calibrating the system clock against the NTP servers. (Where Facilities Exist... if your system can't do that, well, you should ask your vendor to fix it because the free ones can.)
Although they were single-scan, single-resolution monitors, they were very closely linked to the video drive chips in the computers. It's not like there was a virtual "video out" port connected to "video in"--the video chip directly controlled the monitor deflection circuits.
By putting non-standard values in the video chip control registers, you could get all sorts of neat effects--the screen apparently wrapped onto a cylinder, compressed into a single line, compressed into a small square.
And it was really changing the drive currents running through the deflector yokes--you'd see the image get much, much, much brighter when it was displaying a small square, as the whole screen worth of electrons hit that smaller bit of phosphor.
The only monitor I've had catch on fire was a TTL RGB set (like CGA, but different) that was simply defective.
The trigger, for me, was that my iBook G3 would no longer run off battery for an entire feature-length DVD movie.
That just won't do, the whole reason for having a laptop is to have a portable DVD player that can also do e-mail and Web.
But it seems Apple improved the batteries between then and now... the runtime on the new battery is better than it was on the original battery when it was new. The case on the new battery is better manufactured as well: no gaps in the joins.
It just looks a little weird, because the older iBooks were slightly grey compared to the new models. So there's this Bright! Shiny! battery on a dull iBook.
The article does not state that information was transmitted to the off-site servers in order to trigger the "gotcha".
There is also no evidence, from the article, that information was NOT transmitted off-site.
It's easy enough to set up a "trap" to test your users.
For the fake web-form, put the input boxes in a form element without a submit button. Then, put the submit button in a second form element that contains only information that YOU sent to the "victim"--other than "address exists" confirmation, this does not leak any further information.
For the password checker, it sounded like people were alerted that it was a test before the user provided their password.
A classic, and often Career Limiting, move is to send out an e-mail with a link or attachment. When clicked, it runs a script that brings up a big flashing box saying, "Your IT Department Reminds You Never Click On Links In E-Mail."
You can do the same sort of thing by sending a harmless trojan executable, one that just brings up a "Had this been a real virus your computer would be hosed by now" message.
You've still got the misrepresentation aspect to deal with, but you don't have to have an information leak to do this kind of "education" program.
Don't be too sure it doesn't; Firefox has almost every pref that Mozilla has.
What it often lacks is a user-interface for setting that preference. You can either frob user.js by hand, or use about:config. In this case, I believe you're after network.cookie.lifetime.days.
Yeah... I have no sympathy for cookies set in response to IMG requests (typically, cross-site tracking cookies). And I got fairly tired of Certain Ad Servers taking forever to cough up the ad, that my nameserver grew a few new entries like this:
Any site which results in the browser "barberpole" running for ages after page load appears complete gets their whole domain taken out that way. Especially if it is a file called "blank.gif" that is reported to be "1px x 1px". That's there for nothing but cross-site tracking.
Thanks, that's the funniest thing I've read all day.
Minor degradation in Netscape 4... that's a good one.
Let's try "major weirdness" in Netscape 4, as it renders color = inherit as #00e000 and other fun tricks.
The thing about Netscape 4 isn't that it doesn't handle modern standards like CSS and HTML. It's that it tries, but gets it completely and utterly wrong. In fact, on a page rich in CSS, you're better with Netscape 3 than Netscape 4... I tried it. (And Netscape 3 is amazingly fast on a 1 GHz Pentium III....) OK, disabling CSS in Netscape 4 works pretty good, too.