I'm all in favour of modifying the EULA before agreeing, but this practice is coming to an end rapidly.
For example, most modern Microsoft products sign the EULA (Or rather, they locate the EULA within a signed portion of the installer's data files), which means you won't be able to get the installer to run if you've modified the EULA.
Why not use a strong password plus the number of the month?
So they force you to change your password, fine -- Why use the same simple word (+date)over and over, why not use a strong password (+date) over and over?
That only works if you can secure the input device and the authentication system, and everything in between.
If the scanner or anything between the scanner and the authentication device is compromised, an attacker can intercept the digitized copy of your finger print (or whatever biometic you decide to use) and you're screwed. Worse, you can't just change your finger print (Well, you've got 8 fingers and two thumbs, but after that, you're out of luck)
Go to Google and type "speeling mistake" and Google will say "Did you mean: spelling mistake"
This is completely different from "Google Suggest" which won't come up with "spelling mistake" at all when you type "speeling mistake" (although the "Did you mean" feature will still catch it)
As cool as the DNS option (or UDP push alternatves) would be, the reality of it is that it's beyond what most users could easily accomplish on your average hosting company.
Not everybody that has an RSS feed even has anything other then static content -- I've got one HTML file I update locally which I also offer via RSS -- I just upload a new RSS file as well.
Why not use HTTP's native caching support?
Client connects to server, provides the date/time of the last cached copy. The server either says 304/Not Modifed, or 200/OK and provides the updated content. There is no reason to transmit the whole XML shebang on every request.
Ideally, it would be nice if the server could tell the client when the next expected update is too, either on the original request, or with an HTTP extension to include it in the 304/Not Modified response as well.
For a feed like slashdot the time is hard to predict, but for some feeds we know in advance that the feed only updates every Wednesday morning.
Users don't care enough to find out how often the feed updates, they usually just accept whatever their client's default is -- Why not integrate this into the protocol?
Cutting the number of data bytes transmitted from a few KB to a couple hundred bytes would be a huge savings.
Sounds like you're a threat to national security and under the "ream honest americans" act of 2004, your meals and living arrangements will be handled, at no expense to yourself, for the remainder of your natural life.
Repeat "Please continue to hold. Your call is important *snicker* to us and we will be pleased to assist you as soon as *snicker* possible" every few minutes
The same amount of the color most people run out of, less of the rest.
Putting less of that one wouldn't make sense, they'd be wasting more and more of the other colors -- Even if the ink isn't a significant cost, it's still a cost.
By reducing the others, they could screw users who don't print using the most popular color, plus they could save a few pennies themselves.
I'm surprised they haven't attached the black cartridge to the color cartridge by now to force you to throw out the color if you happen to run out of black first.
And I'm not so sure about the viability of recovering overwritten data anyway, even with electron microscopes and whatnot. Let's face it, if it was at all practical, someone, somewhere would have used the techniques to build a high-capacity drive that worked by storing new data "over the top of" old data, and there'd be a fanfare of press releases about it
People have this weird fetish about wanting their data back in a reasonable amount of time, and they seem to want the same data out as what they put in.
Sure you might be able to recover much of the drive using million dollar equipment, with a few caveats.
Not all the data will be recoverable, there will be lost bits, and it may take hours or days to read a KB.
This wouldn't be useful, especially with a million dollar price tag.
Slashdot Mirror
I'm all in favour of modifying the EULA before agreeing, but this practice is coming to an end rapidly.
For example, most modern Microsoft products sign the EULA (Or rather, they locate the EULA within a signed portion of the installer's data files), which means you won't be able to get the installer to run if you've modified the EULA.
IIRC the court tossed that out.
Congrats to both of you
Why not use a strong password plus the number of the month?
So they force you to change your password, fine -- Why use the same simple word (+date)over and over, why not use a strong password (+date) over and over?
Usually a quick call to IT will get your account set to require an immediate password change.
However, three quick calls to IT (to wipe out the cache of 3 most recently used passwords) would probably raise some flags.
That only works if you can secure the input device and the authentication system, and everything in between.
If the scanner or anything between the scanner and the authentication device is compromised, an attacker can intercept the digitized copy of your finger print (or whatever biometic you decide to use) and you're screwed. Worse, you can't just change your finger print (Well, you've got 8 fingers and two thumbs, but after that, you're out of luck)
Making that a fireable offense (And enforcing that policy) should be sufficient.
Reading isn't your area of expertise, is it?
Go to Google and type "speeling mistake" and Google will say "Did you mean: spelling mistake"
This is completely different from "Google Suggest" which won't come up with "spelling mistake" at all when you type "speeling mistake" (although the "Did you mean" feature will still catch it)
I do? How do you figure?
I'm just a realist.
Before arming everyone with a weapon to be used to fight spammers, you'd better be damn sure that the spammer can't aim it at the good guys.
Sure. Are you willing to be one of the few that gets hit with a thousand+ dollar bandwidth bill?
Or do you expect your host to take it up the ass and pay for it?
And when a spammer puts your URL in their spam, you'll just happily pay the bandwidth bill in the name of fighting spammers?
Repeat after me: Do not fight abuse with abuse.
As cool as the DNS option (or UDP push alternatves) would be, the reality of it is that it's beyond what most users could easily accomplish on your average hosting company.
Not everybody that has an RSS feed even has anything other then static content -- I've got one HTML file I update locally which I also offer via RSS -- I just upload a new RSS file as well.
Why not use HTTP's native caching support?
Client connects to server, provides the date/time of the last cached copy. The server either says 304/Not Modifed, or 200/OK and provides the updated content. There is no reason to transmit the whole XML shebang on every request.
Ideally, it would be nice if the server could tell the client when the next expected update is too, either on the original request, or with an HTTP extension to include it in the 304/Not Modified response as well.
For a feed like slashdot the time is hard to predict, but for some feeds we know in advance that the feed only updates every Wednesday morning.
Users don't care enough to find out how often the feed updates, they usually just accept whatever their client's default is -- Why not integrate this into the protocol?
Cutting the number of data bytes transmitted from a few KB to a couple hundred bytes would be a huge savings.
What are the telemarketers selling? The ones I get usually sell services, rarely products.
In either event though, the client is normally within the same country as the targeted victim.
If a telemarketer is selling Sprint long distance service, you fine Sprint. You fine them enough that they'll never telemarket again.
Sounds like you're a threat to national security and under the "ream honest americans" act of 2004, your meals and living arrangements will be handled, at no expense to yourself, for the remainder of your natural life.
Repeat "Please continue to hold. Your call is important *snicker* to us and we will be pleased to assist you as soon as *snicker* possible" every few minutes
To what end? They can annoy all they want, but at some point they want your money.
Typically, in order to get money, they will offer to send you something.
Follow the money, find a local connection, put them in jail. Rinse. Repeat.
Okay... THAT is cool.
And then dupe it a week later.
Money?
hah. More likely you'd see the war on the world's nerds heat up considerably.
AND they're less likely to burst into flames at random. It still happens, don't get me wrong, it just happens less often.
I realize that -- But the output looks like shit PLUS it burns a huge amount of ink, so John J Consumer doesn't like those printers.
My "suggestion" (of doom and gloom for the future) was still having C+M+Y+K, but putting it in one cartridge "for user convenience"
Just think how giddy printer manufacturers would get if you had to replace the $80+ color cartridge every time you ran out of black.
The same amount of the color most people run out of, less of the rest.
Putting less of that one wouldn't make sense, they'd be wasting more and more of the other colors -- Even if the ink isn't a significant cost, it's still a cost.
By reducing the others, they could screw users who don't print using the most popular color, plus they could save a few pennies themselves.
I'm surprised they haven't attached the black cartridge to the color cartridge by now to force you to throw out the color if you happen to run out of black first.
And like with that situation, Microsoft will simply pay up or settle.
And I'm not so sure about the viability of recovering overwritten data anyway, even with electron microscopes and whatnot. Let's face it, if it was at all practical, someone, somewhere would have used the techniques to build a high-capacity drive that worked by storing new data "over the top of" old data, and there'd be a fanfare of press releases about it
People have this weird fetish about wanting their data back in a reasonable amount of time, and they seem to want the same data out as what they put in.
Sure you might be able to recover much of the drive using million dollar equipment, with a few caveats.
Not all the data will be recoverable, there will be lost bits, and it may take hours or days to read a KB.
This wouldn't be useful, especially with a million dollar price tag.