I'm afraid this is not enough of an explanation. The reasons for poor interfaces vary. I was somewhat irritated when I wrote that comment, I'd just spent a long time with a particularly bad interface.
But far, far too many of our open source interfaces are an exploration of "Exciting! Java! Widgets! Popping! Up! Everywhere!" and doing things that no one actually cares about, rather than providing consistent and meaningful choices.
I've offered money to change these things. I've offered _good_ money and contracts to fix and change some interfaces, and I've written fixes and patches myself. It's not often considered important enough, by the developers to do so. Like security, the interface is often dealt with as an afterthought to be glued onto the product later.
Oh, dear. I don't suppose your dismay and frustration show up in your bug reports, do they? That can help keep them from being read or corrected.
I've certainly seen the "I'm right, you users don't understand!" problem from project leads. Goodness, I've even published popular workarounds, for up to a decade, to some design "choices" that were bugs in real use until someone else took over a project or a new project was released that did a better job of it. Patience is very helpful. So is actually contributing to the user community.
In fact, one of the most fun activities for a moderately experienced user is to take up answering the questions from the "newbs", and helping keep the load off the core developers. Be cautious and ready to escalate, but it can help people a lot if someone closer to their own experience level can help them out.
Oh, dear Lord, user interfaces. They're tough to write well, and one of the great flaws of oopen source. Try the guidelines at the bottom of http://catb.org/~esr/writings/cups-horror.html.
One thing Eric missed in his rant is "throwing things out". Most of CPAN, for example, should have been flushed down the toilet as incompatible with thermodynamics, much less the last five yearf of Perl releases, years ago. Subversion should have thrown out Berkeley DB as an unstable piece of unusable debris years ago. And password based FTP should have been discarded as a bad idea 10 years ago, but Matlab continues to rely on it for upstream file transfer with no built-in HTTPS or WebDAV.
I'd settle for "thorough" bug reports. Some bugs are difficult to repeat under slightly different setups, and the difference can be difficult to capture for a developer. I just spent some time, for example, reporting an authentication bug with a VPN setup, which expended over time to be a complete inability to do password authentication for certain Kerberos based tools. It turned out the official corporate NTP servers were deranged, and my clock chip was the first to drift far enough out of compliance for NTP to fail.
No one else was seeing the bug. But the presence of the early reports, from a competent programmer who'd already done all the easy fixes, helped get the big fixed early, and properly. And my early discovery of the real fix and publication of the short-term workaround was even more useful.
That's why I listed the various DOS based releases. NT and Win9x coexisted for years: while NT 3.5 came out before Win95, NT 4 came out after, and was billed as far more compatible with Windows 9x applications (which it was). That increasing compatibility was a source of rampaging security issues.
_Of course_ Win95 included DOS. DOS was its kernel. What did you think that "boot in DOS mode" option was for? That wasn't removed until WinME, but even WinME was still a DOS kernel.
First, I'm hardly "ignorant". I've also had access, with MSDN and other licenses. Those non-disclosure agreements a re a real problem for publishing your patches or, in many cases, observations. If you've also had access to _VMS_ source code, and you go look at the memory modules, you can see where Cutler lifted his old work wholesale. You can also review the legal history of DEC and Microsoft concerning this piracy, as much of it as you can find not under court seal. Cutler duplicated or appropriated code that he did for DEC: that was both copyright and non-compete violations on his part, and he got caught. He lifted it wholesale.
Security issues are hardly restricted to a 10-minute script's ability. The video driver handling, for example, is a rampant disaster in security terms: it's far too easy to abuse the video driver installations to leverage privilege. So is the stunning hash of undocumented DLL misarrangement and dependencies and extremely strange scattering of components around the operating system by different installers, different installers, and especially Microsoft themselves.
Also, are you only discussing "NT 3.x" or "NT 4" as "NT"? Windows XP is NT 5, Vista is NT 6, Windows 7 is NT 7 based on the kernel history. (Where did you think that number came from?) I'll admit that NT 3 and 4 were cleaner, but they weren't consumer compatible OS's. Those non-Microsoft packages are what they have to work with, and the underlying architecture those work with contributes stunningly to the lack of security. Couple that with the closed source, and you have massive security and support issues, issues we see every day and which remain documented but unpublished by groups like CERT because they vendor has not published a fix, nor even admitted publicly that they exist. Look at that video driver issue.
Active Directory is a useful interface to the underlying protocols. My poinit with them is that Microsoft didn't write *any* of those technologies, only the interface on top of it. Their underlying reliability and security is therefore not Microsoft's fault by any means.
You've a valid point about miscomparing NetBIOS to DNS, rather than its more direct analog, IP. I was admittedly referring only to the naming scheme, the legacies of which we see today abused widely in place of actual DNS, and the pain of integrating between the NetBIOS naming and DNS and the confusion among them by people who only see them as "the machine's name".
What? "Culture", better written _core_ utilities, and the open access to the base software rather than the secretive and obscure security models of NT all contribute massively to Linux security by comparison. The smaller system components are easier and safer to do well. Also, while the kernel of NT was based on VMS when David Cutler stole his old work from DEC, it was forced to integrate numerous historical poor choices of DOS, Windows 3.x, and Windows 95 to provide backwards compatibility. These have been a _disaster_ in security terms, and very difficult to address due to the closed nature of the code and difficulty of upgrading other components to preserve compatibility.
Some of the most "secure" components of NT, such as Active Directory, are actually due to its integration of far more secure open source components such as Kerberos, and its use of open standards such as DNS, DHCP, and LDAP to replace Microsoft's older versions of "NetBIOS" (which they also did not invent, it came from IBM and IBM discarded it years ago).
And perform cold fusion in the coffee machine while you're at it.
The "willing to work overtime" is in direct conflict with the "start a business on the side". That business on the side is often a direct violation of your employee contract if it's related to your primary work, and keeping them separate can be very, very difficult: I've seen full-time employees spend their morning, on corporate systems, on their contract work, and notified their supervisor at both worksites that they were doing it. (It was obvious from the phone number and the IP address they were using to connect to the contracting site.)
Overtime is tricky. Salaried employees may not be able to charge "overtime", even when their paychecks are based on "40 hours" of reported work. Even hourly employees, paid for 80 hours a week, usually have their work quality degrade badly, and some workplaces demand it on a frequent basis. (It's common in startups or companies that can't get out of the startup mentality.)
Your suggestion of conveying willingness to work overtime, but for critical work only, is a very important one, and I agree with it. But get the requests on email or on paper if you can, and make sure it shows up on your progress reports or status reports, so your boss can use it for leverage to get more time for critical projects.
Every boss has a hobby. Online Poker, theatre, Warhammer, something. And the bosses often share a hobby, potentially a different one as they move up the ranks. For those occasions when you have to get help to overrule your immediate supervisor, it is _immensely_ helpful if his boss or the corporate president know your name from somewhere as someone at least socially competent.
This goes both ways: finding out the janitor's name and the helpdesk people's names and sending them and their supervisor's thank you's when they go the extra mile for you helps them remember you in office gossip. Finding out if the people above you, and below you, have kids and helping cover if they have to be home with a kid is paid back a lot at annual review time.
They're busy killing people in Iraq and Afghanistan. Al Queada has _exploded_ in political and "terrorist" operations there, it's become part of daily politics. It's also far more effective for their immediate goals of political control, fairly effectively counteracting the military might of the wealthiest nation on Earth.
After all, it worked against the British Empire and later the Soviet Union as invaders of Afghanistan.
Unfortunately, there's no need to do so. As a few people have pointed out, quite a lot of Cisco gear has been identified as having hardcoded backdoor passwords for "law enforcement" uses. Simply steal _those_ passwords, or obtain them from wherever crackers publish them, and you have quite a lot of network access. It's a major reason that relying on your VPN, your firewall, or your NAT for network security is clearly insufficient.
Oh, dear. So that excuses passwords written in cleartext and sent via email? Failure to patch systems for published, known security holes? Leaving the backup tapes in an unlocked cabinet? Using NFS to store medical data in a place with open access wireless services?
The "chair" in question is not necessarily the one the user is sitting in.
It's very handy to be able to destroy a target with hundreds of thousands of dollars of missiles from thousands of miles away. It is, unfortunately, very cheap to buy rocket launchers in Afghanistan and Iraq, and they can change position in minutes: they're natives, they live there, they can leave weapons on the ground and walk away while the next few guerrillas take up arms and start shooting. And it's cheap to train up a few idiots to pop up on a rooftop, shoot weapons, and run away: the Afghans developed it to a high art against the Russian army while the older of us Slashdot readers were kids.
Spam was the logical outcome of low sending cost and extremely few consequences. The niche exploited by people like Canter&Siegel, and by AOL's incessant spamming, has its origins in junk mail advertising, and before that in the wars for public billboard space in the cities of Europe, and doubtless had counterparts in ancient Rome and Athens and Jerusalem. and Babylon. In fact, the Tower of Babylon is a good metaphor for what happens now with spam flooding desirable traffic.
The problem isn't a technical one. It's a social one: The cost of individual messages is very low, especially if the resources to send them are stolen. And the consequences of sending them in bulk are, so far, insufficient to discourage the spammers or the professionals who provide them the tools. Even though spam seems to be rarely profitable, the _expectation_ of profit is enough to lure numerous hopeful or larcenous participants. Prosecutions remain rare, and the upstream providers seem happy to take the cash since they so rarely face consequences for hosting professional operations, and the newer zombie nets are too expensive to bother cleaning up.
There have been legal attempts to reduce spam. But spam is built on such a classic business model, that of junk mail, that any legislative effort runs headlong into the Direct Marketing Association and their lobbyists, or the equivalent in other countries. As individual technical fixes are applied, other versions of spam services expand to quickly fill the economic niche. So unless the technologically based approaches or the social approaches such as reasonable laws get so effective that the _apparent_ profit is eliminated, we're going to continue to see the deluge.
No, he didn't withhold "the programming knowledge". He withheld the passwords. Moreover, he was _already_ paid: the contract still clearly applies, unless the city actually breached the contract in some way. Forcing the city to continue to dance to his tune, without that kind of a breach of contract on the city's part, was clearly a breach of contract unless his contract was _very_ strange.
I. Intellectual work product. Any writing, invention, process, creative mark or other work which Employee may make or conceive of, either alone or with others, at any time while Employee is an employee of Employer which in any way relates to the business of Employer, shall be the sole property of Employer and Employee shall have no rights in nor claims thereto (including, but not limited to, rights or claims accruing under the copyright, trademark, or patent laws of any country).
Oh, dear. So when a conductor retires, he gets to take the keys to the train with him, even if they'r ethe only keys, because handing them in isn't his job anymore? No, you leave all the keys behind on your way out the door. If you happen to still have a set of keys, or other work equipment, in your home or your vehicle, you don't get to keep them because you're no longer an employee. You have to return them _precisely_ because you are no longer an employee.
Mr. Childs was mishandled: given the cost and embarrassment of this case, he should have given a written set of passwords directly to the mayor, washed his hands of it, and allowed the mayor to be the fool who shared the passwords. Given the alleged incompetence of the consultants and employees who would wind up with the vital passwords, notifying the press or the city emergency departments of the risk so that they can be prepared for system failures might also be reasonable.
Oh, dear. Does anyone else remember anonymous posting services for Usenet? We've had things like this happen before. Generally, the anonymizing services have safely ignored such rulings, but on occasion the police have shown up with search warrants for ridiculous and trumped up charges. (http://en.wikipedia.org/wiki/Anon.penet.fi)
It's a dangerous world out there. Hosting anonymous providers carries some legal risks, even if they're ridiculous and unexpected.
Until you store it on the corporate file server. Or your brand new laptop where the vendor didn't provide it encrypted and you lack 20 hours to do the re-install and downloads of patches. Or your backup tapes get stolen. Or you share client data with an FTP server because that's all your software will support. Or your corporate president refuses to let you re-image their laptop with encryption. Or some clever salesman puts their customer data on a USB stick and drops it in a bar.
These are not small issues, and encrypting a particular desktop is only the start of the issues.
No, I'm pointing out that there are circumstances where duplicate MAC addresses are useful, and as I understand it, this can create havoc for IPv6.
As long as the duplicate MAC addresses are on different subnets, so that the same router or gateway cannot see both, it's not a problem. So I can run _precisely_ the same virtualized OS image in two different locations, without having to modify the virtualized system's hosting data or its network configuration tools. There are times, though not many, when this is handy.
_Yes_. This especially includes _hosting_ of services. The ability of a few ill-behaved clients or employees to host websites or FTP or IRC or mail or torrent services, and to absolutely overwhelm resources and clutter a network is stunning. NAT has been very effective in reducing this to manageable levels in my environments. I don't want my backup server or my authentication server exposed to the Internet, and I don't want to have to write clever firewall rules to protect it.
I suspect that you've not run into some of the weirder security issues I've run into over the years. A public facing IP address is, essentially, an attractive nuisance and will be attacked. I don't see IPv6 helping this at all, but the limitations of IPv4 space and the pressure to use NAT have actually been helpful in security terms.
But it's not my problem. It's all effectively occurring on the NAT box, which is a cheap appliance and built into my cable modem box or my firewall. It's already paid for as a default feature and works fine, I don't have to do any of the work locally.
You've a good point about connection tracking, but have you seen it as an issue in the real world? I've certainly not.
Duplicate network addresses are not uncommon with virtualized clone images. Renegotiating MAC addresses as guests are cloned is a longstanding problem, and the address spaces for the guest hosts is getting tricky to negotiate and avoid accidental duplicates.
Slashdot Mirror
I'm afraid this is not enough of an explanation. The reasons for poor interfaces vary. I was somewhat irritated when I wrote that comment, I'd just spent a long time with a particularly bad interface.
But far, far too many of our open source interfaces are an exploration of "Exciting! Java! Widgets! Popping! Up! Everywhere!" and doing things that no one actually cares about, rather than providing consistent and meaningful choices.
I've offered money to change these things. I've offered _good_ money and contracts to fix and change some interfaces, and I've written fixes and patches myself. It's not often considered important enough, by the developers to do so. Like security, the interface is often dealt with as an afterthought to be glued onto the product later.
Oh, dear. I don't suppose your dismay and frustration show up in your bug reports, do they? That can help keep them from being read or corrected.
I've certainly seen the "I'm right, you users don't understand!" problem from project leads. Goodness, I've even published popular workarounds, for up to a decade, to some design "choices" that were bugs in real use until someone else took over a project or a new project was released that did a better job of it. Patience is very helpful. So is actually contributing to the user community.
In fact, one of the most fun activities for a moderately experienced user is to take up answering the questions from the "newbs", and helping keep the load off the core developers. Be cautious and ready to escalate, but it can help people a lot if someone closer to their own experience level can help them out.
Oh, dear Lord, user interfaces. They're tough to write well, and one of the great flaws of oopen source. Try the guidelines at the bottom of http://catb.org/~esr/writings/cups-horror.html.
One thing Eric missed in his rant is "throwing things out". Most of CPAN, for example, should have been flushed down the toilet as incompatible with thermodynamics, much less the last five yearf of Perl releases, years ago. Subversion should have thrown out Berkeley DB as an unstable piece of unusable debris years ago. And password based FTP should have been discarded as a bad idea 10 years ago, but Matlab continues to rely on it for upstream file transfer with no built-in HTTPS or WebDAV.
What are these idiots thinking?
I'd settle for "thorough" bug reports. Some bugs are difficult to repeat under slightly different setups, and the difference can be difficult to capture for a developer. I just spent some time, for example, reporting an authentication bug with a VPN setup, which expended over time to be a complete inability to do password authentication for certain Kerberos based tools. It turned out the official corporate NTP servers were deranged, and my clock chip was the first to drift far enough out of compliance for NTP to fail.
No one else was seeing the bug. But the presence of the early reports, from a competent programmer who'd already done all the easy fixes, helped get the big fixed early, and properly. And my early discovery of the real fix and publication of the short-term workaround was even more useful.
That's why I listed the various DOS based releases. NT and Win9x coexisted for years: while NT 3.5 came out before Win95, NT 4 came out after, and was billed as far more compatible with Windows 9x applications (which it was). That increasing compatibility was a source of rampaging security issues.
_Of course_ Win95 included DOS. DOS was its kernel. What did you think that "boot in DOS mode" option was for? That wasn't removed until WinME, but even WinME was still a DOS kernel.
Oh, dear.
First, I'm hardly "ignorant". I've also had access, with MSDN and other licenses. Those non-disclosure agreements a re a real problem for publishing your patches or, in many cases, observations. If you've also had access to _VMS_ source code, and you go look at the memory modules, you can see where Cutler lifted his old work wholesale. You can also review the legal history of DEC and Microsoft concerning this piracy, as much of it as you can find not under court seal. Cutler duplicated or appropriated code that he did for DEC: that was both copyright and non-compete violations on his part, and he got caught. He lifted it wholesale.
Security issues are hardly restricted to a 10-minute script's ability. The video driver handling, for example, is a rampant disaster in security terms: it's far too easy to abuse the video driver installations to leverage privilege. So is the stunning hash of undocumented DLL misarrangement and dependencies and extremely strange scattering of components around the operating system by different installers, different installers, and especially Microsoft themselves.
Also, are you only discussing "NT 3.x" or "NT 4" as "NT"? Windows XP is NT 5, Vista is NT 6, Windows 7 is NT 7 based on the kernel history. (Where did you think that number came from?) I'll admit that NT 3 and 4 were cleaner, but they weren't consumer compatible OS's. Those non-Microsoft packages are what they have to work with, and the underlying architecture those work with contributes stunningly to the lack of security. Couple that with the closed source, and you have massive security and support issues, issues we see every day and which remain documented but unpublished by groups like CERT because they vendor has not published a fix, nor even admitted publicly that they exist. Look at that video driver issue.
Active Directory is a useful interface to the underlying protocols. My poinit with them is that Microsoft didn't write *any* of those technologies, only the interface on top of it. Their underlying reliability and security is therefore not Microsoft's fault by any means.
You've a valid point about miscomparing NetBIOS to DNS, rather than its more direct analog, IP. I was admittedly referring only to the naming scheme, the legacies of which we see today abused widely in place of actual DNS, and the pain of integrating between the NetBIOS naming and DNS and the confusion among them by people who only see them as "the machine's name".
No, it's been declared a munition, and your publication has been blocked lest it be exported.
http://en.wikipedia.org/wiki/Phil_Zimmermann#Criminal_investigation_by_US_Customs
What? "Culture", better written _core_ utilities, and the open access to the base software rather than the secretive and obscure security models of NT all contribute massively to Linux security by comparison. The smaller system components are easier and safer to do well. Also, while the kernel of NT was based on VMS when David Cutler stole his old work from DEC, it was forced to integrate numerous historical poor choices of DOS, Windows 3.x, and Windows 95 to provide backwards compatibility. These have been a _disaster_ in security terms, and very difficult to address due to the closed nature of the code and difficulty of upgrading other components to preserve compatibility.
Some of the most "secure" components of NT, such as Active Directory, are actually due to its integration of far more secure open source components such as Kerberos, and its use of open standards such as DNS, DHCP, and LDAP to replace Microsoft's older versions of "NetBIOS" (which they also did not invent, it came from IBM and IBM discarded it years ago).
And perform cold fusion in the coffee machine while you're at it.
The "willing to work overtime" is in direct conflict with the "start a business on the side". That business on the side is often a direct violation of your employee contract if it's related to your primary work, and keeping them separate can be very, very difficult: I've seen full-time employees spend their morning, on corporate systems, on their contract work, and notified their supervisor at both worksites that they were doing it. (It was obvious from the phone number and the IP address they were using to connect to the contracting site.)
Overtime is tricky. Salaried employees may not be able to charge "overtime", even when their paychecks are based on "40 hours" of reported work. Even hourly employees, paid for 80 hours a week, usually have their work quality degrade badly, and some workplaces demand it on a frequent basis. (It's common in startups or companies that can't get out of the startup mentality.)
Your suggestion of conveying willingness to work overtime, but for critical work only, is a very important one, and I agree with it. But get the requests on email or on paper if you can, and make sure it shows up on your progress reports or status reports, so your boss can use it for leverage to get more time for critical projects.
Every boss has a hobby. Online Poker, theatre, Warhammer, something. And the bosses often share a hobby, potentially a different one as they move up the ranks. For those occasions when you have to get help to overrule your immediate supervisor, it is _immensely_ helpful if his boss or the corporate president know your name from somewhere as someone at least socially competent.
This goes both ways: finding out the janitor's name and the helpdesk people's names and sending them and their supervisor's thank you's when they go the extra mile for you helps them remember you in office gossip. Finding out if the people above you, and below you, have kids and helping cover if they have to be home with a kid is paid back a lot at annual review time.
They're busy killing people in Iraq and Afghanistan. Al Queada has _exploded_ in political and "terrorist" operations there, it's become part of daily politics. It's also far more effective for their immediate goals of political control, fairly effectively counteracting the military might of the wealthiest nation on Earth.
After all, it worked against the British Empire and later the Soviet Union as invaders of Afghanistan.
Unfortunately, there's no need to do so. As a few people have pointed out, quite a lot of Cisco gear has been identified as having hardcoded backdoor passwords for "law enforcement" uses. Simply steal _those_ passwords, or obtain them from wherever crackers publish them, and you have quite a lot of network access. It's a major reason that relying on your VPN, your firewall, or your NAT for network security is clearly insufficient.
Oh, dear. So that excuses passwords written in cleartext and sent via email? Failure to patch systems for published, known security holes? Leaving the backup tapes in an unlocked cabinet? Using NFS to store medical data in a place with open access wireless services?
The "chair" in question is not necessarily the one the user is sitting in.
It's very handy to be able to destroy a target with hundreds of thousands of dollars of missiles from thousands of miles away. It is, unfortunately, very cheap to buy rocket launchers in Afghanistan and Iraq, and they can change position in minutes: they're natives, they live there, they can leave weapons on the ground and walk away while the next few guerrillas take up arms and start shooting. And it's cheap to train up a few idiots to pop up on a rooftop, shoot weapons, and run away: the Afghans developed it to a high art against the Russian army while the older of us Slashdot readers were kids.
No, sadly enough, they are our are our eras baby "Vietnam". Haven't you been paying attention?
Spam was the logical outcome of low sending cost and extremely few consequences. The niche exploited by people like Canter&Siegel, and by AOL's incessant spamming, has its origins in junk mail advertising, and before that in the wars for public billboard space in the cities of Europe, and doubtless had counterparts in ancient Rome and Athens and Jerusalem. and Babylon. In fact, the Tower of Babylon is a good metaphor for what happens now with spam flooding desirable traffic.
The problem isn't a technical one. It's a social one: The cost of individual messages is very low, especially if the resources to send them are stolen. And the consequences of sending them in bulk are, so far, insufficient to discourage the spammers or the professionals who provide them the tools. Even though spam seems to be rarely profitable, the _expectation_ of profit is enough to lure numerous hopeful or larcenous participants. Prosecutions remain rare, and the upstream providers seem happy to take the cash since they so rarely face consequences for hosting professional operations, and the newer zombie nets are too expensive to bother cleaning up.
There have been legal attempts to reduce spam. But spam is built on such a classic business model, that of junk mail, that any legislative effort runs headlong into the Direct Marketing Association and their lobbyists, or the equivalent in other countries. As individual technical fixes are applied, other versions of spam services expand to quickly fill the economic niche. So unless the technologically based approaches or the social approaches such as reasonable laws get so effective that the _apparent_ profit is eliminated, we're going to continue to see the deluge.
You could just use Subversion. Look in your ~/.svn/auth/ directory for every HTTPS site you access with Subversion.
No, he didn't withhold "the programming knowledge". He withheld the passwords. Moreover, he was _already_ paid: the contract still clearly applies, unless the city actually breached the contract in some way. Forcing the city to continue to dance to his tune, without that kind of a breach of contract on the city's part, was clearly a breach of contract unless his contract was _very_ strange.
Allow me to quote the relevant portion from a sample contract below. It makes very clear that your model has no relevance to any typical IT employment situation, and this sample can be found at http://www.medlawplus.com/legalforms/instruct/sample-employmentcontract.pdf.
I. Intellectual work product. Any writing, invention, process, creative mark or other work which Employee
may make or conceive of, either alone or with others, at any time while Employee is an employee of
Employer which in any way relates to the business of Employer, shall be the sole property of Employer and
Employee shall have no rights in nor claims thereto (including, but not limited to, rights or claims accruing
under the copyright, trademark, or patent laws of any country).
Oh, dear. So when a conductor retires, he gets to take the keys to the train with him, even if they'r ethe only keys, because handing them in isn't his job anymore? No, you leave all the keys behind on your way out the door. If you happen to still have a set of keys, or other work equipment, in your home or your vehicle, you don't get to keep them because you're no longer an employee. You have to return them _precisely_ because you are no longer an employee.
Mr. Childs was mishandled: given the cost and embarrassment of this case, he should have given a written set of passwords directly to the mayor, washed his hands of it, and allowed the mayor to be the fool who shared the passwords. Given the alleged incompetence of the consultants and employees who would wind up with the vital passwords, notifying the press or the city emergency departments of the risk so that they can be prepared for system failures might also be reasonable.
Oh, dear. Does anyone else remember anonymous posting services for Usenet? We've had things like this happen before. Generally, the anonymizing services have safely ignored such rulings, but on occasion the police have shown up with search warrants for ridiculous and trumped up charges. (http://en.wikipedia.org/wiki/Anon.penet.fi)
It's a dangerous world out there. Hosting anonymous providers carries some legal risks, even if they're ridiculous and unexpected.
Until you store it on the corporate file server. Or your brand new laptop where the vendor didn't provide it encrypted and you lack 20 hours to do the re-install and downloads of patches. Or your backup tapes get stolen. Or you share client data with an FTP server because that's all your software will support. Or your corporate president refuses to let you re-image their laptop with encryption. Or some clever salesman puts their customer data on a USB stick and drops it in a bar.
These are not small issues, and encrypting a particular desktop is only the start of the issues.
No, I'm pointing out that there are circumstances where duplicate MAC addresses are useful, and as I understand it, this can create havoc for IPv6.
As long as the duplicate MAC addresses are on different subnets, so that the same router or gateway cannot see both, it's not a problem. So I can run _precisely_ the same virtualized OS image in two different locations, without having to modify the virtualized system's hosting data or its network configuration tools. There are times, though not many, when this is handy.
_Yes_. This especially includes _hosting_ of services. The ability of a few ill-behaved clients or employees to host websites or FTP or IRC or mail or torrent services, and to absolutely overwhelm resources and clutter a network is stunning. NAT has been very effective in reducing this to manageable levels in my environments. I don't want my backup server or my authentication server exposed to the Internet, and I don't want to have to write clever firewall rules to protect it.
I suspect that you've not run into some of the weirder security issues I've run into over the years. A public facing IP address is, essentially, an attractive nuisance and will be attacked. I don't see IPv6 helping this at all, but the limitations of IPv4 space and the pressure to use NAT have actually been helpful in security terms.
But it's not my problem. It's all effectively occurring on the NAT box, which is a cheap appliance and built into my cable modem box or my firewall. It's already paid for as a default feature and works fine, I don't have to do any of the work locally.
You've a good point about connection tracking, but have you seen it as an issue in the real world? I've certainly not.
Duplicate network addresses are not uncommon with virtualized clone images. Renegotiating MAC addresses as guests are cloned is a longstanding problem, and the address spaces for the guest hosts is getting tricky to negotiate and avoid accidental duplicates.