It's only inefficient if the person you kill was doing something too -- if they were just sitting there on a bench enjoying the afternoon sun there's probably no loss to overall efficiency, other than the time you spend cleaning them off your car; if you can continue using your cell phone in the car wash you might still come out ahead.
I agree that one should consider the potential effect on others when making choices, particularly with respect to safety.
But you're argument is generally ridiculous, and I have trouble believing you don't already know that. By the "it could hurt others" standard we shouldn't be allowed to drive in the first place -- you would certainly be safer in your car if the person behind you not only wasn't allow to use their phone, but also wasn't allowed to drive at all when others are on the same road.
As a society we allow individuals to make their own decisions about when and where (and to a lesser degree, how) to drive, without any particular coordination or mandatory consideration of others -- in other words we allow individuals to make choices that might negatively influence the safety of others.
Now maybe we shouldn't do that for cell phones. Maybe cell phones are so dangerous that we need to strictly regulate when and where they can be used. But the idea that individuals can't make decisions on their own anytime that decision might reduce the safety of other is patently absurd.
Of course, now that we have solid-state, fairly efficient DC-DC power converters, you don't need an inverter to get higher voltages -- you can run DC the whole way.
In fact, high-voltage DC is commonly used for power distribution in places where the additional cabling needed for 3 AC phases costs more than the conversion equipment needed to transmit as high-voltage DC.
A parallel port is a lot of complication and pins to drive 8 contacts; for $20 you could build a board with real relays that have much better electrical isolation from the motherboard and a USB or serial interface. (And that's what it cost me in a one-off construction; presumably you could do it much cheaper en mass). In addition to avoiding the space dedicated to the connector you can avoid resetting the relays on reboot -- something you can't do if you're driving the relays directly.
Serial is handy if you plan to integrate with other devices, (e.g. control your TV/lights/etc. from the HTPC).
That being said, USB is plenty fast enough to drive a whole slew of serial ports, and you can get pretty good RS-232USB adapters for $20 or less (and cheap ones for $6 or less).
First, it's pretty easy to simply publish your known_hosts file(s) -- it's not like they contain secret data. Just be sure to provide external cryptographic signatures from an individual for integrity verification, or only run the update script manually when you know the published files are valid. I do this for just my handful of personal systems because I get annoyed with updates; I can't imagine running more than a handful of machines without synchronizing the known_hosts and authorized_keys files.
If you wanted something with more host-specific control you could easily extend the basic idea to be an add/revoke list instead of an absolute list. You could even allow updates of the signing key by providing a copy of the new key signed by the old key. Just require the signing individual to provide a copy of their secret key with some sort of secret-sharing scheme before they start publishing updates. Then when they leave you get the secret-sharers together, reconstruct the signing key, and send out an updated key from the new signer via the existing publication system. You'd never have to touch individual systems again.
Second, exactly how is this ex-employee faking an internal SSH host? Did he hack into DNS or a router and redirect traffic? The only thing host keys are meant to protect against is impersonation of the host -- they do not secure any private session data. And his account authentication key presumably stops working when you disable his account; if you're worried about him having installed his key in other accounts before you removed access then this isn't a problem you can solve by revoking his old key anyway -- he could just have easily have made 100 new keys for 100 different accounts.
Entering an unlocked, unposted house is not a crime, at least not in my jurisdiction. If you enter a locked house, you're breaking and entering. If you enter a house posted with no trespassing signs, or enter a house and refuse to leave after being instructed to do so by a legal resident or their agent, you are trespassing. If you simply enter a house, stand around inside, and leave when asked without breaking anything, you have committed no crime.
Not that cookies have anything to do with geo-location of IP addresses, but you're only 98% correct. Cookies are set by the server. And servers should updates them as necessary.
But sometimes you have old cookies with names that still mean something to the server, and values that don't. It's bad programming practice, but it happens. In particular it can happen if you don't go to the site very often -- when the site is updated from v1 to v2, v2 can read v1 cookies without a problem. And when the site is updated from v2 to v3, v3 can read v2 cookies without a problem. But if you visit during v1, and don't visit again until v3, the server could be confused by your cookies that are invalid for both v2 and v3. Obviously the right choice is for the server to clear/update cookies it doesn't understand, but that doesn't always happen. And while clearing the cookies client-side is lame, it does fix such problems.
No, but physical access == need additional security regardless of OS security.
This bug is nothing to scoff at, but it does really only affect people who have untrusted users with local/pseudo-local access to machines, and that group already has increased security concerns regardless of bug like this.
I'm gonna go ahead and say that discrimination based on, you know, race is a better example of "racism". Discrimination based on national origin is called "nationalism". Note the common root words in both cases.
Now nationalism might still be a bad time, and might even lead to racism if people of a particular nationality commonly share a race, (see the use of "Mexican" as a racial slur against all latinos regardless of national origin) but it is not racism in and of itself.
if ($desired->$feature) {
if (! $existing_device_features->$feature) {
$whining_on_slashdot = kINSIGHTFUL;
} else {
$whining_on_slashdot = kREDUNDANT;
} }
Seriously, we get that one of the two things he complained about is a problem. But it's valid to point out that ONLY one of the two things is a problem, and the other is either a troll, or honest misunderstanding, and there's some value in calling out either one (entertainment or learning respectively).
Gun-type designs aren't unreliable -- in fact they are incredibly reliable, which is why the design was chosen for early bombs.
But they are terribly inefficient in terms of how much bang you get for the amount of nuclear material is required to build them. It's also somewhat difficult to predict the exact magnitude of the reaction.
Generally speaking, time alone will not reduce the strength of a permanent magnet. Heat, vibration, magnetic flux, and other forms of energy exposure can weaken permanent magnets. But in a box in your cabinet they are unlikely to encounter any sufficiently strong energy source to have a significant impact.
As someone who runs a VoIP server, I have no idea what you are talking about.
Just like email, you can send calls to <arbitrary.address@hostname> And just like email the from address is completely unverified.
Now, if you want to terminate calls from the PSTN you need an address from that network (i.e. a phone number) so the call can be routed to your VoiP/PSTN exchange. But pure VoIP calls have no need of such things, nor do VoIP->PSTN calls.
It doesn't need to be anywhere near that complicated. Just ask them to "Press 4 to be connected" if they aren't on the whitelist, and blacklist any number that fails more than twice for ~30 days.
Low-value targets aren't worth trying to crack except by very simple means, and high-value targets are worth a little human intervention to overcome whatever system you put up anyway -- as someone who write automation systems that pretend to be people for a living, I do know a little about this.
First, as the parent noted, it *is* possible to determine where the call came from. You may not have that information on your CID display, but it is available.
Second, spoofing CID is a crime in and of itself. Report that to your attorney general and let him deal with it.
It works for many people in many businesses. It maybe doesn't work for sales people, but it does for almost anyone else.
But even in sales, a simple greylist doesn't seem like a big deal: "Thank you for calling Bob's Widgets. Please press 2 to be connected to Bob, or 8 to reach our switchboard operator."
It's not a lot of work, even to do every time. But if you're worried about annoying people, just auto-whitelist any number that has successfully pressed 2 within the past 90 days, and reset the timer whenever they call back. And of course give Bob the ability to blacklist/whitelist numbers manually.
You should set your voicemail server to delete messages less than say, 3 seconds in duration, and to print the duration of other messages in the text section of the associated message, so you know what to expect before listening.
Whitelists would work for VoIP for the same reasons and with the same effectiveness as email-from whitelists -- faking the source address only help if you know which address(es) are accepted in the first place. I may be predictable, but I'm not predictable enough for a spam robot to guess the email address and phone numbers of my friends.
Why isn't "flawed data" at least sometimes the same as "some data" and therefore better than "no data"?
For example, what if you had a rain meter that leaked -- you couldn't accurately determine accumulation, and you couldn't conclusively ascertain that no water had fallen just because it was empty, but if the meter read 1.28" when you looked at it you could conclude that at least 1.28" of water had fallen since last time the collector was drained. The 1.28" reading would flawed, but the device would still provide the same sort of data it was designed to collect; so long as your understand the nature of the "flaw" in your data it is still generally useful.
What is it with you people and filesystem-level snapshots?
I'd much rather have volume or block level snapshots, like with LVM and other similar systems. Those systems provide RO and RW snapshots, dynamic partitioning, drive spanning, etc., and can be easily layered with other block-level components to provide compression, encryption, remote storage, etc. as well. All that without tying you to a single file system (though that may be a moot point on OS X, as it will only boot from HFS/HFS+ AFAIK).
If you really wanted to you could even write a script that takes no arguments other than a path name and automatically created a series of volumes of an appropriate size for the folder you selected, setup software raid to mirror them into a single device, mount the device with a compression filter, format it (with any file system) mount it normally, move the data over, drop the old data, rebind the mount point to the old path name, and update fstab. The only thing you miss here that ZFS may be able to do (I didn't check) is avoid closing the files that are moved.
I'm not saying the features ZFS has are useless -- I think they are great -- they just aren't all that new and exciting. They might be new OS X, or repackaged in a way that's easy to consume, but they are things that anyone with big disks has been doing for years.
It maybe shouldn't automatically download files by default. But I had better be able to tell it to automatically download files with certain MIME types -- I do not want a dialog box for every file I download.
Slashdot Mirror
It's only inefficient if the person you kill was doing something too -- if they were just sitting there on a bench enjoying the afternoon sun there's probably no loss to overall efficiency, other than the time you spend cleaning them off your car; if you can continue using your cell phone in the car wash you might still come out ahead.
I agree that one should consider the potential effect on others when making choices, particularly with respect to safety.
But you're argument is generally ridiculous, and I have trouble believing you don't already know that. By the "it could hurt others" standard we shouldn't be allowed to drive in the first place -- you would certainly be safer in your car if the person behind you not only wasn't allow to use their phone, but also wasn't allowed to drive at all when others are on the same road.
As a society we allow individuals to make their own decisions about when and where (and to a lesser degree, how) to drive, without any particular coordination or mandatory consideration of others -- in other words we allow individuals to make choices that might negatively influence the safety of others.
Now maybe we shouldn't do that for cell phones. Maybe cell phones are so dangerous that we need to strictly regulate when and where they can be used. But the idea that individuals can't make decisions on their own anytime that decision might reduce the safety of other is patently absurd.
Of course, now that we have solid-state, fairly efficient DC-DC power converters, you don't need an inverter to get higher voltages -- you can run DC the whole way.
In fact, high-voltage DC is commonly used for power distribution in places where the additional cabling needed for 3 AC phases costs more than the conversion equipment needed to transmit as high-voltage DC.
A parallel port is a lot of complication and pins to drive 8 contacts; for $20 you could build a board with real relays that have much better electrical isolation from the motherboard and a USB or serial interface. (And that's what it cost me in a one-off construction; presumably you could do it much cheaper en mass). In addition to avoiding the space dedicated to the connector you can avoid resetting the relays on reboot -- something you can't do if you're driving the relays directly.
Serial is handy if you plan to integrate with other devices, (e.g. control your TV/lights/etc. from the HTPC).
That being said, USB is plenty fast enough to drive a whole slew of serial ports, and you can get pretty good RS-232USB adapters for $20 or less (and cheap ones for $6 or less).
Since it was convenient to use that as a reason not to open-source the drivers.
First, it's pretty easy to simply publish your known_hosts file(s) -- it's not like they contain secret data. Just be sure to provide external cryptographic signatures from an individual for integrity verification, or only run the update script manually when you know the published files are valid. I do this for just my handful of personal systems because I get annoyed with updates; I can't imagine running more than a handful of machines without synchronizing the known_hosts and authorized_keys files.
If you wanted something with more host-specific control you could easily extend the basic idea to be an add/revoke list instead of an absolute list. You could even allow updates of the signing key by providing a copy of the new key signed by the old key. Just require the signing individual to provide a copy of their secret key with some sort of secret-sharing scheme before they start publishing updates. Then when they leave you get the secret-sharers together, reconstruct the signing key, and send out an updated key from the new signer via the existing publication system. You'd never have to touch individual systems again.
Second, exactly how is this ex-employee faking an internal SSH host? Did he hack into DNS or a router and redirect traffic? The only thing host keys are meant to protect against is impersonation of the host -- they do not secure any private session data. And his account authentication key presumably stops working when you disable his account; if you're worried about him having installed his key in other accounts before you removed access then this isn't a problem you can solve by revoking his old key anyway -- he could just have easily have made 100 new keys for 100 different accounts.
Entering an unlocked, unposted house is not a crime, at least not in my jurisdiction. If you enter a locked house, you're breaking and entering. If you enter a house posted with no trespassing signs, or enter a house and refuse to leave after being instructed to do so by a legal resident or their agent, you are trespassing. If you simply enter a house, stand around inside, and leave when asked without breaking anything, you have committed no crime.
Not that cookies have anything to do with geo-location of IP addresses, but you're only 98% correct. Cookies are set by the server. And servers should updates them as necessary.
But sometimes you have old cookies with names that still mean something to the server, and values that don't. It's bad programming practice, but it happens. In particular it can happen if you don't go to the site very often -- when the site is updated from v1 to v2, v2 can read v1 cookies without a problem. And when the site is updated from v2 to v3, v3 can read v2 cookies without a problem. But if you visit during v1, and don't visit again until v3, the server could be confused by your cookies that are invalid for both v2 and v3. Obviously the right choice is for the server to clear/update cookies it doesn't understand, but that doesn't always happen. And while clearing the cookies client-side is lame, it does fix such problems.
No, but physical access == need additional security regardless of OS security.
This bug is nothing to scoff at, but it does really only affect people who have untrusted users with local/pseudo-local access to machines, and that group already has increased security concerns regardless of bug like this.
If that's not racism, I don't know what is
I'm gonna go ahead and say that discrimination based on, you know, race is a better example of "racism". Discrimination based on national origin is called "nationalism". Note the common root words in both cases.
Now nationalism might still be a bad time, and might even lead to racism if people of a particular nationality commonly share a race, (see the use of "Mexican" as a racial slur against all latinos regardless of national origin) but it is not racism in and of itself.
if ($desired->$feature) {
if (! $existing_device_features->$feature) {
$whining_on_slashdot = kINSIGHTFUL;
} else {
$whining_on_slashdot = kREDUNDANT;
}
}
Seriously, we get that one of the two things he complained about is a problem. But it's valid to point out that ONLY one of the two things is a problem, and the other is either a troll, or honest misunderstanding, and there's some value in calling out either one (entertainment or learning respectively).
Gun-type designs aren't unreliable -- in fact they are incredibly reliable, which is why the design was chosen for early bombs.
But they are terribly inefficient in terms of how much bang you get for the amount of nuclear material is required to build them. It's also somewhat difficult to predict the exact magnitude of the reaction.
Generally speaking, time alone will not reduce the strength of a permanent magnet. Heat, vibration, magnetic flux, and other forms of energy exposure can weaken permanent magnets. But in a box in your cabinet they are unlikely to encounter any sufficiently strong energy source to have a significant impact.
You're seriously going to tell me that physical child-porn smuggling is a significant problem that we need to deal with through customs enforcement?
And how many other illegal bits of information are there? I'd like to think there isn't a whole lot of *data* I'm not allowed to poses.
No you're not. Unless the collapsing thing was a design failure.
As someone who runs a VoIP server, I have no idea what you are talking about.
Just like email, you can send calls to <arbitrary.address@hostname> And just like email the from address is completely unverified.
Now, if you want to terminate calls from the PSTN you need an address from that network (i.e. a phone number) so the call can be routed to your VoiP/PSTN exchange. But pure VoIP calls have no need of such things, nor do VoIP->PSTN calls.
It doesn't need to be anywhere near that complicated. Just ask them to "Press 4 to be connected" if they aren't on the whitelist, and blacklist any number that fails more than twice for ~30 days.
Low-value targets aren't worth trying to crack except by very simple means, and high-value targets are worth a little human intervention to overcome whatever system you put up anyway -- as someone who write automation systems that pretend to be people for a living, I do know a little about this.
First, as the parent noted, it *is* possible to determine where the call came from. You may not have that information on your CID display, but it is available.
Second, spoofing CID is a crime in and of itself. Report that to your attorney general and let him deal with it.
It works for many people in many businesses. It maybe doesn't work for sales people, but it does for almost anyone else.
But even in sales, a simple greylist doesn't seem like a big deal:
"Thank you for calling Bob's Widgets. Please press 2 to be connected to Bob, or 8 to reach our switchboard operator."
It's not a lot of work, even to do every time. But if you're worried about annoying people, just auto-whitelist any number that has successfully pressed 2 within the past 90 days, and reset the timer whenever they call back. And of course give Bob the ability to blacklist/whitelist numbers manually.
You should set your voicemail server to delete messages less than say, 3 seconds in duration, and to print the duration of other messages in the text section of the associated message, so you know what to expect before listening.
Whitelists would work for VoIP for the same reasons and with the same effectiveness as email-from whitelists -- faking the source address only help if you know which address(es) are accepted in the first place. I may be predictable, but I'm not predictable enough for a spam robot to guess the email address and phone numbers of my friends.
Why isn't "flawed data" at least sometimes the same as "some data" and therefore better than "no data"?
For example, what if you had a rain meter that leaked -- you couldn't accurately determine accumulation, and you couldn't conclusively ascertain that no water had fallen just because it was empty, but if the meter read 1.28" when you looked at it you could conclude that at least 1.28" of water had fallen since last time the collector was drained. The 1.28" reading would flawed, but the device would still provide the same sort of data it was designed to collect; so long as your understand the nature of the "flaw" in your data it is still generally useful.
What is it with you people and filesystem-level snapshots?
I'd much rather have volume or block level snapshots, like with LVM and other similar systems. Those systems provide RO and RW snapshots, dynamic partitioning, drive spanning, etc., and can be easily layered with other block-level components to provide compression, encryption, remote storage, etc. as well. All that without tying you to a single file system (though that may be a moot point on OS X, as it will only boot from HFS/HFS+ AFAIK).
If you really wanted to you could even write a script that takes no arguments other than a path name and automatically created a series of volumes of an appropriate size for the folder you selected, setup software raid to mirror them into a single device, mount the device with a compression filter, format it (with any file system) mount it normally, move the data over, drop the old data, rebind the mount point to the old path name, and update fstab. The only thing you miss here that ZFS may be able to do (I didn't check) is avoid closing the files that are moved.
I'm not saying the features ZFS has are useless -- I think they are great -- they just aren't all that new and exciting. They might be new OS X, or repackaged in a way that's easy to consume, but they are things that anyone with big disks has been doing for years.
It maybe shouldn't automatically download files by default. But I had better be able to tell it to automatically download files with certain MIME types -- I do not want a dialog box for every file I download.