Often they don't even verify that the disk contains the correct data; only that a disk is mounted with the correct name. Many games will work if you simply rename your hard drive to match the CD volume name. Others only verify a single folder or file on the disk (again, often only by name), and/or that the disk is removable.
If you're worried about disk space is may be worth checking -- just create an empty disk image and name is correctly. If that fails try adding the file/folder structure from the original disk using empty files. It doesn't work with everything, but it works with enough games to be worth checking, at least on space-limited devices.
This really begs the question because it depends on what Ebert says in his review. If he says that you should not go see this movie because the director is a known pedophile and that statement is false, then Hollywood can sue Ebert and get discovery into his methodology. The legal distinction is between opinion which is generally not actionable under the libel laws and false statements of fact which may be actionable under the libel laws if other criteria are met.
Your analogy fails in application to Google. If Ebert privately believes that the directory is a pedophile but publicly simply says "I don't think you should see this movie", without discussing his reasoning, there is no actionable cause, even if you can prove his beliefs and those beliefs are false, because he made no false statement.
Google doesn't say "Don't go here because this site looks spammy" they just say "Don't go here" by putting those results at the bottom of the page. If they don't express any reasoning behind their recommendation that recommendation cannot possibly be actionable as libel because they did not express any falsehood.
Because the credit card company doesn't actually have damages. They don't even get bad PR. Here's what happens:
1. Bad Man, Inc. charges you through his CC processor, Bad CC Processor, LLC 2. Bad CC Processor, LLC forwards the charge to your CC company. 3. You notice and dispute the charge with your CC company. 4. Your CC company gladly removes the charge from your account. 5. Your CC company refuses to pay Bad CC Processor, LLC. 6. Bad CC Processor, LLC refuses to pay Bad Man, Inc.
Now, if the CC processor wasn't dirty, they'd eventually refuse to process charges from Bad Man, Inc., because he's obviously a fraud. But they are dirty, so they don't do anything. And if Bad Man, Inc. wasn't dirty he'd probably provide evidence to support his charges and try to get payment. But is his dirty, so he doesn't do anything.
At no point in that process does the CC company lose any money, other than a few minutes of telephone support time. They probably know that Bad CC Processor, LLC is dirty too, they just don't care. Obviously it would be good for their customers if they refused to accept charges from Bad CC Processor, LLC, but they aren't very motivated because, while they have to deal with some fraud reporting, they don't lose any money, don't really risk their reputation, and still get to process the successful 65% of charges that come in. If you've ever worked in a sales-oriented company, you'll know that it's essentially impossible to get sales to walk away from existing revenue streams, even if you could sustain a better profit margin on other types of business.
It's a question of application. For a home system, where you plan to keep the disks for a long time, maybe even moving them between computers, where you run only simple RAID configurations, where you don't have the backup capacity to create a complete archive, and where you don't have the budget to have a spare controller, software RAID is probably the right choice.
But there are still plenty of applications for hardware RAID.
For one thing, most RAID cards have 512+ MB of RAM cache, which is nothing to sneeze at, particularly when it can be safely used as persistent, stable storage, which the main system memory cannot. For another, hardware RAID cards are bootable in arbitrarily complex configurations, whereas software RAID requires a RAID-1 partition for booting. And while linux software RAID works in any modern version of linux, it doesn't work very well under Windows, BSD, OS X, or any other operating system, which is a problem if you want to boot more than one OS, or need to recover data from the disks under another OS.
And they aren't mutually exclusive. On systems with lots of disks I commonly run a combination of hardware and software RAID, with hardware RAID at the bottom level to tie all my disks into bigger containers, and then tying together two such containers with RAID-1 in software. That setup gives me the flexibility of software RAID in placing those containers on different controllers (or even different hosts) while ensuring that I can recover a full data set from the low-level RAID setup even if there's a problem with the RAID-1 host.
It seems unlikely that people who complain about their weight in stones being related to the beer consumption in pints, while driving their cars at the posted 60 MPH speed limited would be considered to be using the metric system.
For all practical purposes, the English are still using the Imperial (that's Imperial England mind you, so your correction is rather indistinct anyway) system, and will likely continue for the foreseeable future. In the past few years they've declared that certain types of trade good must be labeled in metric, but that's about it. The EU wanted them to go metric, but that effort has essentially failed.
Don't buy in to the metric propaganda. It isn't an inherently better system. It provides no additional accuracy. It's decimal-based, which makes multi-unit conversions easier. But the Imperial system generally provides for division by 2, 3, and 4, which makes same-unit calculations easier. It would be handy for everyone to use the same system, to avoid conversion errors, but getting there would still require an initial conversion, which is equally prone to error, not to mention retooling and retraining.
And I think there's something to be said for diversity and valid interfaces -- while potentially error prone they provide better compatibility -- for example, when you're using a sensor that doesn't provide output in calibrated metric units -- and allow for more error checking. I believe there is value in specifying units and ensuring everything matches up, as opposed to just assuming everyone will be able to read your Word document, err, use the same units you did.
Ice you can do; water doesn't have enough thermal capacity to be useful as a storage mechanism, unless you have a ludicrous amount of space to dedicate to chilled water storage. But even ice requires a fair amount of space, and the tanks themselves are not cheap. Ice management is a feature of almost any modern chiller system, it's just not terribly popular except in the largest installations.
And even with an ice system, you only get to turn off the compressor. You still need to run all the water pumps, including the big ones the move water from the basement ice storage to the primary heat exchanger, and all the smaller loops that run to air handling units. It's less power than running the compressor, but it's not like you wouldn't need the cooling system to be on the backup generator.
Many file systems already addressed the need to call one file by more than one name, and to allow each instance of that file reference to be independently moved or renamed. It's called the hard link, and it's supported by a variety of IMAP servers as the mechanism for COPY, and by delivery agents as a mechanism for single-instance storage. No hacks, no symlinks, just multiple labels for the same file. Google is cool and all, but they didn't invent everything.
You see, it's not just a structural failure of the support system for the (at least as far as reported) otherwise working gun, it's a structural failure of the support system for the otherwise working robotic gun. Apparently. I'll admit the difference doesn't seem important to me either, but all comments here have convinced me that adding the word "robot" to any story involving a mechanical failure is grounds for anti-technology panic.
And remember, those doors at the supermarket aren't just automatic, they're... ROBOTIC. OH NOES!!1! THE SUPERMARKET DOORS COULD KILL SOMEONE IF THEIR SUPPORT TRACK FALL OFF THE WALL. WE MUST REMOVE ALL ROBOTS TO SAVE THE CHILDRENS.
Because the new refrigerants are less efficient than the old ones, which means we use more energy (i.e. burn more coal, etc.) to get the same amount of cooling. In essence, we've decided to protect against the possibility of high-altitude ozone depletion at the cost of ground-level ozone and toxic pollution and increased CO2 production.
No one even considered the big-picture environmental impact of banning CFCs, we just lurched in to action. I'm not necessarily saying it was the wrong choice -- there were certainly non-cooling uses of CFCs that we could have (and did) cut without any significant detriment to the environment. But it would have been nice if we spent less time panicking and posturing about the ozone hole and more time creating pragmatic environmental policies.
I don't disagree per say, but how many people have you worked with that didn't have the necessary technical skills, but later turned it around? I know my total would be 0, and just like the assholes, sometimes they even drag otherwise useful people down with them.
I don't see why. For one thing, the variable 64 bits of X are the MAC address of the Ethernet interface, which is the same bit of information traditionally used to manage DHCP and DHCP->DNS entries. There are DHCP-based systems for IPv4 that do this already, and if you keep using IPv4 there's no good reason to switch, but there's enough information available on the wire in IPv6 to make the same thing happen if it were imporant to you, and client-side programs, like a DHCP client but without the root privileges, are not unreasonable if you want to retrive client-side information as part of the registration process.
I'm not saying DHCP for IPv6 would be useless; there are lots of things DHCP can do that IPv6 autoconf can't. But registering a machine to a DNS entry is pretty trivial in any version of the IP protocol, particularly in IPv6 where autoconf generates some broadcast messages, even if you don't have a client-side program running.
No, it does. The RA (router advertisement) message can (and should. if one is available) include the IP address of a recursive DNS server for the subnet.
There's some complication with multi-subnet systems, but that's no different than DHCP -- you need a proxy between any two networks that aren't mutually broadcast reachable.
It's not the concept that's flawed, it's the implementation. Having well-known ports be protected is a good idea. Requiring full root access to bypass that protection is not.
The good thing about having well-known ports be protected is that unprivileged users can't grab them. Imagine this scenario:
1. Web server running on an unprotected port 80
2. Non-root user does something to make web server crash (consumes all memory, etc.)
3. Non-root user launches on own web server on port 80
4. Restarted system web server can't bind The non-root user has now effectively taken over web services on the machine. That's what the protected well-known ports is supposed to prevent.
The implementaiton flaw is that privileges are so broad. In traditional UNIX there's no way to say "allow this user program to bind to port X, but grant them no additional permissions beyond those of normal users". That's one of things SELinux is working to fix -- fine-grained access controls for privileged operations.
BS on your BS. I'm willing to believe that on newer cars this is true, but having done it myself I can tell you that the transmission in an '82 Dodge pickup has no such protection system.
I accidentally shifted in to reverse once when I bumped the shift lever while turning -- the spring on the control lever was weak and it didn't always lock into position. When the lever was moved to reverse, it most definitely reversed the transmission. Tire squeal, rapid deceleration, the whole bit. But only for about 2 seconds; after that the engine died and the transmission disengaged.
You're making this more complicated than is has to be -- I can't imagine a scenario where the first assembly of violating system is a difficult point to find. Someone actually assembled the bits into a violating system and sold it. That's the bottom of the chain, that's who you can sue.
In the case of your wipers example it's just a question of what the patent covers. If it's just the control system, then that component is in violation all by itself, and its manufacturer is at fault. If it's just the practical application of the control system then it's the auto manufacturer, because they put all the bits together.
It's also dead easy from many mail servers to just put the wrong From: header in -- this often is as easy as changing your settings in Outlook Express or Thunderbird to say you're someone else. If your SMTP server doesn't require -- not allow, but _require_ -- you to authenticate, this is often allowed. Switch ISPs or use an independent mail provider if this is the case.
SMTP AUTH does not necessarily prevent the use of invalid FROM headers. It's possible to setup such policies, but in general it's a bad idea. For one thing, it only provides protection from against people already using your mail server to inject messages, and doesn't pass that authentication forward in any useful way. If I wanted to impersonate someone else -- in your domain or another -- I could simply inject mail without using your SMTP server and claim to be whoever I like. For another, there are legitimate reasons that my FROM header may not match my the account that is authenticated. For example, role-based emails, such as support@bob.com, are not actually generated by someone logged in as "support". And when dealing with automated response systems it's vital to be able to control where messages appear to be from, so that the reply is sent to the appropriate place.
I doubt they're even all that good at that measurement -- I'd bet that consecutive IQ tests would have a fairly high variance.
But that doesn't mean they have no application. Electronic scales generally measure the stress of the support structure of their platform support arm. We assume that number is indicative of the force exerted by the platform with respect to the base of the scale. We assume that number is indicative of the force applied to the platform and its contents by gravitational attraction. And if you set the scale to display in units of mass we assume that number is indicative of the mass of that platform and its contents.
I'll grant you that IQ tests are pretty fuzzy things with less strictly defined relationships than stress, force, and mass. But just because they don't directly measure what you want to know doesn't make them useless. Like most statistics IQ tests can probably be used in useful ways, it's just important to figure out what those are before you start making claims.
You don't have to write it. You could, like Rails does, auto-generate it. You're allowed to use code to generate code. It's a groundbreaking idea I know, but it just might work.
If only there we're a second company somewhere in the world that wasn't already trying to sell something in the same market space. For them an operation and follow up care is a whole new revenue stream with little or no impact on their other revenue sources. Look, a viable product. One they might spend money to develop, and will seriously consider lobbying to make sure it isn't blocked by development by anyone.
The auto-configured address is static. If you wanted a DNS entry you'd have to set it up -- once. After that the machine would get the same address time and time again.
Their not being derivatives doesn't mean they aren't covered under copyright, it just means they're covered under the original song's copyright.
That's exactly the opposite of what "not being derivatives" means, at least in the context of new works and copyright.
There are three options here: 1. The new work is an exact, complete copy of the original, and simple copyright rules apply. 2. The new work is a derivative of the original work and cannot be distributed without permission from the original copyright holder. 3. The new work is completely independent and the original copyright holder has no claim to make against it.
Common sense dictates that short bits of a work, while they may be allowable under fair use, are derivative works. There may or may not be a legal ruling to the contrary. Regardless, if something is legally a non-derivative work there is not claim for the non-existent original copyright holder to make -- there is no original copyright holder, beside the author of the new, completely original work.
First I have to say, this whole article is ridiculous. Paper records provide auditabilitly. I don't know why anyone would think they'd increase accuracy -- that isn't the intent (or if it was the intent, someone screwed up).
Canada gets away just fine with using paper ballots. When you vote, you use a pencil to put a check in a circle next to the name of the candidate you're voting for. The circle is large and the text is large, to allow those with poor eyesight to get a better view of what's on the ballot, thus reducing mistake.
I don't care how large the circle is, blind people can't see it. And illiterate people still won't be able to read it. And some disabled people still won't be able to mark the circle. Electronic machines solve all those problems. Electronic ballots also make it easier for people to change their mind or correct a mistake without having to ask the staff for new ballot -- something they might think is not allowed, or that they might be too embarassed to do. In general it can improve participation and accuracy among people who have might have trouble with traditional ballots.
There are also increased risks for fraud, if the system is not kept appropriately transparent. And those risks certainly need to be weighed against the benefits of the new interface. That's what paper records are supposed to provide -- a way to make the system transparent, and to provide a second count for the same set of machines. Also note that the systems aren't mutually exclusive; here in Iowa we have mostly optical scan paper ballots, but also provide electronic machines for the sorts of reasons I named above.
Why would you do DNS queries on the monitored end of the connection -- SOCKS 5, which is built in to modern SSH, supports remote DNS lookups. If you can remember the IP address of your SSH host there are exactly 0 local DNS lookups to log. And thats assuming that DNS is actually logged and that anyone knows how to search those logs, which doesn't seem terribly likely at most places trying to filter children's web access.
As for disallowing SSH tunnels -- I don't know where you get "trivial". Port-based blocking is right out, as there's a command line option to bypass that. Even if you had a protocol-level filter on the line that only allowed HTTP traffic, and only allowed valid HTML characters in the HTTP stream, I could still form an SSH tunnel by base64 encoding my SSH traffic and wrapping it in HTTP requests.
If you knew what was going on and were willing to put the time in to it you might be able to stop me, but it's at best an arms race so long as I have the ability to execute programs on a node inside your network, control of some host outside your network, and any ability to form any sort of IP connection to the outside world.
That being said, I agree that the grandparent sounds like a dipwad.
Slashdot Mirror
Often they don't even verify that the disk contains the correct data; only that a disk is mounted with the correct name. Many games will work if you simply rename your hard drive to match the CD volume name. Others only verify a single folder or file on the disk (again, often only by name), and/or that the disk is removable.
If you're worried about disk space is may be worth checking -- just create an empty disk image and name is correctly. If that fails try adding the file/folder structure from the original disk using empty files. It doesn't work with everything, but it works with enough games to be worth checking, at least on space-limited devices.
This really begs the question because it depends on what Ebert says in his review. If he says that you should not go see this movie because the director is a known pedophile and that statement is false, then Hollywood can sue Ebert and get discovery into his methodology. The legal distinction is between opinion which is generally not actionable under the libel laws and false statements of fact which may be actionable under the libel laws if other criteria are met.
Your analogy fails in application to Google. If Ebert privately believes that the directory is a pedophile but publicly simply says "I don't think you should see this movie", without discussing his reasoning, there is no actionable cause, even if you can prove his beliefs and those beliefs are false, because he made no false statement.
Google doesn't say "Don't go here because this site looks spammy" they just say "Don't go here" by putting those results at the bottom of the page. If they don't express any reasoning behind their recommendation that recommendation cannot possibly be actionable as libel because they did not express any falsehood.
Who is planning to be old -- I'd like to use up my life and then be done.
Because the credit card company doesn't actually have damages. They don't even get bad PR. Here's what happens:
1. Bad Man, Inc. charges you through his CC processor, Bad CC Processor, LLC
2. Bad CC Processor, LLC forwards the charge to your CC company.
3. You notice and dispute the charge with your CC company.
4. Your CC company gladly removes the charge from your account.
5. Your CC company refuses to pay Bad CC Processor, LLC.
6. Bad CC Processor, LLC refuses to pay Bad Man, Inc.
Now, if the CC processor wasn't dirty, they'd eventually refuse to process charges from Bad Man, Inc., because he's obviously a fraud. But they are dirty, so they don't do anything. And if Bad Man, Inc. wasn't dirty he'd probably provide evidence to support his charges and try to get payment. But is his dirty, so he doesn't do anything.
At no point in that process does the CC company lose any money, other than a few minutes of telephone support time. They probably know that Bad CC Processor, LLC is dirty too, they just don't care. Obviously it would be good for their customers if they refused to accept charges from Bad CC Processor, LLC, but they aren't very motivated because, while they have to deal with some fraud reporting, they don't lose any money, don't really risk their reputation, and still get to process the successful 65% of charges that come in. If you've ever worked in a sales-oriented company, you'll know that it's essentially impossible to get sales to walk away from existing revenue streams, even if you could sustain a better profit margin on other types of business.
It's a question of application. For a home system, where you plan to keep the disks for a long time, maybe even moving them between computers, where you run only simple RAID configurations, where you don't have the backup capacity to create a complete archive, and where you don't have the budget to have a spare controller, software RAID is probably the right choice.
But there are still plenty of applications for hardware RAID.
For one thing, most RAID cards have 512+ MB of RAM cache, which is nothing to sneeze at, particularly when it can be safely used as persistent, stable storage, which the main system memory cannot. For another, hardware RAID cards are bootable in arbitrarily complex configurations, whereas software RAID requires a RAID-1 partition for booting. And while linux software RAID works in any modern version of linux, it doesn't work very well under Windows, BSD, OS X, or any other operating system, which is a problem if you want to boot more than one OS, or need to recover data from the disks under another OS.
And they aren't mutually exclusive. On systems with lots of disks I commonly run a combination of hardware and software RAID, with hardware RAID at the bottom level to tie all my disks into bigger containers, and then tying together two such containers with RAID-1 in software. That setup gives me the flexibility of software RAID in placing those containers on different controllers (or even different hosts) while ensuring that I can recover a full data set from the low-level RAID setup even if there's a problem with the RAID-1 host.
It seems unlikely that people who complain about their weight in stones being related to the beer consumption in pints, while driving their cars at the posted 60 MPH speed limited would be considered to be using the metric system.
For all practical purposes, the English are still using the Imperial (that's Imperial England mind you, so your correction is rather indistinct anyway) system, and will likely continue for the foreseeable future. In the past few years they've declared that certain types of trade good must be labeled in metric, but that's about it. The EU wanted them to go metric, but that effort has essentially failed.
Don't buy in to the metric propaganda. It isn't an inherently better system. It provides no additional accuracy. It's decimal-based, which makes multi-unit conversions easier. But the Imperial system generally provides for division by 2, 3, and 4, which makes same-unit calculations easier. It would be handy for everyone to use the same system, to avoid conversion errors, but getting there would still require an initial conversion, which is equally prone to error, not to mention retooling and retraining.
And I think there's something to be said for diversity and valid interfaces -- while potentially error prone they provide better compatibility -- for example, when you're using a sensor that doesn't provide output in calibrated metric units -- and allow for more error checking. I believe there is value in specifying units and ensuring everything matches up, as opposed to just assuming everyone will be able to read your Word document, err, use the same units you did.
Ice you can do; water doesn't have enough thermal capacity to be useful as a storage mechanism, unless you have a ludicrous amount of space to dedicate to chilled water storage. But even ice requires a fair amount of space, and the tanks themselves are not cheap. Ice management is a feature of almost any modern chiller system, it's just not terribly popular except in the largest installations.
And even with an ice system, you only get to turn off the compressor. You still need to run all the water pumps, including the big ones the move water from the basement ice storage to the primary heat exchanger, and all the smaller loops that run to air handling units. It's less power than running the compressor, but it's not like you wouldn't need the cooling system to be on the backup generator.
You're assuming that xmit() has a bandwidth greater than the CPU. In long-range communications equipment that seems unlikely at best.
Many file systems already addressed the need to call one file by more than one name, and to allow each instance of that file reference to be independently moved or renamed. It's called the hard link, and it's supported by a variety of IMAP servers as the mechanism for COPY, and by delivery agents as a mechanism for single-instance storage. No hacks, no symlinks, just multiple labels for the same file. Google is cool and all, but they didn't invent everything.
No, it's totally different.
You see, it's not just a structural failure of the support system for the (at least as far as reported) otherwise working gun, it's a structural failure of the support system for the otherwise working robotic gun. Apparently. I'll admit the difference doesn't seem important to me either, but all comments here have convinced me that adding the word "robot" to any story involving a mechanical failure is grounds for anti-technology panic.
And remember, those doors at the supermarket aren't just automatic, they're... ROBOTIC. OH NOES!!1! THE SUPERMARKET DOORS COULD KILL SOMEONE IF THEIR SUPPORT TRACK FALL OFF THE WALL. WE MUST REMOVE ALL ROBOTS TO SAVE THE CHILDRENS.
Because the new refrigerants are less efficient than the old ones, which means we use more energy (i.e. burn more coal, etc.) to get the same amount of cooling. In essence, we've decided to protect against the possibility of high-altitude ozone depletion at the cost of ground-level ozone and toxic pollution and increased CO2 production.
No one even considered the big-picture environmental impact of banning CFCs, we just lurched in to action. I'm not necessarily saying it was the wrong choice -- there were certainly non-cooling uses of CFCs that we could have (and did) cut without any significant detriment to the environment. But it would have been nice if we spent less time panicking and posturing about the ozone hole and more time creating pragmatic environmental policies.
I don't disagree per say, but how many people have you worked with that didn't have the necessary technical skills, but later turned it around? I know my total would be 0, and just like the assholes, sometimes they even drag otherwise useful people down with them.
I don't see why. For one thing, the variable 64 bits of X are the MAC address of the Ethernet interface, which is the same bit of information traditionally used to manage DHCP and DHCP->DNS entries. There are DHCP-based systems for IPv4 that do this already, and if you keep using IPv4 there's no good reason to switch, but there's enough information available on the wire in IPv6 to make the same thing happen if it were imporant to you, and client-side programs, like a DHCP client but without the root privileges, are not unreasonable if you want to retrive client-side information as part of the registration process.
I'm not saying DHCP for IPv6 would be useless; there are lots of things DHCP can do that IPv6 autoconf can't. But registering a machine to a DNS entry is pretty trivial in any version of the IP protocol, particularly in IPv6 where autoconf generates some broadcast messages, even if you don't have a client-side program running.
No, it does. The RA (router advertisement) message can (and should. if one is available) include the IP address of a recursive DNS server for the subnet.
There's some complication with multi-subnet systems, but that's no different than DHCP -- you need a proxy between any two networks that aren't mutually broadcast reachable.
It's not the concept that's flawed, it's the implementation. Having well-known ports be protected is a good idea. Requiring full root access to bypass that protection is not.
The good thing about having well-known ports be protected is that unprivileged users can't grab them. Imagine this scenario:
1. Web server running on an unprotected port 80
2. Non-root user does something to make web server crash (consumes all memory, etc.)
3. Non-root user launches on own web server on port 80
4. Restarted system web server can't bind
The non-root user has now effectively taken over web services on the machine. That's what the protected well-known ports is supposed to prevent.
The implementaiton flaw is that privileges are so broad. In traditional UNIX there's no way to say "allow this user program to bind to port X, but grant them no additional permissions beyond those of normal users". That's one of things SELinux is working to fix -- fine-grained access controls for privileged operations.
BS on your BS. I'm willing to believe that on newer cars this is true, but having done it myself I can tell you that the transmission in an '82 Dodge pickup has no such protection system.
I accidentally shifted in to reverse once when I bumped the shift lever while turning -- the spring on the control lever was weak and it didn't always lock into position. When the lever was moved to reverse, it most definitely reversed the transmission. Tire squeal, rapid deceleration, the whole bit. But only for about 2 seconds; after that the engine died and the transmission disengaged.
UNFAIL
You're making this more complicated than is has to be -- I can't imagine a scenario where the first assembly of violating system is a difficult point to find. Someone actually assembled the bits into a violating system and sold it. That's the bottom of the chain, that's who you can sue.
In the case of your wipers example it's just a question of what the patent covers. If it's just the control system, then that component is in violation all by itself, and its manufacturer is at fault. If it's just the practical application of the control system then it's the auto manufacturer, because they put all the bits together.
It's also dead easy from many mail servers to just put the wrong From: header in -- this often is as easy as changing your settings in Outlook Express or Thunderbird to say you're someone else. If your SMTP server doesn't require -- not allow, but _require_ -- you to authenticate, this is often allowed. Switch ISPs or use an independent mail provider if this is the case.
SMTP AUTH does not necessarily prevent the use of invalid FROM headers. It's possible to setup such policies, but in general it's a bad idea. For one thing, it only provides protection from against people already using your mail server to inject messages, and doesn't pass that authentication forward in any useful way. If I wanted to impersonate someone else -- in your domain or another -- I could simply inject mail without using your SMTP server and claim to be whoever I like. For another, there are legitimate reasons that my FROM header may not match my the account that is authenticated. For example, role-based emails, such as support@bob.com, are not actually generated by someone logged in as "support". And when dealing with automated response systems it's vital to be able to control where messages appear to be from, so that the reply is sent to the appropriate place.
I doubt they're even all that good at that measurement -- I'd bet that consecutive IQ tests would have a fairly high variance.
But that doesn't mean they have no application. Electronic scales generally measure the stress of the support structure of their platform support arm. We assume that number is indicative of the force exerted by the platform with respect to the base of the scale. We assume that number is indicative of the force applied to the platform and its contents by gravitational attraction. And if you set the scale to display in units of mass we assume that number is indicative of the mass of that platform and its contents.
I'll grant you that IQ tests are pretty fuzzy things with less strictly defined relationships than stress, force, and mass. But just because they don't directly measure what you want to know doesn't make them useless. Like most statistics IQ tests can probably be used in useful ways, it's just important to figure out what those are before you start making claims.
You don't have to write it. You could, like Rails does, auto-generate it. You're allowed to use code to generate code. It's a groundbreaking idea I know, but it just might work.
If only there we're a second company somewhere in the world that wasn't already trying to sell something in the same market space. For them an operation and follow up care is a whole new revenue stream with little or no impact on their other revenue sources. Look, a viable product. One they might spend money to develop, and will seriously consider lobbying to make sure it isn't blocked by development by anyone.
The auto-configured address is static. If you wanted a DNS entry you'd have to set it up -- once. After that the machine would get the same address time and time again.
Their not being derivatives doesn't mean they aren't covered under copyright, it just means they're covered under the original song's copyright.
That's exactly the opposite of what "not being derivatives" means, at least in the context of new works and copyright.
There are three options here:
1. The new work is an exact, complete copy of the original, and simple copyright rules apply.
2. The new work is a derivative of the original work and cannot be distributed without permission from the original copyright holder.
3. The new work is completely independent and the original copyright holder has no claim to make against it.
Common sense dictates that short bits of a work, while they may be allowable under fair use, are derivative works. There may or may not be a legal ruling to the contrary. Regardless, if something is legally a non-derivative work there is not claim for the non-existent original copyright holder to make -- there is no original copyright holder, beside the author of the new, completely original work.
First I have to say, this whole article is ridiculous. Paper records provide auditabilitly. I don't know why anyone would think they'd increase accuracy -- that isn't the intent (or if it was the intent, someone screwed up).
Canada gets away just fine with using paper ballots. When you vote, you use a pencil to put a check in a circle next to the name of the candidate you're voting for. The circle is large and the text is large, to allow those with poor eyesight to get a better view of what's on the ballot, thus reducing mistake.
I don't care how large the circle is, blind people can't see it. And illiterate people still won't be able to read it. And some disabled people still won't be able to mark the circle. Electronic machines solve all those problems. Electronic ballots also make it easier for people to change their mind or correct a mistake without having to ask the staff for new ballot -- something they might think is not allowed, or that they might be too embarassed to do. In general it can improve participation and accuracy among people who have might have trouble with traditional ballots.
There are also increased risks for fraud, if the system is not kept appropriately transparent. And those risks certainly need to be weighed against the benefits of the new interface. That's what paper records are supposed to provide -- a way to make the system transparent, and to provide a second count for the same set of machines. Also note that the systems aren't mutually exclusive; here in Iowa we have mostly optical scan paper ballots, but also provide electronic machines for the sorts of reasons I named above.
Why would you do DNS queries on the monitored end of the connection -- SOCKS 5, which is built in to modern SSH, supports remote DNS lookups. If you can remember the IP address of your SSH host there are exactly 0 local DNS lookups to log. And thats assuming that DNS is actually logged and that anyone knows how to search those logs, which doesn't seem terribly likely at most places trying to filter children's web access.
As for disallowing SSH tunnels -- I don't know where you get "trivial". Port-based blocking is right out, as there's a command line option to bypass that. Even if you had a protocol-level filter on the line that only allowed HTTP traffic, and only allowed valid HTML characters in the HTTP stream, I could still form an SSH tunnel by base64 encoding my SSH traffic and wrapping it in HTTP requests.
If you knew what was going on and were willing to put the time in to it you might be able to stop me, but it's at best an arms race so long as I have the ability to execute programs on a node inside your network, control of some host outside your network, and any ability to form any sort of IP connection to the outside world.
That being said, I agree that the grandparent sounds like a dipwad.