Yes, we have "privacy laws" that violate the laws of physics in place because of ignorant people having ignorant expectations about what is private. They think "because I want it to be" is sufficient. It isn't. If your cell phone conversation can be picked up by my television set, your "privacy laws" don't mean much (and yes, the old analog cell phones could be picked up on tv sets.)
I don't understand your objection to using laws (legal ones) to provide a method for enforcing "social niceties" which violate the laws of physics. I mean, that is pretty much the entire point of having laws in the first place; why would you make a law saying it's illegal to do something that's physically impossible to do? Or are you one of those people who think we shouldn't have a reasonable expectation of being able to walk down a street without being bashed to death by someone who felt like seeing if they could?
The only reason you think it'd be possible to have a private conversation with someone over lines you own or encryption you did yourself is because of your expectation that nobody else would have access to those lines, or the information required to decrypt your message. That expectation is there because of laws which say people aren't allowed to use your property without your permission, or to break into your computer and access your encryption key, or to torture you until you reveal it to them. All laws which violate the laws of physics.
I think you got the wrong end of the stick there; they weren't claiming such data doesn't exist. They were pointing out that "pro-climate change people" tend to use graphs that only show the last few hundred years, because when you look at graphs that go back a significant period of time the current warming trend suddenly stops looking abnormal and alarming.
ATI cards don't do any PhysX processing though, do they? So if you have an only-ATI system it won't make any difference since the card was never doing any of the physics processing in the first place. That requires special hardware which is found in newer nVidia cards since they bought ought Ageia (who previously were making standalone physics accelerator cards).
So the only people that are affected by this, as the summary says, are those who are using a non-nVidia card for their display, but also have an nVidia GPU with PhysX capability installed in their system. Very small number of these.
However the number is so small, it makes you wonder what the perceived advantage to nVidia is. The only people that would do it are people who really want an ATI card anyway, so aren't they just stopping those people from also chucking a few dollars in nVidia's direction? Maybe they just want to kill off the standalone Ageia cards?
Time to upgrade to Vista/Win7/Server2008, then. Now it's all C:\Users\.
Application Data seems to have been renamed AppData, amongst other things... except the old directories still exist. Only if you try to access them you get an Access Denied error, so I guess they're only pretending to exist. Kludge upon kludge for backwards compatibility?
It's even worse than that, because in most environments users don't have administrator rights and therefore cannot install application updates themselves. But as you say, there's also no good, widespread way of delivering patches for third-party applications without user involvement.
Sometimes it seems like the easiest way is just to reimage every PC every week/day.
apt and friends aren't perfect, especially when dealing with large applications. On the other hand, reinstalling the entire app does mean you don't need to keep its install files around for patches. <grumble> It seems like these days Windows has at least 3 copies of every damned application buried somewhere under \Windows\... </grumble>
The ISPs do the filtering, they don't funnel all the traffic to a central government-run filter. The government provides the ISPs with the list of things to block and the ISPs do the blocking. A particular ISP might run into performance problems but it'd only impact their customers.
I think the reason people are getting confused is because the distinction doesn't matter.
We're a small organisation and most of our remote offices use VPNs over the internet for a connection to our internal network, but we have one location a few blocks with a "direct" fiber connection and another one on the other side of the country with its own dedicated fiber link "direct" to our main office. In reality these actually terminate at our service provider's facility and they pass the traffic between them as if they were both plugged into the same switch (which is pretty much what happens), so the visible effect for us is we have a direct link from our office here to the one a few blocks away, and a separate direct link to our office a few thousand kms away.
That doesn't mean they're on the same LAN. As you mentioned, we use different subnets to keep broadcast traffic and so on from going across WAN links. In order for data from my PC to get to a PC at one of our other offices, it has to go through our floor access switch, to the core switch/router (my PC's default route), then to the ONU which takes it through our service provider's network (we don't see any of their stuff, they present it as if it was a directly switched network), out the ONU at the far end, to our router, to their access switch, and then to the PC.
For our connections that go through the VPN, it's pretty much the same thing. VPN doesn't have to mean "run a client on your PC to connect to the server", LAN-to-LAN VPNs are very common and the tunneling is all handled by the routers at each end. There's no practical difference between that and a direct switched connection across the continent (or around the world), except the VPN method will probably be a lot cheaper but slightly less performant. You won't be able to tell the difference in e.g. a ping or traceroute and you'll never know it's operating unless we tell you. In fact our office on the other side of the country used to use a VPN over in the internet from the router, and still have that as a failover: if our direct link goes down, we simply reroute the traffic via the VPN connection instead.
Think of it as if your company has built its own internet. After all, "The Internet" is just a collection of networks that are connected to each other, and that's exactly what your large company has.
In many cases, people don't bother to filter traffic between locations at the routers or put firewalls between them, but that's just laziness and/or a decision that the cost of filtering the traffic outweighs the benefits so we'll just take the risk. It's no harder to filter traffic over these kinds of links than it is to filter traffic to/from the internet. It's still being passed through the same kinds of devices.
But it doesn't take very good pictures. My N73 gave me much better quality photos than the i8510. Maybe those Carl Zeis lens really do make a difference.
Probably no need to actually notify the police in the event of non-payment. Maybe better having it randomly flash up an image with a reminder they need to pay for the "cleaning software". I think a lot of people would pay to make THAT stop.
However the main problem is that receiving money from people is hard to do without being traceable by the police.
And this kind of trojan would get you charged with unlawful use of a computer as well as distribution of child pornography images.
Probably the potential reward is far lower than the actual risk.
No need to overcomplicate things, they'll just implement what works for most people.
Most people on a LAN will have at least one (and usually, only one) network interface on the same subnet as others on the same LAN. Their public IP addresses will be identical -- most likely BNET won't try to get clients to connect via internal interfaces unless they have the same public IP address.
So it'd be pretty trivial for the client to send a list of its internal addresses to BNET and for the BNET server to decide if it's trying to play with clients that have the same public IP. If so, it finds any matching internal addresses and gets them to connect to each other.
I don't think they'd need to bother with broadcasts - their networking code would be designed to handle play over the internet. Even though unicast to each machine on the LAN is less efficient, the LAN itself is pretty fast compared to the internet. If their multiplayer is playable over the internet then that won't be a problem for local networks.
There are other options, too. If the clients have the same external IP, the server could notify them of this and they could start broadcasting and listening for discovery packets on every network interface they have. This would be a bit easier for the BNET server; it pretty much just says to each client "I think you guys are local to each other, see if you can find each other". Then leaves it up to them.
One question is whether BNET will proxy traffic for users that aren't able to connect directly to each other -- a lot of people don't have their routers set to forward ports to their own computers, and so on. That would provide a fallback method for clients on the same LAN that for some reason can't find each other.
Seems to be an ancient tradition of the finance industry, amongst others.
Typically "M" indicates 1,000, so "MM" indicates 1,000 x 1,000. I guess this comes from "mega"? I'm not entirely sure, but I've seen it around enough times to know what is intended, even if I would never use it myself.
Assuming the IP address will remain the same throughout a session is, theoretically, a bit risky. Some large proxy installations can use multiple IP addresses, and a single session can move amongst them over time.
This kind of setup is not very common, but possibly very large organisations may have multiple locations where they access the internet, and user sessions may be shuffled amongst them depending on bandwidth or availability. It's likely rare enough that you could successfully delude yourself into believing a user's IP address will always remain the same during an entire session.
Also, I'm not sure what purpose storing both the ID number and "confirmation code" in the cookie is. It doesn't increase security any more than having a longer confirmation code/session ID would, since if an attacker is able to get either value they're able to get both.
Finally, if you're not using SSL then anyone able to sniff the wire can probably hijack a user's session.
Well the SSH is only used a convenient transport mechanism, with a nice side effect of some kind of authentication that the host it thinks its transferring the data to really is that host. But all the transfers happen through our internal network anyway, so it's not really important. The reason it's preferred is because the internal server connects to the DMZ server, rather than the other way around. We try to avoid letting DMZ hosts contact internal servers whenever possible, under the assumption that the DMZ server will one day be controlled by someone we don't like. That's why it's in a different network segment, after all.
The internal master server doesn't actually run bind, though there's no particular reason it couldn't. The master puts together the zone files using an in-house templating system, then copies the internal versions to our internal resolvers (which also handle recursive requests for web browsing and so on), and copies the public versions to the public servers whenever I tell it to.
As per the article, with this vulnerability access controls don't help. So if an attacker compromised our public servers, they'd be able to use this to shut down the internal server (since the slaves need to be able to contact the master). Not so bad since this is just a DoS, but what if it could be used to execute code? Now the internal server is trivially compromised using the same flaw that was used to compromise your public server.
And what's the benefit? So we can avoid using "type master" in a config, which apparently doesn't just mean "don't try to update the zone from another server, your copy is fine and always accurate" but also means "and also do retarded things like process dynamic DNS update packets even if it's not enabled"?
Fair enough, no software is perfect and we always have to do stupid workarounds for stupid features -- it's part of the job. But I still reserve the right to bitch about it. And I think I will switch to different, less "featureful" software. Though with the aforementioned templating system we're moderately invested in the bind zonefile format so will need to use something compatible with that.
As kju responded, you can reload on particular zones if you want. The logs seem to suggest that bind itself only actually reloads the zones which have changed (i.e. mtime is newer than the last time it was loaded). I only get messages that it's loading every zone if I actually restart bind (stop and start), telling it to reload I only get messages about zones that have actually been changed.
I haven't noticed any performance hit from doing a simple reload, but I only have 120 zones.
If we were supplying secondary DNS for an (un?)trusted third party then yes I'd use bind's zone transfer mechanism. But we don't so it's not an issue - we only serve DNS for things we host/manage ourselves.
I do it that way mostly because I didn't previously consider "type master" to be a potential vulnerability (they don't have dynamic DNS or anything fancy enabled). Maybe it is time I looked into djbdns, now that it's no longer a pain in the ass to install.
As for not using the built-in zone transfer method, that's partly because I don't particularly like it, but mostly because I don't see any reason to allow access to our internal hosts from our DMZ unless absolutely necessary -- and this is not a case where it's "absolutely necessary". My own sync mechanism ensures that all transfers are initiated from the internal host rather than from an untrusted public facing server, and the content DNS servers are always up to date.
Having a play now, it seems pretty feasible to configure it as a slave but not use bind's zone transfer mechanism, using 127.0.0.1 as the master. The only issue is almost all my domains were immediately considered expired since the zones are only updated when they're actually changed. I can sort of work around that by setting the expires time really high, but it appears to now be used as the time to cache NXDOMAIN results which could have some unpleasant side effects. It seems touching the zone file solves that... so maybe I can schedule a job to touch them and reload bind each day?
I guess it's doable, but it seems like a lot of hoops just to avoid the software's built-in stupidity. Maybe it really is time to switch to something else. Thanks for the advice.
Hmm, both of my public servers are 'masters' because the zones are synced via rsync over SSH from an internal server which actually has the master copy of the zones. However as far as bind is concerned, they public-facing ones are masters.
I could potentially trick it into thinking it's a slave zone but seems too fiddly/risky, so I'll just wait for it to be patched. Nagios will tell me if they stop working, anyway.
I put together something similar with Perl. The main feature which you haven't mentioned (so possibly you haven't thought of implementing it) is that it tracks users in real-time and shows them on the map. This is just done with a simple VB script that's run by the login script, which posts its info to a CGI every 5 minutes (basic stuff like the user that's logged on, IP and MAC addresses, computer name, serial number).
A separate process polls the switches via SNMP for the MAC address tables, which tells us which MAC address is visible on which switchport. Then there's a table used to map the switchports to the tie cable connected to that port, and then the tie cable to a physical outlet number on the floor, and then finally to a location on the map.
The result is a simple web page our helpdesk guys can go to, type in a username, and see a map showing where that particular user is.
We have a completely separate system (Infra Enterprise) for actually tracking assets so there's no tie-in there, but it could potentially be used to at least track the physical location of PCs. Monitors are always a pain though.
If you came and parked your car in my front yard, am I at fault if I figure out how to drive it, and do so?
Of course you are. You're still stealing their car! They were probably violating your property rights by parking it there (i.e. trespass) and you could and, depending on the circumstances, should have them charged with it and towed; but one person's breaking of one law doesn't give you carte blanche to do what you like with them or their property.
To put it even in more stupid terms so it's clear why it'd be illegal: "If you came and parked your car in my front yard, am I at fault if I rig a bomb to it so it explodes when you come to pick it up?"
Like it or not, broadcasters have the right to broadcast their cancer-causing radiation into your home and protect it from being viewed by you unless you pay them money for the privilege. Don't like it? Then try to get the law changed... but good luck with that. Even if it was illegal, their breaking the law wouldn't give you the right to do so.
Declaring you have a legal right to listen in to any cell phone conversation that happens to be transmitted across your property is just as absurd.
I don't think it was reaching the top of the screen that was the problem, rather the fact that if you're working in an application on your second monitor, to access its menus you have to move the mouse over to the other monitor. It really is retarded.
Obviously that's our graphics designer's fault for being uncommon enough to use two monitors. Hahaha. Priceless.
I'm no psychologist, but I do sometimes read about studies into the minds of serial killers and the like. A common thread I've seen is that it's very common for the nastiest of people to have no "inner world" - so a lack of imagination may be construed as at least a warning sign. Nothing to say that everyone who lacks imagination becomes a serial killer, of course; but it may be one of the factors.
Maybe British/Australian journalists do a tiny bit of additional research to find out how an organisation writes its own name and use that format, while American journalists follow the grand tradition of expecting the world to conform to their own particular idiosyncrasies. Zing!
Seriously, look at the blog in question and see if you still think it's inappropriate to refer them as Bkis. At most, it seems a bit pointless to explain what it stands for.
It might be a bit presumptious to assume you know your cat's goals and motivations and is too silly to realise it doesn't work. It may be that she drops a piece of food into the water for other reasons. Maybe your former cat was a messy eater and it reminds her of him (wouldn't that be tragic?). Perhaps it simply makes the water taste better. Maybe it's fun to do, but only once. Why would it be fun, but only once? I don't know, I'm not a cat.
Of course, you could be right. Years of empirical evidence clearly shows that a water bowl with a piece of food in it will eventually be refilled. Perhaps she only learned the first half of the scientific method.
Another possibility is that she started doing it for a specific reason, and now continues doing it just because it's what she's always done. It's merely a comfortable habit.
Slashdot Mirror
Yes, we have "privacy laws" that violate the laws of physics in place because of ignorant people having ignorant expectations about what is private. They think "because I want it to be" is sufficient. It isn't. If your cell phone conversation can be picked up by my television set, your "privacy laws" don't mean much (and yes, the old analog cell phones could be picked up on tv sets.)
I don't understand your objection to using laws (legal ones) to provide a method for enforcing "social niceties" which violate the laws of physics. I mean, that is pretty much the entire point of having laws in the first place; why would you make a law saying it's illegal to do something that's physically impossible to do? Or are you one of those people who think we shouldn't have a reasonable expectation of being able to walk down a street without being bashed to death by someone who felt like seeing if they could?
The only reason you think it'd be possible to have a private conversation with someone over lines you own or encryption you did yourself is because of your expectation that nobody else would have access to those lines, or the information required to decrypt your message. That expectation is there because of laws which say people aren't allowed to use your property without your permission, or to break into your computer and access your encryption key, or to torture you until you reveal it to them. All laws which violate the laws of physics.
I think you got the wrong end of the stick there; they weren't claiming such data doesn't exist. They were pointing out that "pro-climate change people" tend to use graphs that only show the last few hundred years, because when you look at graphs that go back a significant period of time the current warming trend suddenly stops looking abnormal and alarming.
ATI cards don't do any PhysX processing though, do they? So if you have an only-ATI system it won't make any difference since the card was never doing any of the physics processing in the first place. That requires special hardware which is found in newer nVidia cards since they bought ought Ageia (who previously were making standalone physics accelerator cards).
So the only people that are affected by this, as the summary says, are those who are using a non-nVidia card for their display, but also have an nVidia GPU with PhysX capability installed in their system. Very small number of these.
However the number is so small, it makes you wonder what the perceived advantage to nVidia is. The only people that would do it are people who really want an ATI card anyway, so aren't they just stopping those people from also chucking a few dollars in nVidia's direction? Maybe they just want to kill off the standalone Ageia cards?
Really? I wince at not having to type any uppercase to use pathnames which clearly contain uppercase characters. Madness!
Time to upgrade to Vista/Win7/Server2008, then. Now it's all C:\Users\.
Application Data seems to have been renamed AppData, amongst other things... except the old directories still exist. Only if you try to access them you get an Access Denied error, so I guess they're only pretending to exist. Kludge upon kludge for backwards compatibility?
Oh well, I haven't had any problems so far.
It's even worse than that, because in most environments users don't have administrator rights and therefore cannot install application updates themselves. But as you say, there's also no good, widespread way of delivering patches for third-party applications without user involvement.
Sometimes it seems like the easiest way is just to reimage every PC every week/day.
apt and friends aren't perfect, especially when dealing with large applications. On the other hand, reinstalling the entire app does mean you don't need to keep its install files around for patches. <grumble> It seems like these days Windows has at least 3 copies of every damned application buried somewhere under \Windows\... </grumble>
The ISPs do the filtering, they don't funnel all the traffic to a central government-run filter. The government provides the ISPs with the list of things to block and the ISPs do the blocking. A particular ISP might run into performance problems but it'd only impact their customers.
Not that I support the filter at all, of course.
I think the reason people are getting confused is because the distinction doesn't matter.
We're a small organisation and most of our remote offices use VPNs over the internet for a connection to our internal network, but we have one location a few blocks with a "direct" fiber connection and another one on the other side of the country with its own dedicated fiber link "direct" to our main office. In reality these actually terminate at our service provider's facility and they pass the traffic between them as if they were both plugged into the same switch (which is pretty much what happens), so the visible effect for us is we have a direct link from our office here to the one a few blocks away, and a separate direct link to our office a few thousand kms away.
That doesn't mean they're on the same LAN. As you mentioned, we use different subnets to keep broadcast traffic and so on from going across WAN links. In order for data from my PC to get to a PC at one of our other offices, it has to go through our floor access switch, to the core switch/router (my PC's default route), then to the ONU which takes it through our service provider's network (we don't see any of their stuff, they present it as if it was a directly switched network), out the ONU at the far end, to our router, to their access switch, and then to the PC.
For our connections that go through the VPN, it's pretty much the same thing. VPN doesn't have to mean "run a client on your PC to connect to the server", LAN-to-LAN VPNs are very common and the tunneling is all handled by the routers at each end. There's no practical difference between that and a direct switched connection across the continent (or around the world), except the VPN method will probably be a lot cheaper but slightly less performant. You won't be able to tell the difference in e.g. a ping or traceroute and you'll never know it's operating unless we tell you. In fact our office on the other side of the country used to use a VPN over in the internet from the router, and still have that as a failover: if our direct link goes down, we simply reroute the traffic via the VPN connection instead.
Think of it as if your company has built its own internet. After all, "The Internet" is just a collection of networks that are connected to each other, and that's exactly what your large company has.
In many cases, people don't bother to filter traffic between locations at the routers or put firewalls between them, but that's just laziness and/or a decision that the cost of filtering the traffic outweighs the benefits so we'll just take the risk. It's no harder to filter traffic over these kinds of links than it is to filter traffic to/from the internet. It's still being passed through the same kinds of devices.
But it doesn't take very good pictures. My N73 gave me much better quality photos than the i8510. Maybe those Carl Zeis lens really do make a difference.
Probably no need to actually notify the police in the event of non-payment. Maybe better having it randomly flash up an image with a reminder they need to pay for the "cleaning software". I think a lot of people would pay to make THAT stop.
However the main problem is that receiving money from people is hard to do without being traceable by the police.
And this kind of trojan would get you charged with unlawful use of a computer as well as distribution of child pornography images.
Probably the potential reward is far lower than the actual risk.
No need to overcomplicate things, they'll just implement what works for most people.
Most people on a LAN will have at least one (and usually, only one) network interface on the same subnet as others on the same LAN. Their public IP addresses will be identical -- most likely BNET won't try to get clients to connect via internal interfaces unless they have the same public IP address.
So it'd be pretty trivial for the client to send a list of its internal addresses to BNET and for the BNET server to decide if it's trying to play with clients that have the same public IP. If so, it finds any matching internal addresses and gets them to connect to each other.
I don't think they'd need to bother with broadcasts - their networking code would be designed to handle play over the internet. Even though unicast to each machine on the LAN is less efficient, the LAN itself is pretty fast compared to the internet. If their multiplayer is playable over the internet then that won't be a problem for local networks.
There are other options, too. If the clients have the same external IP, the server could notify them of this and they could start broadcasting and listening for discovery packets on every network interface they have. This would be a bit easier for the BNET server; it pretty much just says to each client "I think you guys are local to each other, see if you can find each other". Then leaves it up to them.
One question is whether BNET will proxy traffic for users that aren't able to connect directly to each other -- a lot of people don't have their routers set to forward ports to their own computers, and so on. That would provide a fallback method for clients on the same LAN that for some reason can't find each other.
Seems to be an ancient tradition of the finance industry, amongst others.
Typically "M" indicates 1,000, so "MM" indicates 1,000 x 1,000. I guess this comes from "mega"? I'm not entirely sure, but I've seen it around enough times to know what is intended, even if I would never use it myself.
Assuming the IP address will remain the same throughout a session is, theoretically, a bit risky. Some large proxy installations can use multiple IP addresses, and a single session can move amongst them over time.
This kind of setup is not very common, but possibly very large organisations may have multiple locations where they access the internet, and user sessions may be shuffled amongst them depending on bandwidth or availability. It's likely rare enough that you could successfully delude yourself into believing a user's IP address will always remain the same during an entire session.
Also, I'm not sure what purpose storing both the ID number and "confirmation code" in the cookie is. It doesn't increase security any more than having a longer confirmation code/session ID would, since if an attacker is able to get either value they're able to get both.
Finally, if you're not using SSL then anyone able to sniff the wire can probably hijack a user's session.
Well the SSH is only used a convenient transport mechanism, with a nice side effect of some kind of authentication that the host it thinks its transferring the data to really is that host. But all the transfers happen through our internal network anyway, so it's not really important. The reason it's preferred is because the internal server connects to the DMZ server, rather than the other way around. We try to avoid letting DMZ hosts contact internal servers whenever possible, under the assumption that the DMZ server will one day be controlled by someone we don't like. That's why it's in a different network segment, after all.
The internal master server doesn't actually run bind, though there's no particular reason it couldn't. The master puts together the zone files using an in-house templating system, then copies the internal versions to our internal resolvers (which also handle recursive requests for web browsing and so on), and copies the public versions to the public servers whenever I tell it to.
As per the article, with this vulnerability access controls don't help. So if an attacker compromised our public servers, they'd be able to use this to shut down the internal server (since the slaves need to be able to contact the master). Not so bad since this is just a DoS, but what if it could be used to execute code? Now the internal server is trivially compromised using the same flaw that was used to compromise your public server.
And what's the benefit? So we can avoid using "type master" in a config, which apparently doesn't just mean "don't try to update the zone from another server, your copy is fine and always accurate" but also means "and also do retarded things like process dynamic DNS update packets even if it's not enabled"?
Fair enough, no software is perfect and we always have to do stupid workarounds for stupid features -- it's part of the job. But I still reserve the right to bitch about it. And I think I will switch to different, less "featureful" software. Though with the aforementioned templating system we're moderately invested in the bind zonefile format so will need to use something compatible with that.
As kju responded, you can reload on particular zones if you want. The logs seem to suggest that bind itself only actually reloads the zones which have changed (i.e. mtime is newer than the last time it was loaded). I only get messages that it's loading every zone if I actually restart bind (stop and start), telling it to reload I only get messages about zones that have actually been changed.
I haven't noticed any performance hit from doing a simple reload, but I only have 120 zones.
If we were supplying secondary DNS for an (un?)trusted third party then yes I'd use bind's zone transfer mechanism. But we don't so it's not an issue - we only serve DNS for things we host/manage ourselves.
I do it that way mostly because I didn't previously consider "type master" to be a potential vulnerability (they don't have dynamic DNS or anything fancy enabled). Maybe it is time I looked into djbdns, now that it's no longer a pain in the ass to install.
As for not using the built-in zone transfer method, that's partly because I don't particularly like it, but mostly because I don't see any reason to allow access to our internal hosts from our DMZ unless absolutely necessary -- and this is not a case where it's "absolutely necessary". My own sync mechanism ensures that all transfers are initiated from the internal host rather than from an untrusted public facing server, and the content DNS servers are always up to date.
Having a play now, it seems pretty feasible to configure it as a slave but not use bind's zone transfer mechanism, using 127.0.0.1 as the master. The only issue is almost all my domains were immediately considered expired since the zones are only updated when they're actually changed. I can sort of work around that by setting the expires time really high, but it appears to now be used as the time to cache NXDOMAIN results which could have some unpleasant side effects. It seems touching the zone file solves that... so maybe I can schedule a job to touch them and reload bind each day?
I guess it's doable, but it seems like a lot of hoops just to avoid the software's built-in stupidity. Maybe it really is time to switch to something else. Thanks for the advice.
Hmm, both of my public servers are 'masters' because the zones are synced via rsync over SSH from an internal server which actually has the master copy of the zones. However as far as bind is concerned, they public-facing ones are masters.
I could potentially trick it into thinking it's a slave zone but seems too fiddly/risky, so I'll just wait for it to be patched. Nagios will tell me if they stop working, anyway.
I put together something similar with Perl. The main feature which you haven't mentioned (so possibly you haven't thought of implementing it) is that it tracks users in real-time and shows them on the map. This is just done with a simple VB script that's run by the login script, which posts its info to a CGI every 5 minutes (basic stuff like the user that's logged on, IP and MAC addresses, computer name, serial number).
A separate process polls the switches via SNMP for the MAC address tables, which tells us which MAC address is visible on which switchport. Then there's a table used to map the switchports to the tie cable connected to that port, and then the tie cable to a physical outlet number on the floor, and then finally to a location on the map.
The result is a simple web page our helpdesk guys can go to, type in a username, and see a map showing where that particular user is.
We have a completely separate system (Infra Enterprise) for actually tracking assets so there's no tie-in there, but it could potentially be used to at least track the physical location of PCs. Monitors are always a pain though.
If you came and parked your car in my front yard, am I at fault if I figure out how to drive it, and do so?
Of course you are. You're still stealing their car! They were probably violating your property rights by parking it there (i.e. trespass) and you could and, depending on the circumstances, should have them charged with it and towed; but one person's breaking of one law doesn't give you carte blanche to do what you like with them or their property.
To put it even in more stupid terms so it's clear why it'd be illegal: "If you came and parked your car in my front yard, am I at fault if I rig a bomb to it so it explodes when you come to pick it up?"
Like it or not, broadcasters have the right to broadcast their cancer-causing radiation into your home and protect it from being viewed by you unless you pay them money for the privilege. Don't like it? Then try to get the law changed... but good luck with that. Even if it was illegal, their breaking the law wouldn't give you the right to do so.
Declaring you have a legal right to listen in to any cell phone conversation that happens to be transmitted across your property is just as absurd.
I think they were correcting the summary, which states (emphasis mine):
"The Anchorage Daily News reports that a 15 mile-long blob of unknown, 'gooey,' probably organic material is
So please to be saving your snarky comments for a more appropriate juncture. Same to the post above yours.
I don't think it was reaching the top of the screen that was the problem, rather the fact that if you're working in an application on your second monitor, to access its menus you have to move the mouse over to the other monitor. It really is retarded.
Obviously that's our graphics designer's fault for being uncommon enough to use two monitors. Hahaha. Priceless.
I'm no psychologist, but I do sometimes read about studies into the minds of serial killers and the like. A common thread I've seen is that it's very common for the nastiest of people to have no "inner world" - so a lack of imagination may be construed as at least a warning sign. Nothing to say that everyone who lacks imagination becomes a serial killer, of course; but it may be one of the factors.
Firefox's default behaviour is to tell you when new plugins have been installed, so it should be very hard not to be aware of them.
Not excusing the behaviour, just pointing out a convenient feature that helps mitigate unfriendly auto-installs.
Maybe British/Australian journalists do a tiny bit of additional research to find out how an organisation writes its own name and use that format, while American journalists follow the grand tradition of expecting the world to conform to their own particular idiosyncrasies. Zing!
Seriously, look at the blog in question and see if you still think it's inappropriate to refer them as Bkis. At most, it seems a bit pointless to explain what it stands for.
It might be a bit presumptious to assume you know your cat's goals and motivations and is too silly to realise it doesn't work. It may be that she drops a piece of food into the water for other reasons. Maybe your former cat was a messy eater and it reminds her of him (wouldn't that be tragic?). Perhaps it simply makes the water taste better. Maybe it's fun to do, but only once. Why would it be fun, but only once? I don't know, I'm not a cat.
Of course, you could be right. Years of empirical evidence clearly shows that a water bowl with a piece of food in it will eventually be refilled. Perhaps she only learned the first half of the scientific method.
Another possibility is that she started doing it for a specific reason, and now continues doing it just because it's what she's always done. It's merely a comfortable habit.